User Involvement Key to Building Effective Business Cases for IT

Torture rack

Is this what getting business approval is like?

Done well, they can mean the difference between success and failure of IT projects. Done poorly, they can lead to failure, “delusional optimism” and even hamper IT’s room to innovate.

The comments came from Prof. Joe Peppard at an Irish Computer Society (@IrishCompSoc) talk on Building the Business Case for IT Investments.

A well-done business case not only contains solid data but has already secured stakeholder approval, Peppard said. Very often, IT projects are well put together with the  latest methodologies and draw on impressive data sets, but the first the end-user community hears about them is after the project has been signed off by the senior management team, he said.

Little involvement with stakeholders will lead to low levels of buy in, Peppard said. After all, people will ask, “What’s in it for me?”

Drawing on his academic work, Peppard said business-case approval processes can be flawed.

  • Is it a game? Are cases drawn up with a view towards beating out others to win budget share?
  • Is it a torture devised by Accountants to make people go through a process? (waterboarding pic)
  • Or, ideally, is it a business tool used to get value?

Despite their potential, however, Cranfield’s surveys of European businesses show shortcomings. While 96% of those surveyed require a case, 38% said business benefits are usually overstated and 65% expressed dissatisfaction with their ability to deliver benefits.

One problem is that business cases are used to get funding. But once that happens, “they are parked and never seen again,” Peppard said. Management should be demanding rigorous assessment during and after IT projects, he said.

Another problem surrounds “delusional optimism” around new projects, Peppard said. This is when there is a benefit is either oversold or there is a belief technology can be a cure-all for organizational problems. Citing Lee Iacocca on the amount of projects he had approved that promised savings and staff reductions, the former CEO is reported to have said,

“I have signed so many projects that by I should have nobody left.”

Peppard cautioned to distinguish between benefits and value in IT projects. A robust business case will: Enable priorities to be set, identify how the combined IT and business changes will deliver value, ensure commitment from business managers, and create a basis for project review.

Peppard also asked if scope creep is necessarily a bad thing. But Peppard took the view that the business case is a “living document.”  “As soon as it’s approved, it’s probably out of date,” he said. “It does what it says on the tin, but the business has moved on.”

Although it requires a good deal of work, Peppard suggested building a benefits dependency network (BDN) to map out the relationship between IT and the business benefits that arise from technology. BDN’s were developed by Peppard and consist of:

  • Investment Objectives
  • Benefits
  • Business Changes
  • Enabling Changes
  • IT Enablers.

It is intended to highlight cause and effect, and interdependencies. “It’s a powerful tool, but it’s not easy,” Peppard said. But if the network is thought out, it will show IT and business managers what their role is in projects, he said.

Summarizing the importance of building business cases, Peppard said:

  • If you don’t do one, your project will be designed to fail.
  • Build a BDN. It will take time, but it is better to sort out the problems at the planning stage than after implementation.
  • Remove the game from investment decisions.
  • A business case is a repository of what you know at a given point.
  • A business case is “wrong” the moment it is approved.
  • A business case is a living document.

Photo from the Torture Museum in Amsterdam courtesy of Sandeep Thukral on Flickr.