A business case is written to get approved.

The numbers, and what each one hides

Four calculations do most of the work. Each answers a real question and each conceals something.

Payback	How long until you get your money back. Easy to explain and ignores everything after the payback date, so it favours short projects over better ones
NPV	Future cash flows discounted to today's value. The most complete measure, and entirely dependent on the discount rate and the forecasts you fed it
IRR	The rate of return the project earns. Comparable across options, and it flatters small projects. A 40% return on $20,000 is worth less than a 15% return on $2 million
WACC	What your money costs, blending debt and equity. Usually the basis for the discount rate, and the reason a project returning less than your borrowing rate destroys value however positive it looks

Use more than one. A project that looks good on all four is genuinely good. A project that looks good on exactly one is usually being presented on that one for a reason.

The assumptions matter more than the arithmetic

The calculation is a few minutes of work. The inputs are where the answer actually lives, and they are typically supplied by whoever wants the project to proceed.

The questions worth asking about any business case:

• Where did the revenue forecast come from? A signed contract, a customer conversation, or an assumption about market share
• Does it include the costs nobody budgets? Training, downtime during changeover, the extra work on people already fully occupied, maintenance and licensing in later years
• What is the base case being compared to? Doing nothing is rarely static. Sometimes doing nothing means declining
• Who benefits from approval? Not as an accusation. Just as information

Testing the case before you commit

Three levels of rigour, escalating with the size of what is at stake.

Sensitivity	Move one variable at a time. Tells you which assumption the answer actually depends on, which is frequently not the one under discussion
Scenarios	Move several together in coherent stories. What a bad year actually looks like, rather than each input being 10% worse independently
Simulation	Move everything at once, thousands of times, and get a probability rather than a number

For a smaller business, stop at scenarios

Three scenarios worked through honestly beat a simulation built on invented distributions. The most valuable discipline is simpler still: write down what would have to be true for this to work, before you decide. Then the assumptions exist somewhere other than in your head, and you can check them against what actually happened.

That is the small-business version of everything in the second half of this page.

What simulation adds, and where it misleads

Monte Carlo simulation runs the model repeatedly, drawing each input from a range rather than taking a single value, and returns a distribution. The question shifts from what is the NPV to what is the probability this loses money, which is what a board is actually asking.

It exposes three things a point estimate hides:

• The flaw of averages. If six things each have to go roughly to plan, and each is individually likely, the base case is nowhere near as likely as any single assumption suggests. Nobody computes that probability by hand
• Contingency becomes principled. Instead of adding 10% because that is what was added last time, contingency is the gap between the base case and the confidence level you have chosen to fund. That is defensible in a way a percentage never is
• Correlation, which is where simulations go wrong. Treating inputs as independent when they are not understates the tails badly. Labour cost and schedule delay move together. A supply chain disruption hits several line items at once. A model that misses this produces a comfortingly narrow distribution and is worse than no model

Wrapped around this, the Cost Estimate Validation Process is the discipline of getting the inputs honestly: structured workshops to elicit risks from the people who know them, then simulation, with the output expressed as confidence levels rather than a single figure. The process matters more than the mathematics, because the mathematics is only as good as what went in.

Its real contribution is that it gives management and the board something they can actually challenge. A single number invites one question, whether it is right, and there is no good way to argue about it. A ranged estimate with its assumptions written down invites better questions: which risks were identified, who identified them, what was assumed about the ones nobody could price, and why the estimate is being funded at this confidence level rather than a higher one.

That turns approval from an up-or-down vote into a discussion about specific assumptions owned by specific people. It also creates a record, so when a variance appears eighteen months later it can be traced to an assumption rather than absorbed as bad luck. An estimate nobody was able to interrogate is an estimate nobody is accountable for.

The caution: a smooth curve looks authoritative regardless of whether its inputs were evidenced or guessed. False precision is its own risk, particularly when used to ratify a decision already taken.

Why projects overrun

Cases fail at execution more often than at approval. The patterns repeat across industries and across scales.

Scope, and the two ways it moves

Intentional scope change is a decision: circumstances changed, and adding something is the right response. That is legitimate and manageable, provided it goes through a process.

Unintentional scope creep is accumulation. Nobody decided; a series of small accommodations added up. It is usually invisible until it is expensive, because no single step was large enough to challenge.

