Project Business Case | Options, Costs, Benefits, Risk & Justification

A project business case is the decision system that explains why a project should exist, what problem or opportunity justifies investment, which options were considered, what the project is expected to cost and deliver, what risks and assumptions could change the result, and whether the preferred option still deserves approval as evidence matures. In project management, a strong business case connects strategic alignment, project justification, options appraisal, cost-benefit analysis, benefits, costs, risks, return on investment, affordability, value for money and delivery feasibility into one governed argument rather than treating them as separate paperwork exercises.

A useful business case in project management does more than present a persuasive business case template. It compares realistic alternatives—including doing nothing or doing the minimum where those are legitimate choices—tests the economic and financial consequences, makes assumptions visible, identifies who receives the benefits and bears the costs, and shows how the proposed project will be delivered, governed, monitored and evaluated. The document is therefore both an investment proposal and a continuing test of whether the organisation is still solving the right problem in a defensible way.

This guide develops that full project business case from first principles. It covers strategic need, business case examples, business case analysis, options appraisal, project ROI, cost-benefit analysis, payback and discounted cash flow, non-financial benefits, risk and uncertainty, commercial strategy, funding and affordability, management arrangements, stage-gate approval, sunk costs, optimism, benefit ownership, disbenefits, evaluation and continued business justification. It also explains where the business case stops: the sponsor owns executive legitimacy, portfolio management compares investments, benefits realisation governs outcomes, risk management governs uncertainty, estimation produces forecasts, and project delivery turns an approved investment into controlled work.

The question before the project
What a business case is—and is not
The case for change
Objectives before solutions
The five-case lens
Generate options before comparing them
The do-nothing and do-minimum options
Critical success factors
Cost the whole decision
Benefits need owners, evidence and timing
Disbenefits and distribution
Cost-benefit analysis without false precision
ROI, payback and discounted cash flow
Value for money is not lowest price
Risk, uncertainty and sensitivity
Optimism, reference classes and independent challenge
Commercial feasibility
Affordability and the financial case
The management case: can this actually be delivered?
Business case stages and decision gates
Continued business justification
Sunk costs and the courage to stop
Business case vs charter, plan and benefits case
Business case in agile and hybrid delivery
Business case in AI projects
Worked case: replace, repair or retire a service
Worked financial model
Decision clinic: the attractive option that should not win
Decision clinic: when the preferred option stops being justified
A practical business-case review
Common failure modes
The deeper idea

1. The question before the project

Before a project has a schedule, a work breakdown structure, a risk register or a delivery team, it has a more fundamental question: why should this investment exist at all? That question is easy to weaken because organisations often encounter projects first as proposed solutions. Someone asks for a new platform, a larger facility, an AI assistant, a curriculum redesign or a supplier transition. The noun arrives before the justification.

A business case reverses that order. It starts with the condition that matters: a problem, opportunity, obligation or strategic change. It asks what happens if nothing changes, what outcomes the organisation actually needs, what realistic options exist, what each option costs, what benefits each may create, what risks and dependencies could alter those results, whether the organisation can afford and deliver the preferred option, and what evidence would later justify continuing.

Consider a fictional service organisation whose appointment platform is becoming expensive to maintain. A senior manager proposes a full replacement. The suggestion feels sensible because the current system is old, support is difficult and users complain. Yet four different responses are possible: keep the platform for another period and accept the consequences; repair and extend it; replace it with a managed service; or build a more ambitious custom platform. “Replace the old system” is therefore not yet a business case. It is one candidate answer.

The discipline matters because projects consume more than money. They use executive attention, specialist capacity, organisational change tolerance, procurement effort, transition time and the opportunity to do something else. Approving one project can delay another. Even a technically successful project can destroy value if it solves the wrong problem, arrives after the opportunity has passed or creates operating costs that exceed the benefit.

The Association for Project Management defines a business case as the justification for undertaking a project, programme or portfolio and describes it as an evaluation of the benefit, cost and risk of alternative options. HM Treasury’s 2026 Green Book likewise treats appraisal as structured comparison of costs, benefits and risks across options for achieving objectives. These sources belong to different institutional contexts, but they converge on a critical principle: the business case is not a ceremonial explanation of the option leadership already wants. It is a structured reason for choosing among alternatives. APM: What is a business case? HM Treasury: The Green Book 2026

This also explains why the business case should not disappear after approval. Early estimates are broad, assumptions are immature, supplier information may be incomplete and benefits may depend on behaviour the organisation has not yet observed. As the project learns, the justification becomes more accurate. Sometimes the evidence strengthens the investment. Sometimes it reveals that the chosen solution should change. Sometimes it shows that the project should stop.

The business case therefore sits before and above many other project controls without replacing them. Project Planning asks how the approved objective will be delivered. Project Risk Management manages uncertainty. Project Estimation constructs forecasts. Project Benefits Realisation governs whether intended outcomes actually occur. The business case draws evidence from all of them to answer the investment question.

The reader job of this article is therefore precise. It is not to provide a decorative template. It is to make the investment argument inspectable. By the end, a reader should be able to distinguish strategic need from solution preference, compare options without false precision, recognise when a financial model hides an assumption, identify which benefits need real owners, and understand when new evidence should trigger a change, pause or stop decision.

2. What a business case is—and is not

A business case is often mistaken for a project charter, budget request, sales pitch or project plan. Those artefacts can contain overlapping information, but they answer different questions. The business case explains why a particular investment choice is justified. The charter authorises a project and names its broad authority. The budget allocates funding. The plan explains how delivery will be organised. A persuasive proposal can support a business case, but persuasion without comparison is not appraisal.

The distinction becomes clear when the preferred solution changes. Suppose the organisation originally believed a custom build was necessary. Market testing later shows that a managed service can satisfy the critical requirements at lower whole-life cost and lower implementation risk. A project charter written around “build a custom platform” may need revision. A well-constructed business case can survive the change because its deeper purpose is to solve the service problem and achieve defined outcomes, not protect the initial technology preference.

A business case should also be distinguished from a business plan. A business plan may describe how an ongoing enterprise intends to operate, grow and earn revenue. A project business case concerns a specific proposed investment or change. It may use business-plan data, but it has a bounded decision: should this intervention proceed, in which form, under which conditions, and with what continuing tests of justification?

Nor is the business case merely a financial spreadsheet. Some projects have strong financial returns and weak strategic fit. Others are mandatory because of safety, regulation or essential-service obligations and should be evaluated through cost-effectiveness, compliance and feasible alternatives rather than pretending every benefit can be monetised. Public-sector appraisal often distinguishes social value from narrow cash return; private organisations may still need to consider non-financial strategic benefits, resilience or capability.

A useful business case contains an argument with evidence. The argument has a recognisable structure: there is a problem or opportunity worth addressing; the objectives follow from that need; plausible options have been generated; options have been assessed against relevant success criteria; costs, benefits and risks have been estimated; the preferred option is affordable enough and deliverable enough; the governance and benefit ownership are credible; and the decision can be revisited when important assumptions change.

This is why a one-page business case can be excellent for a small reversible decision while a sixty-page document can be weak for a major irreversible investment. Length does not create justification. The amount of analysis should follow consequence, uncertainty and reversibility. A small internal tool may require a concise case. A new campus, core banking platform or major public infrastructure decision may require extensive modelling, specialist evidence and independent review.

The same principle governs this 20,000+ word article. The length is not an SEO claim. Search engines do not require a preferred word count. The depth is justified because the reader job crosses strategy, economics, finance, risk, commercial structure, delivery feasibility, governance and evaluation. Each section has to preserve its own boundary while returning to one central proposition: an investment deserves approval only while its justification remains stronger than the credible alternatives.

A business case is therefore best treated as a living decision model. The “document” is one representation of that model. Its tables, assumptions, forecasts and approval records should point to evidence that can be updated. If the only surviving artefact is a polished PDF whose numbers cannot be reconstructed, the organisation has preserved presentation rather than decision capability.

3. The case for change

The strongest business cases begin by describing the present condition before describing the preferred future. A weak opening says, “We need a new system.” A stronger opening says, “The current process creates an average of X hours of avoidable manual work, fails to meet a defined requirement, depends on a technology reaching end of support, or prevents a strategic capability the organisation has decided it needs.” The solution comes later.

The case for change should separate evidence from interpretation. In the fictional service organisation, evidence might include rising support cost, service incidents, manual reconciliation time, user abandonment, inaccessible workflows, vendor support notices and audit findings. Interpretation connects those facts to strategic consequence: cost is rising faster than demand, service reliability threatens a commitment, the existing platform cannot support a required future operating model, or the organisation is exposed to an unacceptable risk.

Good diagnosis also asks whether the problem is actually caused by the asset targeted for replacement. Slow service may come from policy, staffing, unclear responsibilities or poor data rather than technology. Replacing the interface could leave the real constraint untouched. A business case that begins with a solution can spend millions to automate a confused process more quickly.

The counterfactual is essential: what happens if the organisation does nothing material? “Do nothing” rarely means literally no activity. Existing operations continue, current maintenance continues, risks evolve, demand may change and some costs remain. The counterfactual establishes the baseline against which the intervention’s incremental costs and benefits should be assessed. Without it, the case can credit the project for outcomes that would have happened anyway.

The case for change should also identify who experiences the problem. A cost-saving project may reduce central expenditure by transferring work to frontline staff. A digital service may improve access for most users while excluding people who need assisted channels. A building consolidation may reduce property cost while increasing travel time. These distribution effects matter because “the organisation” is not a single person experiencing one outcome.

Strategic alignment is stronger when it is specific. “Supports digital transformation” is usually too vague. Identify the actual strategic objective: reduce service failure, reach a new market, comply with a regulation, improve student progression, shorten a critical response time, retire an unsupported system or enable a future portfolio capability. Then show the causal link between the proposed project and that objective.

A project can align with strategy and still be a poor investment. Several different projects may support the same strategic objective. One may offer better value, lower risk or stronger timing. This is where Portfolio Management becomes the neighbouring owner: the portfolio compares candidate investments across the organisation. The business case gives that portfolio decision something credible to compare.

Before moving to objectives, the case for change should be testable in a simple sentence: because the current state produces these evidenced consequences, and because those consequences matter to these strategic or mandatory objectives, a decision about intervention is justified. Notice what the sentence does not say. It does not yet say which intervention should win.

4. Objectives before solutions

Once the need is clear, the business case should define the outcomes the intervention must achieve. Objectives become the bridge between diagnosis and options. If they are written after the preferred solution has been chosen, they can become retrofitted reasons for that solution. If they are defined from the need, several options can compete against the same standard.

