Project Management

What goes in a full program business case?

From the The Money Files Blog
A blog that looks at all aspects of project and program finances from budgets, estimating and accounting to getting a pay rise and managing contracts. Written by Elizabeth Harrin from

About this Blog


Recent Posts

5 Things to Consider When Choosing Training Firms [Infographic]

Agile Finances on Projects: Cost and Procurement Management

What are Present Value and Future Value?

Aligning Strategy to Value [Video]

Agile Finances on Projects: Schedule Management

Categories: business case

Earlier this month I looked at what Michel Thiry says is important for a preliminary program business case, according to his book, Program Management (Gower, 2010). Today I want to look at the things you would include in a full program business case.

Let’s say that your preliminary business case has been approved by the powers that be. Now you have to put together a full business case for the program. This may be subject to further approval. Here is what he says needs to be included in the document at this stage.

Stakeholder analysis

Carry out a full stakeholder analysis and include it in the document. You should also put in a stakeholder engagement plan – this shows how you will work with and communicate with all the different stakeholders that have been identified as part of the analysis. What’s different about a program business case is that this piece of stakeholder work should also include which benefits relate to which stakeholders. In other words, who is gaining what from the program. Your program marketing strategy can also go in here, although Thiry says that at this point it only needs to be a high level marketing plan.


Review the scope again and make sure that the final version is accurately reflected in this document.


Your preliminary business case would have included some costs, but this is the place to document the program’s baseline budget. You should also specify where the money is coming from. If you can’t plan the budget for the whole program, do it in stages and only include the detail for the first stage.

Organisational structure

By this point you should have some idea of who you need on the team, so this is the place to put in an organisational chart. Thiry recommends showing the decision makers and communication channels here too. This is also a good place to list the roles and responsibilities of the people involved in the program. You can link this to show who is responsible for benefits and delivering to the critical success factors or key performance indicators.


Document all the links to other programs, projects within programs, other business activities, and (although Thiry doesn’t specify it) things happening outside the company such as regulatory changes.

Transition plan

This is specific to a program as you probably wouldn’t need one of these on a project. This specifies the work required to properly integrate the outcomes of the projects into the program and embed the new capabilities in the business.


This is a fancy word for timescales. This should show when the benefits are likely to be achieved and the key program milestones, taking into account when resources are available.


Write down the governance structures that the program will abide by. This could include reporting schedules, dates for audits, approach for peer reviews and what criteria will be used to assess whether the program is performing effectively. Change management also fits in here. I would have thought that you could simply reference existing company change management processes but if you have to put together something specific for this program, this is the section to spell it out.

Task listTask list

Here is where you list the activities and projects that make up the work to do for the next stage. It doesn’t matter if you can’t predict all the projects and tasks required going forward, but you should at least know what’s coming up in the next stage. Thiry says this is the point where you identify (and, I suppose, seek approval for) the projects that make up that stage and prepare the relevant project charters.

That’s it. That still seems quite a lot, but if you don’t know all this information, then you can’t really move forward effectively with the program. It seems to me that this gives you more than just the business justification – in effect, it also covers a lot of what you would expect at charter stage, if we compare this to managing projects.

Have you ever worked on a program? What documentation was in place before it started or moved to the next stage?

Posted on: June 28, 2013 09:51 AM | Permalink

Comments (2)

Please login or join to subscribe to this item
Hello Elizabeth, I am wondering if the contents you included is more like a charter than a business case. Whether for a program or project, I tend to think of a business case as a method of achieving funding and support. Although items like scope, budget and the like are included to frame the resulting program, an analysis of the alternatives and outcomes should be included to make it a true business case (in my opinion. In addition to stakeholder analysis (which I totally agree) and in environmental study can be included which includes opportunities, threats, etc.

I like your question at the end and hope others will also comment. I am currently working on a large multi-year program and yest a business case was put out before embarking. The program was to replace infrastructure and involves civil work on about 25 sites, technology up grades, and a small software component. The business case included all the elements you described above as well as a study of potential options/vendors and an analysis of ongoing cost implications. Once the approved, the program moved to a RFP phase that lasted about a year. The business case was not updated after the RFP (but probably should have) but the charter was finalized and the capital budget plan and resource plans were updated and reapproved.

Thanks, Michelle. I think you are right, that an options appraisal should certainly be included. I wonder if Thiry didn't include it in the book because that would work for projects, but for programs maybe they can be more 'conceptual' and lean towards business change as the outcome rather than the delivery of a specific product. Although, as your example proves, you can include an options appraisal in a business case for programs as well. For projects, I would definitely include an options appraisal, with a short bit about the options that were rejected and more detail about the one we decided to go for.

For the program I worked on most recently we had a business case (which didn't have a lot in it, to be honest), procurement paperwork like RFI's, proposals and vendor comparisons, a really detailed budget and a very high level scope document. I think that was it. Then we put the other documents in place as we went along. One of the most useful documents was the ToR for the steering group as it helped to keep them focused on the right discussions!

Please Login/Register to leave a comment.


"I would have made a good Pope. "

- Richard M. Nixon