A Core Management Tool: the Business Case
There are three principles to keep in mind with business cases. One, a business case in a living document that will grow (in accuracy and detail) over time. Two, cross-functional participation and input (especially from stakeholders) strengthens business case accuracy and credibility. Three, the business case’s job is not over once the project is approved.
A Living, Growing Document
Business cases grow over time. They can start with a payback calculation on the back of a napkin during a business lunch. That simple calculation will raise questions that need to be fleshed out (like how’s that compare to the company’s hurdle rate). Then you make a list and start to work. All of this will items in your business case. So the best way to start a business case is with an outline of the major sections. Some will be blank at first. As you work it over time, those blanks get filled in and others may be added.
There are plenty of example outlines around for business cases. Since each prospective project will vary, likewise there is no one-size-fits-all business case. I’ve found that you just need to pick one and then be ready to customize. My favorite outline is:
Executive Summary
Problem Statement or Objective (including Background)
Enablers and Constraints in Reaching the Objective
Option Exploration and Selection
Financial Analysis of Selected Option
Project Approach
The Projected Revenue (Market Forecast or Dollars Benefit Based on Expected Production Volume)
The Projected Costs: One Time and Ongoing
Cash Flow
Expected Return on Investment (ROI) or Internal Rate of Return (IRR)
Sensitivity Analysis
Risk Assessment and Mitigation (including actions if there are changes in ROI or IRR
Project Description
Organization (Departmental Participants)
Schedule
Governance
Progress Retorting
All too often I’ve seen business cases start to collect dust after the project go-ahead. Projects moved to completion even after changes in business environment or technology obsoleted the original value proposition. Best Practices for major projects (like large capital projects) call for a periodic review of the business case throughout the project life cycle. Generally speaking, the phases in a project life cycle are Initiation, Development, Design, Construction, and Commissioning.
The calculation and questions from the back of that napkin feed the Financial Analysis in Initiation. This phase calls for an Order of Magnitude cost estimate (± 25% to ± 75% depending on your company’s policy). This is the basis for an initial elimination of weak projects at the first Gate review before going further on into Development. An Order of Magnitude estimate requires minimal effort before applying ever increasing levels of detail and effort in later phases.
Having passed the first Gate review, the project goes into Development. Greater levels of effort are applied to building the business case. Project participants increase. Stakeholders get involved. Alternate options to address the problem are explored and selected. A project is designed using the selected option.
Now a Budget estimate is applied (± 25%). The Gate review is conducted. If the IRR meets or exceeds the targeted IRR, the project, and its business case, moves to the next phase: Design.
The business case is continually updated and reviewed at the project Gates. New information updates original. Depending on the nature of a project, a project can be suspended or stopped if new information comes to light that drops the IRR below the hurdle rate. At a minimum, there should be risk assessments during reviews when the financials or other key factors go south. The business case is the central tool throughout.
Cross-functional Participation
At critical reviews, functional representatives will pass judgement on the project based on their perspective on the business case. Finance, Engineering, Human Resources, Marketing, QA, HSE, and Operations will have a say in whether or not the project should go ahead. It is far better to involve them before the big presentation rather than during. You’re better off knowing what they’re going to say going into the approval meeting rather than during.
That being the case, involve each functional group (preferably the representative) in developing that part of the business case on which they will pass judgement. A stretch goal is to have them present their part of the business case during the approval meeting! At a minimum your business case will include those elements, and their data, they’ll be looking for in approval.
Life after Project Approval
It seems that the widest spread practice for business cases is to leave them in a dark archive after project commissioning and turnover. We’ve seen where this practice leads to a history of questionable projects. The organization never returned to the business case to see if the project performed as described in the approval processes (at each Gate review). The organizations suffered from overly optimistic revenue and/or cost projections but never took corrective action.
Again looking at Best Practices for project and program management, each project should conduct a Lessons Learned after a project is completed (up and running, handed off to the “customer”). The Lessons Learned should include an assessment of forecast accuracy. Forecast accuracy includes that for revenues, production volumes, gross margins, implementation costs, and IRR. Any significant findings should be used proofing forecasts on future projects.
