Chapter 8
Documenting the Business Case for Your Programme
In This Chapter
Understanding the role of the programme Business Case
Knowing what goes into a Business Case
Tracing the life-cycle of your Business Case
If this chapter was an Agatha Christie story, perhaps detective Hercule Poirot would start by saying: ‘Mesdames and messieurs, I ‘ave gazzered you ‘ear to uncover ze mystery of ze Business Case.’
Zis – sorry, that's enough of that – this chapter covers the Business Case for a programme, including its composition and how you use it as a communication tool and update it throughout the life of the programme.
The purpose of a Business Case reaches beyond simply justifying the programme, as you'll discover in this chapter. If you're familiar with Business Cases, say from project management, you're sure to find the ideas in this chapter pretty straightforward.
Introducing the Case of the Business Case
The purpose of a Business Case is to:
- Validate initiation of the programme
- Demonstrate the on-going viability of the programme
In plain English, that means you can use the Business Case to check that you're starting the right programme and show that the programme has a good chance of being successful.
What's more, the Business Case links to the following principles:
- Focusing on benefits and threats to them
- Adding value
A prime reason behind creating a Business Case is that it allows you to answer questions such as:
- Is the investment in the programme (still) worthwhile?
- Do you have the best mix of information to decide whether the programme is desirable, viable and achievable?
- Have you identified the following:
- Added value of the programme over and above that of the project (for the distinction between programme and project, see Chapter 1)?
- Programme costs above projects’ costs?
- Have you described the value to the organization of the outcomes?
I think of any Business Case as comprising costs, benefits, risks and timescales, and a little more as well. The order of the sections isn't fixed, but you're trying to tell a story. You might start with the options and then describe the chosen option in detail, or describe the selected option from big picture down to detail, ending up with the options to be rejected. The aim is to make the Business Case compelling and rigorous. The following sequence usually works for me:
- Strategic programme objectives
- Expected benefits or outcomes
- Confirmation that you have the capability to achieve transformation
- Overall risk profile
- Assumptions that can affect costs and benefits. For example, if you're moving into new premises you assume you can sell the old offices for a certain price.
- Costs and timescales
- Investment appraisal (check out the very next section)
- Forecasted cash flow
- Options that have been considered. Usually you include a ‘do nothing’ option along with a few options on what you could do. After you've selected what you want to do, you can then look at options on how to achieve that Vision.
Including an investment appraisal
The finance director, or equivalent, probably has a standard spread sheet template for how to show costs against financial benefits over time. Including the dry financial facts about your programme is pretty normal. This is known as an investment appraisal.
An investment appraisal enables you to objectively summarize the financial facts about your programme. If those facts are presented in this same style for your programme and other investment opportunities in the business, members of the Sponsoring Group find it easier to compare investment choices. So including a nice clear investment appraisal in your Business Case is in your own best interests.
An investment appraisal enables you to calculate the cumulative net benefit of the programme; in other words, the costs and the benefits over time. (For example, if I spend £10 in year 1 and get a benefit of £6 in year 1 and £6 in year 2, at the end of year 1 the cumulative net benefit is –£4, but at the end of year 2 the cumulative net benefit is +£2.)
Figure 8-1 shows costs against financial benefits over time. You can add up those figures to calculate the cumulative net benefit.
Figure 8-1: Cumulative net benefit.
Looking at different types of cost can be helpful when showing others where costs arise and so where the programme focuses its efforts. You can find these costs in the different documents you create during the Defining a Programme stage. Table 8-1 summarises the type of costs and which documents you use to find them.
Table 8-1 Types of Cost
|
Type |
Description |
Documents Where You can Find these Costs |
|
Project |
Cost of acquiring and delivering outputs. |
Project Dossier Programme Plan Project Business Case |
|
Benefit realization |
Implementing, measuring, monitoring and reporting benefits realization.Cost of realizing benefits. |
Benefits Management Strategy Benefits Profiles Benefits Realization Plan |
|
Business change and transition |
Supporting operational units until new practices are embedded. |
Programme Plan Resource Management Plan Benefits Profiles |
|
Programme management |
Programme roles plus the on costs. |
Resource Management Plan Information Management Strategy Programme Communications Plan Quality and Assurance Strategy. Programme Plan |
|
Capital |
For fixed assets. |
Blueprint |
Note that on costs in Table 8-1 are the costs over and above a person's salary. For example, they include accommodation costs and the cost of providing employees with IT.
Examining the net benefit line and stakeholder engagement
When you plot the cost information from the preceding section onto the graph in Figure 8-1, the net benefit line becomes a powerful tool for engaging stakeholders. For example, it can give evidence of early financial benefit realization, it can communicate the breakeven point and it can show benefits that still need to be realized after the programme closes.
By the way, if you're running a compliance programme (which I define in Chapter 2), you may need to express financial benefits as ‘avoided costs’.
Be careful: by producing an investment appraisal you've reduced the benefits to a monetary equivalent. Sometimes, doing so is entirely valid and certainly makes comparing options more straightforward. But as you convert intangible or indirect benefits to an equivalent monetary value, you run the risk of severing the link with stakeholders who are interested in those benefits (check out the nearby sidebar ‘The bottom line isn't the be-all and end-all’ for an example).
If creating an investment appraisal is a little difficult, ask for financial advice and try to get a finance person seconded to the programme management team.
Following the flow of the Business Case
Figure 8-2 contains an elegant diagram that illustrates the relationship between various documents that feed into the Business Case.
Figure 8-2: Related flow of the Business Case.
You start with Vision which leads to the Blueprint. You then have two loops that you go around again and again:
- Benefits Map: Describes, surprisingly, the benefits! It's fleshed out in the Benefits Realization Plan.
- Project Dossier: Shows projects at high-level. It's expanded upon in the Programme Plan (I discuss both in Chapter 7).
Carry out regular cross-checks to make sure that all these documents are in alignment. The two loops – costs from the Programme Plan and benefits from the Benefits Realization Plan – come together in the Business Case.
If the Business Case isn't viable, you have to go round those two loops again. You need to revisit benefits, revisit the costs and, if doing so isn't radical enough, you may have to revisit the Blueprint in order to envisage a different future state, which has a different set of benefits and a different set of costs. Figure 8-2 is a useful little model for getting your mind round the Business Case.
Reviewing and Communicating the Business Case
In this section, I lead you through reviewing your Business Case and describe the people involved in managing it.
Assessing the Business Case
When you're reviewing the Business Case (around the Defining a Programme process or subsequently, perhaps, at a tranche boundary; check out Chapters 7 and 18, respectively), here are the sort of questions you're trying to answer. Some are at a very high level and some are pretty detailed:
- Is the programme still affordable?
- Does sufficient funding exist?
- Are the outcomes still achievable?
- Can the organization cope with the change that it has to deal with?
- Is the programme still value for money?
- Are the costs and benefits in balance?
- Have you considered and updated the options?
- Is the Project Dossier still optimal?
- Is the programme still justified?
- Will it still meet strategic objectives?
- Do you have contingency plans and the money to pay for them?
- Do they cover a wide enough range of risks and uncertainties?
Meeting the key players
Here are the areas of focus of the various roles in the programme management team for creating and communication the Business Case. I cover roles in more detail in Chapter 9.
Taking overall responsibility: Senior Responsible Owner
The Senior Responsible Owner (SRO) is the senior individual accountable for the Business Case. This person approves it and must ensure that it's monitored, reviewed and updated. Here are the SRO's main responsibilities:
- Answering to the Sponsoring Group for the successful delivery of the programme and achievement of the Business Case.
- Securing investment for the programme.
- Ensuring that the Business Case is controlled and audit trails are in place to account for changes as the programme develops.
- Scanning the business horizons surrounding the programme for issues that lead to realignment of the programme in some way.
- Ensuring that the progress of the programme remains aligned with the Business Case.
- Consulting with the Sponsoring Group to identify any early-warning indicators of change that may undermine the Business Case or cause it to lose strategic alignment.
- Initiating independent assurance reviews of whether the Business Case is still viable.
Running day-to-day: Programme Manager
The Programme Manager operates the programme on a daily basis and may have a Financial Controller or Programme Accountant who helps with the following tasks:
- Preparing the Business Case.
- Supporting the SRO in the on-going validation and review of the Business Case.
- Managing the programme's expenditure against the overall investment defined in the Business Case.
- Identifying opportunities to optimize the Business Case.
Implementing in the business: Business Change Managers
Business Change Managers achieve change as their part of the business. Their primary focus in terms of the Business Case is management of benefits, but in addition their job is:
- Profiling the benefits and dis-benefits and their associated costs.
- Ensuring that benefits continue to be valid through regular Business Case reviews.
- Ensuring that the full cost of change is being captured in the Business Case.
- Identifying operational risks to the Business Case and ensuring that they're controlled.
- Measuring benefits at the start of the programme and tracking throughout, to feed into the net benefit line (see the earlier section ‘Examining the net benefit line and stakeholder engagement’).
- Managing business change costs.
- Managing benefits realization costs.
- Realizing the profiled benefits.
Administering: Programme Office
The Programme Office looks after the administration of the programme and is responsible for:
- Supporting the SRO and the Programme Manager in compiling and updating the Business Case.
- Collecting and maintaining Business Case information.
- Facilitating Business Case reviews.
Observing the Business Case across the Life of the Programme
This section is sort of like a David Attenborough programme, where you get to see the details of the life-cycle of a Business Case. Take a look at Figure 8-3 and don't worry, it's not too icky!
Copyright © AXELOS Limited 2011 Reproduced under licence from AXELOS
Figure 8-3: Life-cycle of a programme Business Case.
You don't just write a Business Case at the beginning of the programme and then leave it in a filing cabinet gathering dust.
Defining the Business Case
After the Sponsoring Group agrees to meet the Mandate by starting the programme, the SRO creates the Programme Brief, which includes an outline Business Case (I provide more on that subject in Chapter 3).
The Sponsoring Group's approval of the Programme Brief triggers the Defining a Programme process within the transformational flow, which I discuss in Chapter 7. During Defining the Programme you identify outcomes and projects, which allow you to describe the benefits in detail. From those programme projects and from your benefits, you can extract cost and benefit information to put into the Business Case.
Revisiting the Business Case
You update and review the Business Case at each tranche boundary, but it may happen at other times during the programme. (I describe the end of one tranche and the beginning of the next in Chapter 18.)
You have to update the programme Business Case for two broad reasons:
- Because the external environment changes
- Because more is known about the internal environment: that is, the costs and benefits to date
Recognising the need
The Business Case stems from the identified strategic need: in other words, the big picture reason why you need to do the programme in the first place. That need is expressed initially in the business drivers, clarified in some form of business strategy and then crystallised in the Programme Mandate (drivers are the triggers that cause you and lots of other people to change; see Chapter 3).
Validating the Business Case
Take a look Figure 8-4, which shows how the Business Case evolves and what it's used for during each of the processes in the transformational flow.
Copyright © AXELOS Limited 2011 Reproduced under licence from AXELOS
Figure 8-4: Validating the Business Case.
Initial Business Case
During the Identifying the Programme and Defining the Programme processes (see Chapters 3 and 7, respectively), you need to test the emerging Business Case continually. Ask if the programme is still justified and whether you've considered enough options. You need to do so several times during these two processes.
Tranche boundaries
At a tranche boundary, you can ask whether you have historic evidence and a valid future projection. Do the costs and benefits to date mean that the programme is viable today and in the future? You learn from experience by recalculating figures and asking whether the programme is still the best possible programme that you can be running.
You want to discover whether the programme will realize the expected benefits and whether changes to the cost–benefit profile (the net benefit line; see the earlier section ‘Examining the net benefit line and stakeholder engagement’) are going to alter the status and relative priority of the programme when related to corporate objectives.
You can assess a few other things as well:
- What's the impact going to be of accommodating any strategic change or change business driver?
- What about proposed revisions to the programme's boundary and Blueprint and what will be the impact?
- What about the impact of revised benefit and cost estimates from the Business Change Managers and projects; or the impact of major new issues or significant new risks?
You need to answer all these questions in the Business Case.
Closure
At the end of the programme, you need to ask whether you succeeded. In other words, did you achieve the initial and updated Business Case and what lessons can you learn to share with future programmes?
Deciding when to close the programme
When discussing the Business Case you can reflect on when the programme may close. Although costs and benefits continue to accumulate after the end of the programme, it's still an interesting discussion. For one reason, a quick analysis shows that the programme closes some considerable time after the final delivery of the full capability, because benefits still have to accrue.
One useful definition for the end is ‘when sufficient transition is achieved from old to new’. Another view holds that the end point is when changes are so embedded that the target outcome has been achieved again (quite useful if you have an outcome model).That could be in the Blueprint, which I describe in Chapter 6 or something you produce when modelling benefits, which I discuss in Chapter 15.
Personally, I use a simple but powerful test to determine when to close the programme. The last thing to flow is the benefits. Therefore, when benefits management is embedded in the business and is carrying on without any intervention from the programme, the programme has no more work to do. So that's when it closes.
If you're working in a programme, review your Business Case using the questions I pose in this chapter. Consider checking detail such as the composition and the types of cost.
If you aren't currently in a programme, look at a project Business Case you're familiar with and ask yourself what else you'd add if your project was being run as a programme.