The Business Case: Building a TCO Model That Survives the Questions

Most infrastructure business cases fail for the same reason. They are built to justify a decision that has already been made, by someone who knows the answer they need the model to produce.

Everyone in the room knows it. The CFO knows it, which is why the questions get sharper each year. And the model falls apart the first time somebody tests an assumption, because the assumptions were reverse-engineered from the conclusion.

This is how to build one that survives the questions. It is presales craft rather than architecture, but the two are the same job in most enterprises.

The three numbers that decide everything

Every infrastructure business case reduces to three figures, and most models get two of them badly wrong.

Get those three honest and the model largely builds itself. Get them wrong in the flattering direction and you have produced an argument rather than an analysis.

What belongs in the cost side

The licence or subscription figure is the number in the proposal and often less than half the real total. The components that get missed, roughly in order of how much they get missed by:

• Migration labour, estimated per workload class rather than per unit. A stateless VM might be an hour. A clustered database with a vendor support matrix, a change window and a rollback plan might be a fortnight. Averaging across the estate produces a number that is wrong by a multiple.
• Parallel running. You pay for both platforms during transition. For a large estate that overlap runs to quarters, and it is frequently the single largest line in the model.
• Retooling. Backup, monitoring, automation, security tooling, ITSM integration. Routinely underestimated by an order of magnitude, because each individual integration looks small and there are forty of them.
• Productivity dip. Your team gets slower before it gets faster. Six months of reduced throughput is a real cost even though nobody invoices you for it.
• Training and hiring. Including the market rate for skills you do not currently have, in your actual location rather than the global average.
• Hardware. Whether the target runs on what you own, and what the certification position genuinely is rather than what the datasheet implies.
• Risk-weighted cost of the migration going badly. Probability times impact. Rarely modelled, and the reason some honest business cases conclude "not yet."
• Exit cost of the destination. You are choosing your next lock-in. Price it, or you will run this exercise again in five years without the information.

What belongs in the value side, and how to keep it honest

The temptation is to claim everything. Resist it, because one indefensible benefit contaminates the credibility of the rest.

Split the benefits into three tiers and label them clearly.

Hard, contracted savings. A licence you stop paying. A data centre contract you exit. A support renewal avoided. These have invoice numbers behind them and they belong in the headline.

Quantifiable but modelled. Consolidation ratio improvements, storage efficiency, reduced incident volume. Real, but dependent on assumptions. Show the assumption next to the number, every time.

Directional. Faster time to market, improved developer experience, better security posture. Genuine and often the actual reason for the project. Do not attach a dollar figure to these. State them as outcomes and let them stand on their own, because a fabricated number here is what gets the whole model dismissed.

Model over five years, not three

Three-year models flatter migration projects. The disruption sits in year one, the savings arrive in years two and three, and the model conveniently ends before the next refresh or renewal event.

Five years shows whether the payback is real, and it forces you to model the second renewal, which is where a lot of apparent savings quietly reverse.

Run three scenarios rather than one. Expected, pessimistic, and optimistic. Present the pessimistic case first. It is counterintuitive and it works, because it signals you have thought about what could go wrong before anyone has to ask.

The assumptions page

Every model rests on assumptions. Most models bury them. Put them on one page, visible, with a name against each.

Migration hours per workload class. Consolidation ratio achieved. Parallel running duration. Rate of staff attrition during transition. Hardware refresh timing. Renewal pricing at year three.

Two things happen when you do this. The conversation shifts from arguing about the total to arguing about specific assumptions, which is a far more productive argument. And when something turns out differently, you have a documented basis for revising rather than a discredited model.

How to present it

• Lead with the decision, not the analysis. One slide: here is what we recommend, here is what it costs, here is what it returns, here is what would change our mind.
• Show the sensitivity. Which two assumptions, if wrong, would flip the answer. That is the question a good CFO asks, and having it answered before it is asked is worth more than any amount of detail.
• Name the risks you are carrying. A business case with no risks listed reads as either naive or dishonest.
• Keep the model available, not in the deck. Nobody wants to read a spreadsheet on a screen. They do want to know it exists and that you can open it.

Where this usually goes wrong

Three patterns, all common.

The model is built by the person who wants the outcome. Unavoidable sometimes, but it needs an independent reviewer with permission to say the number is wrong.

The benefits are modelled at full realisation from day one. Consolidation gains do not arrive on go-live. Ramp them.

Nobody owns the number. Distributed cost modelling produces a total that no single person can defend, which means the first hard question kills it. One person, accountable, with the assumptions written down.

The point of all this

A business case is not a sales document. It is the artefact that lets a group of people with different incentives agree on a decision and remember why they made it.

The best ones I have been part of were the ones where the honest model said no, and the team said so. That is the thing that buys you credibility for the next one, and there is always a next one.

Views expressed here are my own.