Why Business Cases Matter After Greenlight (Not Just Before): Use the Five Case Model to Prove Value Through Delivery
Picture this all too familiar scene.
It’s the third week of a project.
Someone senior asks, in a perfectly friendly tone:
“Remind me why we’re doing this again?”
And the room goes quiet for just a bit too long.
We’ve seen that pause more often than we’d like but it rarely means the project is a bad idea.
It usually means the reasoning behind it lived in someone’s head, or in a slide deck from eight months ago, or in a business case that got approved and then quietly filed away.
A good business case that gets you the greenlight, is referred to throughout the project’s life, and helps prove that you delivered the business value envisioned – is an absolute project essential. It’s also a corner that is frequently cut.
It doesn’t have to be a hefty document but a reference resource that answers the awkward questions before anyone even asks them is a useful tool.
WHAT’S YOUR GO TO BUSINESS CASE METHODOLOGY?
Do you even have one or do you wing it?
Recently I was working with a public sector Project Manager who reminded me of The Five Case Model (FCM), a structured methodology used to develop robust business cases for public-sector investments. I see Five Cases used in private sector environments too and it always delivers.
FCM ensures proposals are aligned with strategic goals, deliver value for money, are commercially viable, affordable, and can be successfully delivered. It is the required standard across UK central government and has been adopted internationally too for business case preparation.
Above all, I think it focusses our attention on five key paradigms to keep us aligned with the actual business need from pre-green light to post-delivery.
For the uninitiated:
THE FIVE CASES
1 – The strategic case: why are we doing this at all?
This is the “remind me why” question. If you can’t connect the project to something the organisation genuinely cares about, no amount of good delivery will save it. Try explaining it in two sentences to someone outside your team. If you need a third, keep working.
Here’s a real life application, we see versions of this a lot! An IT Director kept proposing a security upgrade, framed as a technical risk, and it kept losing out to projects with a clearer commercial upside. Then someone reframed it: what would a day of downtime cost in lost orders, customer trust and regulatory exposure? Same project, same budget, different question. It was approved within a month. The technology never changed. The case for it finally spoke the board’s language.
2 – The economic case: what else could we do?
The most common gap here is that there’s only one option on the table, and it’s the one somebody already wanted. A credible case includes the alternatives, including “do nothing” and “do the minimum”, and explains why the preferred route wins. It’s also your best defence when someone proposes a shinier idea halfway through.
3 – The commercial case: can this actually be bought and delivered?
Great plans die here quietly.
Are there suppliers who can do this? Is the procurement route realistic? What happens to the contract if the scope shifts? Nobody enjoys this section, which is exactly why it’s worth a proper look.
4 – The financial case: can we afford it?
Not just “is there a budget”, but whether it’s the right budget, what the risks to it are, and what happens if costs move. Finance teams tend to trust a case that names its uncertainties more than one that pretends there aren’t any.
5 – The management case: who does what, and how will we know it’s working?
Governance, timelines, skills, and, the bit that often gets forgotten, how you’ll measure whether the benefits arrived. A project can be delivered on time and on budget and still fail if nobody checks the outcome.
Take a service desk rollout that goes live on time and on budget. Everyone celebrates. Six months later, only a third of the team is using it properly. The business case promised “improved customer visibility” but never said how or when that would be measured, or who was responsible for checking. Delivered, but not successful, and nobody could quite say when it had stopped being either.
THE REAL VALUE SHOWS UP LATER
Many project teams treat the business case as an entry ticket – it’s the document that gets you the go ahead. While that matters, of course, the teams getting the most from it are the ones for whom the business case document is a reference point they return to.
When a stakeholder asks for one extra feature, the case tells you whether it belongs. When priorities wobble, it reminds everyone what success was meant to look like. When the project ends, it gives you a baseline for an honest review, which is how the next project gets better.
That only works if the document stays alive:
Update it when the facts change.
Keep it short enough that people will actually open it.
Use the same format your organisation already uses, so nobody has to learn a new one before they can read it.
And where a simple visual makes a point faster than a paragraph, use it.
A QUICK TEST BEFORE YOU SIGN OFF
Feeling brave?
Hand your business case to someone who wasn’t involved in its preparation and give them ten minutes to read it through.
Then ask them three things:
1 – Why are we doing this?
2 – What did we decide not to do?
3 – How will we know it worked?
If they can answer, you have a case that will earn its keep. If they can’t, you’ve found the gap while it’s still cheap to fix.
FINALLY
Business cases can feel like paperwork. I have never met a fan of paperwork.
Reframing business case, I think they’re closer to insurance: a small effort up front that pays off on the day someone asks the awkward question.
If you’d like a second pair of eyes on a project business case, or you just want to talk through a project that’s still at the “should we?” stage, we’re always happy to have that conversation.
What method do you use to prepare a business case?
FAQ
What is a business case?
A business case is a clear justification for undertaking a project. It weighs benefits against costs and risks, compares alternatives, and explains why the chosen approach is the most effective. It’s used to win approval and to keep everyone pointed the same way during delivery.
What is the Five Case Model?
The Five Case Model is a framework for structuring a business case around five questions: why are we doing this (strategic), what are our options (economic), can we deliver it (commercial), can we afford it (financial), and how will we run it (management). It originated in HM Treasury’s Green Book and is now used well beyond government.
What should a business case include?
At a minimum: the reason for change, the options considered, how the project would be bought or delivered, the costs and funding, and the governance and benefits measurement. If you can’t answer any one of those, that’s usually where the project is most exposed.
How long should a business case be?
As short as it can be while still answering the five questions. For a smaller IT project that might be a few pages. The test is whether someone who wasn’t involved can read it and explain the project back to you.
Who is responsible for writing a business case?
Usually the project sponsor or project lead owns it, with input from finance, procurement, technical teams and the people affected by the change. Having a fresh pair of eyes review it before sign-off is a good habit, whoever writes it.
What’s the difference between a business case and a project plan?
The business case explains why the project should happen and whether it’s worth it. The project plan explains how and when it will be delivered. One justifies the work, the other organises it, and the plan should always trace back to the case.
Should a business case be updated during a project?
Yes. Treat it as a living document and revisit it when scope, costs, risks or priorities change. That keeps it useful as a benchmark for change requests and as a baseline for reviewing how the project performed.
The Q&A about the plan versus the business case is one I added, since it’s a genuinely common point of confusion and isn’t in the handout. If you’d like, I can fold the definition paragraph and FAQ into the full draft and give you a clean version, with a suggested meta description too.
