CIO brings you an ongoing series on project management from Jed Simms on a vital component of any project: the business case.
Central to the business case is the value proposition — what value shall the organisation get from investing in this project? This may sound obvious but the value proposition is often largely missing in most business cases because they’re the result of upside down thinking.
In most business cases there is much discussion about the cost; and the benefits are seen as the off set to these costs so as to create a positive (or passable) return on investment (ROI). So, the project’s benefits are buried in a section entitled, “Cost/benefits”. Provided the benefits’ financials are acceptable the project is approved. This approach completely misses the point of projects (which is to deliver, enable and support the realization of the business benefits) and inadvertently frequently ensures the benefits are reduced to just those needed to generate the requisite ROI.
Your business case should spell out its value proposition, in terms of (using The Value Equation™ approach)
1. The business outcomes/end states to be delivered. These are (or should be) any project’s primary measures of success. This is where we’re going to get to in business end state defined (and measurable) terms.
2. The associated benefits. Outcomes deliver or enable the delivery of benefits. Benefits are consequential on the successful delivery of the business outcomes. Diminished outcomes results in diminished benefits. Simple. Every benefit must be linked to its enabling/delivering outcome.
3. the financial values (where appropriate). Only some benefits will be financially quantifiable; however what is important here is that the bases on which these financial benefits are quantified are known and trackable throughout the project; so that any changes in these value drivers can be monitored and the financial viability of the project recomputed at any time.
4. The outcomes/benefits delivery roadmap. The timeframe when the outcomes and their associated benefits will be delivered (and their interdependencies and delivery sequence). This is when and how you’ll get this value.
So, your business case should spell out the outcomes, benefits and value that will be delivered. Just having some series of numbers masquerading as ‘the benefits’ is woefully insufficient.
This simple approach provides the measures of success (each element should be measurable to verify its achievement), enables simple progress tracking (outcomes deliver benefits and then some benefits have a financial value that can be recomputed at the time of realisation) and ensures no benefits are claimed that cannot be delivered. (The most common complaint with our value proposition generation is process is that it generates “too many benefits!” — now that’s a nice problem to have.)
For the integrity of your business case it is important that no spurious benefits are claimed. On a recent project one manager was adamant that “Reducing financial errors” was a key benefit; but he could not point to any project outcome that would do anything to reduce any financial errors if they existed. The benefit was deleted.
The value proposition is the Project Sponsor’s commitment to the organisation — “this is what I will deliver through the project/program”. This is also the Sponsor’s measure of success so they need to ‘own’ it.
At the end of this section you need to have established:
A) The business value of this project in outcomes, benefits and value terms — is it worthwhile?
B) The consequential ROI/NPV or alike.
How does your business case process compare? Tell me: Jed_Simms@capability.com.au
Further support and useful tools to help you manage your investments, projects and portfolio are available from .
To view the first article in this series, click here.
To view the last article in this series, click here.
Join the CIO Australia group on LinkedIn. The group is open to CIOs, IT Directors, COOs, CTOs and senior IT managers.