If you have a business case to write and need a structure that will survive a governance board, start here. The business case template I use has stayed largely consistent across 25 years of work in government, utilities, health, and enterprise environments because the same sections keep causing problems when they are missing or underdeveloped. Cost estimates that cannot be defended. Options analyses that considered only the preferred solution. Benefit claims that nobody believes. Risks that surface in the project log six months later because nobody documented them upfront. What follows is the structure I actually use, what each section needs to do, and a real example where the process surfaced complications that would have been expensive to find later.
What a business case is actually for
A business case is a decision support document. Its job is to give the people who control budget and authority enough information to make a considered decision about whether to proceed, how to proceed, and what they are committing to if they do. Most of the business cases I have seen rejected or sent back for rework were written to justify a decision that had already been made rather than to inform one that needed to be made. Decision-makers are not looking for confirmation that your preferred solution is right. They are looking for evidence that you have genuinely considered the alternatives, that your costs are grounded in something real, that you understand the risks, and that your recommendation is defensible. A business case that cannot withstand scrutiny in a governance meeting has not served its purpose.
The sections I include in every business case
The depth of each section varies with the scale and complexity of the decision, but none of these sections are optional.
- Executive summary. A one to two page summary of the problem, options considered, recommended option, expected cost, expected benefit, and key risks. Written last but positioned first. If your recommendation is not clear from the executive summary alone, the document is not ready.
- Problem or opportunity statement. A precise description of what is wrong with the current situation or what opportunity is not being captured. Vague problem statements produce vague solutions. If you cannot describe the problem in concrete terms, with evidence, the business case will not survive scrutiny.
- Business context and objectives. Why this problem matters to the organisation right now, how it connects to strategic priorities, and what success looks like. This section answers the question of why now rather than later.
- Options analysis. A structured comparison of at least three options, including a do nothing option, each assessed against the same criteria. This is where most business cases are weakest. Decision-makers notice when the alternatives are included as window dressing, and it undermines trust in the whole document.
- Recommended option. A clear statement of which option you recommend and why, referencing the options analysis rather than simply asserting the recommendation.
- Costs. A breakdown of upfront costs, ongoing costs, and costs that are easy to overlook such as internal resourcing, infrastructure, training, and change management. Assumptions behind estimates should be stated explicitly.
- Benefits. Quantified where possible, described in business terms where quantification is not possible. Overstated benefits are discovered during benefits realisation and damage credibility for future business cases.
- Risks. The things that could prevent expected benefits from being realised, cause costs to blow out, or cause the project to fail. Each risk needs a likelihood, an impact, and a mitigation strategy. A risk register that lists risks without mitigations is incomplete.
- Implementation approach. A high-level view of how the recommended option would be delivered, including timeframes, governance, and key dependencies.
- Recommendation and approvals. A clear statement of what you are asking the decision-maker to approve, and space for the relevant signatures.
A real example: where the friction appeared
In 2010 I worked on a business case for Organisation B, a shared services agency within state government, that needed to implement an operational reporting and analytics system. The organisation was managing performance data across multiple lines of business using a patchwork of spreadsheets, manual data entry processes, and a reporting database that required significant duplicate data entry to maintain. The problem was well understood internally. Getting approval to invest in a solution required a business case that could survive scrutiny from a governance board that had watched ambitious technology investments fail to deliver before.
The options analysis was the section that caused the most work and, in retrospect, provided the most value. We assessed four broad options: do nothing, utilise an existing government technology investment, purchase a commercial solution, and custom build. Within each option we reviewed specific technology solutions against five assessment criteria: requirements coverage, contract value, implementation timeframe, ongoing cost, and risk. Each criterion was weighted and scored, and the scores were documented in a decision matrix so the governance board could see the reasoning rather than just the conclusion.
The first point of friction came when a senior director on the governance board challenged the weighting we had given to requirements coverage. We had weighted it at double the other criteria on the grounds that a system that did not meet business requirements was not a viable solution regardless of its cost or timeframe. The director argued that cost should be weighted equally given the current budget environment. We had anticipated this and prepared a sensitivity analysis showing what the decision matrix looked like under alternative weightings. Under every scenario we modelled, including equal weighting across all five criteria, the recommended solution still came out on top. That preparation was the difference between a recommendation that was approved in the meeting and one that was sent back for rework.
The second friction point was the cost estimates. A director from the finance team questioned the ongoing support cost, estimated at approximately $90,000 per annum for a dedicated internal resource. She asked why an ongoing resource was needed at all if the product was being purchased from a vendor with an existing support arrangement. The answer was that vendor support covered product defects and upgrades but did not cover internal configuration, report development, and user support that the business would need as requirements evolved. That distinction was not obvious from the cost table alone. After the meeting we added a paragraph to the costs section explaining what was and was not covered by the vendor arrangement. That explanation should have been in the original document, and its absence was a gap that could have undermined confidence in the overall cost estimate if the director had not asked the question.
The options analysis table
This is the format I use for the options analysis comparison table. It forces a consistent evaluation across every option and makes the reasoning visible to decision-makers who were not in the room when the analysis was done.
| Assessment criterion | Option 1: Do nothing | Option 2: Use existing investment | Option 3: Purchase solution | Option 4: Custom build |
|---|---|---|---|---|
| Requirements coverage | Does not meet requirements | Partially meets requirements | Fully meets requirements | Potentially meets requirements |
| Contract value | No cost | High, due to customisation required | Medium, within budget constraint | High, difficult to estimate |
| Implementation timeframe | Not applicable | Longest, exceeds required timeframe | Shortest, meets required timeframe | Longest, highest risk of overrun |
| Ongoing cost | Opportunity cost only | High, dependent on external resources | Low to medium, vendor supported | High, proprietary maintenance required |
| Risk | Current risks maintained | High, timeframe and cost overrun risk | Low, proven product with referees | Extreme, no proven delivery path |
| Overall assessment | Not recommended | Viable but not preferred | Recommended | Not recommended |
The mistakes that cause business cases to fail
- Treating the options analysis as a formality. If the options other than your preferred solution are not genuinely evaluated, experienced decision-makers will notice. The do nothing option is the most commonly skimped, and a credible do nothing analysis should include the cost of inaction, not just a note that it is not recommended.
- Benefit claims that cannot be substantiated. If you claim 20% efficiency savings, you need to show where that number came from. Industry benchmarks, comparable implementations, or a calculation based on current process data are all acceptable. A round number with no source is not.
- Cost estimates that omit the obvious. Internal resourcing is the most commonly omitted cost. The business case for Organisation B included detailed costings for internal staff time across initiation, procurement, and implementation phases. Without those, the total cost of implementation would have been significantly understated.
- A risk register without mitigations. Listing risks signals awareness. Documenting mitigations signals that you have thought about what you will do when those risks materialise. Decision-makers want to see both.
- Writing the executive summary first. The executive summary should be written last, once the full analysis is complete. Writing it first produces a document that argues backward from a predetermined conclusion rather than forward from evidence.
When to update your business case after approval
A business case that is approved and then filed is a missed opportunity. On complex projects, the assumptions behind your cost estimates and benefit projections will be tested as implementation progresses. When those assumptions change materially, the business case should be updated to reflect the current position. This is not about admitting the original case was wrong. It is about giving decision-makers current information to support ongoing governance decisions. A business case that was accurate at approval and is still being referenced eighteen months later as if nothing has changed is providing false assurance.
The trigger for updating a business case is usually a scope change, a significant cost variance, or a change in strategic context that affects the relevance of the original benefits. Treat the business case as a living document for the duration of the project, not a one-time artefact that gets filed after the governance board signs it. For guidance on how scope changes are identified and managed during requirements work, the scope creep and governance article covers the practical steps in detail. If you need to develop a requirements document to sit alongside your business case, the Business Requirements Document Template gives you a solid starting point. And if you are thinking about how your solution options connect to assessment criteria, the article on solution assessment criteria is worth reading alongside this one.
The business cases I have seen fail governance review almost always failed for the same reasons: options that were not genuinely compared, costs that could not be traced back to anything, and benefit claims that sat unsupported on the page. Getting the structure right matters, but the structure only works if every section is doing real analytical work. A business case template is a scaffold, not a shortcut, and the quality of what you put inside it is what determines whether the governance board leaves the room with enough confidence to say yes.
Frequently asked questions
What should a business case template include?
A complete business case should include an executive summary, a problem or opportunity statement, business context and objectives, an options analysis with at least three options including do nothing, a recommended option with rationale, detailed cost estimates with assumptions, quantified or described benefits, a risk register with mitigations, a high-level implementation approach, and a clear statement of what approval is being sought. None of these sections are optional, though the depth of each will vary with the scale and complexity of the decision. The executive summary should always be written last, even though it appears first in the document.
How detailed does a business case need to be?
Depth should match the scale and risk of the decision. A small internal improvement might need a two-page summary, while a significant technology investment or organisational change might need a twenty-page document with appendices covering cost breakdowns, risk assessments, and option scoring matrices. The rule is that every claim in the document should be substantiated and every cost should be traceable to a source.
What is the difference between a business case and a project charter?
A business case justifies the decision to proceed with an initiative by comparing options and demonstrating value. A project charter authorises a specific project to begin and defines its scope, objectives, governance, and resources. The business case precedes the project charter in most governance frameworks, and the project charter draws on the approved business case to define what will be delivered.
How do I write the do nothing option in a business case?
The do nothing option should describe what happens if no action is taken, including the ongoing costs of the current situation, the risks that remain unmitigated, and the opportunities that are not captured. It is not sufficient to note that do nothing is not recommended. The do nothing option needs to be substantive enough that decision-makers can see what they are choosing not to do and understand the consequences.
How do I justify cost estimates in a business case?
Cost estimates should be sourced from vendor quotations, internal resourcing calculations based on FTE costs and time allocations, infrastructure assessments, or comparable project data from previous implementations. Where estimates are used rather than quotations, the assumptions behind them should be documented explicitly. Sensitivity analysis showing how the recommendation changes under different cost scenarios strengthens the credibility of the estimate significantly.
Try Ash, Your Virtual BA
If your business case is approved and the next step is producing a Business Requirements Document to support it, Ash can help you get that done efficiently and thoroughly. Ash guides you through a structured elicitation process across 15 categories of requirements and produces a complete BRD you can download as a Word document, giving you a solid requirements foundation that strengthens your options analysis and makes the scope section of your business case significantly easier to defend in governance. Try Ash Virtual BA.
Further reading
Written by Sam Cordes, founder of the Business Analyst’s Toolkit.