Why Most Business Cases Get Rejected

By Ty Sutherland

You’ve identified a real problem. You have a solution in mind. You’ve even done some research. But when you present your business case, the answer comes back as a soft no — “let’s revisit this next quarter” — and nothing happens.

The problem usually isn’t the idea. It’s the case you built around it. Decision-makers reject business cases when they can’t quickly see the return, when the risks feel unaddressed, or when the numbers don’t hold up to a single follow-up question.

This guide walks you through how to build a business case that earns approval — not by being clever, but by giving your audience exactly what they need to say yes with confidence.

What a Business Case Actually Is

A business case is a structured argument for why an organisation should invest resources — money, time, or people — in a specific initiative. It answers three questions:

• What is the problem or opportunity?
• What do you propose to do about it?
• Why is this worth the investment?

It’s not a project plan. It’s not a wish list. It’s a decision-making document. Keep that framing in mind as you build it, because every section should be pulling the reader toward a clear decision.

Step 1: Define the Problem Precisely

Vague problems produce vague approvals — or no approval at all. Start by defining the problem with enough specificity that a sceptical executive can’t dismiss it as an opinion.

Instead of writing “our onboarding process is slow,” write “new hires currently take 11 weeks to reach full productivity, compared to an industry benchmark of 6 weeks. This delays output and increases manager time-on-boarding by an estimated 4 hours per hire.”

Good problem statements include:

• A measurable description of the current state
• The impact of leaving it unchanged (cost, risk, missed opportunity)
• Evidence that this is real and not a one-off anomaly

If you can’t quantify the problem yet, use observable indicators. Customer complaint trends, staff turnover data, delivery delays, and support ticket volumes are all legitimate evidence. The goal is to make the problem feel real and urgent — not abstract.

Step 2: Identify Your Options

A common mistake is presenting only one solution. This makes your case look like advocacy rather than analysis, and it puts decision-makers in the uncomfortable position of choosing between your idea and nothing.

Present at least three options:

• Option A: Do nothing. Describe what happens if the status quo continues. Include the ongoing cost or risk. This is your baseline.
• Option B: A minimal or low-cost intervention. This shows you’ve thought about resource constraints.
• Option C: Your recommended solution. The full proposal you’re actually building the case for.

You don’t need to give each option equal weight. The point is to show rigour, not to genuinely promote doing nothing. By including options, you demonstrate that your recommendation was chosen from alternatives — not invented in isolation.

Step 3: Build Your financial case

This is where most business cases fall apart. Executives and finance teams will scrutinise your numbers, and if they find one figure that looks inflated or unsupported, they’ll question everything else.

Your financial case should cover:

• Total cost of the initiative — include one-time costs, ongoing costs, and any hidden costs like staff time during implementation
• Expected return or benefit — revenue gained, cost avoided, time saved (converted to a dollar value), or risk reduced
• Payback period — how long until the investment breaks even
• Return on investment (ROI) — a simple percentage or ratio that makes comparison easy

Be conservative. Decision-makers discount optimistic projections automatically. If you can show a strong ROI even with conservative assumptions, your case is far more credible. Label your assumptions clearly — “this estimate assumes a 10% reduction in call-handling time based on vendor data from similar deployments” is much stronger than an unexplained number.

If the benefit is hard to quantify — improved staff morale, reduced reputational risk — say so honestly and provide a range or a qualitative argument. Pretending you can precisely measure everything is less credible than acknowledging what you can and can’t prove.

Step 4: Address Risk Upfront

Decision-makers are paid to worry about what can go wrong. If you don’t address risk in your business case, they’ll fill in the gaps themselves — usually with worst-case thinking.

Include a short risk section that covers:

• The two or three most significant risks to the initiative
• The likelihood and impact of each
• What you plan to do to mitigate them

You don’t need a full risk register. You need to show you’ve thought beyond the best-case scenario. A manager who can say “here’s the main risk and here’s how we’ll manage it” is far more reassuring than one who only talks about upside.