The Royal Adelaide Hospital is the standard example of the first kind compounding: a major public project where changes to the design and requirements during construction contributed to substantial cost and schedule overrun. The individual decisions were defensible. The aggregate was not.

Change control, and whether anyone respects it

Almost every organization has a change control process. The question worth asking is not whether one exists but whether it is used, and whether the answer is ever no.

Warning signs:

• Change orders used routinely to compensate for design, permitting or planning work that was incomplete at the outset. When change orders become the mechanism for finishing the design, the original estimate was never an estimate
• Approval authority unclear, so decisions get made by whoever is nearest and are documented afterwards, if at all
• Political pressure to approve, where challenging a change is understood to be unwelcome
• No analysis of causes. Nobody asks what is driving the change orders, so the same cause produces them again next quarter

Tone at the top decides all of this. A process nobody is allowed to invoke is not a control.

Procurement and contracts

• The competitive process gets shortened under time pressure, which is precisely when it is most needed
• Standard templates get abandoned for a bespoke arrangement, and the standard clauses that were in the template for a reason are the ones that go missing
• Procurement and the project team work separately, so terms get agreed that operations cannot actually live with
• Risk is transferred downstream without visibility. A prime contractor passing risk to subcontractors does not remove it from the project; it removes it from view
• Subcontractor oversight is thin. Know who is actually doing the work, what their credentials are, and who they rely on before anyone is inside your key processes

Lead times and the supply chain

Long-lead items deserve their own analysis, because they cannot be recovered by working harder.

Electrical transformers are the current textbook case: largely imported, with lead times that have extended dramatically, so a delivery route disruption becomes a project bottleneck that money cannot solve. The question to ask at the outset is not what the lead time is, but what the plan is if it doubles, and whether an alternative source has been identified while there is still time to qualify one.

Buying early to avoid this has its own failure mode. Materials purchased ahead of a design being finalised may turn out to be unusable and have to be sold off, which is poor due diligence appearing as prudence.

Siloed departments

Worth separating out, because most of the failures above are downstream of it.

Procurement, finance, operations, legal and the project team each hold part of the picture and none holds all of it. Finance forecasts from figures the site would not recognise. Legal sees the contract after the commercial terms are fixed. Operations discovers a specification it cannot work with. Nobody owns the interfaces between workstreams, which is exactly where projects fail.

The fix is unglamorous: information has to travel sideways, not only up. Reporting lines carry information to the top and rarely across, and the people who could have flagged a problem to each other never met.

Forecasting and late-surfacing problems

Reforecasts should reflect real progress on the ground rather than the percentage of budget consumed. A project reporting 60% complete because 60% of the money is gone is not reporting progress; it is reporting spending.

And material problems should escalate early, while options still exist. The tendency runs the other way: bad news travels slowly upward, arrives late, and arrives when the remaining choices are all poor. An organization where early escalation is rewarded gets different information than one where it is punished, and it gets it in time.

Where challenge has to live

Three layers, and none substitutes for another.

• Management challenges its own case. The hardest of the three, because the people preparing it usually want the project
• The board challenges what it is given. But a board can only challenge what reaches it. If reforecasts arrive smoothed, the board is not failing to challenge; it is being given nothing to challenge
• Independent review challenges both

Five questions worth asking about any major case

1. What would have to be true for this to fail?
2. Which single assumption moves the answer most, and who owns it?
3. What confidence level is this number, and what does the funded contingency assume?
4. What happens if the long-lead item slips two quarters?
5. What did we learn from the last one of these?

The last question does more than the other four combined, because asking it routinely creates the feedback loop that makes the next case better.

What the SANDAG programme illustrates

The Mid-Coast transit extension in San Diego is instructive because the public record separates the causes. A 2010 estimate of about $1.24 billion against a budget that reached roughly $2.1 billion, driven both by added scope and by the same scope costing more. Those are different problems with different remedies, and conflating them prevents either being addressed.

One engineering and environmental services contract grew from about $25 million awarded to over $128 million. And in 2023 the organization's own internal auditor reported that leadership had hindered a review of contracts, which is the tone-at-the-top point stated by someone whose job was to look.

Before the money goes

Where I fit

For a smaller business, building the case: what it costs fully loaded, what it has to deliver, and what would have to be true. See accounting solutions.

For larger programmes, independent review at the front end, structured to preserve the boundary between assurance and advisory work. I can challenge a case, and the same person should not then be helping build the thing they approved.