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.
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.
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.
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.
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?