Then it struck me – this is all the wrong way around! Granted, I usually examine benefits in front-line (health and care) environments not in back office functions, but many of the enablers are back office.
Nobody at the event asked “didn’t we already know why we wanted this, before we designed it?”. Instead of starting with the need and creating the solution to solve it, we appear to take the solution as the fixed item and look for ways to justify it after the event. If we knew why it was wanted, the benefits design, planning, management and realisation would be simple: does it do what we want it to do?
So start with the need. What is the problem that needs solving (insufficient resources to meet demand, waiting lists too long, costs too high, demand for different services, administration ineffective, people’s safety privacy and respect threatened)? What is the whole of the solution that IT is only a part? What about the IT solution proposed (or mandated) actually solves the original problem, in conjunction with other (workforce, service transformation, facilities change) components?
Build a benefits profile around this. IT solutions can’t deliver benefits in isolation, and nor can most of the other components of the solution. The solution is in response to a need, so the benefit is resolving the need. Monitor progress towards resolving the need, and you have your benefits realisation. Measure something specific to the IT project, and you run the risk of becoming divorced from the whole solution and benefits not realised.