Project Delivery · Project Control Methods
Project Business Case and Benefits Control
A business case is a live decision model, not a one-time funding form. It explains why the project is worth doing, compares feasible options and gives governance a reference point for deciding whether to continue. Benefits control then carries that logic beyond product delivery by assigning ownership, baselines, measures and review dates for the changes the project is meant to enable.
Executive summary
What this guide enables
A business case is a live decision model, not a one-time funding form. It explains why the project is worth doing, compares feasible options and gives governance a reference point for deciding whether to continue. Benefits control then carries that logic beyond product delivery by assigning ownership, baselines, measures and review dates for the changes the project is meant to enable.
Learning outcomes
- Distinguish project outputs, outcomes, benefits and dis-benefits.
- Develop a decision-ready business case without treating illustrative forecasts as guaranteed value.
- Maintain justification through stages, issues, risks and changes.
- Plan benefit ownership and measurement before, during and after project closure.
Control guidance
The business case as a control baseline
A business case assembles the information needed to judge whether a project is desirable, viable and achievable. Desirable means the intended change remains worthwhile and aligned with need. Viable means a feasible solution can be delivered and operated. Achievable means the organisation has a credible path through resources, capability, time, risk and change adoption. The case normally brings together reasons, options, expected benefits, dis-benefits, costs, timescales, major risks, affordability and an investment appraisal suitable for the decision.
The case is not proof that benefits will occur. It is an approved set of assumptions and forecasts with owners and uncertainty. Governance uses it to compare the latest forecast with the reason investment was authorised. A project can deliver all specified products and still represent a poor investment if costs grow, adoption becomes unlikely, a strategic need disappears or a better alternative emerges. Conversely, a forecast may change while remaining justified.
The accountable business representative owns the case and secures funding. The project manager develops and maintains the integrated delivery evidence, supports impact analysis and updates forecasts. User representatives specify benefit needs and confirm whether products can enable them. Supplier representatives confirm feasibility and cost assumptions. Assurance challenges optimism, missing options, weak measures and unowned exposure.
Desirable
The change addresses a real need, aligns with strategy or obligation, and offers acceptable value.
Viable
The proposed products, transition and operating model can work in the intended environment.
Achievable
Resources, capability, schedule, funding, risk responses and stakeholder change can be mobilised.
Control guidance
Trace value from output to benefit
An output is a product delivered by the project. An outcome is a changed condition, behaviour or capability that results when users or operations apply the output. A benefit is a measurable improvement arising from that outcome and perceived as advantageous by the investing organisation. A dis-benefit is a measurable negative consequence that is knowingly accepted as part of the change. Keeping these terms separate prevents a project from claiming value merely because an asset, system, procedure or facility was handed over.
For example, a project might deliver a new scheduling tool. Use of the tool could create the outcome of more consistent production sequencing. A benefit might then be reduced average changeover loss measured against a pre-project baseline. Training time and temporary disruption could be dis-benefits. The figures are illustrative and must not be transferred into another project as expected performance. Each project needs its own baseline, measure, time horizon and attribution logic.
The chain should identify dependencies outside the project. Operational leadership may need to change work practices, maintain master data, coach users or invest in supporting capability. If these actions are not funded and owned, the project output may be accepted while the intended outcome never occurs.
| Element | Control question | Owner | Evidence |
|---|---|---|---|
| Output | What will the project deliver and how will it be accepted? | Project and supplier leadership | Product description, quality and acceptance records |
| Outcome | What behaviour or capability changes when the output is used? | Operational or user owner | Transition plan and adoption indicators |
| Benefit | Which measurable improvement should arise, compared with what baseline? | Named benefit owner | Benefit profile, baseline and review result |
| Dis-benefit | Which negative consequence is accepted and within what boundary? | Business decision-maker | Approved trade-off and monitoring evidence |
Control guidance
Develop the case in layers
- 1
Clarify the reason
State the problem, opportunity, obligation or strategic need in outcome terms and identify who is accountable for resolving it.
- 2
Define the do-nothing position
Explain the likely operational, financial, safety, regulatory or strategic consequence if no project action is taken.
- 3
Identify feasible options
Include a minimum-change option and credible alternatives; do not compare only the preferred solution with an unrealistic baseline.
- 4
Estimate whole-life impact
Consider project cost, operational cost, transition, support, disposal, dis-benefits and residual risk, not only initial procurement.
- 5
Model benefits
Define baselines, measures, owners, dependencies, timing, uncertainty and the period over which value is expected.
- 6
Assess risk and sensitivity
Identify the assumptions that drive the conclusion and test how the decision changes when they deteriorate.
- 7
Recommend and approve
Explain why the preferred option offers the best balance of value, risk, feasibility and strategic fit within available authority.
Control guidance
Investment appraisal and uncertainty
The depth of appraisal should match the decision. A small project may compare whole-life cost, quantified annual saving, payback and major non-financial effects. A material investment may require discounted cash flow, scenario analysis, sensitivity testing and a clear treatment of optimism and contingency. The project-control method does not supply universal acceptance thresholds; those come from the investing organisation's policy, funding authority and risk appetite.
Avoid false precision. Separate source data, engineering estimates, supplier quotations, management assumptions and contingent benefits. State the confidence range and date of each material input. Where a benefit cannot be monetised reliably, define an operational measure and explain how it affects the decision. Do not assign an arbitrary dollar value merely to make all options appear comparable.
Sensitivity analysis should concentrate on decision-changing variables: adoption rate, delivery delay, demand, unit saving, resource availability, operating cost, useful life or regulatory date. The analysis is useful when it shows the boundary at which the preferred option no longer remains preferred, allowing governance to set monitoring triggers.
Net benefit = measurable benefit - project cost - transition cost - ongoing cost - quantified dis-benefitUse consistent time periods and state what has not been quantified. This expression is a planning aid, not a mandatory accounting rule.
Payback period = initial investment ÷ net benefit per periodPayback ignores value after the payback point and the time value of money; use a more complete appraisal when the decision warrants it.
Control guidance
Maintain and verify continued justification
The case is developed from the mandate or strategic plan, verified before major commitments, maintained with actual cost and forecast information, and confirmed through benefit reviews. At startup it may be an outline showing that initiation is worth funding. During initiation it becomes a robust baseline. At each stage boundary it is refreshed with stage performance, current exposure, next-stage cost and the latest benefits forecast. Material issues, risks and proposed changes trigger an impact assessment between gates.
Review should distinguish sunk cost from future value. Money already spent is relevant to learning and total return, but it should not force further investment if the remaining cost and risk no longer justify the achievable value. The decision options include continue unchanged, continue with conditions, reshape products or approach, defer, pause, transfer into another initiative, or close prematurely while salvaging useful products.
An exception plan should update the case when a forecast tolerance breach changes the authorised delivery path. A request for change should show benefit and dis-benefit impact, not only delivery cost. An off-specification should explain whether the product can still enable the intended outcome. Risk exposure should be reflected in viability, contingency and decision timing.
| Control question | Evidence to inspect | Decision or response |
|---|---|---|
| Has project value changed? | Updated benefits, dis-benefits, cost, schedule, risk, operational readiness and strategic context | Continue, reshape, pause or stop |
| Is the preferred option still preferred? | Current alternatives, remaining cost, feasibility and sensitivity | Confirm or select a different approach |
| Can the next stage be afforded? | Funding availability, commitments, contingency and forecast to complete | Authorise, condition or defer |
| Are dependencies owned? | Operational actions, external projects, policy decisions and benefit-owner commitments | Secure ownership or revise expected value |
Control guidance
Build a benefits management approach
The benefits approach defines what will be measured, by whom, when and using which baseline. Each benefit profile should include a clear description, link to outcomes and products, owner, baseline, target or direction of improvement, measurement method, data source, frequency, earliest and latest expected realisation, dependencies, risks and tolerance. Dis-benefits need equivalent transparency.
Measurements may begin before delivery to establish a credible baseline, continue during staged releases and extend after closure. The project can schedule reviews and create the measurement capability, but operational or programme authorities often own post-project reviews because the temporary project organisation no longer exists. Closure should therefore confirm named owners, dates, data access, reporting route and action authority for benefits that remain unrealised.
Benefits should not be double-counted across projects. Where several initiatives contribute to one outcome, define attribution or treat the benefit at programme or portfolio level. Also distinguish leading indicators, such as adoption or process compliance, from lagging benefits, such as cost reduction or service improvement. Leading indicators help early control but do not replace confirmation of realised value.
Benefit profile quality check
- Clear outcome-to-benefit causal link
- Baseline measured before the change where practical
- Accountable owner able to influence realisation
- Unambiguous data source and calculation method
- Timing, frequency and review decision defined
- Dependencies and enabling operational actions assigned
- Dis-benefits and unintended impacts visible
- No double counting with other investments
- Uncertainty and sensitivity communicated
- Post-project review ownership confirmed before closure
Control guidance
Worked example: decision at a stage boundary
Reassessing an automation investment
Situation: A pilot has delivered the planned technical product, but measured user adoption is below the assumption used in the approved case. The next stage would fund a broad rollout. Technical quality is acceptable and no project tolerance has yet been breached.
- The benefit owner separates the technical output from the adoption outcome and refreshes the value forecast using observed pilot data.
- The team identifies causes of low adoption, estimates the cost and time of corrective training and tests sensitivity to different adoption levels.
- The project manager updates the next-stage plan, risk exposure, dis-benefits and forecast to complete; the accountable business representative updates the recommendation.
- Governance authorises a limited adoption stage with explicit evidence gates rather than approving the original full rollout or closing immediately.
Control outcome: The decision protects value by changing the commitment size and demanding evidence about the actual constraint. Product completion alone does not drive the gate.
Must every benefit be financial?
No. Safety, compliance, service, capability and resilience can be legitimate benefits. They still need a measurable indicator and decision relevance.
Does a mandatory project need options?
Usually yes. The obligation may be fixed, but delivery approach, scope, timing and cost options can still be compared.
When should a project stop?
When the latest evidence shows the remaining investment is no longer justified or an authority determines that risk, affordability or strategic conditions are unacceptable.
Can the project manager own benefits?
The project manager can coordinate measurement, but lasting benefits should be owned by a business or operational person who can influence adoption and performance.