Common business case mistakes that sink otherwise good ideas
Good ideas get rejected every day — not because they were wrong, but because the case for them was badly built. The mistakes below come up again and again, and each one is avoidable once you know to look for it.
1. Leading with the solution instead of the problem
"We should buy Tool X" is not a business case — it is a purchase request. A case starts with the problem: what is broken, who is affected, how much it costs to leave it alone. When the problem is clear and well-evidenced, the solution often sells itself. When the problem is missing, even the best solution looks like spending for its own sake. If you find yourself writing three pages about a product and one paragraph about the problem, flip the proportions.
2. Vague benefits
"Improved efficiency," "better visibility," "enhanced collaboration" — these phrases feel positive but mean almost nothing to an approver. Every benefit should answer: better how, by how much, for whom, and how do we know? "The reporting process takes two days and produces errors that trigger rework; automation would cut it to two hours and remove the manual re-entry step" is a benefit. "Improved efficiency" is a wish.
3. Hidden or incomplete costs
Leaving out implementation effort, training, ongoing maintenance, or internal staff time does not make a case look cheaper — it makes it look untrustworthy. Approvers have seen optimistic costings before, and they probe for the missing pieces. The irony: a complete, higher cost figure usually wins more trust than a lowballed one, because the decision-maker believes the numbers. Include every cost you can identify, label your assumptions, and let the honest total stand.
4. No alternatives — or a strawman alternative
Presenting only your preferred option reads as advocacy, not analysis. But the opposite failure is just as common: including a deliberately weak alternative so your choice looks good by comparison. Decision-makers spot strawmen quickly, and it poisons the whole document. Present real alternatives fairly — including "do nothing" with an honest account of what inaction costs — and let your recommendation win on merit.
5. Ignoring the do-nothing baseline
Every option must be compared against something. Without a clear picture of what happens if you do nothing, there is no way to judge whether a proposal is worth it. The baseline is not "zero cost" — problems left alone usually have growing costs: more manual work, more errors, missed opportunities, increasing risk. Quantify the cost of inaction and your proposal has something to beat.
6. No named risks
A case with no risks section does not look confident — it looks naive. Every project has risks: delays, adoption problems, dependencies, cost overruns. Naming them, with a mitigation for each, shows you have thought it through and gives the approver confidence you can handle trouble. The risks you do not name are the ones that will surprise you.
7. Asking for the wrong thing
Sometimes the proposal is sound but the ask is wrong: requesting full funding when a pilot would do, asking for headcount when the real need is budget, or requesting a decision the approver cannot actually make. Match the ask to the decision-maker's authority and to the stage of the idea. A phased ask — "approve the pilot; we return with results before requesting the full rollout" — often succeeds where an all-or-nothing request fails.
8. Writing for yourself instead of the approver
Technical depth, internal jargon, and fifty pages of background are written for the author, not the reader. The approver needs the decision, the cost, the benefit, and the risk — in that order of attention. Everything else is supporting material. If your case cannot survive a two-minute skim (see our guide on writing for executives), it will not survive the meeting.
9. Overstating certainty
Benefits are projections, not promises. Phrases like "will deliver" and "guaranteed savings" invite the approver to find the flaw. Honest language — "we estimate," "based on," "assuming" — does not weaken a case; it makes the numbers believable. Show a conservative estimate and note the upside separately. Nobody trusts a forecast with no uncertainty in it.
10. No clear next step
A case that ends with analysis but no ask drifts. End every business case with the specific decision you need, who needs to make it, and what happens the day after approval. Make saying yes easy: the approver should know exactly what their approval sets in motion.
A pre-submit checklist
- Does the first page state the ask, the cost, and the recommendation?
- Is the problem specific and evidenced, not assumed?
- Are all costs included — including staff time and ongoing costs?
- Are benefits specific, quantified where possible, and free of double-counting?
- Are there at least two real alternatives plus the do-nothing baseline?
- Are risks named, with mitigations?
- Would the case survive a two-minute skim?