If you’re a project manager, chances are that at some point in your career you’ll be expected to write a project business case. This can be a daunting exercise, especially if you’ve never written one before.
I remember the very first business case I ever wrote. I can honestly say it was the biggest bunch of drivel I have ever written. It was even worse than some of my university assignments and that’s saying something! Thankfully, I had a great mentor who took the time to explain exactly where I went wrong and how I could make things better.
What is a business case?
Regardless of the project’s size, the business case’s job is to provide justification for the project, as well as give options on how to proceed. There should be enough information in the document to ensure that the steering committee can decide if the project is viable.
Unfortunately, I’ve seen some really horrendous project business cases over the years. A couple of stand-out examples are:
A one page business case for a multi-million dollar revamp of an IT system. To make matters worse, there weren’t even any options – just a quote from a supplier (who turned out to be a friend of the project manager)
The business case that bore absolutely no resemblance to the project whatsoever. When questioned, the business case team said that they thought their idea was better than the organisation’s idea for the project, so they wrote that instead.
Needless to say, both business cases had to be completely rewritten, putting the projects behind time and over budget before they’d even started!
So how do you avoid the rubbish business case trap?
First, take into account the size of your project. The amount of work and information that you’ll need to provide in the business case will depend on that. There’s no point writing a one page summary if you’re trying to get funding for a multi-million dollar project. The same is true in reverse. Presenting a 40 page in-depth document for funding for a $50,000 project will make you look stupid.
The project executive is ultimately responsible for delivering the project’s business case but they typically delegate the writing to the project manager or a business analyst.
If you’re running a small project, and by that I mean something with a budget less than $500,000 and which will take a few months to complete, then it’s perfectly possible for you to write a one page business case on your own.
However, if the project is large, it is wise to put together a team to write the business case. That way you can make sure you have experts on hand to help. A typical business case writing team will include:
The project manager
A finance expert
Subject matter experts
Stakeholders tend to be overlooked when developing a business case for large and complicated projects. It’s not uncommon for a business case to be approved without any stakeholder input and then be rejected when people kick up a fuss about the lack of consultation.
To avoid this from happening, make sure you develop a stakeholder engagement plan specifically for the business case and follow it. This should include a plan on how to influence senior decision makers so that they will support your proposal.
Contents of the business case
When you write the business case, you need to make sure it has enough information in it so the key stakeholders can make a decision.
Before you start, check if your organisation has a template. Most organisations will and they’ll likely have examples that you can work with (copy from). If they do have a standard format, then it is a simple process of filling in the blanks.
If you find yourself having to write a business case from scratch, here’s a good structure to follow:
Table of contents
Background and current situation
Relationship to other projects and strategy
High level organisational impact
Expected project timing
What to make sure you include in your business case
When you’re writing the project business case, there are some key things to make sure you include. Always provide three options in the options section. I make the first one the do nothing, or status quo option. The second one is the preferred option and the third one is a compromise or completely out-there solution.
Make sure you include any downsides as well as benefits.
Highlight any impacts on the business, both positive and negative.
Things to avoid
Sending a document that isn’t fit-for purpose will see your business case rejected on the spot.
Avoid ambiguity. On more than one occasion I’ve seen project managers held to account in the delivery phase of the project for something that was badly written in the business case.
I hope these tips are useful and will help you the next time you have to write a project business case, whether large or small.
About the author:
Rhona is Deputy Everything Officer at Psoda, where she does everything except code. After starting life as a microbiologist she moved into PMO leadership roles around the world before settling in New Zealand with her family.