Suppose the service organisation writes this objective: “Implement Platform Z by December.” That is a solution-and-date statement. It may be useful later as a delivery commitment, but it does not help compare options. A better objective might be: “Reduce avoidable appointment-processing effort while maintaining service availability, accessibility and required information controls before the current support arrangement expires.” This describes the result without prescribing the technology.

Objectives should be specific enough to discriminate among options. “Improve customer experience” is difficult to appraise. “Reduce the proportion of users who need staff assistance for a routine reschedule while preserving an assisted route for users who need it” creates observable outcomes and an accessibility guardrail. “Improve resilience” becomes stronger when the case defines the service condition the organisation must sustain and the recovery capability required.

Not every objective belongs in one metric. A business case may contain economic, operational, compliance, service and strategic objectives. The challenge is to avoid an unranked list where every desirable property is declared equally critical. Some conditions are mandatory gates. Some are optimisation goals. Some are preferences. The distinction changes how options should be compared.

Objectives also need time boundaries. A project that saves money over ten years may be unattractive if the organisation must survive a funding constraint next year. A rapid workaround may solve the immediate problem but create expensive technical debt after three years. The case should state the relevant decision horizon rather than allowing short-term and long-term consequences to be mixed opportunistically.

Benefits and objectives are related but not identical. An objective is a condition the intervention is intended to achieve. A benefit is a measurable improvement resulting from that condition. For example, the objective may be to reduce manual reconciliation; the benefit may be staff hours released for higher-value work, lower operating cost or faster service. Project Benefits Realisation later governs whether those improvements actually occur.

The objective set should survive challenge from an option the author does not prefer. If a low-cost process redesign satisfies the objectives as well as a large software replacement, the business case should allow that result to emerge. If the objective language makes only one preselected solution possible, the appraisal has been constrained before it begins.

By the time the fictional organisation finishes this step, it has not “approved a platform project.” It has approved a problem statement and a decision framework: maintain reliable and accessible appointment service, reduce avoidable manual effort, preserve required controls, retire unacceptable support risk, remain affordable, and create an operating model the organisation can sustain. Only now is it ready to ask what options could achieve those outcomes.

5. The five-case lens

One useful way to prevent the business case from becoming a financial spreadsheet with decorative narrative is to examine the proposal through several linked dimensions. The UK Government’s Five Case Model does this explicitly through the strategic, economic, commercial, financial and management cases. APM presents a closely related five-part view: strategic context, economic analysis, commercial approach, financial case and management approach. The terminology is institutional; the underlying logic is widely transferable. HM Treasury: The Green Book 2026 APM: What is a business case?

The strategic case asks whether there is a real need for change and whether the intended outcome aligns with the organisation’s objectives or obligations. It should be possible for a financially attractive proposal to fail here if it distracts from strategy or solves a problem the organisation does not need to solve.

The economic case asks which option creates the strongest overall value relative to alternatives. In public-sector settings, that may include social costs and benefits that do not appear as cash flows to one organisation. In private organisations, economic reasoning can still extend beyond simple accounting return: strategic capability, customer retention, resilience and opportunity cost may matter. The economic case is where options appraisal lives most visibly.

The commercial case asks whether the market and contracting strategy can support the preferred option. A solution may look attractive on paper but depend on suppliers that do not exist, an impossible allocation of risk, restrictive intellectual-property terms, or a procurement model that destroys competition. Commercial feasibility is not the same as technical feasibility.

The financial case asks whether the organisation can afford the option within its actual funding, cash-flow and accounting constraints. An option may create strong long-term value and still be unaffordable this year. Another may fit the capital budget but create an operating-cost burden the receiving organisation cannot sustain.

The management case asks whether the preferred option can be delivered and sustained. It includes governance, change management, benefit ownership, risk management, monitoring, evaluation, contingency and the practical route from approval to operation. HM Treasury’s 2026 Green Book describes the management case as the practical arrangements for successful implementation, including governance, change, benefits, risks, monitoring, evaluation and contingency.

The five cases should not become five isolated essays. A commercial decision can change the financial model. A risk can change the preferred economic option. A delivery constraint can make an otherwise attractive option unrealistic. A strategic change can remove the need for the whole project. The strength of the framework lies in forcing the decision to survive several perspectives on the same proposal.

For a small organisation, these dimensions can fit on a few pages or one decision canvas. For a major capital programme, each may require extensive analysis. The framework scales through depth, not through mandatory bureaucracy. The core question remains: is the need real, is this the best way to address it, can we transact for it, can we afford it, and can we actually make it work?

6. Generate options before comparing them

Options appraisal is weak when all options are minor variations of the preferred answer. “Buy Product A, buy Product B, or buy Product C” may be too narrow if the real alternatives include repairing the current process, changing policy, outsourcing part of the work, removing a low-value requirement, combining services or delaying investment until uncertainty is reduced.

The 2026 Green Book is unusually explicit that options generation and longlist appraisal are often overlooked because practitioners are tempted to jump directly to detailed cost-benefit analysis. It argues that the longlist should be generated and documented before the shortlist is analysed in depth. This matters because sophisticated analysis of a poor option set can still produce a poor decision.

A practical option-generation workshop should begin with the objective and constraints, not with vendor names. Ask: what different mechanisms could produce the required outcome? Could demand be reduced? Could the current asset be extended? Could the process be redesigned? Could capability be shared with another unit? Could an existing platform be configured? Could a managed service be bought? Could a custom solution be built? Could the change be staged?

Some options can then be screened out quickly using legitimate critical success factors. A solution that cannot meet a legal requirement does not deserve elaborate financial modelling. A solution that depends on a supplier market known not to exist may be commercially infeasible. A solution that requires more annual operating funding than the organisation can ever secure may fail an affordability gate.

But screening should be documented. Otherwise a preferred option can appear to have won against competitors that were never allowed into the analysis. For each excluded option, record the decisive reason. “Rejected because senior management does not like it” is different from “rejected because it fails mandatory accessibility requirements” or “rejected because market testing found no supplier capable of supporting the required jurisdiction.”

The longlist can include combinations as well as pure strategies. The fictional appointment service might combine a process simplification with a smaller managed platform, rather than choosing between “process” and “technology” as mutually exclusive categories. A business case should be alert to false binaries created by organisational structure.

Option generation is also a chance to reduce uncertainty before commitment. If the difference between two options depends on whether the existing data can be reused, a short discovery exercise may be more valuable than arguing from assumptions. Project Assumption Management provides the neighbouring discipline: identify the assumption, show what depends on it, and replace it with evidence before an irreversible decision where possible.

The strongest longlist is not the longest. It is broad enough to represent materially different ways of meeting the objective. Once those mechanisms have been surfaced and screened transparently, the shortlist becomes a meaningful field for deeper economic, financial, commercial and delivery analysis.

7. The do-nothing and do-minimum options

Every business case needs a credible counterfactual. The most useful baseline is often called “business as usual,” “do nothing” or a comparable term. It describes what is expected to happen if the proposed intervention is not undertaken. This is not the same as pretending the world freezes.

If the current system continues, support costs may rise. Vendor support may expire. Staff may keep performing manual work. Service demand may grow or fall. A competitor may enter. A regulation may take effect. The organisation may need unavoidable maintenance simply to keep operating. Those consequences belong in the baseline because they occur without the proposed project.

The “do minimum” option is often distinct. It represents the smallest intervention that keeps the organisation compliant or functional. In the fictional appointment service, do nothing might mean continue the current support arrangement until failure or contractual expiry. Do minimum might mean a targeted technical refresh, security patching and limited process redesign sufficient to maintain service for three years.

These baselines protect the appraisal from overclaiming benefits. Suppose demand is expected to increase by 10 percent even without the project. If the preferred option increases transactions by 12 percent, the incremental benefit attributable to the project may be closer to 2 percent than 12, depending on the causal model. Similarly, if the organisation must spend $500,000 maintaining the old system regardless, a replacement’s incremental cost should be compared with the avoided baseline expenditure rather than with zero.

The baseline can also win. If the problem is modest, technology is changing quickly and the decision can be revisited cheaply in a year, “do minimum and learn” may create more value than immediate large-scale investment. A business case that treats non-intervention as inherently irresponsible cannot discover that result.

There are situations where doing nothing is not legally or ethically available. A safety defect may require action. A regulation may mandate compliance. A failing essential service may need intervention. Even then, options appraisal remains meaningful: different compliant responses may have different costs, risks and operational consequences. The “baseline” becomes the minimum lawful or safe response rather than literal inaction.

The counterfactual should also be reviewed later. If the external world changes, the original baseline may become obsolete. A new regulation may make the old system impossible to retain. A supplier may extend support. A market price may collapse. Continued business justification depends on comparing the project with the best current alternative, not endlessly comparing it with the world imagined at initiation.

A simple quality test is to ask whether the business case author would be comfortable if the baseline option won. If the answer is no because the project team has already been formed, the preferred vendor announced and the launch date promised, the appraisal may be occurring too late to be genuinely comparative.

8. Critical success factors

Critical success factors are the attributes an option must possess if it is to be a credible candidate. The 2026 Green Book describes them as attributes necessary for an option to achieve the proposal’s objectives successfully. Used well, they create an explicit bridge between strategy and option screening. Used badly, they can be written to guarantee the preferred option wins.

A critical success factor should be traceable to the problem, objectives or genuine constraints. For the fictional service case, mandatory factors might include compliance with information-control requirements, support for assisted access, credible migration of existing records, continuity through transition, affordability inside the available funding envelope and an operating model the organisation can sustain.

“Must use cloud technology” is not a legitimate critical success factor merely because the technology team prefers cloud. It could become legitimate if the organisation has a formally approved architecture policy and the project is required to conform. The source of the factor should be visible.

Some factors are non-compensatory. An option that fails a mandatory legal requirement should not win because its ROI is high. Others are tradeable: one option may cost more but create stronger service benefits. The business case should distinguish gates from scored criteria. Averaging everything into one weighted score can allow an unacceptable failure to disappear inside a high total.

Weighted scoring can still be useful for tradeable attributes if weights are defined before the results are known and the basis is transparent. The team should perform sensitivity analysis on the weights. If the preferred option changes whenever one subjective weight moves slightly, the decision is fragile and deserves more judgement rather than more decimal places.

A critical success factor should also describe the required outcome rather than a feature of one solution where possible. “Must integrate with the existing finance system using the approved interface” may be a genuine interoperability constraint. “Must use Vendor X’s integration module” is a solution choice unless authority or existing architecture makes it mandatory.

The factors should be reviewed as the project learns. A previously mandatory requirement may be changed through legitimate governance. A new legal obligation may appear. A supplier dependency may become unacceptable. The business case should preserve the history of those changes because altering the success factors can alter which option would have been preferred.

