The Project Business Case Structure That Wins Funding

Most project business cases open with the tool. Slide two lists the features, slide three lists the benefits, and by slide four the sponsor is quietly deciding whether the budget really needs to move this quarter. That order is backwards, and it is why well-argued cases with real numbers still get sent back for a second pass.

A project business case that gets funded leads with the cost of doing nothing, not with what the proposed tool or project does. The structure that reliably wins approval has five parts, in this order: the problem stated in the sponsor's terms, the options considered, the recommended option with a defensible cost and benefit, the cost of inaction, and a payback figure the sponsor can check without having to trust you.

The five-part structure, in order

1. The problem, in the sponsor's terms, not the PMO's
2. The options considered, including doing nothing
3. The recommended option, with a defensible cost and benefit
4. The cost of inaction: what doing nothing actually costs, with a date attached
5. A payback figure the sponsor can check independently

Why Feature-First Project Business Cases Get Rejected

A sponsor reading a feature-first case has to do the hardest part of the evaluation themselves: figuring out what happens if they say no. When that number is missing, the proposed spend looks optional, and optional spend gets deferred to next quarter almost by reflex.

	Feature-first case	Cost-first case
Opening slide	What the tool or project does	What doing nothing costs, by when
First number cited	Feature count or price	Cost of inaction
Benefits framing	General ("better visibility")	Specific and dated
Sponsor's first question	"Do we need this now?"	"Is this number right?"
Typical outcome	Deferred for more information	Approved or specifically challenged

The right-hand column is not a trick. It is the same facts, reordered so the sponsor's first question is about your numbers instead of about your timing.

Start With the Problem, in the Sponsor's Terms

The PMO's version of the problem is usually about process: schedules aren't visible, resources are double-booked, reporting takes three days to assemble. The sponsor's version of the same problem is about the thing they are accountable for: a portfolio decision made on stale data, a delivery commitment made without knowing capacity was already spoken for. A business case, in the formal sense, connects proposed work to a demonstrable business need rather than to a technical improvement, and the problem statement is where that connection either gets made or gets lost. State the problem in the sponsor's language, not the PMO's, and the rest of the case reads as relevant instead of as a tooling request.

Present Options, Including Doing Nothing

A case with one option, the one you already want, reads as a decision dressed up as a request, and sponsors who notice that (most do) start looking for what was left out. Present the real options, typically three: do nothing, a minimal fix, and the recommended path, each with its own cost and consequence. "Do nothing" has to carry a real cost, not a zero. If it costs nothing to do nothing, there is no case to make.

The diagram below shows how the five parts connect: each one sets up the number the next one depends on.

Make the Benefit a Number the Sponsor Can Check

The payback figure is the number a sponsor remembers from the meeting, so compute it in a way they can audit without asking you to walk them through it again. Payback period is simply the cost of inaction minus the cost of the recommended option, expressed as the month the recommended option's cumulative cost drops below the do-nothing cumulative cost. Show the assumptions next to the number, not buried in an appendix: user count, the productivity-loss percentage you used, the consulting rate. A sponsor who can re-derive your number trusts it more than a sponsor who has to take it on faith.

For a worked version of this at Project Online migration scale, the ROI calculation walkthrough runs the same payback math end to end at 100 seats, and the CFO-proof migration business case applies this exact five-part structure to a retirement-driven migration specifically.

What to Leave Out

Feature lists belong in an appendix, not the first five slides; sponsors approve financial decisions, not checklists. Soft benefits ("improved collaboration," "better visibility") get one line near the end, not the opening argument; a benefit nobody can measure is a benefit a CFO discounts to roughly zero. And drop hedged language: "may reduce" and "could improve" read as a case that does not believe its own numbers. If a claim needs a hedge to be honest, the fix is a better number, not softer language.

Once a case is funded, the work does not stop at approval. Benefits realization is the discipline of checking, after delivery, whether the numbers in the business case actually showed up, and it is worth building that check into the case itself: name the metric, the date you will measure it, and who owns the answer. A governance model that requires this at project close is what keeps the next business case's numbers credible, because the sponsor remembers whether the last one was right.

Microsoft Project Online™ is a trademark of Microsoft Corporation. Onplana is not affiliated with Microsoft.