As we have seen with project failure reasons 1 to 3, if you have a project with the wrong scope, poor requirements and the wrong target, it's business case will not rate well on "maximizing the project's value" scale.
However, the problems with the business case are greater than just the poor quality inputs.
The first problem is its timing. As a result of the poor scope and requirements definitions processes there were many projects in the 1990s that went on forever and never really got going. They were in 'analysis paralysis' but were also eating up the funds before they were formally 'approved' or funded.
To combat this unauthorized expenditure of (substantial) funds the business case was moved forward in the project delivery process. Unfortunately, it was moved before the requirements definition step. So, before the full requirements and workload of the project were known, the project and governance teams were expected to define a (fairly) accurate business case.
This is the equivalent of trying to estimate the cost of a house before you've even decided what it will be like. Two results can occur. The first is, to allow for the many unknowns, the cost is bumped up as far as the benefits/ROI will allow. (As few organizations have an effective benefits tracking process the benefits can also be bumped up as well to cover increased costs with little fear that you'll be held accountable for their non-delivery at the end.)
The second result is that the original estimate is underestimated, resulting in "increases in the project's budget" or the project being seeing to come in "over budget". No matter how many caveats accompany an early estimate of the project's cost, management (and stakeholders in general) only remember the original estimated figure. All upward revisions are then put down to a project 'out of control' or poor project management, rather a faulty estimate made too soon in the process.
This early timing necessarily makes the numbers unreliable. Most project managers will over-estimate to give themselves some room to manoeuvre during the project. However, once this figure is approved it then becomes the budget to be spent (not the maximum amount allowed).
The effectiveness of the business case depends on several elements — the quality of the work to date (which we've seen is usually poor), the quality of the data available for estimating (which we've just seen is often missing), the presence of financial standards so all proposals can be compared (surprisingly often missing) and the presence of a benefits management process to ensure the benefits claimed are delivered (currently rare). Without all of these elements the business case is often not really worth the time to evaluate it.
Which brings us to the other dimension that is usually assumed to be present but is rarely in place — knowledge of how to effectively evaluate project business cases/proposals.
In a recent review of several approved multi-million business cases in one major organization we found that 87 percent should not have been approved. The business cases themselves gave the clues that the project off the rails, the solution was inappropriate, the need for the project was missing, and so on. However, all these pointers were missed by those evaluating the business cases.
Critically evaluating project proposals/business cases will often not win you friends as it puts the onus on those proposing the project to actually do the work properly and spell out exactly why the organization should invest in this proposal (rather than do nothing or choosing other projects).
Poor evaluation lets poor business cases through. This, in turn, encourages sloppy business cases and the loss of project value resulting in the approval of unworthy and doomed-to-failure projects.
Some project managers see they have a vested interest in poor business cases as it can ensure their project is approved and their job/role is secured. But, when an end-to-end benefits management process is in place to measure the success and achievement of the desired business outcomes and their associated benefits, the project manager (and Sponsor) tend to be more careful in the generation of the business case.
While people can get lost in the detail of the business case format, a well designed business case format (a rarity in itself) should help the project team define exactly why the organization should invest in the project, what it will get in return for the funds and other resources invested. This should then become the driving force of the project (but is rarely so, as we'll deal with later in this series).
Join the CIO Australia group on LinkedIn. The group is open to CIOs, IT Directors, COOs, CTOs and senior IT managers.