At the end of this step, the organisation has a defensible shortlist. It knows what problem is being solved, what outcomes matter, what alternatives exist, what baseline they are compared against and which conditions every viable option must meet. The next challenge is harder: calculate the whole consequence without pretending the future is known precisely.

9. Cost the whole decision

A project business case becomes misleading when it compares one option’s full cost with another option’s partial cost. Purchase price is only one component. The relevant decision may include discovery, design, procurement, implementation, migration, integration, training, transition, support, licences, hosting, maintenance, security, assurance, decommissioning, exit and residual obligations.

Whole-life costing asks what the organisation must spend because it chooses this option rather than the baseline. For a managed software service, the visible implementation fee may be modest while recurring subscription and data-exit costs dominate later. A custom build may require large initial expenditure and lower licence cost but higher internal maintenance, specialist retention and upgrade responsibility. A repair option may appear cheapest until repeated maintenance and delayed replacement are included.

Costs should be incremental where the decision calls for incremental analysis. Suppose five staff are already employed and will remain employed under every option. Their salaries may matter to resource capacity but may not be cash savings generated by the project. If the preferred option “saves” 5,000 staff hours yet no staffing cost is actually released, presenting those hours as immediate cash savings would overstate the financial benefit. The hours may still create capacity for other work and should be valued honestly under that mechanism.

Likewise, sunk costs should be kept separate from future decision costs. Money already spent cannot be recovered by choosing one future option over another. It may explain how the organisation arrived at the decision point, but it should not make an otherwise weak option preferable simply because “we have already invested too much to stop.” Chapter 22 returns to that problem directly.

Timing matters. Two options with the same undiscounted total cost can create very different funding pressure. One may require most expenditure next year; another may distribute cost over five years. A project can therefore be economically attractive but financially unaffordable within the organisation’s cash or capital constraints. That distinction is why financial affordability deserves its own analysis rather than being inferred from value for money.

The cost estimate also needs a Basis of Estimate: what scope is included, what rates are used, what assumptions govern productivity, what contingency is included, what is excluded and how mature the estimate is. A number without a basis is difficult to challenge and almost impossible to update responsibly when new evidence appears.

Taxes, inflation, escalation, exchange rates and financing should be treated consistently according to the organisation’s appraisal rules. This article does not prescribe one accounting basis because public-sector economic appraisal, commercial investment analysis and internal budgeting can use different conventions. The important requirement is internal consistency: compare options using compatible bases and explain any differences that matter.

Opportunity cost belongs in the conversation even when it does not appear as a line item. If a project consumes the only senior architect for a year, what higher-value work cannot proceed? If a school programme uses classroom capacity that displaces another activity, the lost alternative matters. Opportunity cost is often hard to monetise precisely; difficulty does not make it conceptually irrelevant.

A strong cost model therefore answers more than “how much?” It answers how much compared with what, paid by whom, at what time, under which assumptions, over what life, with what uncertainty, and with which obligations left behind at exit?

10. Benefits need owners, evidence and timing

Benefits are where many business cases become most optimistic because future improvements are easy to describe and difficult to falsify before the project begins. “Improved efficiency,” “better customer experience,” “higher productivity” and “enhanced decision-making” can sound persuasive while remaining too vague to manage.

A credible benefit has a mechanism. Suppose the preferred platform allows customers to reschedule without staff intervention. The causal chain might be: self-service capability → fewer routine calls → fewer staff hours spent on rescheduling → released capacity or reduced staffing need → financial or service benefit. Each arrow contains an assumption. If customers still prefer calling, the software capability exists but the benefit may not.

Benefits need owners because projects produce outputs while operations usually create the outcomes. The project can implement the new platform. An operational manager may need to redesign staffing, retire the old process and ensure adoption before savings occur. If no one owns that post-delivery change, the business case can count a benefit that nobody is responsible for creating.

The benefit should also have a baseline, target, measurement method and expected timing. “Reduce manual appointment changes by 30 percent within six months of full rollout, measured from service records against the pre-rollout baseline” is stronger than “improve efficiency.” The target may still be uncertain, but its meaning is inspectable.

Cash-releasing and non-cash-releasing benefits should be distinguished. If staff time is freed but headcount and spending remain unchanged, the organisation may gain capacity rather than cash. That capacity can be highly valuable if it is used for unmet demand or higher-value work. Calling it direct cost reduction would be misleading unless expenditure genuinely falls.

Revenue benefits require similar care. A new service may be expected to attract more customers, but the forecast should identify whether the project creates the demand, merely enables capacity to serve existing demand, or relies on a separate marketing programme. Benefits shared across several projects should not be counted in full by each one.

Strategic benefits can be real even when they resist monetisation. A project may create a platform capability needed for several future products, improve resilience, preserve regulatory permission to operate or create evidence valuable for later decisions. These benefits should be described with appropriate evidence and decision relevance rather than forced into arbitrary dollars solely to make them fit a spreadsheet.

Project Benefits Realisation owns the post-approval discipline of converting outputs into outcomes and measuring whether intended benefits occur. The business case owns the earlier question: are the expected benefits plausible enough, attributable enough and valuable enough to justify investment relative to alternatives?

A mature business case is willing to say, “This benefit is important but not yet quantified,” rather than invent precision. It can then define what evidence will be gathered before the next gate. Uncertainty made visible can be managed. Uncertainty disguised as a precise forecast becomes a governance problem.

11. Disbenefits and distribution

Every meaningful change can create losers as well as winners. A disbenefit is a negative consequence of the option that is accepted as part of achieving the larger outcome. Business cases that record only benefits produce an incomplete picture of value.

The appointment platform may reduce staff handling of routine changes but increase training burden during transition. It may make service easier for digitally confident users while requiring additional assisted support for others. A managed service may improve reliability but reduce flexibility. A custom build may create strategic control while increasing long-term maintenance responsibility.

Distribution matters because an aggregate net benefit can hide concentrated harm. Saving 10,000 hours centrally while imposing 12,000 hours of extra work on customers is not an efficiency improvement from a whole-system perspective. A building consolidation can reduce property cost while increasing travel burdens on employees or service users. Whether those effects are acceptable requires explicit judgement, not arithmetic alone.

Some costs are difficult to monetise and still need to be visible. Loss of professional autonomy, reduced service choice, accessibility barriers, transition stress, retraining burden, environmental effects and supplier concentration can matter materially. The business case should describe them at a level proportionate to the decision.

There is also a timing asymmetry. Costs often occur early and visibly; benefits arrive later and conditionally. Transition disbenefits can therefore threaten adoption before the long-term gain appears. A management case that ignores those temporary burdens may underestimate resistance and operational risk.

Disbenefits should have owners too. If the project knowingly creates a temporary service slowdown during migration, who protects vulnerable users? If a new process removes a familiar role, who manages retraining and redeployment? If a supplier change creates a period of dual running, who funds and coordinates it?

The distribution question can also influence option choice. Two options may produce similar total value, but one may place unacceptable burden on a group the organisation has a duty to protect. Another may spread cost more fairly or preserve a necessary assisted route. A business case should make such trade-offs visible rather than burying them inside a total score.

This is one reason “ROI” cannot be the sole measure of a project business case. Return to the investing organisation is important, but it does not necessarily describe the full social, operational or ethical consequence of the decision. The appropriate evaluation frame depends on the organisation’s purpose and obligations.

A useful question is: who becomes better off, who becomes worse off, by how much, when, and who has authority to decide that the trade is acceptable? A business case that cannot answer that question is not yet describing the full investment.

12. Cost-benefit analysis without false precision

Cost-benefit analysis asks whether the value of an option’s expected benefits justifies its expected costs relative to alternatives. The arithmetic can be simple. The difficult work lies in defining the counterfactual, estimating quantities, valuing impacts, avoiding double counting and representing uncertainty.

Suppose Option A costs $1.0 million over its relevant life and is expected to produce $1.5 million of monetised benefits. Option B costs $1.4 million and produces $2.1 million of monetised benefits. A simple undiscounted net-benefit comparison gives $0.5 million for A and $0.7 million for B. That result does not automatically make B preferable. Timing, uncertainty, affordability, strategic fit and non-monetised impacts still matter.

The comparison is only as valid as the baseline. If $0.3 million of the benefit would occur without either project, both options need adjustment. If the options share a common enabling project whose benefits are counted elsewhere, double counting must be avoided. If Option B’s additional $0.6 million benefit depends on an untested adoption assumption, the headline $0.7 million net benefit is more fragile than it appears.

Monetisation can support comparability, but not every impact should be given a made-up price. Some organisations use established values for time, emissions, reliability or risk reduction. Where no defensible valuation exists, the impact can be reported separately and included in decision judgement. “Not monetised” should not mean “not considered.”

Cost-benefit analysis should also preserve causality. If a project is expected to reduce complaints, ask how the proposed change leads to fewer complaints and whether another cause could dominate. Financial models often create an illusion of causal certainty because each cell contains a number. A number can be precise while the causal link behind it is weak.

Ranges and scenarios are often more informative than one deterministic total. The case can show a central estimate alongside lower-benefit or higher-cost scenarios. Sensitivity analysis can identify which assumption controls the result. If the preferred option remains preferred under plausible variation, the decision is robust. If a minor assumption reversal changes the winner, the organisation may need more evidence before commitment.

Public-sector economic appraisal can include social costs and benefits beyond the cash flows of the sponsoring organisation. HM Treasury’s Green Book is a primary example of that broader frame. Private organisations may use narrower corporate measures, but they should still avoid treating accounting return as the only possible expression of strategic value.

Good analysis therefore distinguishes calculation from judgement. The spreadsheet can show that under stated assumptions one option has the highest expected net benefit. It cannot decide whether the uncertainty, distribution, timing or strategic consequence is acceptable. Those decisions belong to legitimate governance.

The goal is not to make the business case less quantitative. It is to make the quantities more honest. A credible model allows a reviewer to trace where a number came from, what assumption drives it, what happens when that assumption changes and which important effects remain outside the monetised total.

13. ROI, payback and discounted cash flow

Return on investment is popular because it compresses a decision into one ratio. A common simple form is (benefit − cost) ÷ cost. If an option costs $1.0 million and produces $1.4 million of benefits on the same compatible basis, the simple ROI is 40 percent. The ratio is easy to communicate. Its usefulness depends entirely on what the numerator and denominator contain.

ROI can mislead when options have different lifetimes, timing or scale. A 100-percent return on a $50,000 project may create less total value than a 30-percent return on a $5 million project. An option whose benefits arrive in Year 8 is not equivalent to one whose benefits arrive in Year 1. A project that produces a high accounting ROI while violating a mandatory requirement is not rescued by the ratio.

