Realizing Benefits Realization

For the better part of the past 20 years John Thorp has been beating his head against a very hard wall and he just doesn’t seem to be getting through. Maybe it’s the definition of insanity to continue, but Thorp believes in his cause.

At 63, he is the chairman of the IT Governance Institutes’ (ITGI) newest initiative. Called Val IT, ITGI is an attempt to get business people to realize the value of IT has nothing to do with IT and everything to do with the business. It’s all about benefits realization; whether a project delivers the business benefits its creators set out to deliver.

For myriad reasons, most companies never know. It is this situation Thorp keeps trying to change.

“My frustration is I have been talking about this for 20 years and … we don’t seem to be learning,” said Thorp. “Not a month certainly, not a week goes by without reading an article that someone says ‘We implemented (Technology X) and at the end we realized it wasn’t about technology it was about change’. Well, how many more times do people have to read this before they get it?”

There are two main reasons why most companies continue to struggle with benefits realization. Foremost is most projects never have a clearly defined business case attached to them. This means there are no benchmarks from which to make before and after comparisons, to see if a project was successful in meeting its goals.

The second reason most companies fail to know if projects ever really pay off, is they don’t look, said Tim Jennings, research director at the Butler Group, an IT consultancy and author of The Ten Axioms for Measuring IT Cost and Value.

“The difficulty there is if you take the view of the project from proposal through to go-live date … people say ‘We’ve committed X dollars to this year’s initiative and you get to go-live date with a wing and a prayer and you come in close to budget and you put a tick in a box.”

And after that you move on. It’s human nature. Once a project is completed it’s easier to move on the next project. Budgets are spent, the work is done (hopefully), it’s time for a drink, a pat on the back and a “Job well done” for everyone.

“This is particularly relevant because usually once the money is sunk it’s not like you can change course and you’re not getting your money back,” said Erik Dorr, a senior business advisor at the Hackett Group, which looks at world-class company’s best practices and documents them in its Book of Numbers research series.

But that approach, although the most common by far, misses the whole point of doing Project X in the first place: solving a business problem. After all, not a single IT project would ever happen if there wasn’t a business-driven need.

While there are no one-size-fits-all best practices per se to finding business value like ITIL for service management or CoBIT, human nature probably plays a bigger role in the benefits realization game than any other factor.

What Hackett has found in its research is the few companies like Intel that do consistently look back at projects to see if they actually delivered any value stick to the basics. They look at the problems they want solve, agree on the metrics that will indicate a solution has worked and then go back to see if said solution did the trick. At the core of Intel’s process are metrics called business value dials, which “represent the common language for identifying the value IT solutions deliver.”

“What Intel is doing is not rocket science,” said Dorr. “It’s pretty much the basics.”

But, of course, the basics, which always seem so easy to understand and yet so hard to put into practice, are where most people fall short. Complexity can be exotic and therefore exciting, but the “basics”? Not really.