Building a Business Case Executives Actually Approve

A business case executives actually approve is one built around a single, specific financial or operational outcome they already care about, not a list of features or technical benefits. Executives approve business cases they can defend to their own boss in one sentence; everything else in the document exists to support that one sentence.

Start With the Metric, Not the Solution

The business cases that stall in committee almost always lead with the solution - 'we need a new CRM,' 'we should move to the cloud' - and only justify the spend afterward. The ones that get approved quickly lead with the metric the executive is already accountable for: sales cycle length, cost-to-serve, order-to-cash time, customer churn. The technology is presented as the mechanism, not the headline. Executives fund outcomes they're measured on; they don't fund technology for its own sake, however elegant the architecture.

This means the first conversation in building a business case isn't with IT or the vendor - it's with the executive sponsor, establishing exactly which number they need to move and by how much to make the investment worth defending upward. If you can't get a specific answer to that question, the business case isn't ready to be written yet, no matter how well-scoped the technical solution is.

This also reshapes who should be in the room when the business case is drafted. Involving the finance team early, rather than presenting them with a finished number to validate, means the cost and benefit assumptions are already built in a way finance will recognise and trust, instead of requiring a second round of scrutiny that delays approval by weeks. A business case co-authored with finance from the outset moves through committee markedly faster than one finance sees for the first time in the approval meeting.

The Numbers Have to Survive Scrutiny

Every business case includes a cost and a projected benefit, and the benefit number is where most cases lose credibility - inflated ROI projections, unrealistic adoption assumptions, or benefits that assume everything goes perfectly. Executives who've approved technology projects before have seen this pattern and discount optimistic numbers on sight. A business case that shows the conservative case, the expected case, and the assumptions behind each is more credible than one showing a single best-case number, because it signals the team has actually stress-tested its own thinking.

It also helps to show the benefit in the same units the organisation already uses to talk about performance elsewhere - if the finance team reports in EBITDA impact, translate the case into that language rather than a generic ROI percentage that has to be re-translated by whoever reads it next. A business case that speaks the organisation's existing financial language gets approved faster than one that requires the reader to do the translation themselves.

The cost side needs the same rigour: total cost of ownership over three to five years, not just the initial build cost, including licensing, the internal time commitment from business teams, the change management effort, and the ongoing maintenance the new system will require. Executives have been burned before by 'cheap' projects that turned expensive after go-live; showing you've already accounted for that builds trust the number itself can't.

What Belongs in the Business Case, and What Doesn't

• The specific business metric this investment moves, with a target and a timeframe
• Total cost of ownership across three to five years, not just build cost
• A conservative, expected, and best-case benefit scenario, with the assumptions stated explicitly
• The risk of doing nothing - what happens to the metric if the organisation doesn't act
• A phased delivery plan that shows value within the first quarter, not just at the end
• The specific decision being asked for - approval to fund the next phase, not the entire multi-year programme in one ask

Addressing Risk Without Undermining Your Own Case

Every executive reading a business case is silently running their own risk assessment, and a document that ignores risk entirely reads as naive, not confident. Name the two or three biggest risks explicitly - data migration complexity, user adoption, integration with an existing system - and show the specific mitigation for each. This does more to build confidence than omitting risk altogether, because it demonstrates the team understands what could go wrong and has already planned around it, rather than hoping it won't happen.

The risks worth naming aren't limited to delivery risk. Include the organisational risk too - what happens if the project succeeds technically but the affected teams don't adopt it, or if a key stakeholder who championed the project changes roles midway through. Executives who have sat through failed technology projects before are specifically listening for whether the team has thought past the technical delivery into the messier organisational reality that determines whether a project actually pays off.

Getting the Timing and the Ask Right

A useful discipline here is writing the ask as a single sentence before writing anything else: we are asking for a specific amount to fund a specific phase, which will move a specific metric by a specific amount within a specific timeframe. If that sentence can't be written cleanly, the business case underneath it usually isn't ready either, no matter how much supporting detail has been assembled around it.

The single biggest tactical mistake we see is asking for approval of the entire programme budget upfront, when a phased ask - fund the first phase, prove the metric moves, then fund the next - is both easier to approve and lower risk for everyone involved, including the sponsor whose name is on the case. A business case that asks for a smaller, provable first commitment gets approved faster than one asking for a multi-year blank cheque, and it builds the track record that makes the second ask far easier than the first.