Every infrastructure business case compares a proposed future with another future. The analysis may look like a comparison of costs, technologies, or ownership models, but underneath it is always a counterfactual: what happens if we do not choose this option?
That comparison case is often called the baseline. It may be current operations, repair and continued use, replacement in kind, outsourcing, a different technology, phased investment, or doing nothing for a period of time.
If the baseline is wrong, the rest of the analysis can be perfectly calculated and still support the wrong decision.
WORKING PRINCIPLE
A project is only attractive relative to a realistic alternative.
The baseline is not background information. It is part of the decision itself. Define it poorly, and the economics, risks, and strategic tradeoffs can all be distorted.
“Do nothing” is rarely free
One of the most common mistakes in infrastructure analysis is treating the status quo as if it has no future cost.
Existing equipment may require rising maintenance, emergency repair, staffing, fuel, compliance work, capital renewal, or increasing outage risk. Deferred replacement may preserve cash today while creating larger obligations later.
A no-project case is still a future scenario. It should include the costs and risks of continuing on the current path.
Current operating cost is not always the right baseline
A proposed project is often compared with what the organization spends today. That can be misleading when current infrastructure is near the end of its useful life.
If major replacement is approaching, the more relevant comparison may be the full cost of continuing service through replacement, not simply this year’s operating expense.
A service model can look expensive compared with fully depreciated equipment and attractive compared with the capital program the organization is actually facing.
The baseline should reflect the decision the organization really has
Business cases are strongest when they compare realistic alternatives rather than artificial opposites.
The choice may not be “new system versus existing system.” It may be replace in kind, repair and defer, outsource, connect to shared infrastructure, phase the investment, or choose a different technical configuration.
The relevant alternatives are the ones the organization could actually pursue.
Timing changes the baseline
Infrastructure decisions are highly sensitive to when an alternative would have to occur.
A boiler that might last ten more years creates a different comparison than one expected to require replacement within two. A capacity constraint that may affect growth next year creates a different baseline than one with substantial remaining headroom.
The baseline therefore needs a timeline, not merely a cost estimate.
THE BASELINE TEST
What would the organization actually do if this project disappeared tomorrow?
The answer should describe a credible alternative path, including its timing, capital requirements, operating costs, risks, and consequences—not simply “continue as-is.”
Sunk costs should not make the old system look artificially cheap
Existing infrastructure often appears inexpensive because much of its original capital cost has already been spent.
That historical cost matters for accounting, but it should not automatically determine the forward-looking decision. The question is what resources, risks, and future obligations each alternative creates from this point forward.
A fully depreciated asset can still be expensive to keep.
The baseline should include operating reality
A comparison based only on energy and capital can miss what changes in day-to-day operation. Staffing needs, maintenance demands, and the ability to respond when equipment fails can make the less expensive option harder to sustain.
If one alternative requires specialized operators, recurring overhauls, or continued exposure to a known failure mode, those conditions belong in the baseline.
The current system is not merely a number. It is an operating model.
Risk belongs on both sides of the comparison
Project teams often scrutinize the risks of a new solution while treating the baseline as certain.
But existing infrastructure also carries uncertainty: failure timing, future maintenance, fuel cost, capacity constraints, regulatory changes, staffing availability, and capital escalation.
A fair comparison makes the uncertainty of both futures visible.
Avoided investment only exists if the baseline really requires it
Avoided capital can be a major source of project value, but only when the organization would otherwise need to make that investment.
If a proposed service model avoids a replacement plant that is already becoming necessary, that avoided investment is real. If the baseline would not require the capital for many years, the value is different.
The strength of an avoided-capital argument depends on the credibility of the baseline behind it.
The baseline can change as the project develops
Early in development, the team may compare a concept with continued operation. Later, better information may reveal that replacement is unavoidable, that capacity requirements have changed, or that another option is more credible than originally assumed.
Updating the baseline is not moving the goalposts. It is part of improving the decision as the evidence improves.
What matters is that changes are explicit and supported rather than quietly embedded in the model.
A good business case compares futures, not products
The most useful infrastructure analysis does not ask whether one technology is cheaper than another in isolation.
It asks what each credible future will cost the organization, how it would operate, and which risks and commitments would remain. That is a comparison of practical choices, not just products on a price sheet.
That is why defining the baseline belongs near the beginning of the decision process, not as a modeling detail near the end.
The baseline is part of the recommendation
A recommendation is only as defensible as the alternative it rejects.
If the comparison case is unrealistic, incomplete, or artificially cheap, the project may look weaker or stronger than it really is.
The first question in a serious business case should therefore be simple: compared with what?