Benefits realization is a persistent need

Benefits realization is an end-to-end process, from governance and planning to change management and deployment.

So what? Flawless development and operations might be OK. But what the business really cares about is not systems, it's pay-off.

For the CIO, this creates a problem. Almost all CEOs it seems end up blaming their CIOs for failures associated with IT projects, no matter where the fault really lies. Worse yet, at first sight, this is not an unreasonable reaction from the CEO. After all, it was the IT department that actually spent the money. Looking to the same group for a payback is not unreasonable.

It is unreasonable of course. And benefits realization, if it is to be done properly, is more then just a blame game. The art of benefits realization is fundamentally an end-to-end process - from governance and planning to change management, deployment and harvesting - that involves all stakeholders, not just IT.

Planning practices lay the foundation. One of the major reasons cited by interviewees from our recent research into benefits realization was that failure to deliver benefits often stems from a failure to uncover all activities, assumptions and dependencies needed to make the benefits happen in the first place.

Benefits also have a tendency to leak away. Partial headcount reductions (for example, half a person) often "disappear", leaving the half a person behind and still happily drawing a salary. Even whole-person headcount reductions may end up with staff simply moving to "other roles", thereby evading the cost-cutting axe. With no accountability mechanism, these evaporating benefits are endemic.

Surprisingly, Gartner's research shows something interesting about benefits and project size. The reasonable person would expect that the bigger the project, the bigger the expected benefit, and therefore the bigger the risk of not achieving them. In this instance, the reasonable person would be wrong. Given how much more CIOs must worry about benefits realization from one or two "big, hairy audacious" projects, the amount of eyeball time these projects get makes benefits shrinkage less likely.

Instead, it is the myriad of small projects that cause all the bother with benefits. And if your IT shop is moving from an era of the mega project - be that a supply chain integration success or an ERP revamp - to a focus on a series of small jobs with small benefits expected from each, then you should be doubly worried. In benefits realization, it seems it is much easier to watch one 800-pound gorilla that it is to watch 800 one-pound monkeys.

How might benefits realization be improved? One method, proposed by management guru John Thorpe in his book The Information Paradox, suggests an approach that lays out, in a picture, how IT investments result in business outcomes. By richly annotating the linkage of IT activities like "Customer Prospect Database", with a business outcome like "To increase sales value and volume from new customers", Thorpe suggests that the clear documented trail of evidence from IT projects to business outcomes can later be used to track down missing benefits.

Another well tested way to deliver benefits is to bake them into mainstream management processes. For example, business benefits in a business case must be baked into budgets, headcounts, scorecards and incentives.

The process of "baking in" combines targets and timing. In a benefits realization workshop with 18 CIOs conducted in Brisbane in mid-2005, "smart-timing" emerged as a key practice - ensuring costs and benefits of projects fell into budgets in a way that maximized the perceived value of a project and minimized business resistance to it. In other words: baking in benefits into the budget cycle.

But no matter how smart the processes and tools that are used to grease the path to realized benefits, at the end of the day, success depends on people, their understanding and their motivations. Benefits realization needs a mind-set shift too.