Project governance

Business Justification

Keep the project worth doing from first idea through closure, using evidence, options, benefits, risk, and sponsor decisions rather than optimism.

What this helps you do

Business justification helps the PM and sponsor decide whether the project is still worth doing now, not just whether it was worth approving at the start. It connects the problem, expected benefits, cost, time, risk, disbenefits, and available options into a clear decision: continue, adjust, pause, recover, or stop.

Use this when

• Starting a project and deciding whether the idea is strong enough to move into initiation.
• Initiating a project and turning early intent into an approved baseline.
• Preparing a stage boundary where the sponsor must decide whether to continue funding and attention.
• A material change request affects scope, cost, delivery date, risk, benefits, or operational impact.
• The project is reporting amber or red and needs a recovery, reset, or stop decision.
• Benefits ownership is unclear or the project is delivering outputs without a credible route to value.

What good looks like

• The reason for the project is written in plain English and links to a real operational, customer, policy, compliance, or strategic need.
• Benefits have named business owners, not just project owners, and each benefit has a simple measure, baseline, target, and review point.
• Costs, time, major risks, disbenefits, and constraints are visible enough for a sponsor to make a trade-off decision.
• Options are compared honestly, including do nothing, minimum viable change, preferred option, and a lower-risk fallback where useful.
• The business case is refreshed at stage boundaries and after material change, not treated as a document created once at initiation.
• The sponsor can see the decision being requested, the recommendation, the evidence level, and what will happen if no decision is made.

Minimum viable version

• A one-page business case lite covering problem, outcome, preferred option, rough cost/time range, main benefits, main risks, and recommendation.
• At least one named benefit owner who accepts responsibility for realising value after project outputs are delivered.
• A simple benefit profile for each important benefit: measure, baseline, target, owner, expected timing, and review method.
• A decision log entry recording sponsor approval, conditions, assumptions, and any evidence gaps.
• A review point at every stage boundary or major change so the case remains live.

Stronger version

• Options appraisal with clear criteria such as value, affordability, delivery confidence, operational impact, sustainability, and risk exposure.
• Sensitivity view showing what happens if cost rises, delivery slips, benefits reduce, uptake is slower, or a supplier dependency fails.
• Benefit confidence trend reported through the control room: improving, stable, weakening, or no longer credible.
• Disbenefits and transition costs made explicit, especially where users, operations, suppliers, or public stakeholders carry the burden.
• Assurance or finance review for high-spend, high-public-value, regulated, or politically visible work.

Step-by-step

1. State the problem or opportunity in operational language. Remove vague phrases like transformation, modernisation, or efficiency unless they are backed by specific outcomes.
2. Define the outcome and success measures. Separate outputs the project will produce from benefits the organisation expects to realise.
3. Identify the realistic options. Include do nothing and minimum viable change so the preferred option is not treated as inevitable.
4. Estimate cost, time, risk, and confidence using ranges where evidence is early. Record assumptions so later changes are traceable.
5. Name benefit owners and confirm how benefits will be measured after delivery. Do not leave benefit ownership with the PM by default.
6. Check affordability and value. Ask whether the project remains worth doing if the main risk happens, delivery slips, or only partial benefit is achieved.
7. Write the recommendation as a decision request: approve, initiate, continue, adjust, recover, defer, or stop.
8. Review the business justification at every boundary, exception, and major change request. Update the decision log with the rationale.

Inputs needed

• Project brief or mandate describing the reason for the work.
• Sponsor objectives, strategic priorities, policy drivers, compliance needs, or service pain points.
• Cost, time, resource, and supplier estimates at the current evidence level.
• Risk, issue, dependency, and change information from the RAID view.
• Operational baseline data such as current cost, time, error rate, service performance, user experience, or compliance exposure.
• Stakeholder and benefit owner input, especially from the people who will operate or adopt the change.

Outputs produced

• Business case lite or full business case proportionate to project risk and governance needs.
• Benefits profile with owner, measure, baseline, target, timing, and review accountability.
• Decision recommendation for sponsor or board approval.
• Decision log entry showing approval, conditions, evidence gaps, and review date.
• Updated stage boundary or exception pack where continuation is being reviewed.

Common mistakes

• Treating the business case as a start-up document instead of a control tool for ongoing decisions.
• Listing benefits without owners, measures, baselines, or a credible path to realisation.
• Using precise-looking numbers too early and hiding the uncertainty that a sponsor needs to understand.
• Ignoring disbenefits such as transition pain, workload increase, service disruption, or reputational risk.
• Continuing because money has already been spent rather than because the forward case still makes sense.
• Approving a change request without checking whether the overall justification still holds.

Tailoring notes

• For Lite projects, use a one-page business case but keep the decision quality high: outcome, owner, cost/time range, risk, benefit, and recommendation.
• For Standard projects, refresh the business case at stage boundaries and after material change.
• For Enhanced projects, include options appraisal, sensitivity, benefit confidence, assurance input, and stronger financial evidence.
• For Recovery projects, rebuild the forward-looking case from today. Do not defend the original promise if the evidence has changed.
• For public-sector or high-social-impact projects, include public value, fairness, sustainability, privacy, policy fit, and audit-ready rationale.
• For agile or hybrid work, keep the strategic justification stable while reviewing benefit confidence and delivery options incrementally.

Questions PMs usually ask

Related templates

Related tools

PRINCE2 mapping

Maps to the PRINCE2 principle of continued business justification and the business case practice. In practical use, it is the evidence-led decision thread that runs through startup, initiation, stage boundaries, exception handling, change control, and closure.