The business case that passes finance.

Most modernization proposals die in finance review, and they die for predictable reasons. The technology was sound. The opportunity was real. The document simply failed to answer the questions a CFO is obligated to ask.

Finance isn't obstructing you. Finance is applying the same standard to your proposal that it applies to a new hire, a facility, or an acquisition — and your proposal, unlike those, usually arrives without a baseline, without a downside case, and with benefits expressed in percentages rather than currency.

The four questions

1. Compared to what?

Every business case is implicitly a comparison against doing nothing, and most never state what doing nothing costs. If the current process consumes 400 hours a quarter at a loaded rate, say so. A proposal without a baseline isn't a case, it's a wish — and it's unfalsifiable, which finance recognizes instantly.

State the counterfactual explicitly: here is what this costs us per quarter if we change nothing, and here is how we measured it.

2. What has to be true?

Every projection rests on assumptions. Proposals that hide them look confident and get rejected. Proposals that list them look rigorous and get funded.

Write the assumptions down as a short list, with a source or a confidence level for each. "Assumes adoption reaches 70% within two quarters, based on our last rollout which reached 74%" is a sentence that wins arguments.

3. What happens if you're wrong?

Present three cases: downside, expected, upside. Most people present only the expected case, which reads as either naivety or salesmanship depending on the reviewer's mood.

The downside case is the persuasive one. If the project still clears the hurdle rate at 50% of projected benefit, say that — it's the strongest sentence in your document. If it doesn't, you've learned something important before spending the money.

4. When does the money come back?

Payback period, not just total return. A project returning three times over five years and one returning twice over one year are very different propositions to someone managing cash.

Include the timing of costs as well. Modernization programs often front-load spend and back-load benefit, and pretending otherwise damages your credibility in month four.

Three things to cut

• Industry-average statistics as evidence for your specific return. That a study found 40% efficiency gains somewhere says nothing about your process. Use benchmarks to size the opportunity, then justify your number from your own data.
• Benefits nobody will be accountable for. "Improved employee satisfaction" belongs in the narrative, not the model, unless you're prepared to measure it.
• Technology detail. Finance is not evaluating your architecture. One paragraph of approach, then back to the numbers.

The structure that works

1. The situation and what it currently costs, with the measurement method
2. The proposed change, in one paragraph, in plain language
3. Assumptions, listed and sourced
4. Three cases: downside, expected, upside
5. Cost and benefit timing, with payback period
6. What we'd need to stop or defer to fund this
7. How we'll know at 90 days whether it's working

That last item matters more than people expect. A proposal that includes its own early kill criteria signals that you're managing risk rather than defending a preference, and it is disproportionately persuasive to anyone who has funded a project that couldn't be stopped.