Payback period asks how long it takes cumulative benefits or cash inflows to recover the initial investment. It can be useful when liquidity or uncertainty beyond a certain horizon matters. It also ignores much of what happens after payback. Two options can pay back in three years while one creates much larger later benefits—or larger later liabilities.

Discounted cash flow addresses timing by reducing future cash flows to a present-value basis using an appropriate discount rate. The basic idea is that a dollar received years from now is not equivalent to a dollar available today. The exact discount convention should follow the organisation’s appraisal framework. This article does not prescribe a universal rate.

For an illustrative private investment, suppose an organisation uses an 8 percent internal discount rate purely for teaching purposes. A $1 million cost today followed by $300,000 of net cash benefit at the end of each of Years 1 through 5 has a present value of approximately $1.198 million for those benefits and therefore a net present value of roughly $198,000. The precise result depends on timing assumptions and the chosen rate; the method matters more than the decorative precision.

Net present value is useful because it expresses the difference between discounted benefits and discounted costs. A positive NPV can support an investment case, but again it is not the entire decision. Risk, strategic fit, affordability and non-monetised effects remain relevant. An option with a lower central NPV may be preferred if the higher-NPV option depends on unrealistic assumptions or creates unacceptable downside.

Internal rate of return is another commonly used measure, but it has well-known interpretation problems when cash-flow patterns are unusual or projects differ in scale. Organisations should use financial metrics that fit their governance and understand what each metric omits rather than accumulating ratios because they appear sophisticated.

A strong business case can show several measures without allowing them to compete for rhetorical dominance. ROI answers one question. Payback answers another. NPV answers another. Affordability answers whether the organisation can actually fund the option. Value for money asks whether the option creates sufficient overall value relative to credible alternatives. The decision improves when those questions remain distinct.

14. Value for money is not lowest price

“Value for money” is sometimes reduced to buying the cheapest option. That interpretation can be dangerous. The UK Government’s current guidance defines value for money in terms of the best mix of quality and effectiveness for the least outlay over the relevant period of use, not simply the lowest upfront price. The exact public-sector definition belongs to that context, but the general insight transfers: price is one component of value.

Suppose Option A costs $600,000 and is likely to require replacement after three years. Option B costs $850,000 and is expected to last seven years with lower support cost. Option C costs $700,000 but introduces a supplier concentration risk that could make exit expensive. Choosing A because its purchase price is lowest ignores life, support, risk and residual obligations.

Value for money should also resist “maximum benefit at any cost.” The highest-benefit option may have marginal improvements that are not worth the additional expenditure or risk. The decision asks whether the incremental benefit of moving from one option to another justifies the incremental cost and exposure.

This can be expressed through incremental analysis. Suppose a medium option costs $1.0 million and produces expected monetised benefits of $1.5 million. A premium option costs $1.5 million and produces $1.7 million of benefits. The premium option produces $200,000 more expected benefit for $500,000 more cost on this simplified basis. Unless important non-monetised advantages justify the difference, the medium option may offer stronger value.

Value can also depend on flexibility. An option that preserves future choices may be worth more than one that locks the organisation into an irreversible architecture, even if central financial estimates are similar. Conversely, excessive flexibility can be expensive if the organisation knows with high confidence which capability it needs.

The business case should therefore explain why the preferred option represents the strongest overall balance rather than simply naming the metric on which it scores highest. One option may lead on NPV, another on affordability, another on speed and another on strategic control. The recommendation should show which differences matter to the objectives and which are secondary.

Value for money is also affected by the market and delivery model. A theoretically efficient design can become poor value if contracting it requires excessive risk premiums or if only one supplier can deliver it. The commercial case and economic case therefore need to inform each other.

A useful final question is: if this were our own money, time, organisational capacity and reputation, what evidence would justify choosing this option over the next credible alternative? That question does not replace formal analysis. It exposes whether the recommendation can survive plain-language scrutiny.

15. Risk, uncertainty and sensitivity

Every business case is a model of an uncertain future. Costs may be higher. Benefits may arrive later. Adoption may be lower. Supplier performance may vary. A regulation may change. The market may move. Risk analysis does not sit beside the business case as an optional appendix; it affects whether the central numbers mean anything.

The first discipline is to distinguish uncertainty in the estimate from discrete risks. A cost estimate may have a plausible range because design is immature. Separately, there may be a risk that migration uncovers a legacy-data defect requiring major remediation. Both affect the economic case, but they may be modelled differently.

Project Risk Management owns the wider process of identifying, analysing, responding to and monitoring uncertainty. The business case uses that information to test viability. A project with high expected benefit may still be unattractive if the downside threatens the organisation’s ability to operate.

Sensitivity analysis changes one assumption at a time to see how strongly the conclusion depends on it. What happens if implementation cost is 20 percent higher? If adoption reaches only 60 percent of the central assumption? If benefits begin one year later? If subscription prices increase? The assumptions that reverse the preferred option deserve management attention.

Scenario analysis changes several related assumptions together. A downside scenario might combine delayed implementation, lower adoption and higher support cost rather than pretending these events are independent. An upside scenario might reflect faster migration and stronger demand. Scenarios are especially useful when the future may follow qualitatively different paths.

Break-even analysis asks what must be true for the investment merely to justify itself under a defined metric. How many customers must adopt? How many staff hours must genuinely be released? What maximum implementation cost preserves a positive NPV? These thresholds can convert an abstract model into observable management triggers.

Risk-adjusted analysis should not become permission to hide arbitrary “contingency” inside every number. The basis should be explainable. Where a probabilistic model is used, the distributions and correlations matter. A sophisticated simulation built from invented inputs is not more truthful than a simple transparent range.

The most valuable outcome of uncertainty analysis is often not a revised total but a decision about what to learn next. If one assumption controls the option choice, the organisation may fund a pilot, market test, prototype or data audit before committing to the full project. Spending a small amount to reduce decision uncertainty can protect a much larger investment.

A business case should therefore show both the central recommendation and its fragility. Decision-makers need to know not only “which option wins?” but “under which plausible conditions does it stop winning?”

16. Optimism, reference classes and independent challenge

Project teams know their proposed solution in detail. That expertise is necessary and dangerous. It encourages an inside view: the team imagines the steps it intends to execute and estimates how those steps should unfold. The plan can look uniquely compelling because the team has not given equal imaginative effort to the ways comparable projects have actually performed.

Reference-class reasoning introduces an outside view. Instead of asking only “How long should our project take?”, ask “How long have comparable projects actually taken?” Instead of relying solely on the team’s expected migration defect rate, examine similar migrations. The reference class need not be perfect; its purpose is to challenge exceptionalism.

Project Estimation develops this principle more fully. In the business case, the outside view matters because optimistic cost and benefit forecasts can determine approval. If an option wins only because its estimates assume performance rarely achieved by comparable projects, the case should explain what evidence justifies the exception.

Independent challenge helps because the person who built the argument may be invested in its success. A reviewer can ask whether the problem is real, the options are broad enough, costs are complete, benefits are attributable, risks are symmetric, and the preferred option still wins under plausible assumptions.

Independence is not hostility. A good challenge function should improve the decision, not merely reject proposals. It can identify missing evidence, suggest a more realistic scenario or recommend staged approval that allows learning before full commitment.

Project Assurance owns the broader architecture of independent challenge. The business case should define when assurance is proportionate. A small reversible investment may need peer review. A major irreversible investment may need technical, commercial, financial and strategic challenge from people outside the delivery team.

Optimism can also enter through omission rather than low estimates. The business case may model implementation cost carefully while ignoring transition, decommissioning or benefit-delivery effort. It may include expected benefits but omit disbenefits. Independent review should examine the model boundary as well as the numbers inside it.

One useful test is to ask a reviewer to construct the strongest case for the second-best option. If that exercise reveals evidence the main case ignored, the comparison becomes more balanced. A genuine options appraisal should be able to explain why credible alternatives lost, not merely why the preferred option is attractive.

Confidence is earned when the preferred option survives informed attempts to disprove its superiority. The business case becomes stronger when it contains the criticism it has already answered, rather than presenting a frictionless future that only exists because nobody challenged it.

17. Commercial feasibility

A preferred option can be economically attractive and still be commercially impossible. The commercial case asks whether the organisation can obtain the goods, services, rights and supplier behaviour the option requires on terms that preserve the intended value.

Market capability should be tested early enough to influence the design. If the business case assumes ten qualified suppliers but market engagement finds only one, the risk allocation, price, procurement timeline and resilience assumptions all change. A specification that only one supplier can satisfy may be justified by a genuine requirement—or it may be accidental lock-in created by unnecessary design constraints.

The commercial model includes more than the procurement event. It includes contract structure, payment mechanism, intellectual-property rights, data ownership, exit arrangements, liability, performance incentives, change mechanisms, indexation, subcontracting, support commitments and the allocation of risks between buyer and supplier.

Risk should be placed with the party best able to manage it, not simply transferred on paper. A buyer can demand that a supplier accept extreme risk, but the supplier may price the risk, refuse to bid or behave defensively. A contract that appears to protect the organisation can therefore reduce competition or increase whole-life cost.

Commercial feasibility also includes internal sourcing choices. Should the capability be built in-house, bought, partnered, licensed or shared? The answer depends on strategic importance, market maturity, internal capability, speed, control and lifecycle obligations. “Buy is cheaper” can be misleading if the organisation loses critical knowledge or becomes unable to exit.

Supplier dependency should be treated as an operating condition, not merely a procurement risk. A managed platform may create excellent service while making future migration expensive. That may be acceptable if the switching cost is understood and priced into the case. Hidden exit cost is different from deliberate dependency.

Project Procurement Management owns the detailed commercial process after the investment route is chosen. The business case owns the earlier test: is there a credible market and contracting strategy capable of delivering the option at the value and risk assumptions used in the appraisal?

A strong commercial case therefore feeds back into the economic case. If market engagement reveals higher prices, different lead times or weaker competition, the option should be reappraised. The preferred solution should not be protected from commercial evidence merely because it won the theoretical comparison first.

18. Affordability and the financial case

An investment can create positive net value and still be unaffordable. The financial case asks whether the organisation can fund the preferred option over time without violating real budget, cash-flow, borrowing, capital, covenant or operating constraints.

Imagine an option with strong expected NPV that requires $2 million of expenditure next year when the organisation has only $1.2 million of available capital. The economic answer may be “worth doing.” The financial answer is “not in this form at this time.” The business case must resolve that tension rather than assuming value automatically creates funding.

