Business Case

Business cases aren't predictions. They're arguments optimized for approval — and the system that rewards the confident version over the accurate one keeps producing the same outcomes.

Most business cases aren't predictions. They're arguments optimized for approval, not accuracy: a hockey-stick projection, an assumptions tab nobody opens, a risk section that acknowledges things could go wrong without engaging with what happens if they do.

Six months or eighteen months later, the project that looked like a layup on paper turns into a postmortem. The timeline slipped. The costs were higher. The benefits materialized slower than projected, if they materialized at all.

The Game Everyone Plays

Here's the unspoken dynamic in most organizations.

The person building the business case has an incentive to get it approved. Their project, their budget, their headcount depends on it. They're not lying (they believe in what they're proposing), but they're also not going to build a case that makes approval harder than it needs to be.

The person approving it has limited time and a stack of other proposals. They're looking for a reason to say yes or a reason to say no. They're not doing a deep interrogation of every assumption. They're scanning for red flags and trusting that the detailed work was done.

So both sides quietly cooperate to produce a document that neither fully believes. The assumptions are generous but not outlandish. The projections are ambitious but not obviously impossible. The risks are acknowledged but not seriously engaged. Everyone does their job. The business case gets approved. And then reality arrives.

This isn't corruption. It's not incompetence. It's a system that rewards a specific kind of optimism and punishes a specific kind of honesty. The person who says "I'm actually not sure this will work" doesn't get funded. The person who says "this will definitely work" does, and then spends the next two years explaining why it didn't.

What Gets Left Out

The business cases that fail tend to fail in similar ways.

The assumptions are load-bearing and untested. The whole model depends on customer adoption following a specific curve, or on the team being able to ship on a specific timeline, or on a key hire being made in the first quarter. None of these things are certain. All of them are presented as if they're certain.

The timeline assumes everything goes right. No unexpected dependencies. No delays in adjacent projects. No surprises in the market. The timeline isn't padded because padding the timeline makes the ROI look worse, and the whole point is to make the ROI look good.

The risk section is decorative. It lists some things that could go wrong in the same tone you'd use to describe unlikely weather events. "There is a risk that adoption will be slower than projected." Okay, and what happens then? What's the decision point? What do we do if we're six months in and the assumptions aren't holding? That part usually doesn't exist.

The counterfactual is ignored. The business case compares "do this project" to "do nothing." It rarely compares "do this project" to "do a different project" or "do this project differently." The opportunity cost of choosing this over something else isn't part of the analysis because the person proposing it isn't incentivized to surface alternatives.

The result is a document that looks rigorous but is actually optimized for one outcome. It's a sales pitch dressed up as analysis.

Why the Honest Version Doesn't Get Built

You could, theoretically, build a different kind of business case.

One where the assumptions are presented with confidence intervals instead of point estimates. Where the timeline includes explicit buffers for the things that usually go wrong. Where the risk section is treated with the same seriousness as the return projection. Where there's a clear "kill switch" that defines what would have to be true for the project to be stopped before completion.

This exists. Some organizations operate this way. They're usually the ones that have been burned badly enough by the optimistic version that they've rebuilt their decision-making processes from the ground up.

But in most organizations, the honest version doesn't get built because it doesn't get funded. The person who says "I think there's a 60% chance this works" loses to the person who says "this is definitely going to work." The person who pads the timeline looks less ambitious than the person who presents the aggressive version. The system selects for confidence over accuracy.

Changing this requires changing the incentives. It requires leaders who are willing to fund projects with uncertain outcomes, as long as the uncertainty is named clearly. It requires a culture where admitting "I'm not sure about this part" is treated as intellectual honesty rather than weakness.

That's a harder sell than a better template. But it's the only thing that actually changes the dynamic.

What the Aftermath Looks Like

The project that fails to deliver on its business case usually doesn't fail dramatically. It fails gradually.

The first quarter, the metrics are off but there's always an explanation. Market conditions. Implementation delays. Things that will work themselves out. The business case said Q3 is when we'd see the real uptake, so let's wait for Q3.

Q3 arrives. The metrics are still off. The explanations get more creative. The project team is working hard, and nobody wants to pull the plug when they're so close to turning the corner. Just give it one more quarter.

By the time the project is officially declared a disappointment, it's been running for eighteen months. The sunk cost is substantial. The people who built the original business case have either moved on or are deeply invested in a narrative where the failure wasn't really a failure.

And then the organization does a postmortem. The postmortem concludes that the assumptions were too aggressive, the timeline was too ambitious, and the risk section should have been taken more seriously. Everyone nods. And then the next business case gets built the same way, because the system that produced the first one hasn't changed.

The Question We Ask

When an organization is struggling with initiative execution, too many projects failing, resources scattered across bets that aren't paying off, we don't start with portfolio review. We start with a question.

What was the last project that failed, and what did the original business case say would happen?

The gap between those two things is diagnostic. If the business case said one thing and reality delivered something completely different, the problem is how the organization thinks about uncertainty before it commits resources, not execution.

Nobody sets out to build a fantasy. But if the system rewards optimism and punishes honesty, fantasies are what you'll get. Changing the system is hard. It requires leadership that's willing to fund uncertainty honestly and a culture that treats conservative estimates as rigorous rather than weak.

That's the work, and it's worth doing now, before the next business case gets built the same way.

— Principal Resolution