Building the Business Case for Microsoft Fabric to Your CFO

Read from the finance chair, a technology-framed paper requests certain cash against a described capability — no line a CFO can put in a forecast, no line they can hold someone to, and no point at which they can stop. That is not obstruction; that is a CFO doing the job.

The fix is a different document: one that names benefits, owners, dates, and the point at which the investment can be stopped. Here is how to build it.

It asks a CFO to approve dated, certain cash outflow against benefits expressed as capabilities with nobody accountable. Phrases like "one version of the truth" and "modern data platform" describe a state, not a return. Three failures show up in almost every rejected paper:

• The benefit is a capability, not a number in someone's budget. "Faster reporting" is not a benefit. A benefit is a line that changes in a cost centre or a balance sheet account, with a named person who agrees it will change
• Nobody has agreed to give anything up. If the case claims 1.5 FTE released, finance asks which cost centre reduces its headcount budget and by when. "Nobody — the analysts will do better work" is legitimate, but it is released capacity, not cash, and must be labelled that way
• The cost side is visibly incomplete. Capacity plus an implementation fee, with no internal effort, run cost or parallel running, tells an experienced CFO the author has not done this before

A CFO approves a cash-flow shape and a risk position, not an architecture. They are deciding whether committed spend over a defined period is justified by benefits with named owners, whether the downside is survivable, and whether the commitment can be stopped part-way. Architecture matters only as evidence that the spend estimate is credible.

That moves the medallion diagram to an appendix. The front page carries four things: what is being bought, over what period, what changes and who owns each change, and where the decision points are. It also changes who writes it — benefit lines must come from the people who own the affected budgets: the Supply Chain Head for inventory, the Financial Controller for close effort, the IT Head for licence retirement. A number is trusted only when its owner wrote the definition.

Labour is the one you can count — instrument it, do not estimate it; reconciliation and rework usually dominate the hours, and a platform removes assembly reliably but rework only if data quality is addressed too. Working capital is the biggest number and the weakest evidence — the platform does not release working capital, a planner setting safety stock from a current view rather than a six-week-old spreadsheet does, and only if they act. Cost avoidance is the most defensible line because it references documents finance already holds — but a cost-avoidance line without a decommission date is an intention, not a benefit. And decision speed should be argued as risk: state the exposure factually — if a quality escape is detected eleven days after the batch shipped, recall scope is a function of that lag — and let the CFO price it.

Separate what the platform causes from what it enables. A data platform does not improve margin; it removes a constraint that stopped someone acting. Record the baseline before you build anything — freeze current values for every metric in the register, with date and source, because a benefit claimed against an unrecorded baseline is unauditable. Name the intervening decision — write the chain out: service levels visible daily → planner reviews safety stock weekly → stock on an identified SKU set falls. If any link has no owner, the benefit is not real yet.

Use a control where one exists — deploy to two depots and not the other three and you have a comparison, far better than a before-and-after in a year when three other things changed. Label benefits "platform-enabled" rather than "platform-caused" wherever a human decision sits in between.

A complete cost model has five lines: capacity, implementation, internal time, run cost and the parallel-running period. Capacity is the visible line and rarely the largest — bought as F SKUs, pay-as-you-go or reserved, with two details for the paper: unused reserved hours cannot be carried forward, and OneLake storage is billed separately per GB and keeps billing while a capacity is paused. Implementation is build cost for a defined scope — if it is not fixed-scope, the CFO is being asked to approve an open commitment.

Internal time is the line nobody budgets: source access, master data decisions, metric sign-off, UAT, and the analyst who sits with the delivery team while their day job continues. Cost it at loaded rates and show it — if the business cannot release those people, the schedule is fiction, and the approval meeting is the right place to find that out. Run cost is capacity beyond go-live, per-user licences below the F64 threshold, monitoring and a named support arrangement — a platform with no run budget degrades within two quarters. And the parallel-running period: for one to three cycles you pay for both worlds, and every case I have seen that omitted it produced an unpleasant conversation in month four.

Present the investment as staged tranches with a decision gate after the first slice. Tranche one funds a bounded slice — one domain, one audience, a reconciled outcome — with pre-agreed gate criteria and a stated stop condition. That converts an all-or-nothing commitment into a reversible one, which is materially easier to sign.

Write the gate criteria before the slice starts, with the same care for stop conditions as success conditions. A usable gate reads: the slice reconciles to the legacy report within an agreed tolerance; the named business owner has retired that legacy report on a stated date; measured capacity consumption sits inside the sizing assumption; and at least one benefit line has moved against its recorded baseline. Then commit to the harder half — if the gate is missed, tranche two is not released and the reasons are documented. A sponsor who has genuinely stopped a programme at a gate before will be believed; one who has never stopped anything will not.

A CFO will ask which single assumption, if wrong, breaks the case. Model working capital benefit at zero, adoption delayed by two quarters, capacity consumption one SKU tier above plan, and two legacy systems never decommissioned. If the case survives with working capital at zero, it is fundable on cost avoidance and labour alone — the strongest position to argue from.

Working capital at zero is the honest stress test: if the case only works when the largest and least attributable benefit lands in full, it is a hope, not a case. Adoption lag matters because benefits are modelled from go-live while reality is that one director keeps the legacy report for another quarter.

Say so and narrow the scope rather than inflating the benefits. Three honest responses exist. Narrowing usually works — a case that fails across four domains often clears on one, where a legacy licence renewal falls inside the appraisal period and a single reporting team's hours are recoverable; fund that, prove it at the gate, and the second tranche argues itself. Deferring builds the most credibility — "the arithmetic works from March, when the warehouse appliance comes up for renewal" is a professional answer, and it means you are believed when you return.

Reframing as compliance works only where a regulator, an auditor, an e-invoicing mandate or a customer contractual obligation genuinely drives it; there the hurdle rate is the wrong test. Where it is not real, do not reach for it — inflating a number to clear a gate creates a debt that comes due at the first post-implementation review.

A good case does not create a sponsor — if no executive outside IT will put their name against a benefit line, the case is not weak, the mandate is missing; fix that first. Benefit registers decay — owners move roles and baselines get overwritten, so unless someone owns the register as a standing monthly item, tracking stops within two quarters. Attribution never becomes clean — even with baselines and a control group you will not fully separate the platform's contribution from a new planner or a demand shift; plan to argue contribution, not causation.

Cost avoidance evaporates if nobody decommissions — the legacy warehouse stays alive because one report nobody will name still runs on it, the licence renews, and the saving disappears. Capacity cost is not fixed by approval — consumption moves with what gets built, so the approved figure is a starting run rate. And a funded platform does not produce decisions — approval buys infrastructure and a delivery team; changing what happens in the Monday operations meeting is separate work, and every benefit line depends on it.

Five questions to answer this week, before rewriting a page:

• Which named executive outside IT will put their name against a benefit line — and have you asked them?
• Which contracts does this displace, with renewal dates and current invoice values? Pull the actual documents
• Have you instrumented two full reporting cycles to measure analyst hours, rather than estimating them?
• What is the smallest slice that produces a reconciled, owned outcome — and does that slice clear the hurdle on cost avoidance and labour alone?
• What would have to be true for you to recommend stopping after tranche one, and would you actually say it?

If question one has no answer, the problem is not the business case. If question four clears on its own, you have a fundable paper already, and working capital becomes upside rather than load-bearing. We build these with the client rather than for them, because benefit lines only hold up in a finance review when the budget owners wrote them.