Business
How to write a business case that supports a real decision
Stefan Weiss
To write a business case, explain the problem, compare credible options, set out their benefits, costs and risks, and ask for a specific decision. Show how the preferred option could be delivered and how the organisation would check whether it worked. Keep evidence, estimates and assumptions visibly different.
A business case should make it possible to approve, reject, change or defer a proposal for clear reasons. If the only possible conclusion is the writer's preferred solution, the analysis needs another pass.
This guide is for managers, project leads and consultants preparing an ordinary operational or product initiative. Start with the organisation's required approval process, a named decision owner and the evidence available so far. Where a formal funding or procurement framework applies, use its required structure and involve the relevant owners.
What is a business case for?
A business case explains why an initiative merits organisational resources and provides a reference for reviewing it later. PMI Montréal describes it as a document that connects a project's purpose, intended value and eventual evaluation. Henri-Jean Bonnis on the purpose of a business case.
It has a different immediate job from several related documents:
Business plan: describes how a business will operate and develop; a business case usually justifies a bounded initiative or change.
Client proposal: presents an offer to a buyer, including proposed deliverables and commercial terms.
Project brief: establishes the project's intended outcome, boundaries and responsibilities.
Decision memo: organises a particular choice and recommendation; it can summarise a business case or address a smaller decision.
The documents can share evidence without being interchangeable. A detailed implementation plan does not by itself explain why the initiative is worthwhile. A persuasive proposal does not establish that the buyer can afford or deliver the change.
Decide the scope of the decision first
Write a plain sentence describing the decision: for example, “Approve a limited pilot to test whether a new onboarding process reduces repeat enquiries.” This is different from asking for full implementation. State the scope, the responsible approver and what the approval would allow the team to do next.
Match the detail to the commitment. A reversible pilot and a major long-term programme need different depth. Ask the decision owner what evidence is required rather than guessing a page count. Record any information that must be supplied by finance, procurement, delivery or another responsible team.
For formal UK public-sector work, HM Treasury's current guidance sets out a step-by-step process based on the Five Case Model. Its guidance was updated in June 2026. The model is a useful reference, but an informal internal note should not be described as satisfying a formal approval process merely because it uses similar headings. HM Treasury guidance on developing business cases.
1. Describe the problem and the current position
Start with the situation the organisation needs to change. Describe who is affected, what happens today and why that matters for an agreed objective. Avoid making the preferred solution part of the problem statement.
“We need a new portal” names a solution. “Customers cannot reliably find the next onboarding step, and support must repeatedly clarify it” describes a problem that several solutions might address.
Support the statement with the best available evidence. That might include operational records, customer research, recorded discussions or an agreed service review. State the period and scope. A few interviews can illustrate a difficulty without establishing how often it occurs across the whole customer base.
If the scale is unknown, say so and define the next measurement. A specific gap is more useful than an unsupported claim that the current situation wastes a large amount of time.
Output: a problem statement that remains understandable even if the preferred solution changes.
2. Define the outcome and how it would be assessed
Describe the improvement in observable terms. What would change for the people affected? Which result would make the initiative worth continuing, and who would judge it?
For the onboarding example, possible outcomes include fewer repeat enquiries, fewer cases returned for missing information or clearer next-step understanding. Choose the outcome that matches the problem. A delivered portal or a completed training session is an output; its use and effect still need checking.
Record the baseline where it is known, the measurement method, the relevant population and the review point. Keep unconfirmed targets visibly proposed. Ask the responsible owner to agree what would trigger continuation, adjustment or stopping.
Do not imply that a metric will be available merely because it would be useful. If collection needs new work, include that work in the plan and cost assessment.
3. Compare realistic options, including the current course
Identify alternatives that could plausibly address the problem. Include maintaining the current approach where that is a credible choice, and explain its consequences. A minimal change may provide a more useful comparison than an exaggerated “do nothing” option.
For example, a team might compare:
Keep the current onboarding materials and monitor the problem.
Clarify existing instructions and introduce a consistent handover check.
Test a small guided workflow with one suitable customer group.
Implement a broader system change after the necessary investigation.
These are fictional options, not recommendations for a particular organisation. The comparison should use criteria that matter to the decision: expected benefit, delivery effort, affordability, dependencies, uncertainty and reversibility, for example.
Apply the same criteria to every option. Do not give the preferred option a detailed benefit story while describing alternatives only through their disadvantages. Where an option is not feasible, preserve the reason for excluding it.
4. Build the cost and benefit picture from owned evidence
Ask the relevant owners for estimates and identify their basis. Include the costs of getting started, operating the change and moving away from the current approach where those apply. Training, migration, review, support and staff capacity can matter even when the visible purchase is small.
Keep these categories distinct:
Confirmed cost: supported by an approved quote, agreement or other suitable source.
Estimate: a reasoned figure with a basis, date, scope and uncertainty.
Assumption: a condition the case relies on but has not established.
Unquantified effect: a relevant benefit or cost that has not been given a reliable monetary value.
Use the organisation's agreed financial methods and assumptions with its finance owner. Do not invent a monetary return simply to fill a spreadsheet. Likewise, time released from a task is not automatically a cash saving or additional revenue. Explain what would have to happen for the proposed benefit to follow.
For a simple hypothetical illustration, reducing work by ten minutes on thirty cases would release five hours in that period if both the reduction and case count hold. That arithmetic does not show how the time will be used, whether staffing cost falls or whether the benefit recurs. Those are separate questions to investigate.
5. Test the assumptions that could change the recommendation
List the conditions the preferred option depends on. Prioritise the ones whose failure would change the decision, rather than producing a long list of minor unknowns.
For the onboarding example, the team may assume customers will use the new guidance, staff can keep it current and the integration can be delivered within the available capacity. Each assumption needs a suitable check and an owner.
Ask what happens if a benefit arrives later, the expected uptake is lower or a dependency is unavailable. Describe the effect on the recommendation. For a larger or formal case, use the organisation's required analysis with the responsible specialists; a narrative confidence statement cannot replace it.
Keep risks, assumptions and existing issues distinct. An unresolved integration problem already observed is different from the possibility of a future delay. A claim that “the team will adopt the process” is an assumption until supported. The assumptions and risks guide explains that distinction in more detail.
Output: a short set of decision-critical uncertainties, with a check, owner and consequence for each.
6. Explain how the proposal could be delivered
Identify the people, capabilities and dependencies needed to carry out the preferred option. State what has been confirmed and what still needs agreement. A proposed delivery date should not appear as a commitment before the delivery owner accepts it.
Include a proportionate sequence: preparation, implementation or pilot, review and the next decision. Explain who will own the change after launch. If a supplier or another team is essential, identify the dependency and the current status of that arrangement.
Plan how the organisation will evaluate the result. Who checks the outcome, when, against which baseline and with what evidence? What would cause the team to stop or adjust the initiative? A benefit that has no owner or review point can disappear between approval and delivery.
Do not bury a major unresolved condition in an appendix. If the recommendation depends on an unconfirmed capability or unavailable resource, make that visible in the decision request.
7. Write the recommendation and executive summary last
Once the comparison is coherent, write a concise opening that lets the approver understand the decision without reconstructing the whole analysis. Include the problem, preferred option, main reason, resources requested, material uncertainty and next review point.
For the fictional onboarding initiative, a useful opening might recommend a limited pilot because the full rollout depends on untested adoption and delivery assumptions. It should say what is needed to run the pilot and what evidence would support a later rollout. It should not describe the pilot's hoped-for result as an achieved saving.
Make the requested response explicit: approval, rejection, a changed scope or a decision to collect more evidence. If the next commitment is conditional, state the condition and who confirms it.
The supporting sections should let a reviewer challenge the recommendation. A clear business case can survive a different conclusion because its sources, alternatives and assumptions remain inspectable.
Use recorded discussions as evidence for a draft
Stakeholder meetings can supply the original problem, objections, constraints and alternatives. They rarely supply the entire business case. Costs may live in approved estimates, operational baselines in another system and authority in the organisation's approval process.
Start with relevant conversations and make their scope explicit. In Weeve, Chat can review saved recordings and help draft a proposed document from retrieved material. Ask first for the evidence: stated problem, options discussed, constraints, assumptions and unresolved disagreements, with source references. Review that before asking for a structured draft.
Genuine Weeve interface with synthetic demonstration content. The panel illustrates a reviewable draft, not a completed business case or financial calculation.
A useful request is: “Draft the narrative sections of a business case from these discussions. Separate sourced facts, estimates mentioned by speakers, assumptions and proposed recommendations. Mark missing costs, baselines and approvals as unknown. Cite the material claims.”
Check attribution and coverage. A speaker's estimate is not a verified cost; an idea is not an authorised commitment; no matching passage is not proof that nobody raised an objection. Weeve's library tools are read-only and do not approve expenditure, validate financial models or update external systems. Local Chat processes recording text on your Mac; optional cloud providers receive relevant text outside the device.
Review the case before requesting approval
Read it once as the person responsible for the decision and once as the person responsible for delivering it. Check whether the decision is bounded, alternatives are credible, numbers have sources, uncertainty is visible and delivery ownership is clear.
Pay particular attention to double-counting: the same improvement should not appear once as saved staff time and again as a separate benefit without explaining why both values are justified. Check that figures use consistent periods and scope. Ask the responsible owner to review any material financial assumption.
If the draft still depends on unsupported figures, seek a decision to investigate rather than presenting the full commitment as ready. If a concern would overturn the recommendation, give it space in the opening rather than hoping the reviewer misses it.
Keep the case useful after the decision
Preserve the version that was reviewed and record the actual decision, including conditions. Connect the approved scope to the project brief and the follow-up work. Do not rewrite an earlier forecast to make it match later events.
At the agreed review point, compare what happened with the assumptions and outcomes in the case. A changed situation may justify a different decision. Keep that reasoning visible so the document remains useful throughout the initiative, rather than becoming an approval attachment nobody consults again.
