The Business Case Nobody Wants to Write — But Should

There's a particular kind of stall that happens right before a genuinely good initiative gets funded, and it happens often enough to be recognizable within the first few minutes of a meeting. A particular quality of silence when someone asks "so what's the actual number here," followed by everyone in the room finding something interesting to look at on their own notepad. Everyone in the room genuinely agrees the problem is real. Everyone agrees, with real conviction, that something should be done about it. And then the whole thing simply sits there, unfunded, for months, sometimes for a full budget cycle or longer, because nobody wants to be the person who commits their name to a number they can't fully defend under questioning. The business case becomes the document nobody actually wants to write, and, not entirely coincidentally, it becomes the single most important document standing between a good idea everyone believes in and a funded one that actually happens.

open_in_full

Why teams avoid writing the business caselinkshare

The discomfort here is genuinely understandable, and it doesn't reflect any lack of competence or seriousness on the part of the people avoiding it. A business case asks someone, specifically and by name, to put a particular figure next to a claim, knowing that figure will be scrutinized in a room, possibly proven wrong later, and attached permanently to their name in an organization where being visibly wrong carries real professional consequences. "We don't have the numbers yet" is a very reasonable sounding way to avoid that exposure, and it's the sentence heard most often when a promising initiative has been sitting untouched for an uncomfortably long time.

It's also, in the great majority of cases, an excuse dressed up convincingly as a precondition. The numbers you would genuinely need to be fully certain almost never exist before you've already done the work that the business case itself is meant to justify funding for in the first place. Waiting for certainty before writing the case is a bit like waiting for the rain to stop before agreeing to buy an umbrella. The certainty you're waiting for is usually downstream of the decision, not a prerequisite for it.

Building a defensible estimate without perfect datalinkshare

A business case doesn't need to be precise in order to be genuinely useful, and this is the single most liberating idea for anyone who's been stuck avoiding writing one. It needs to be defensible: built from a transparent method that a skeptical reader can follow and poke at, reasonable and explicitly stated assumptions, and a presented range rather than a single false-precision number that implies far more confidence than actually exists behind it.

A useful, practical approach, used constantly in this kind of work, is to gather rough, honest input from two or three people who sit closest to the actual problem. Not a formal study, just structured conversations. State the assumptions behind their input explicitly and in writing, and present the result as a range with a clearly identified most likely scenario, rather than a single figure dressed up to look more certain than it is. Typically, decision-makers are consistently more comfortable approving a transparent, honestly caveated range than they are trusting a confident sounding single number that later, inevitably, turns out to have been a guess wearing a suit. The range signals honesty. The false-precision number, once it's caught out even once, tends to poison trust in every business case that follows it.

Connecting the case to a decision-maker's actual incentiveslinkshare

A business case that speaks purely in operational language, "improves visibility," "reduces friction," "streamlines the process," very rarely moves a budget decision on its own, however true those claims happen to be. It needs to connect, explicitly and specifically, to something the decision-maker is already personally accountable for: margin, working capital, unit cost, risk exposure, a customer commitment they've already made and don't want to break. That translation step, from an operational benefit that sounds good in the abstract to the specific, named measure a decision-maker already tracks on their own scorecard, is very often the entire difference between a proposal that gets read sympathetically once and set aside, and one that actually gets funded in the same meeting it's presented.

The exact same initiative, described in two different ways to two different audiences, has received completely different receptions purely because of this translation. "This will reduce planning friction" got a polite nod and no budget. "This reduces the working capital tied up in finished-goods inventory by an estimated eight to twelve percent" got funded within the week, from the same underlying facts, presented to a decision-maker who happened to be personally accountable for working capital that quarter.

open_in_full

What a good-enough business case looks like at each stagelinkshare

Different stages of an initiative's life genuinely call for different levels of rigor, and conflating them is one of the more common ways good ideas die slowly. At the very first ask, permission to run a short diagnostic, or a small, contained pilot, a rough, honestly ranged estimate with clearly stated assumptions is genuinely, completely enough. Demanding full quantitative certainty at this earliest stage usually just kills initiatives that would have proven themselves quickly and cheaply if only someone had been allowed to actually try them on a small scale first.

At the later stage of committing to a larger, more consequential investment, the case should tighten considerably, ideally validated by the results of that earlier pilot rather than purely projected from assumptions nobody has yet tested against reality. Matching the required rigor to the actual stage the initiative is at, rather than demanding full certainty upfront regardless of stage, is what lets genuinely good initiatives move at all, instead of dying quietly in the gap between "sounds promising" and "prove it with numbers nobody can currently produce."

A simple structure for the rough versionlinkshare

