If you are currently writing a business case and wondering why your last one failed to get the traction it deserved, the problem almost certainly wasn’t the analysis. It was the structure. Decision-makers at the level that approves funding and signs off budgets read a lot of these documents. They are time-poor, often already briefed informally, and rarely read past the first two pages. The analysis you spent six weeks producing sits unread in the appendix while the meeting to approve or reject your proposal lasts forty minutes. Understanding that reality before you write a single word will change the way you approach the whole document.
I have been producing business cases across government, utilities, health, and enterprise environments for over two decades. The ones that got approved shared a consistent trait: they were built around a compelling front section that made the rest of the document feel like reassuring backup rather than required reading. The ones that stalled or got sent back for rework were usually technically excellent and structurally wrong. Here is how to get it right.
Stop Trying to Get People to Read the Whole Document
The single most freeing mindset shift I made early in my career was accepting that no one reads a business case from cover to cover. That is not a failure of your writing or your stakeholders. It is simply how busy organisations work. Your job is not to produce a document that people read in full. Your job is to produce a document that gives approvers everything they need to make a confident decision, with all the supporting detail available if they want to dig in.
That means the most important section of your business case is not the financial model or the risk register. It is the opening section. And I strongly recommend you stop calling it an executive summary. In my experience, calling it a Case for Change immediately signals to the reader what you are asking them to engage with. It is a subtle but effective difference. An executive summary sounds like administration. A case for change sounds like a conversation worth having.
What to Put in Your Case for Change
Your case for change needs to do one thing above everything else: make the approver feel that doing nothing is the riskier option. You are not summarising a document. You are making an argument. Write it in plain language, use short paragraphs and summary tables, and cover the following in whatever order serves your specific situation best.
- Purpose and context: One short paragraph explaining what this business case is about and why it is being presented now. No history lesson, just enough to orient a reader who may not have been involved in the work to date.
- The problem and its consequences: Describe the current situation with real specificity. Vague problem statements lose approvers immediately. Name the operational impact, the financial exposure, or the compliance risk. Use actual figures where you have them.
- Options considered and key findings: Keep this brief. Two or three bullet points per option is enough at this stage. You are signalling that rigour was applied, not asking people to evaluate the options themselves.
- Your recommendation and what is needed: State clearly what you are recommending and what you are asking the approvers to do. Approve funding, authorise the next phase, endorse the preferred vendor. Be explicit.
- Benefits of the recommended approach: Lead with the benefits that matter most to this particular audience. Financial savings land differently in a cost-reduction programme than in a growth-focused initiative. Know your room.
- Basis for the benefit calculations: If you are quoting financial benefits, briefly note the assumptions behind them. This protects you and builds credibility. Approvers who have been burned by optimistic projections before will look for this.
- Estimated costs: A clear, honest cost summary. Do not bury contingency in the middle of a table. Put it in the open.
- Known limitations or shortcomings: Every recommendation has trade-offs. Name them. Approvers who discover limitations you failed to mention will lose confidence in your entire analysis.
A Real Example, and Where It Nearly Came Apart
On a technology consolidation project for Organisation A, a government-adjacent body managing licensing and compliance for a regulated industry, I spent eight weeks producing a business case for replacing three legacy systems with a single integrated platform. The analysis was thorough. The financial modelling showed a net saving of $1.4 million over five years, with break-even at month 26. I was confident in the numbers and confident in the recommendation.
The steering group meeting did not go the way I expected. Within fifteen minutes, the CFO pushed back hard on the projected savings. She had seen similar projections on two previous projects at the organisation and both had overrun. The document was open in front of her but she was not reading it. She was asking me questions I had answered on pages 14 and 22, neither of which she had reached.
What I had failed to do was address the previous project failures directly in the case for change. I had treated my analysis as if it existed in a vacuum. It did not. The room had a memory. I asked for the meeting to be paused, pulled up a two-slide summary I had prepared as a fallback, and walked through the cost model and the assumptions behind it verbally. I also acknowledged the previous overruns by name and explained specifically what was different about the methodology used this time, including an independent cost validation from a third party. The mood shifted. The case was approved at the following meeting two weeks later, subject to a revised risk register that addressed implementation risk more explicitly.
The lesson was not about getting the numbers right. The numbers were right. The lesson was about knowing what objections exist in the room before you walk in, and making sure your case for change speaks to those objections directly. If I had structured that opening section around the CFO’s known concerns rather than around the logical flow of the analysis, I would not have lost two weeks. When you are preparing your opening section, think about who is in the room and what they are already worried about. Then answer those worries before they are asked.
How to Evaluate and Present Your Options
A business case that presents only one option is not a business case. It is a proposal. The difference matters because approvers who feel they have not been given a genuine choice often feel the process has been managed rather than analysed. Even if your preferred option is obviously correct, presenting a structured comparison builds credibility and demonstrates that the recommendation is evidence-based rather than predetermined.
I use a weighted decision matrix for this, scoring each option against a set of agreed criteria. The criteria themselves should be agreed with key stakeholders before you start the analysis, not invented after the fact to justify a conclusion you have already reached. For more on how to structure this evaluation in practice, the solution assessment criteria framework on this site gives a solid methodology for developing and defending a recommendation.
| Evaluation Criterion | Weight | Option 1: Do Nothing | Option 2: Patch Existing System | Option 3: Replace Platform |
|---|---|---|---|---|
| Alignment with strategic goals | 25% | 1 | 2 | 5 |
| Cost over five years | 30% | 2 | 3 | 4 |
| Implementation risk | 20% | 5 | 3 | 2 |
| Operational disruption | 15% | 5 | 3 | 2 |
| Scalability for future needs | 10% | 1 | 2 | 5 |
| Weighted Score | 2.75 | 2.75 | 3.65 |
The table above is a simplified version of the kind of matrix I use. The important thing is that the weights are agreed before you run the scores, not after. If stakeholders challenge the outcome, you can show them the criteria they endorsed and work through the scoring together. That transparency is what makes a weighted matrix genuinely useful rather than just decorative.
Presenting the Business Case in Person
Once your case for change section is written, turn it into a presentation. Not a document that gets emailed in advance and skimmed before the meeting. A live, verbal presentation where you are in the room, or on the call, walking people through the argument. Take your case for change section, add diagrams and summary tables where they add clarity, and present it with confidence.
This matters more than most BAs realise. A written document is a one-way communication. A presentation is a conversation. The questions you get in a live presentation tell you exactly what the room is uncertain about, and you can address those uncertainties in real time rather than waiting for written feedback that arrives three weeks later with seventeen comments and a request to start again. If you want to sharpen your confidence in exactly these kinds of stakeholder conversations, the guidance on communicating with non-technical stakeholders is worth reading before your next approval meeting.
The detailed analysis in the body of your business case is not wasted effort. It is the evidence base that supports the decision you are asking people to make. The fact that most of it will not be read in the meeting is fine. It exists to validate the recommendation if anyone wants to go deeper, and to protect the organisation if the decision is challenged later. You can also pair your business case with a structured business case template to make sure nothing critical is missing from the supporting sections.
The weeks of analysis you pour into a business case are worth it, but only if the front of the document is strong enough to get the recommendation across the line. Structure your case for change around the decision your approvers need to make, speak to the objections you know are in the room, present it in person, and treat the detailed analysis as the safety net it is. Do those things consistently and you will find that your business cases stop being documents that get deferred and start being decisions that get made.
Frequently asked questions
What should be included in a business case?
A business case should include a clear problem statement, an analysis of options, a recommended course of action, estimated costs and benefits, a risk assessment, and a summary of any known limitations. The opening section, often called a case for change, is the most important part because it is what decision-makers actually read. Supporting detail such as financial models and risk registers belongs in the body of the document where it can be referenced if needed.
How long should a business case be?
There is no fixed length, but the most effective business cases I have worked on keep the case for change section to two or three pages and use the remaining sections for supporting analysis. The total length depends on the complexity and investment involved. A business case for a $50,000 process improvement does not need the same depth as one proposing a $5 million platform replacement.
How do you write a business case for a new system?
Start by clearly defining the problem the current system is creating, using specific operational or financial impacts rather than general complaints. Analyse at least three options, including doing nothing, and use a weighted decision matrix to compare them against agreed criteria. Make your recommendation explicit and state what you are asking approvers to do, then let the detailed cost-benefit analysis and risk assessment support that recommendation in the body of the document.
What is the difference between a business case and a project proposal?
A project proposal typically outlines what you want to do and asks for permission to proceed. A business case goes further by justifying why the organisation should invest, comparing alternatives, quantifying costs and benefits, and assessing risk. A business case is a decision-making document, not just a request.
How do you get stakeholders to approve a business case?
The most effective approach is to socialise the key findings informally before the formal approval meeting, so there are no surprises in the room. Present the case for change section in person rather than relying on people to read the document in advance. Address known objections directly in your opening section, and use a weighted options comparison to show that the recommendation is evidence-based rather than predetermined.
Try Ash, Your Virtual BA
If you are in the middle of writing a business case right now, Ash can help you work through the structure, sharpen your case for change section, and think through the options analysis before you put it in front of approvers. Ash is built specifically for BA work, so the guidance you get is grounded in real practice, not generic templates. Try Ash Virtual BA and get your business case moving.
Further reading
- 3 tips for writing better business cases as a business analysis professional | IIBA®
- Mastering Business Case Writing | DC Metro – IIBA
Written by Sam Cordes, founder of the Business Analyst’s Toolkit.