Funding source matters. A grant may be restricted to capital expenditure. A subscription may sit in operating budgets. A project may create savings in one department while requiring expenditure in another. If the department paying cannot access the benefit, organisational incentives can block a theoretically valuable project.

The financial model should therefore map cash by period and owner, not only total cost. It should show implementation spending, recurring cost, expected savings, transition overlap, contingency, tax treatment where relevant, and the effect of delay. A monthly or quarterly profile may be necessary for projects with tight liquidity.

Affordability should extend beyond project completion. A new asset can fit the project budget and overwhelm operations later. The receiving organisation needs funding for licences, maintenance, staffing, energy, support, security, content renewal, upgrades or supplier management. If those costs are omitted, the project budget becomes a temporary illusion.

The case should also distinguish committed funding from hoped-for funding. “A future budget bid will cover the operating cost” is an assumption, not cash. If the project can only succeed when several unapproved funding decisions occur later, those dependencies belong in the business case and risk analysis.

Funding flexibility can affect option preference. A staged option with slightly lower total value may be preferable if it allows the organisation to stop after each increment, learn before spending the next tranche and preserve liquidity. A large irreversible investment may offer higher theoretical efficiency but create unacceptable financial exposure.

A useful affordability statement answers: what funding is needed, when, from which source, under whose authority, with what headroom, and what happens if cost or timing changes? If those answers are missing, the business case has not yet shown that the organisation can carry the preferred option into reality.

19. The management case: can this actually be delivered?

The management case converts a preferred investment into a credible route to implementation. It asks whether governance, people, plans, change capability, benefit ownership, monitoring, evaluation, risk management and contingency are sufficient to turn the option into the intended outcome.

A technically attractive option may fail this test if the organisation cannot absorb the change. A hospital system may have no safe transition window. A school may lack teacher preparation time. A company may already be running several major transformations that compete for the same subject-matter experts. Delivery feasibility is part of value because an undeliverable benefit is not a benefit.

The management case should identify governance and decision rights. Who sponsors the investment? Who owns the business case? Who can authorise changes to the baseline? Who owns benefits after the project team disbands? Who accepts residual operational risk? Who can stop the project if justification disappears?

Project Sponsorship owns executive legitimacy and protection. Project Governance owns the wider authority system. The business case uses those structures to prove that the investment can be governed through decisions that may be uncomfortable, including scope reduction or stop decisions.

The project approach should match uncertainty. A well-understood physical build may justify predictive planning. A novel digital service may need iterative discovery before full commitment. A hybrid solution may have fixed regulatory milestones and adaptive product development. The management case should show why the chosen lifecycle helps manage the investment’s real uncertainties rather than adopting a methodology by fashion.

Operational readiness belongs here too. The project must not treat handover as the moment responsibility magically transfers. Project Readiness Management asks whether people, procedures, data, infrastructure, support, contingency and receiving ownership are ready enough for the next transition.

Monitoring and evaluation should be designed before delivery. If the business case claims that wait times will fall, the baseline data and measurement method should exist before the project changes the process. If the organisation only decides how to measure success after launch, it may discover that no credible comparison remains.

The management case also needs a credible failure route. What happens if the pilot fails? Can migration be rolled back? Is there a fallback service? What evidence triggers replanning? What contingency exists for supplier failure? A project is more credible when it explains how it will respond to bad news rather than assuming bad news proves the plan was wrong.

The strongest management case therefore demonstrates that the organisation can not only build the output but adopt, operate, measure, govern and, if necessary, change or stop the investment without losing control.

20. Business case stages and decision gates

A business case should become more detailed as the decision becomes more consequential. HM Treasury’s current framework describes Strategic Outline Case, Outline Business Case and Full Business Case stages for major public project business cases. The names belong to that framework, but the underlying principle is widely useful: do not demand final-answer precision before the project has earned it, and do not make irreversible commitments using evidence appropriate only to early exploration.

An early case should establish the need, objectives, broad options, main benefits, rough costs, important risks and whether further investigation is justified. The decision may be to fund discovery, not to approve the entire project.

A middle-stage case can compare a refined shortlist using better estimates, technical discovery, market information and clearer benefit assumptions. It should show enough commercial, financial and management detail to decide whether to proceed into procurement or detailed design.

A final pre-commitment case should reflect procurement results, detailed costs, delivery arrangements, confirmed funding and an updated risk picture. If supplier bids are much higher than the assumptions used to approve the outline case, the final case should not simply “update the budget.” It should revisit whether the option remains justified relative to alternatives.

Decision gates work when they can genuinely produce more than one answer. “Go” is one answer. “Go with conditions,” “do more work,” “change option,” “pause” and “stop” may also be legitimate. A gate that cannot change the course is a reporting meeting, not an investment decision.

The evidence threshold should match reversibility. A reversible pilot can proceed under greater uncertainty because the organisation can learn cheaply and stop. A large land purchase, irreversible migration or long-term contract deserves stronger evidence before commitment. This is Project Decision Management applied to the investment life cycle.

Gates should also test strategic relevance, not only delivery readiness. The project may be on time and on budget while the original need has disappeared. A competitor may have changed the market, a policy may have changed, or another programme may now provide the same capability. Continuing merely because delivery is healthy can still waste investment.

A staged business case therefore prevents two opposite errors: demanding false certainty too early and preserving outdated certainty too late. Early stages permit learning. Later stages demand stronger evidence. At every stage, approval means only that the investment remains justified under the current information—not that the original argument can never be challenged again.

21. Continued business justification

The business case is not finished when the project begins. Approval creates a continuing obligation to ask whether the investment is still justified under the best current evidence. This principle is sometimes called continued business justification: the project should remain desirable, viable and achievable enough to deserve the next unit of commitment.

The question is prospective. It asks whether future cost and risk are justified by future expected benefits and strategic need. It does not ask whether the original decision was understandable at the time. A project can have been a rational investment last year and become an irrational one today because the world changed.

Triggers for review include major cost growth, benefit erosion, schedule delay, supplier failure, changed regulation, changed strategy, newly available alternatives, material technical discoveries, failed pilots, operational-readiness gaps and changes in demand. The trigger threshold should be proportionate. Constant full reappraisal would paralyse delivery; ignoring major change would make the business case meaningless.

The review should update the counterfactual as well as the project. Suppose the project was approved because the existing supplier planned to end support. Six months later the supplier extends support by three years at a reasonable price. The project may still be worthwhile, but the baseline has changed. Continued justification compares the investment with the current alternative, not the obsolete baseline that made the original case look strongest.

Benefit assumptions also need refresh. If adoption after a pilot is half the expected rate, the project should not preserve the original benefit forecast simply because full rollout has not yet occurred. The lower observation becomes evidence. The appropriate response may be improved change management, redesigned service, reduced scope or stopping. The business case should show which explanation and intervention are justified.

Cost growth should be treated similarly. An increased estimate is not automatically proof that the project should stop. The question is whether the revised whole-life cost still produces sufficient value relative to alternatives, given the benefits, risks and sunk costs now in place. A project can survive substantial cost growth if the benefit is critical and alternatives are worse; another can lose justification after a small change if the original margin was thin.

The sponsor is central because continued justification may require decisions the delivery team cannot make safely. Project Sponsorship owns the executive responsibility to protect the investment’s legitimacy rather than simply defend the project’s existence.

A mature governance system therefore keeps a versioned record of the business case assumptions, major changes and gate decisions. It should be possible to answer: what changed, why the project still deserves continuation, who accepted the revised risk, and what evidence would trigger another review?

The deepest purpose of continued justification is not financial policing. It is organisational honesty. Projects are temporary means to outcomes. When the means no longer serves the outcome better than the available alternatives, stopping or changing it can be the most responsible project-management decision available.

22. Sunk costs and the courage to stop

Sunk costs are expenditures that have already occurred and cannot be recovered by choosing one future option over another. They matter for accountability and learning. They should not distort the forward decision about whether to continue.

Suppose a project has already spent $2 million. Completing it will require another $1.5 million. The remaining expected benefit is now only $800,000 because market conditions changed. A common reaction is, “We cannot waste the $2 million already spent.” But the $2 million is already gone whether the project continues or stops. The forward comparison is primarily between spending the additional $1.5 million for the expected future benefit and the available alternatives.

This does not mean historical expenditure is irrelevant. Some sunk investment may have created reusable assets, knowledge or contractual rights that alter the remaining options. Cancellation may trigger exit costs. Reputation or legal obligations may matter. These are future consequences and belong in the current decision. The analytical discipline is to separate them from emotional attachment to past spending.

Projects become psychologically difficult to stop because people have careers, commitments and public identities attached to them. Leaders may fear admitting error. Teams may believe stopping invalidates their effort. Suppliers may have incentives to preserve scope. A strong business-case process anticipates these pressures by defining stop conditions before the organisation becomes heavily invested.

Stage funding can help. Instead of authorising the entire investment at once, the organisation funds a discovery or pilot and defines what evidence must exist before the next tranche. If the evidence fails, stopping becomes the planned use of a gate rather than a dramatic reversal.

Stopping can also mean redirecting. A failed technical approach may reveal that the strategic need remains real but requires a different option. The business case should distinguish “this project should stop” from “this problem no longer deserves investment.” Those are different conclusions.

Project Recovery becomes relevant when the project is troubled but may still be salvageable. Recovery rebuilds a credible route to the outcome. Business-case review asks whether rebuilding is still worth doing.

A stop decision should preserve lessons. What assumption failed? Which evidence arrived too late? Was the option set too narrow? Did incentives bias estimates? Did the market change genuinely outside reasonable foresight? These questions improve future investment decisions and prevent cancellation from becoming either blame theatre or forgotten history.

The ability to stop is therefore part of investment competence. An organisation that can start projects but cannot stop them does not have a complete business-case system. It has an approval system with no credible exit.

23. Business case vs charter, plan and benefits case

Project documents often overlap because they describe the same investment from different angles. Clear ownership reduces duplication and contradiction.

The business case owns investment justification: need, options, costs, benefits, risks, affordability, commercial feasibility, delivery feasibility and continued justification.

The project charter or equivalent initiation authority owns formal project authorisation: purpose, high-level scope, sponsor, project manager, authority, major constraints and initial governance. The charter may reference the business case rather than repeat it.

The project management plan owns the integrated delivery system: scope, schedule, cost, quality, resources, risk, communications, procurement, change and other controls. It explains how the approved investment will be delivered, not why the investment beats alternatives.

The benefits realisation plan owns the detailed route from outputs to benefits: baseline, benefit owner, target, measurement, timing, dependencies and post-project tracking. The business case uses the headline benefit evidence to justify investment; the benefits plan operationalises those claims.