If you're staring at a blank page and the discomfort described above is exactly what's stopping you, it helps to have a fixed, minimal structure to fill in rather than trying to write "a business case" as an open-ended, intimidating document. Five short sections do the job for almost any early-stage initiative. State the problem in one or two sentences, in language the decision-maker already uses for their own priorities. State the assumption set explicitly, not buried in a footnote, but named up front, so anyone reading it knows exactly what they'd need to disagree with if they wanted to challenge the number. State the range, with a most likely scenario clearly marked, rather than a single figure. State what you're actually asking for at this stage, usually permission and a small budget for a diagnostic or pilot, not the full investment. And state how you'll know, concretely, within a defined and short timeframe, whether the rough estimate was in the right neighborhood.

That fifth section is the one most rough business cases skip, and it's often the one that does the most to earn a decision-maker's trust, because it converts an estimate that could be wrong into a commitment to find out quickly rather than a number people quietly hope nobody ever checks against reality.

The psychology of the room, and why the rough version wins itlinkshare

There's a subtler dynamic worth naming here, because it explains why the rough, honest version so consistently outperforms the polished, falsely precise one in practice. A decision-maker sitting across the table has, almost always, been burned before by a confident number that didn't hold up. A business case presented with total certainty that quietly fell apart six months into execution. That memory makes them more skeptical of unearned confidence than most people writing business cases assume. A range with visible assumptions doesn't read as weakness to that audience. It reads as someone who understands the actual uncertainty involved and is being straightforward about it, which is precisely the quality that makes a decision-maker trust the rest of the document too. Ironically, the case that admits what it doesn't know is very often the one that gets believed.

The maintenance case that took a year, then a monthlinkshare

A proposed maintenance-scheduling initiative sat unfunded for close to a year at one organization, stuck in exactly this loop, almost textbook in how it played out. Everyone agreed the current reactive approach to maintenance caused avoidable downtime. Nobody in any meeting disputed that basic premise. And nobody would commit to a precise savings figure, because the kind of historical data a rigorous, fully defensible calculation would have required simply didn't exist in any usable, structured form. It had never been captured that way, because nobody had previously needed it captured that way.

The unlock, when it finally came, came from a much rougher approach than anyone had initially been willing to propose. Informal input from three plant managers, each asked directly for their own honest estimate of avoidable downtime based on their daily experience, presented together as a range with explicit, stated assumptions rather than as a single confident number that any one of them would have to individually defend. That rough, honestly caveated business case was enough to secure a pilot budget within a single month, something an entire year of waiting for perfect, unavailable data had completely failed to produce. The pilot itself, once it ran for a quarter, produced real numbers that then supported a much tighter, more rigorous business case for the larger rollout. Numbers that, tellingly, turned out to be reasonably close to what the three plant managers had estimated from experience alone.

An approximate business case that gets funded beats a precise one that never gets writtenlinkshare

open_in_full

Perfection is, in a very real sense, the enemy of the business case that actually moves an initiative forward. A transparent, well-reasoned range, explicitly tied to something the decision-maker already personally cares about and is measured on, will get more genuinely good initiatives funded over time than the pursuit of a precision the available data rarely supports anyway, at least not at the stage when the decision actually needs to be made. Write the approximate version. Typically, it's the one that actually gets read carefully, taken seriously, and funded, while the perfect version everyone keeps promising to write, once the data finally arrives, has a way of never quite getting written at all.

If you're currently sitting on an initiative that's stalled in exactly this way, everyone agrees it's worth doing, nobody's willing to commit to a number, try this as a starting exercise. Get two or three people closest to the problem into a room for an hour, ask each of them independently for their honest estimate before anyone anchors the group on a number, state your shared assumptions plainly, and write the range down. You'll likely find you already have enough to ask for a pilot. You almost never need what you think you need before you're allowed to start.

One last piece of encouragement is worth adding for anyone who still feels the pull to wait. The discomfort of writing a rough business case never fully disappears, no matter how many you write. What changes, with practice, is your relationship to that discomfort. You stop treating it as a signal that you're not ready, and start treating it as simply the normal, unavoidable feeling of putting a number in front of people before you can be completely certain it's right. That feeling is the price of admission for getting anything funded at all. The alternative, waiting indefinitely for a certainty that data rarely provides in time to matter, has its own cost. It's just quieter, and easier to mistake for prudence.

Disclaimer

Industry situations in this chapter are composite illustrations unless explicitly attributed to a public source. They are not claims about any particular company, plant, vendor, or incident. External standards, research, and public case studies should be verified before publication. Implementations must be validated against local safety, quality, cybersecurity, regulatory, contractual, labour, privacy, and data-governance requirements. AI recommendations and autonomous actions should remain within clearly defined human authority, operational controls, and tested recovery procedures.'

#BusinessCase #ManufacturingLeadership #CapitalAllocation #SteelIndustry #OperationsExcellence #FinancialJustification #PlantManagement #ProjectFunding #Industry40 #ExecutiveDecisionMaking