Categories: business case
In his book Program Management (Gower, 2010), Michel Thiry looks at the elements that make up a business case for a program. In the first instance, you start off with a preliminary business case. A full business case can come later, when you have worked out whether there is enough justification to pursue the work. Here are the elements that he says are essential for that early business case.
Justification
Why are you doing this program? This should include a statement of the problem.
Objectives
As with a project business case, set out the objectives for the program. This should include the high level scope statement and something about the timescales for the program.
Classification
Depending on what system your Project Management office uses to classify programs of work, specify the classification or category of program. This could be something like ‘compliance’ or ‘continuous improvement’. I think that if you work in a small company you may not have enough programs running to bother to include this.
Strategic contribution
This is the section where Thiry says you should include the critical success factors. Specify how the program will contribute to strategy and deliver something to meet the critical success factors at a strategic level.
Achievability assessment
What a great section! Apparently, this is where you include a statement about whether the program can be achieved. He concludes that it is a subjective assessment at this point but that you can base whether or not it will be a success on some preset factors (which he does not specify). I think that if you have a belief that the program will not be a success there is not much point bothering to put together this business case at all. Who is going to report here that their program is never going to deliver anything and will be a total failure? Still, the concept is interesting, especially if this section is completed by someone independent.
Key deliverables
This section is self-explanatory. Include key deliverables and the associated milestones. You can also link deliverables to critical success factors or key performance indicators.
Risks
Include a short statement about the major risks and opportunities. He doesn’t talk about including mitigation plans but you could do this too if you already know what the approach would be.
Resource requirements
This is the section to list the types of resources you need. If there are any special skill sets required, note them here.
Impact on organisation
This is an interesting section – it should cover the impact of this program on any other organisational initiatives that are happening at the same time. I suppose you could call it ‘dependencies’. This is where you can note any resource conflicts too, but equally any advantages of running this program in parallel to other work.
Costs
Of course, every business case should include costs. If you put your document together in the order Thiry suggests, by the time your sponsor (or the group that decides on whether to approve your program) gets this far, they should be thoroughly convinced that this piece of work needs to happen.
Benefits realisation plan
How are you going to get any benefits from this program? Specify how any financial benefits will be achieved, when the company should expect to see them and who is responsible for them. (Ideally, they should know that they are going to be responsible for them prior to you submitting the document, in my opinion.) You should also specify any non-financial benefits and how they will be tracked.
All this adds up to just the preliminary business case – which implies that a full program business case would need a lot more detail. However, this should be enough to help senior managers make a decision about whether it is worth investigating this program further.
Have you ever prepared a business case for a program? What things did you include?
About the author: Elizabeth Harrin is Director of The Otobos Group, a project management communications consultancy. Find her on Google+ and Facebook.