The requirements baseline owns what the solution must satisfy. The business case can identify critical outcome requirements and option-level constraints, but Project Requirements Management governs the detailed need-to-verification chain.

The risk register owns individual uncertainty records, responses and status. The business case summarises the risks material to investment viability rather than duplicating every operational risk.

These boundaries matter because duplicated information can diverge. If the business case says annual operating cost is $200,000 while the plan says $350,000 and neither points to the authoritative estimate, governance no longer knows which number justifies the decision. Shared source data should feed different documents rather than being copied independently.

Project Configuration Management is therefore relevant even to business-case governance. The organisation should know which business-case edition supported which approval, which estimate version it used and what changed before the next gate.

The rule is simple: each artefact should have one primary job. Cross-reference rather than reproduce where possible. A compact, coherent document system is stronger than five large documents repeating slightly different versions of the same truth.

24. Business case in agile and hybrid delivery

Agile delivery does not remove the need for a business case. It changes where certainty is expected. A product team may not know every feature at approval. The organisation still needs to know why the investment matters, what outcome is being pursued, what funding envelope is justified and what evidence will show whether continued investment deserves support.

An agile business case can therefore focus on outcome, strategic fit, problem evidence, broad option choice, initial funding, benefit hypotheses, major constraints and stop conditions. Detailed scope can remain adaptive while the investment boundary remains controlled.

Incremental funding can strengthen continued justification. Instead of approving a three-year roadmap as though every feature is known, the organisation can fund a discovery or product increment, observe user behaviour, update benefit evidence and decide whether the next increment remains worthwhile.

This requires discipline because “agile” can otherwise become a reason never to revisit the business case. Teams may keep shipping increments while the strategic benefit remains untested. Product metrics should therefore connect to the original benefit logic: adoption, task completion, cost-to-serve, revenue, error reduction, service quality or another outcome appropriate to the case.

Hybrid projects need two kinds of commitment simultaneously. A physical or regulatory component may require early fixed decisions. A digital component may remain adaptive. The business case should identify which parts are reversible and which are not, then place stronger evidence gates before irreversible commitments.

Agile Project Management and Hybrid Project Management own the delivery methods. The business case owns the investment logic that remains above them: why this outcome deserves resources and under what evidence the organisation should keep paying for the next step.

Adaptive delivery also sharpens the distinction between option value and indecision. Preserving the ability to change direction can be valuable when uncertainty is high. But perpetual discovery has a cost. The business case should define what the next increment is expected to learn and when enough evidence exists to commit, change direction or stop.

A healthy agile business case is therefore not a fixed scope promise disguised as flexibility. Nor is it an open cheque. It is a governed learning investment whose justification is updated as real evidence replaces assumptions.

25. Business case in AI projects

An AI project business case should begin with a problem worth solving, not with a model looking for a use. “Deploy generative AI” is a technology direction. It is not yet an investment justification. The organisation still needs to know which task or outcome matters, how the current process performs, what non-AI alternatives exist, what evidence would demonstrate improvement, and what new risks or lifecycle costs the AI option introduces.

The option set should therefore include simpler mechanisms where credible. A service problem might be addressed by clearer information architecture, ordinary workflow automation, rules-based software, search, human process redesign, AI-assisted work or a more autonomous AI system. If a deterministic method can satisfy the requirement more cheaply and predictably, the business case should allow that result to win.

AI benefits need a task-level mechanism. “Improve productivity by 30 percent” is too broad. A stronger hypothesis might be: the system produces a structured first draft of routine summaries; trained staff verify the draft against source records; average preparation time falls while defined error and escalation thresholds remain within acceptable limits. That statement can be tested.

Costs extend beyond model access. The case may need to include data preparation, retrieval systems, evaluation design, human review, security controls, privacy work, monitoring, incident handling, model or vendor migration, prompt or workflow maintenance, inference cost, specialist support and the cost of preserving a safe non-AI route for cases the system should not handle.

Evaluation cost can become a material part of the economics. A model that produces output in seconds may still require expensive verification. If generation capacity increases from ten drafts to a hundred while the qualified review system can accept only twelve, the project may create a review bottleneck rather than ninety extra units of value. Project Bottleneck Management explains why local acceleration must be followed through the complete system.

The benefit case should also account for error consequence, not merely average accuracy. A model can perform well overall while failing badly on rare high-consequence cases. The business case should identify where human judgement remains mandatory, what the fallback route is, and how error affects customer, legal, safety, financial or reputational outcomes.

Vendor and model dependency deserve explicit treatment. The organisation may rely on a model whose pricing, capability, terms or availability can change. A system built tightly around one provider may have high switching cost. That does not make the option unacceptable; it makes exit cost and supplier concentration part of the commercial and risk cases.

Data rights and privacy can be non-compensatory gates. A compelling ROI does not justify using data in a way the organisation lacks authority to use. The business case should identify what data is needed, what permissions apply, where information moves, what retention is required, and whether the proposed operating model can preserve those controls at scale.

NIST’s AI Risk Management Framework provides one current primary reference for managing AI risks across design, development, deployment and use. It does not supply a project-specific ROI or approval decision; it reinforces the principle that trustworthiness and risk belong inside the lifecycle rather than being bolted on after generation works. NIST AI Risk Management Framework

AI Project Management owns the broader delivery and governance discipline. The business case asks the investment question above it: does using AI for this specific job create enough incremental value, under a credible control and operating model, to beat simpler alternatives?

26. Worked case: replace, repair or retire a service

Return to the fictional appointment service. The current platform is expensive to support, relies on ageing technology, requires substantial manual reconciliation and cannot easily support the organisation’s planned service model. The organisation has a hard capital constraint of $1 million for the next investment stage and needs a credible transition before the current support arrangement becomes operationally fragile.

The figures below are invented teaching data. They are not benchmarks for software projects. “Annual net monetised benefit” means expected monetised improvement relative to the baseline after the option’s recurring operating-cost difference has been included. Non-monetised benefits and risks are shown separately.

Option	Upfront investment	Annual net monetised benefit	Analysis life	Indicative delivery	Main advantage	Main weakness
A — Repair and extend	$350,000	$160,000	3 years	6 months	Fast, affordable, low transition disruption	Defers rather than removes ageing-platform risk
B — Full managed platform	$850,000	$280,000	5 years	15 months	Strong service improvement and lower internal maintenance	Supplier dependency and data-exit cost
C — Custom strategic platform	$1,600,000	$480,000	7 years	30 months	Highest strategic control and modelled long-run benefit	Unaffordable under current capital ceiling; highest delivery risk
D — Simplify process + managed core	$650,000	$260,000	5 years	11 months	Lower complexity, affordable, earlier service improvement	Less custom capability; requires operating-process change

The table does not identify a winner yet. Option C has the largest annual benefit and longest strategic horizon. Option A is cheapest and fastest. Option B preserves more functionality than D. Option D removes some low-value complexity instead of rebuilding it. The business case must compare these differences against the objectives and hard gates.

The organisation’s critical success factors include: maintain service continuity; meet information-control and accessibility requirements; transition before the current support risk becomes unacceptable; remain inside the approved $1 million capital envelope unless separate funding is authorised; preserve an assisted service route; and create an operating model that the current support organisation can sustain.

Option C immediately creates a governance problem. Its central modelled economics may be attractive, but it exceeds the current funding authority by $600,000 and its 30-month delivery estimate extends beyond the preferred support-risk window. Those are not minor score disadvantages. Under the present decision rules, they are gates.

Option A satisfies affordability and timing but leaves the organisation dependent on the ageing architecture after the three-year analysis period. It may be a reasonable bridge if uncertainty about the future service model is high. It becomes less attractive if the organisation already has strong evidence that replacement is unavoidable and delaying simply creates another migration later.

Option B provides a more complete managed replacement but requires a larger investment and longer transition than D. Its additional functionality creates some benefits, but several features support processes the organisation is already considering retiring. The business case therefore asks whether those features are genuine requirements or inherited preferences.

Option D combines a process decision with a technology decision. The organisation stops reproducing two low-value legacy workflows, simplifies the service before migration, and buys a smaller managed core. This reduces implementation scope but makes organisational change more important. Its business case therefore depends more heavily on stakeholder readiness and benefit ownership.

The worked case demonstrates why business-case analysis is not equivalent to choosing the biggest financial return. The preferred option must survive strategy, economics, commercial feasibility, affordability and delivery. Chapter 27 turns the central financial assumptions into discounted values; Chapter 28 then shows why the highest NPV is still not automatically the correct decision.

27. Worked financial model

For teaching purposes, assume the organisation uses an 8 percent private internal discount rate, annual benefits arrive at the end of each year, and the annual net monetised benefit in the table is already net of each option’s incremental recurring operating cost. These are fictional assumptions chosen to demonstrate the method, not a recommended rate or benchmark.

Under those assumptions, the present value of a constant annual benefit can be calculated by discounting each year’s amount: benefit in Year 1 divided by 1.08, Year 2 divided by 1.08², and so on. Subtract the upfront investment to obtain the illustrative NPV.

Option	Upfront investment	PV of stated annual net benefits	Illustrative NPV at 8%
A — Repair and extend	$350,000	about $412,336	about $62,336
B — Full managed platform	$850,000	about $1,117,959	about $267,959
C — Custom strategic platform	$1,600,000	about $2,499,058	about $899,058
D — Simplify process + managed core	$650,000	about $1,038,105	about $388,105

Option C has the highest central NPV by a substantial margin. Option D is second. If the organisation’s only objective were to maximise this particular modelled NPV and it had unlimited capital, no timing constraints and confidence in the assumptions, C would look compelling.

But the financial model is not the whole business case. Option C requires $1.6 million of capital when only $1 million is authorised. It also requires 30 months when the current support-risk window favours a materially earlier transition. The organisation could seek additional capital or an extension to the support arrangement, but those would be new decisions with their own evidence.

Option D’s central NPV is lower, but it remains inside the capital envelope and has the earliest full replacement among the non-repair options. It also removes some legacy complexity rather than paying to replicate it. The financial model therefore informs the decision without overruling hard constraints.

Sensitivity analysis now becomes useful. If Option D’s annual net benefit fell from $260,000 to $200,000, its five-year benefit PV at 8 percent would be about $798,543 and its NPV about $148,543. It would remain positive under this simplified metric, though the strategic comparison with A and B would need to be revisited.

If Option C’s cost rose by another $500,000, its NPV would fall by the same $500,000 under these assumptions, to roughly $399,058. It could still exceed D’s central NPV while becoming even less affordable. This demonstrates why economic value and affordability must remain separate questions.

