You’ve got a new project… and new sponsor asking for input into the business case. This video gives you a quick refresher on the top 7 things that you should include in the business case. Include these elements to help you business case sail through the approval process!
One of the things I get asked the most is, “Can you help me with my business case?” It wasn’t always like that, but I think these days project managers are getting more and more involved with writing business cases. We’re taking in part in the project from an earlier point, which often means before the project is even really a project.
I’ve written quite a lot about business cases over the years so here’s a round up of resources that can help you put together a fantastic business case.
Business Case Basics
To get started on a business case you need to know the purpose of a business case, who is going to read it and the 7 essential elements that go into a standard business case. If you’re starting from scratch, these two articles have got you covered:
As with all things in project management, understanding the ‘why’ is a huge benefit for understanding the ‘how’. The 3 reasons why business cases are essential are:
These reasons apply whether or not your company cares much about paperwork and bureaucracy. As a project manager it’s still important to understand why your project has value to the business. If you’re struggling to get your management team to even the shortest business case, keep pushing! It will massively help your project management maturity levels.
And you can watch a short video all about those in more detail below.
Business Cases for Program Management
Programs need a slightly different approach to justifying a project through a business case, although there are many common elements, and the reasons why you would do a business case (to specify the problem, justify the work and explain the solution) are still relevant.
There’s a whole stack of information on preparing a program-level business case in this summary I put together from Program Management (Gower, 2010), by Michel Thiry: What goes into a preliminary program business case?
You’ll see that there is still a great deal of detail required from a benefits realisation plan to resource requirements, and a statement of achievability. It’s a significant amount of work even to get to this position of having a preliminary business case.
Once you’ve got approval in principle to continue with your program, you’ll be able to put together a more detailed program business case. You could argue that this document (again, I’ve pulled together a high level view of some of the ideas outlined in the Program Management book) borders on being a Project Charter, because by this point you’ve had approval for the concepts and solution so you aren’t spending too much effort thinking about options appraisal any longer.
However, there’s also an argument for saying that options appraisals are more suited for solutioning at project level, and at program level you’re really approving the transformative change.
I wrote a recipe for a program business case as well.
More Resources for Business Case Preparation
If you are writing a business case you’ll find this book interesting: Business Case Essentials.
Finally, here are some tips for preparing a business case when your project is all about implementing online collaboration tools. There are some specific things to consider that will help make your proposal more appealing, and it’s especially worth thinking about non-financial elements and how to justify those.
I hope these resources are helpful for you!
It has been a long time since I did AS Level Law aged 17, and I remember contract law being the less interesting part of the course. However, some of it is still relevant to my job today. For a contract to be legal, certain conditions have to be met. There are 5 conditions to fulfil before you can say that your contract can be legally entered into.
1. There must be an offer
There must be an offer and an acceptance. If I don’t offer you something, there is no contract. If you don’t accept it, there is no contract.
I can’t contract you to do something that you don’t want to do because you haven’t accepted my offer. You’re within your rights not to sign a contract with a supplier if the deal isn’t right for you. Just like you would stand your ground with those door-to-door sales people, you can stand your ground with a supplier on your project too.
There’s often back and forth at this point (as there should be) as you refine the offer into something that you can both live with.
2. There must be consideration
This means that something has to be exchanged. Your project suppliers offer you goods or services and you pay them money in exchange.
It doesn’t have to be money. You could give them goods or services back, or exposure to your client base or something else that you both agree to. But there has to be some give and take.
Again, there’s negotiation to be done here. Once you’ve agreed on the offer you might go back and forth on the consideration (the fee) that you are willing to pay, and how this will be structured: all in one go, payment phased over the life of the project and so on.
3. There must be legal capacity
I expect this varies from country to country, but the people entering into the contract must be legally able to enter into an agreement. I remember reading about a case where a toddler had accidentally purchased some expensive stuff online through random button pressing on a parent’s device (it happens) and the case concluded that the family didn’t have to pay as the toddler didn’t have the legal capacity to enter into a contract. I think they had to return the goods though – getting your child to purchase all your supplies is not a legal method of getting resources for your project for free! I’ve looked but I can’t find a citation for that case – if you know of one, let me know and I’ll update this article to reference it. I did find this one where a 3 year old bought a car on ebay, but the case didn’t go to court for contract law to be tested.
You may have capacity in law, but you may not have capacity in terms of your company’s due process. For example, perhaps only Directors can sign contracts above a certain value, or you can only enter into a contract in certain circumstances or with certain providers. While I’m not sure that would hold up in court, it would definitely get you into hot water at work, so make sure you check your company’s contract signing policy and get advice from your Legal team. That will avoid you entering into any deals and contracting the company in ways that they would prefer you didn’t.
4. There must be legal purpose
This simply means that the subject of the contract needs to comply with the law.
In other words, you can’t contract someone to steal for you. Or do anything else illegal. But you wouldn’t do that anyway, would you?
5. There must be intention
There must be the understanding on both sides that this agreement could be enforced by a court if it came to it. You must go into the contract understanding that it is legally binding and that you intend for it to be so. You aren’t signing up to something on a best endeavours basis, or without realising that it’s a legal document.
This is all broadly common sense, but it’s there to protect businesses and individuals.
I don’t know if these are the same conditions enshrined by your local laws, but for UK and US laws these seem to hold true. What’s the situation where you are? Drop a note in the comments to let us know!
I put this infographic together for you to highlight the common types of ways that project leaders and project financial analysts can carry out financial appraisals. These are all techniques that you can use in a business case or project proposal. I hope it's helpful!
The content of the image is drawn from Carlos Serra's book, Benefits Realization Management.
You’ve taken over a new project and you’re reviewing the business case. Or perhaps your sponsor has asked you to pick up a new project and you’re looking over the business case to see what you need to get started with.
In his book, Business Leadership for IT Projects, Gary Lloyd talks about the business case as a management tool. The book is of more value than just for IT projects, and I particularly like the ideas that the author provides when it comes to checking the validity and robustness of your project business case
Here are 16 red flags to look for in a business case. This is Gary’s bullet point list augmented by my take on what they mean for project managers.
1. Is the vision clear?
The vision is what people follow. If you aren’t clear about what the project is about in the business case, the people reading it won’t have a chance. It should be specific about the problem and what desirable end state is the result.
2. Is the scope unambiguous?
There’s always ambiguity at the start of a project, there has to be because you don’t yet know exactly how things are going to pan out.
However, points of ambiguity in a business case should be clearly pointed out, with risk budgets attached and plans about how clarity is going to be reached.
3. Have the key stakeholders been identified and engaged?
You might not want to do too much engagement prior to the business case being approved, but you definitely need people to know what is coming. If you are expecting them to work on the project in some way, they need to know that it is a possibility.
The red flag is when the stakeholder section in the business case looks skimpy. It should hold up to questioning: how much do these people know?
4. How was the cost saving or increased revenue calculated and tested?
The maths should be clear. A number alone isn’t going to give anyone confidence that all the variables have been taken into account. And if you can prove the numbers somehow because of desk-based research or a pilot or something else, then that should definitely be shown.
5. Is the worst case scenario really the worst case?
Is there a worst worse case? This is a good question to challenge a business case of a project that is mandatory or regulatory. Often those projects are started on the premise that ‘worst case’ is not being able to trade again, but that might not really be the situation.
You’ll also want to check what the worst case scenario is based on: if it isn’t to do with stopping trading if the project doesn’t happen, is the worst case to do with project costs, operating costs, missing out on cost savings, revenue or something else?
Dig into the facts and make sure your business case makes this really clear.
6. Does the project cost include contingency?
A no-brainer. If it isn’t there, ask where it is and be prepared to frown if the response is that the business case owner has padded all the estimates.
Contingency should be called out specifically for change budgets and risk budgets.
7. What is the change budget?
On the subject of change budgets, there is one, right?
8. What is the risk budget?
And the same for risk budgets!
9. Does the project cost include all of the non-IT costs?
This is relevant when there is a large IT element, or it’s an “IT project”. Training, temporary office space, staffing costs: they all mount up and might not be covered by the IT budget.
10. Does the NPV include all the operating costs?
See if the business case calculations include licences, infrastructure and staff costs as well.
11. Is the discount rate visible?
And Gary adds: does it reflect the risk of the project? This might be defaulted into the calculations that sit behind the business case but you can at least check that they’ve used the standard calculations and didn’t feel the need to bespoke the maths in anyway.
12. What are the comparators that were used to calculate the discount rate?
Again, this is a good question but might be something set by the Finance team in the spreadsheets used for the business case template.
13. Is the time horizon used for NPV realistic?
A high NPV is better and NPV generally is used to help show which project is more valuable to the organisation. That comparison is really only valid if you are all comparing projects over the same time horizon. Or if you aren’t, that it’s clearly different and realistic.
14. Are the performance criteria realistic?
Check that the performance criteria are something that you can sign up to. Is this what you thought you would be measured on and do you believe you can achieve it?
15. What risks are missing?
There’s nearly always something missing! That happens because you are a fresh pair of eyes and you’ve just combed through the business case looking for mistakes. There might be risks that jump out at you by their absence but you may also want to discuss the project business case with the team and check that the risks they raised made it into the document.
16. What key assumptions are missing?
And the same for assumptions. You may spot some because you are coming to the business case fresh, and ask the team what they had that perhaps didn’t make it to final version.