Five questions to ask before you approve any business case

Blog post — The Sponsor's Playbook

The business case on your desk has been constructed to persuade. The assumptions it makes explicit are the ones the team is most confident in. The risks it surfaces are the ones visible enough to require mention. The estimates it presents are the ones that survived the approval process — the ones that produced an approval-worthy number, not necessarily the ones the project team built from the ground up.

This is not dishonesty. It is the predictable behaviour of a document that has been through multiple rounds of review by people who need it to succeed. It is a presentation, not a disclosure. And the gap between those two things is where most project disappointment originates.

You have ten minutes before the approval meeting. These five questions, asked specifically and waited on for specific answers, take those ten minutes and prevent years of remediation.

Question 1: What does the bottom-up estimate actually total, and how does it compare to what we are approving?

In most organisations, for most complex initiatives, these two numbers are different. The bottom-up estimate — built by the people who understand what the delivery actually requires — and the top-down allocation — the budget the organisation has determined it is prepared to commit — rarely match.

The gap between them does not get negotiated away. It gets absorbed. The bottom-up estimate becomes "initial thinking" or "worst-case scenario," recharacterised until it fits the predetermined budget. The project team receives clear structural messaging: make it work within approved parameters.

If the gap exceeds fifteen percent, demand explicit reconciliation before proceeding. "Which capabilities, contingencies, or resources were removed to close this gap, and what are the specific consequences of each removal if delivery proceeds as planned?" Vague promises of efficiency do not count. You need specific answers.

Question 2: Which assumptions in this business case have been independently validated?

Every business case is built on foundational beliefs — about resource availability, technical compatibility, vendor capability, regulatory timelines, stakeholder readiness, and organisational capacity for change. Some of these assumptions are explicitly stated. Many are implicitly held. All of them are load-bearing.

The question that matters is not "what are the assumptions?" A good business case will have articulated those. The question is: "Which of these assumptions have been independently validated, and which are carrying more weight than the evidence supporting them can bear?"

Ask the project team to specify, for each critical assumption, what evidence underpins it and what happens to the plan if the assumption proves wrong. The response to the second part of that question is particularly revealing. If the answer is silence, or a generalised assertion of confidence, or a restatement of the assumption with more conviction — the assumption is carrying weight it has not earned.

Question 3: What contingency percentage is built in, and what methodology determined it?

Contingency in a business case is the shock absorber designed to protect delivery from the inevitable surprises that complex initiatives produce. It is also the first thing removed during approval negotiations, characterised as padding by people who have never had to explain to a board why a project is twenty percent over budget with no buffer remaining.

Anything below ten percent for a complex initiative signals fantasy planning. Ask for the methodology: how was the contingency figure derived? If the answer is "it is ten percent of the total budget" without any analysis of specific risks and their probability-weighted costs, the number is cosmetic rather than analytical.

Question 4: Who on the project team has delivered similar scope at this scale?

Delivery experience is not transferable in the way that many business cases imply. The project manager who has delivered ten small technology implementations has not thereby demonstrated the capability to deliver a large-scale business transformation. The vendor who has delivered well in a different industry context has not demonstrated that the same capability transfers to yours.

If the answer to this question is "nobody on the current team has delivered at this scale," the timeline is suspect — regardless of how confident the presentation. Build in a realistic ramp period or revisit the resourcing model before approval.

Question 5: What is our honest track record on projects like this?

Pull the last three completed initiatives of comparable scale and complexity. Create a simple two-column document: approved budget, timeline, and scope on the left; actual expenditure, delivery date, and what was ultimately delivered on the right.

If past performance shows thirty percent overruns and this business case assumes zero, you are approving optimism rather than analysis. The pattern is not a coincidence. It is a signal about the structural conditions in which these initiatives are being planned and approved — and those conditions have not changed because a new business case has been written.

These five questions take ten minutes. They are not about distrust. They are about the basic professional responsibility of approving capital commitments with your eyes open about what you are actually committing to.

The project team will have better answers ready than you might expect. In most cases, they have been thinking about exactly these things and waiting for someone with the authority to ask.

Want to go deeper?

This post draws on ideas developed at length in The Sponsor's Playbook. If what you found here was useful, a free core summary is available to download at ghostquantumco.com/books/the-sponsors-playbook.

Richard Cantlon offers one-to-one consultations for executives who want to apply these frameworks to a specific initiative. Schedule a session at ghostquantumco.com.