Every business case for a new IT system must identify and argue for resulting benefits. Benefits management is a well-established competency for ensuring benefits are identified, quantified, tracked and realised. Realised benefits justify the initial investment. Victoria’s State Treasury, which funds some very large IT projects, including a number that have gone off the rails has started providing much-needed guidance on identifying and planning for anticipated system benefits. In light of continuing problems with large public sector IT projects (Queensland Health payroll system, Victoria’s licensing system) this is important capability-building.
But it is not the full picture. Getting benefits management right at the start is of no lasting value (beyond getting the business case approved) if no-one is accountable for benefits realisation after project delivery. And it seems not many are, at least not consistently.
This is a bit like never looking at financial statements to see how your superannuation investment is performing — and then getting a nasty surprise when retirement nears.
One reason may be that benefits tracking over many years is inherently difficult due to the cross-cutting changes in the organisation and business environment. Organisations are open, social systems, and without getting too post-modern about it, cannot always be held to strict cause-and-effect analyses. That said, many of the kinds of benefits that proposers write into business cases are measurable, regardless of soft, contextual factors — EFT reductions due to elimination of redundant data handling or process automation, for example. And every good business case template calls for bankable (quantifiable) and qualitative (soft) benefits.
More starkly, executives are typically not held accountable for realisation of the benefits they claimed would be delivered in their initial business cases. Further to this, the rate of executive churn outpaces most large investment’s benefits realisation timeframes, allowing the executive who makes the commitment to quietly slip the noose.
This problem could be addressed by tying benefits realisation objectives and plans to the role, not the person, so that the incoming executive knowingly adopts the obligations of her predecessor, rather than throwing everything up in the air and selectively catching only the more palatable things — as is common practice. This is routinely done in other industries — healthcare professionals perform ritualised hand-over at shift boundaries (where the option to ignore problems could be fatal). There is no reason why accountability transfer could not be adopted by business executives, other than a collective desire to preserve wiggle room.
Examples of enforced benefits realisation in IT projects can be found. One account describes how a business project owner was required to book the agreed benefits to their plan (in other words, a claimed reduction of 3 FTEs translated literally into removal of 3 FTEs from the operating plan by a given date). If you can measure quantified benefits you can even automate the whole game and run an enetrprise wide benefits realisation dashboard.
Examples of accountability transfer (from outgoing to incoming executive or manager) in IT projects are rare. Thomas Paine, independence propagandist of the American Revolution, understood accountability in the context of big undertakings:
Those who want to reap the benefits of this great enterprise must bear the fatigue of supporting it.
Improving our ability to realise benefits may substantially depend on getting accountability right over the long term, beyond personnel changes. And that’s a cultural change.