Real modelling would be more detailed. Benefits might ramp up gradually, costs would occur across periods, tax or inflation treatment could differ, risk-adjusted scenarios might be used, and residual values or exit costs could matter. The simplified model is useful because every assumption is visible enough to challenge.

The calculation also gives the team break-even questions. How low can D’s annual net benefit fall before its NPV becomes zero? At an 8 percent five-year annuity factor of roughly 3.993, the break-even annual benefit is about $162,800 for a $650,000 upfront cost. That threshold becomes a practical question for benefit validation: is the evidence strong enough to believe the project can produce materially more than that?

The purpose of the model is therefore not to discover one magical number. It is to expose the assumptions that control the investment choice so governance can decide which deserve stronger evidence.

28. Decision clinic: the attractive option that should not win

The investment board receives the worked case and immediately notices that Option C has an illustrative NPV of about $899,000—more than twice Option D’s roughly $388,000. One executive says, “Why would we deliberately choose the lower-value option?” The question is reasonable. The answer demonstrates why business cases need non-compensatory gates.

First, the board restates the decision. It is not choosing the option with the largest spreadsheet output under unconstrained conditions. It is choosing an investment the organisation can fund, deliver before the support-risk window becomes unacceptable, operate sustainably, and justify against alternatives.

Option C fails the current capital condition. The organisation has authority for $1 million. The option requires $1.6 million before risk allowance. The board could seek more funding, but until that funding exists the option is not financially feasible under the current decision.

Second, C’s 30-month central delivery estimate extends beyond the transition horizon the organisation considers prudent. Again, this condition could change if the old support arrangement is extended credibly. Until then, the timing creates a material risk that cannot be compensated simply by a higher NPV.

Third, the custom platform’s benefits depend on the organisation adopting several advanced capabilities not required to solve the immediate service problem. Those capabilities may create future strategic value, but the evidence is weaker than the evidence supporting the simpler appointment and workflow benefits. A large share of C’s advantage therefore depends on more uncertain benefit assumptions.

The board could conclude that D is the preferred current option while preserving C as a future strategic direction. That is not the same as declaring D universally superior. It is a context-dependent decision under current capital, timing, evidence and operating constraints.

Alternatively, the board could fund a short piece of work to test whether C can be modularised into a staged path that preserves some strategic upside while keeping the first commitment under $1 million. This illustrates option value: the best current action may be to buy information rather than choose between two exaggerated all-or-nothing alternatives.

The clinic demonstrates an important governance rule: a weighted score or NPV should not be allowed to average away a hard constraint. If legality, safety, funding authority, essential timing or another legitimate gate is not satisfied, the organisation needs a separate decision to change that gate. It should not pretend the failure disappeared because other benefits are large.

The strongest business cases therefore make non-compensatory conditions explicit before the results are known. That protects the decision from retrofitting rules around the preferred option after the spreadsheet is complete.

29. Decision clinic: when the preferred option stops being justified

Six months later, the organisation returns to the business case. It has spent $150,000 on discovery, market engagement and migration analysis. That expenditure is already incurred. It produced useful information and should be preserved in the project history, but it is sunk for the next investment decision.

The new evidence is uncomfortable. Supplier bids for Option D are higher than the original estimate, bringing the remaining upfront commitment to about $880,000. The data migration is more difficult than expected. The operating team also believes the original $260,000 annual net benefit was optimistic because some of the assumed staff capacity cannot actually be released or redeployed. The revised central annual net benefit is $180,000.

At the same time, the incumbent supplier unexpectedly offers a credible three-year support extension. A repair-and-simplify bridge that was previously unattractive can now be implemented for an estimated remaining $300,000 and is expected to create about $140,000 of annual net monetised benefit for three years while the organisation gathers better evidence about its future service model.

Using the same illustrative 8 percent discount rate, Option D’s revised five-year benefit stream has a present value of about $718,688. Against a remaining upfront commitment of $880,000, the simplified forward NPV is about negative $161,312. The revised repair bridge has a three-year benefit present value of about $360,794 against $300,000 of remaining cost, giving a simplified forward NPV of about positive $60,794.

The $150,000 already spent on discovery should not be added to the repair option merely to make D look better. That cost is common history at this decision point. The question is what future commitment now produces the strongest justified outcome. Some discovery outputs may be reusable under either route and can reduce later uncertainty; that is a future benefit of the knowledge already purchased, not a reason to continue the old option automatically.

The business case has therefore changed materially in three places: D costs more, its plausible benefit is lower, and the baseline alternative has improved. The original preference was not irrational. The current preference can still change because the evidence changed.

Governance now has several choices. It can stop D and use the repair bridge. It can renegotiate D to recover value. It can redesign D into a smaller staged option. It can challenge the revised benefit estimate if new evidence supports a different mechanism. What it should not do is preserve D solely because six months of work and $150,000 have already been invested.

The stop-or-change decision should also examine non-financial effects. The repair bridge leaves ageing architecture in place and may increase the future migration burden. D still offers stronger accessibility, supportability and process simplification. If those benefits are important enough, the organisation may accept a negative narrow financial NPV. But it must say why. The justification has to move into the explicit strategic, service or risk case rather than hiding behind the old financial numbers.

This is continued business justification in its most useful form. It does not ask the project team to defend the past. It asks governance to use the new evidence. A good business case gives the organisation permission to change its mind without pretending that new information means the original decision was negligent.

The lesson extends far beyond financial modelling. Whenever a project’s rationale changes materially, revisit both sides of the comparison: the project and the alternative. A cost overrun matters. So does a cheaper competitor. A delayed benefit matters. So does an extended asset life. A failed pilot matters. So does a newly available technology. Investment choices remain relative decisions even after delivery has started.

30. A practical business-case review

A business-case review should help a decision-maker challenge the investment without reconstructing the entire project from memory. The questions below are deliberately broader than a template. They test whether the argument remains coherent across strategy, economics, commercial reality, finance and delivery.

Strategic case

What evidenced problem, opportunity or obligation justifies intervention?
What happens under the current best estimate of business as usual?
Which strategic objective or mandatory requirement does the proposal serve?
Are the objectives written as outcomes rather than preselected solutions?
Who experiences the current problem, and who would experience the change?
Has the strategic need changed since the previous approval?
Would the organisation still investigate this problem if the current preferred solution did not exist?

Options and economic case

Were materially different options generated before detailed appraisal?
Is there a credible do-nothing or do-minimum counterfactual?
Why were excluded options rejected, and is the reason still valid?
Which critical success factors are mandatory gates and which are tradeable preferences?
Are whole-life incremental costs compared on a compatible basis?
Are benefits attributable to the project rather than to trends that would occur anyway?
Are cash savings distinguished from released capacity?
Are disbenefits and distribution effects visible?
Which impacts are monetised, which are not, and why?
Does the preferred option still outperform the next credible alternative under plausible scenarios?

Evidence and uncertainty

What assumptions control the result?
Which assumptions are supported by observed data, supplier evidence or reference classes?
Which assumptions are still low confidence?
What breaks even first: cost, adoption, timing or benefit?
What evidence would reverse the preferred option?
Have downside scenarios been considered as seriously as upside scenarios?
Has independent challenge examined the option set and model boundary, not only arithmetic?

Commercial case

Does a credible market exist for the required capability?
Are supplier numbers and competition assumptions based on evidence?
What sourcing route is proposed, and why?
Who owns data, intellectual property and exit capability?
Is risk allocated to parties able to manage it rather than simply transferred contractually?
What supplier concentration or lock-in remains?
Have market findings been fed back into the cost, schedule and risk models?

Financial case

Can the organisation fund the investment by period, not merely in total?
Is funding authorised or only expected?
Which department pays and which receives the benefit?
What headroom exists for uncertainty?
Are transition, dual-running and operating costs included?
Can operations fund the asset after project closure?
What happens if procurement prices exceed the approved assumption?

Management case

Who owns the business case and who sponsors the investment?
Who owns each material benefit after delivery?
Does the delivery approach match the uncertainty and reversibility of the work?
Are the scarce capabilities and dependencies available when needed?
Is operational readiness planned rather than assumed?
Are baseline data and evaluation methods defined before implementation?
What contingency, fallback or rollback exists?
Which conditions trigger a business-case refresh?
Who has authority to pause, redirect or stop the project?

A reviewer need not ask every question at every meeting. The point is to expose the weak link relevant to the next decision. Early discovery may focus on need, options and assumptions. A procurement gate may focus on commercial evidence and updated affordability. A go-live gate may focus on delivery readiness while confirming that the strategic and economic justification has not disappeared.

The review should end with a decision record, not merely comments. State what is approved, what remains conditional, what evidence must arrive next, what assumptions have changed, and when the business case must be revisited. An unanswered concern without an owner is not a control.

31. Common failure modes

Business-case failure is often visible long before delivery failure. The following patterns do not prove a proposal is bad, but each weakens the evidence needed for a defensible investment decision.

1. The solution appears before the problem

The case begins “We need Platform X” and then searches for benefits. Repair: restate the current problem and objectives without naming the solution, then regenerate options.

2. Fake alternatives

The shortlist contains one realistic option and two obviously inferior straw alternatives. Repair: generate materially different mechanisms for achieving the outcome, document exclusions, and ask whether the author would accept a non-preferred option winning.

3. No credible counterfactual

The project is compared with a fictional world in which current costs and risks vanish. Repair: model what actually happens if the intervention does not proceed, including unavoidable maintenance and external change.

4. Cash savings that are really capacity

The case converts staff hours into dollars even though payroll will not fall. Repair: classify the benefit as released capacity unless a real spending mechanism exists.

5. Double-counted benefits

Several projects claim the same revenue growth or efficiency gain. Repair: assign benefit ownership and show which intervention contributes what portion of the causal chain.

6. One-point estimates presented as certainty

The case shows $3.274 million with no range, basis or confidence. Repair: preserve the basis of estimate, uncertainty and sensitivity rather than using decimal precision as confidence theatre.

7. Whole-life costs omitted

Implementation is costed while training, support, licences, decommissioning or exit are ignored. Repair: model the lifecycle and state what remains outside the boundary.

8. Strategic alignment as a slogan

The proposal “supports transformation” without demonstrating which strategic outcome changes. Repair: trace the need and benefits to a specific strategy or obligation.

9. Lowest price confused with value

The cheapest purchase is selected despite shorter life, weaker service or higher exit risk. Repair: compare whole-life cost, effectiveness, risk and residual obligations.

10. Ownerless benefits

The project promises outcomes that require operational change but no operational owner is accountable. Repair: name the benefit owner and the post-delivery actions required.

11. Commercial fantasy