Also address the risk of inaction. What happens if this doesn’t get approved? If the answer is “not much,” your case is weak. If the answer is “we continue losing £200k per year in preventable errors,” that belongs in your document.

Step 5: Make a Clear Recommendation

After presenting the problem, the options, the financials, and the risks, tell people what you want them to do. Be specific.

“We recommend Option C: implementing the new onboarding platform at an estimated cost of £45,000, with a projected payback period of 14 months and annual savings of £38,000 thereafter. We are requesting approval to proceed to vendor selection and request a budget allocation from the Q3 discretionary fund.”

This is not the place for hedging. You’ve done the analysis. Own the recommendation. Decision-makers appreciate directness — it makes their job easier.

Step 6: Know Your Audience

The same business case needs to land differently depending on who’s reading it. A CFO wants to see the numbers fast. An operations director wants to know how it affects day-to-day workflows. A CEO wants to understand the strategic rationale.

If you’re presenting to a mixed group, structure your document so the executive summary gives everyone what they need in the first page, and the supporting detail is available further in for whoever wants to dig deeper.

Think about the objections each person in the room is likely to raise, and address them before they’re asked. If you know your finance director always asks about implementation risk, put that section in the body of the document rather than waiting to answer it verbally.

How to Structure the Document

Keep it readable. A business case that requires forty minutes to understand will be deferred. Aim for a document that a busy executive can read in ten minutes and a detailed reviewer can work through in thirty.

A standard structure that works well:

• Executive summary — one page maximum. Problem, recommendation, cost, return, and ask.
• Problem statement — two or three paragraphs with supporting data
• Options considered — brief summaries of each with pros and cons
• Recommended solution — description of what you’re proposing and why
• Financial analysis — costs, benefits, ROI, payback period
• Risk assessment — top risks and mitigations
• Implementation overview — high-level timeline and key milestones
• Conclusion and request — clear statement of what you need approved

Appendices can hold detailed spreadsheets, vendor quotes, and supporting research. The main document should never feel like it’s trying to prove everything at once.

Common Mistakes to Avoid

Burying the ask

Some managers put the recommendation at the end as if they’re building to a reveal. Don’t. State what you want in the first paragraph of your executive summary. Decision-makers read backwards — if they don’t understand what they’re being asked to do, they’ll skim for it and miss your supporting logic.

Overloading with data

More data doesn’t mean a stronger case. It usually means a harder one to read. Use the data that directly supports your argument. Everything else goes in an appendix or gets cut.

Ignoring stakeholder concerns

If you know certain people in the approval chain have reservations, don’t ignore them and hope for the best. Acknowledge the concern in your document and address it directly. A business case that only reflects your perspective will feel one-sided.

Underestimating costs

It’s tempting to sharpen the pencil on costs to make the ROI look better. Resist this. If the real costs emerge later, you lose credibility — not just for this project, but for future ones. Build in a contingency buffer of at least 10 to 15 percent and be transparent about it.

Getting Buy-In Before the Meeting

The approval meeting should rarely be the first time key stakeholders see your business case. Share a draft with your direct manager, a finance contact, and any influential stakeholders before the formal presentation. Ask for their input. This does two things: it improves the document, and it converts potential blockers into collaborators.

When the formal meeting happens, the people who matter have already had a chance to raise concerns privately. You’ve had a chance to address them. The meeting becomes a confirmation rather than a debate.

What Happens After Approval

Once your business case is approved, your job isn’t over — it’s just changed. You’ve made commitments about cost, timeline, and return. Document the assumptions that underpinned your case so that when you measure outcomes six months later, you can compare like for like.

Managers who follow up on the actual results of their business cases, even when the news is mixed, build a reputation for integrity. That reputation makes the next business case easier to get approved.

Final Thought

A well-built business case is one of the most useful skills a manager can develop. It forces you to think rigorously about a problem, pressure-test your assumptions, and communicate with precision. These are the same skills that make you effective at almost everything else in management.

The goal isn’t to produce a perfect document. It’s to give the people who control resources enough clarity and confidence to say yes. Keep that in mind, and you’ll build cases that get approved.