Categories: business case
Last time I looked at some of the basic features of the project business case – the key document that sets out what the project is going to achieve, how the work will be done, and most importantly, why this is a problem that needs to be solved right now. I covered the purpose of a business case, who is likely to be reading it, and the general format. Today I want to look at what different sections go into the document to make up the full business case.
These aren’t in any particular order, and you can arrange the segments as you like, perhaps according to whatever template is used as standard by your Project Management Office. However, if you are going to use an executive summary, that has to come at the beginning, so let’s look at that part first.
Normally, you write the executive summary last. It is a short statement, normally no longer than a page, that sets out a summary of the whole document. It is for people who don’t have time to read the whole thing, but it is also useful for everyone. You get a complete flavour for what the document will be about and how the project is likely to unfold, and then you can read the detail on the subsequent pages.
Because it is a summary of the detail of the document, that’s the reason we write it last. You need to know what goes in to the rest of the document before you can summarise it here!
Statement of need or problem
Early on in the business case you should set out what the problem is that this project will address. After all, readers will quickly want to know more about the issues faced by the company and how this project will fix them. Mention the current situation, if this project relates to improving a particular system or process. Figures and other types of data, such as customer surveys, can also be useful for making the point that there is a real issue that needs addressing. If you can, link the problem back to strategic objectives or key performance indicators for the company, maybe referring to elements of the balanced scorecard.
The important thing in this section is to remember that it will be business people who are reading it, not technical staff or project managers. Try to avoid jargon and make sure that you set out the problem and solution clearly.
A business case should look at all the potential ways to remedy this problem before making a recommendation on the best one, so include a section where you spell out the different options. By this point you’ll already have a view on which solution you will be recommending, so don’t spend too much time describing options that have been rejected and why they are no good. However, you should mention them, so that the readers know the thought process that you went through to identify the best way forward.
Remember that there is always an option to do nothing, so you should also include this as a comparison to the proactive options.
In this section, spend more time explaining your proposed solution. You do have more space to go into detail, but again remember to keep it all in business language avoiding jargon where you can and being really clear about how this particular solution will help solve the problem.
This section is something that you could refer to later when putting together your project initiation document or charter, so it can also include a summary of costs and benefits, key milestone dates and who will be required to work on the project. If you don’t know names at this point, make a note of the key skills or job titles required.
Every business case needs a section on costs as this is one of the main ways that people make decisions about what projects to do and how to prioritise them. Costs cover a number of different areas so consider these:
- Capital costs
- Resource costs
- Running costs for maintenance
- Decommissioning costs if you are switching off another system
- Training costs and other HR-related costs such as redundancy payments
- Consultancy or third-party fees
- Licence fees
- Implementation costs
You can probably think of some others yourself.
The flip side of costs is benefits, and your business case should make it clear what benefits will be achieved by working on this project. Benefits could include things like increase in customers, revenue, staff morale, or avoiding costs, or ensuring the company remains compliant with current legislation.
This section covers positive and negative risk and you would want to include some detail about what mitigation plans would need to be put in place to manage the risk if the project was approved. You can group risks into categories if that makes it easier to present the information to the readers. Your Project Management Office may already have a standard set of categories, but if not you could consider things like technical risk, business risk, and any dependencies on other areas or projects, as these could also be risks.
Those are the main considerations to look into when producing your business case, although there are no hard and fast rules and it is best to include more information (as long as it is clear and concise) than less. This gives people the information they need to be able to make an informed decision about whether to progress with the project.