The option assumes supplier capability, pricing or risk acceptance that has never been tested. Repair: use proportionate market engagement and feed the evidence back into the appraisal.

12. Affordability inferred from positive NPV

The investment creates value but exceeds the organisation’s cash or capital authority. Repair: separate economic attractiveness from financial capacity and model expenditure by period.

13. The business case freezes after approval

New costs, benefits and market evidence update the plan but not the justification. Repair: define material-change triggers and versioned business-case reviews at meaningful gates.

14. Sunk cost becomes an argument to continue

The organisation spends more because stopping would make past spending feel wasted. Repair: separate unrecoverable history from future costs, benefits and exit consequences.

15. Gate theatre

A review is called a decision gate but “go” is the only socially acceptable answer. Repair: define legitimate dispositions and ensure evidence arrives before commitments become irreversible.

16. AI-generated confidence

A model produces polished market, cost or benefit claims without authoritative data. Repair: use AI to propose structures, comparisons and questions while binding official facts to verified sources and accountable owners.

17. Benefits counted before the operating change exists

The case assumes that installing the output automatically changes behaviour. Repair: model adoption, process change, training, policy and operational capacity as part of the benefit mechanism.

18. A score replaces judgement

Weighted criteria produce an overall total and governance treats the highest number as self-authorising. Repair: separate hard gates from tradeable criteria, test weight sensitivity and explain the recommendation in plain language.

These failures share one underlying pattern: the business case stops being an instrument for challenging the investment and becomes an instrument for defending it. The repair is not more paperwork. It is to restore comparison, evidence, uncertainty and the genuine possibility that the answer can change.

32. The deeper idea

A project business case is a disciplined permission to spend scarce resources under uncertainty.

That permission should be difficult to earn for a large irreversible investment and easier to earn for a small reversible experiment. It should become stronger as evidence improves. It should weaken when costs rise, benefits disappear, strategy changes or better alternatives emerge. It should never become permanent merely because the project has started.

The best business case does not predict the future perfectly. No document can. It makes the organisation’s beliefs inspectable: this is the problem; these are the objectives; these are the options; this is what each is expected to cost and create; these are the assumptions; these are the risks; this is why the preferred option wins today; and this is what would cause us to reconsider.

That structure creates accountability without pretending certainty. If the project later fails because an unpredictable event occurred, the record can show whether the original decision was reasonable. If the project fails because a known weak assumption was disguised as fact, the same record can expose the governance failure. Decision quality and outcome are related but not identical.

The business case also protects strategy from projects. Delivery organisations naturally become attached to what they are building. Teams solve problems, vendors mobilise, schedules acquire momentum and public commitments accumulate. Continued justification keeps one question above that momentum: does this still deserve to exist?

Sometimes the answer will remain yes despite cost growth and difficulty because the need is critical and alternatives are worse. Sometimes the answer will become no even though delivery is performing well because the benefit has disappeared. Sometimes the answer will be “not yet”—fund a smaller experiment, preserve options and learn before committing. Those are all legitimate outputs of a mature business-case system.

The discipline therefore links strategy to delivery without confusing them. Strategy says what matters. The business case asks which investment deserves resources. Governance authorises and challenges. Project management controls delivery. Operations creates and sustains the benefits. Evaluation checks whether the causal story actually worked. Organisational learning carries the result into the next decision.

A business case that performs this job is more than a funding form. It is an institution’s memory of why it chose to act, the evidence it relied upon, the alternatives it rejected and the conditions under which it promised itself the right to change its mind.

The central proposition is simple: approve the project only while the best available evidence says its future value, strategic necessity and deliverability still justify the future resources and risks required—relative to the credible alternatives available now.

Practical business case template | An evidence-led structure

A template is useful when it preserves the questions a decision-maker must answer. It becomes dangerous when completing the headings is mistaken for proving the case. The structure below is therefore an evidence route rather than a mandatory document format. A small reversible investment may answer it in a few pages. A major irreversible programme may need multiple supporting models, reviews and specialist reports.

1. Decision requested

State the actual decision in one sentence. Do not write “approve the business case.” Write what authority is being requested to approve: for example, “Approve $120,000 for a twelve-week discovery and pilot, with no authority for full rollout until Gate 2,” or “Approve Option D and authorise procurement up to the defined funding limit.”

Identify who holds the decision authority, the date by which the decision remains useful, and what commitment becomes difficult to reverse after approval. This prevents a document from circulating without anyone knowing which action it is meant to authorise.

2. Executive proposition

Explain the investment argument in plain language: the current condition, why it matters, the options considered, the recommended option, the central cost and benefit logic, the main uncertainties, and the reason this decision is timely. A reader should understand the causal structure before opening the financial model.

Include the strongest reason not to approve. If the case cannot state its own principal weakness, governance is likely to discover it later under less favourable conditions.

3. Case for change

What is happening now?
What evidence demonstrates the problem or opportunity?
Who experiences the consequence?
What strategic objective, service commitment or mandatory obligation is affected?
What is expected to happen if no material intervention occurs?
Which aspects of the current state are facts, forecasts or assumptions?

Link important claims to source records rather than paraphrasing them from memory. A support-cost trend should point to the cost record. A legal obligation should point to the authoritative requirement. A customer problem should be supported by relevant service evidence rather than one memorable complaint.

4. Objectives and success conditions

List the outcome objectives without embedding the preferred solution. Separate mandatory gates from optimisation goals. For each material objective, define the observable condition that would later allow the organisation to say the change worked.

Where an outcome requires post-project operational action, identify the benefit owner at this stage rather than after delivery.

5. Counterfactual

Describe business as usual or the minimum lawful/safe response. Include unavoidable maintenance, existing contracts, expected demand, known changes and current risks. This is the baseline against which incremental costs and benefits are assessed.

State when the counterfactual must be refreshed. A baseline that becomes obsolete can distort every later calculation.

6. Option longlist

Show materially different mechanisms for achieving the objectives. Include do nothing/do minimum where legitimate, process-only changes, smaller staged interventions, build/buy/partner options and combinations where relevant. The longlist demonstrates that the organisation searched the decision space before investing deeply in one answer.

For each excluded option, record the decisive reason. Avoid writing “not preferred” when the real reason is unknown.

7. Shortlist and critical success factors

Identify the shortlist and the criteria used to compare it. Mark hard gates explicitly. If a weighted score is used for tradeable attributes, show the weights, rationale and sensitivity. Do not allow a high aggregate score to compensate for a failed non-compensatory condition.

8. Cost model

Upfront implementation cost
Internal resource cost or capacity requirement
Procurement and supplier cost
Migration, integration and testing
Training and organisational change
Transition and dual running
Recurring operations, licences and support
Security, assurance and compliance
Decommissioning and exit
Contingency or uncertainty treatment

Attach or reference the basis of estimate. State price basis, timing, inflation/escalation treatment where relevant, major exclusions and estimate maturity. Show which costs are incremental and which are existing fixed resources that will not be released.

9. Benefit model

For each material benefit, record the causal mechanism, baseline, target, owner, timing and evidence method. Distinguish cash-releasing savings, released capacity, revenue, service outcomes, risk reduction and strategic capability. Keep shared benefits from being counted in full by multiple projects.

Record disbenefits beside benefits. An honest benefit register should not require a second document before decision-makers can see who bears the downside.

10. Economic and financial appraisal

Use the measures appropriate to the organisation: net benefit, NPV, ROI, payback, cost-effectiveness or another approved method. State discount-rate and timing assumptions explicitly. Explain why the preferred option wins; do not simply display the ranking.

Separately show affordability: funding by period, source, owner and headroom. A positive value-for-money result does not prove the organisation has the money or authority to proceed.

11. Risk, assumptions and sensitivity

Identify the assumptions that control the investment. Link them to risks and evidence. Show at least the major downside scenario or break-even condition. Ask which uncertainty is worth buying down before the next irreversible commitment.

12. Commercial case

Describe the market, sourcing route, contract model, supplier capability, risk allocation, intellectual-property and data position, performance mechanism and exit route. Record what market engagement has demonstrated versus what the team merely expects suppliers to accept.

13. Management and delivery case

Sponsor and business-case owner
Delivery leadership and authority
Major milestones and decision gates
Scarce resources and dependencies
Change/adoption approach
Operational readiness and handover
Benefit ownership
Monitoring and evaluation
Fallback, contingency and recovery

Explain why the project lifecycle fits the uncertainty. If the plan is staged, state what each stage buys in capability or knowledge and what evidence authorises the next tranche.

14. Recommendation

State the preferred option and the reason in comparative terms. A good recommendation sounds like: “Option D is recommended because it meets all mandatory conditions, remains within authorised capital, transitions before the support-risk window, and offers stronger central value than the other affordable options; its principal weakness is dependence on operating-process change, which will be tested through the defined pilot and adoption measures.”

A weak recommendation says only: “Option D is the best option.”

15. Approval conditions and next review

Record what is approved now, funding limits, conditions, evidence still required, assumptions that must be validated, and the next decision point. Define material-change triggers: for example, supplier bid above a threshold, benefit evidence below a threshold, delay beyond a latest useful date, or loss of a mandatory requirement.

This final section is what turns the case from a one-time funding narrative into a living governance instrument. It tells the organisation how to recognise when the current permission to proceed has expired.

Sources and boundaries

The institutional concepts in this article were checked against current public guidance available in September 2026. The fictional service case, numerical option model, 8 percent teaching discount rate, NPV calculations, decision clinics, review checklist and evidence-led template are original explanatory material. They are not financial advice, procurement advice, legal advice or forecasts for an actual project. Real investment appraisal should use the organisation’s authorised accounting, economic, tax, regulatory and governance methods.

HM Treasury — The Green Book 2026. Current UK central-government appraisal guidance; used for options appraisal, value-for-money reasoning and the Five Case Model.
Association for Project Management — What is a business case? Used for the project-management definition of the business case as justification based on alternative options, benefits, costs and risks, and for lifecycle review.
HM Treasury — Guidance on developing business cases. Updated 30 June 2026; used for the staged process for developing project and programme business cases based on the Five Case Model.
National Institute of Standards and Technology — AI Risk Management Framework. Used in the AI section for the principle that AI trustworthiness and risk require lifecycle management rather than being treated as a generation-only capability.

The article intentionally keeps several neighbouring project-management disciplines separate. It does not replace detailed accounting or public-sector appraisal rules, Project Risk Management, Project Estimation, Project Benefits Realisation, Project Procurement Management, Project Sponsorship or Portfolio Management. Its canonical job is the investment argument connecting them.

Project Business Case | How Strategic Need, Options, Costs, Benefits and Continued Justification Govern Investment

Contents