A business case is not a document written to make a project sound worthwhile. It is the point at which an organisation decides whether a problem is worth solving, whether the proposed response is credible, and whether it has the capacity to deliver it.
Knowing how to build a project business case properly matters because approval is only the beginning. A weak case can secure funding on optimism, then leave delivery teams to discover unclear scope, unavailable people, untested assumptions and benefits no one owns. That is how sensible initiatives become expensive disappointments.
A strong business case gives a sponsor a decision they can defend. It sets out the problem in commercial terms, compares realistic options, makes the investment visible and establishes the conditions required for delivery.
Start with the decision, not the document
Before drafting a single section, be clear about the decision you need. Is the executive team being asked to approve discovery work, select an option, release capital, commit internal resources or proceed to implementation? Each decision needs a different level of evidence.
For example, a community housing provider replacing a tenancy system may need approval for a short discovery phase before it can responsibly request full implementation funding. A financial services organisation responding to a regulatory change may have less choice about whether to act, but still needs leaders to decide on the right delivery approach and timing.
Write the decision in one direct sentence: “Approve Option B and release funding to begin implementation in July.” If you cannot write that sentence clearly, the case is not ready. The rest of the document should help decision-makers assess that request, not bury it.
Define the problem in terms leaders recognise
Projects are often framed as solutions too early: “We need a new platform” or “We need to automate this process.” That language assumes the answer before the organisation has agreed on the problem.
Instead, describe the current state and its consequences. Be specific about what is failing, who is affected, how often it occurs and what it costs the organisation. Costs may include direct expenditure, revenue leakage, rework, delayed service, compliance exposure, poor customer experience or an inability to scale.
Avoid broad statements such as “the current process is inefficient”. They invite challenge because they say little. A more useful statement might be: “Manual reconciliation requires four staff members for six business days each month, delays reporting by five days and creates a material risk of reporting errors.” That gives the reader something concrete to assess.
The problem statement should also explain the consequence of doing nothing. This is not fearmongering. It is the baseline against which every option must be judged. If the organisation can comfortably defer the work for two years, leaders should know that. If deferral increases compliance risk or blocks a growth program, they need to know that too.
Build the case around options, including doing nothing
A credible business case does not present a preferred solution as the only sensible path. It compares options fairly, including a genuine do-nothing or minimum-change option.
In most cases, three options are enough: maintain the current state, make targeted improvements, or implement the proposed change. Large programs may require more detailed alternatives, but too many options create false precision and slow decisions.
Assess each option against the same criteria: strategic alignment, expected benefits, implementation cost, timing, delivery risk, operational impact and ongoing effort. Some benefits will be financial. Others, particularly in government, aged care, disability services and not-for-profits, may relate to service quality, safety, access or regulatory compliance. They still need measures.
Do not manipulate the comparison to make the preferred option look inevitable. If it costs more, takes longer or requires difficult change, say so. Leaders are more likely to back a case that acknowledges trade-offs than one that pretends they do not exist.
Make the recommended option easy to understand
The recommendation should state what will be delivered, what will not be delivered and why this option offers the best overall outcome. It should also identify the key assumptions behind the recommendation.
Scope discipline is critical here. A business case is not a wish list for every related improvement. Define the outcome needed now, then make later opportunities visible as future phases or separate decisions. This protects the investment from expanding before the team has even started.
Turn benefits into accountable measures
Benefits are where many business cases lose credibility. “Improved efficiency”, “better visibility” and “enhanced customer experience” may all be true, but they are not benefits plans.
For each material benefit, identify the current baseline, target result, expected timing, method of measurement and accountable owner. If a new workflow is expected to reduce processing time, establish the current average time and decide when the reduction will be measured. If the project is expected to reduce incidents, define which incidents count and where the data will come from.
The benefit owner should be an operational leader with the authority to change the process, policy or behaviour required to realise the outcome. The project team can deliver a system, facility or new process. It cannot, on its own, ensure that the organisation adopts it or captures the value.
Financial modelling should be transparent rather than elaborate. Show one-off investment, ongoing operating impacts, expected savings or revenue effects, timing and assumptions. Where figures are uncertain, use ranges and explain what would change the result. A cautious forecast that can be traced is more persuasive than a headline number built on untested assumptions.
Show that delivery is possible
A project business case must answer a question that is often left until too late: can we actually deliver this without damaging business-as-usual operations or other priorities?
Set out the proposed delivery approach at a practical level. Include the main phases, indicative timeline, governance structure, dependencies, key internal roles and decision points. You do not need a detailed project plan at this stage, but you do need enough detail to demonstrate control.
Be honest about capacity. The people needed to make decisions, validate requirements, test changes and adopt new ways of working are often the same people running the organisation day to day. If their availability is assumed rather than confirmed, the schedule is already at risk.
This is also where a delivery assessment can change the recommended option. A technically attractive solution may be the wrong choice if it depends on a supplier not yet selected, a major data clean-up, legislative timing that cannot move or specialist capability the organisation does not currently have. The right answer is sometimes to stage the work, reduce scope or fund discovery first.
Treat risks as decisions to manage
A risk register pasted into an appendix does not make a business case safer. Focus on the risks that could genuinely change the decision: insufficient internal capacity, uncertain benefits, integration complexity, stakeholder resistance, procurement delays, data quality, regulatory deadlines or conflict with other programs.
For each major risk, explain the likelihood, consequence, mitigation and residual exposure. More importantly, identify what leaders need to decide or provide to reduce it. That might be a named sponsor, access to operational subject matter experts, a phased rollout or a clear escalation path.
Risk should not be used as a reason to avoid worthwhile change. Every meaningful project carries uncertainty. The purpose of the case is to make that uncertainty visible early enough to manage it properly.
Put governance and ownership on one page
Senior leaders should be able to see, quickly, who owns the investment and how decisions will be made. Name the executive sponsor, accountable business owner, project lead, steering group and key stakeholders. Clarify which decisions sit with which group.
Good governance is not more meetings. It is timely decisions, clear accountability and honest reporting when delivery moves off track. In our experience at JJPH, projects recover fastest when the sponsor has a clear view of scope, risks, dependencies and decisions required - not when they receive more status updates.
Before submission, test the case with the people who will be asked to approve it. Ask what evidence they would challenge, what assumptions they would question and what decision they believe is being requested. Their feedback is not a formality. It is the fastest way to expose gaps while they are still easy to fix.
A business case earns confidence when it is clear about both the opportunity and the work required to capture it. Give leaders a decision grounded in evidence, name the people who will carry it forward, and make the first delivery steps visible. That is how approval becomes progress rather than another document filed away after the meeting.
