Strategy isn't usually the reason it failed

When a large decision fails, the post mortem almost always examines the decision. Was the market read correctly? Were the numbers optimistic? Did we misjudge the competition? These are reasonable questions and they're usually the wrong ones, because in most failures the decision was fine and the organisation couldn't carry it.

That distinction sounds academic until you notice that it changes what you'd have had to do differently. If the strategy was wrong, you needed better analysis. If the strategy was unexecutable, you needed to know that before you funded it, and no amount of market analysis would have told you, because the answer wasn't in the market. It was in your own building.

What unexecutable actually means

Take a decision like entering a new country. It might be entirely correct. The market may be real, the timing good, the economics sound. Now ask a different set of questions:

1. Who owns this, by name?
2. What authority do they actually hold to commit money and hire people?
3. Which existing processes have to change, and who signs those off?
4. Which teams become dependent on each other that weren't before?
5. Does anyone have spare capacity, or is this on top of a full plate?
6. What information will management see, and how quickly?
7. Who finds out first when it starts going wrong?
8. Who has the standing to stop it?

Notice what those have in common. Not one of them is about the new country. They're all about you. And in most organisations approving a decision of that size, several of them have no answer at all, which nobody discovers because nobody asked.

The most reliable predictor of a large initiative failing isn't a flaw in its logic. It's that the person nominally leading it already had a full job, and the decision was added to it without anything being taken away. That's knowable on day one and it's almost never written down, because writing it down feels like a lack of ambition.

Claims and evidence are not the same thing

When these questions do get asked, they're usually asked in a room, out loud, and answered by whoever is most senior. Someone says yes, we have reporting for that. Yes, there's an escalation path. Yes, the regional team has bandwidth.

Every one of those is a claim. Some are true. The uncomfortable and useful discipline is to record claims and evidence in different columns, and then look at how much of the readiness assessment sits in the claims column.

This is not about distrust. Senior people answer these questions honestly and are frequently wrong, for a structural reason: they're describing the organisation as designed rather than as running. The escalation path exists on a slide. Whether anyone has used it in the last year, and what happened when they did, is a different question, and it's the one that determines what happens when this decision starts going sideways.

The second failure: nothing breaks, it drifts

Suppose you do all of that, fix what's missing, and commit. There's a second, entirely separate failure waiting, and it has a different shape.

Execution doesn't usually collapse. It drifts. A date moves, then another. A number softens. A dependency slips and nobody escalates it because individually none of it is worth escalating. An exception happens often enough to stop feeling like an exception. The plan and reality come apart slowly, and every single step along the way is defensible.

Then a reporting date arrives and it looks like something went wrong suddenly.

The reason nobody catches this is that most reporting compares against dates rather than against trajectories. Consider a launch due on 30 August. On 27 August, three dependencies are incomplete and two of them belong to a team that has missed its last two internal dates. Every status report will show that launch as on track, and every report is correct, because the date hasn't passed yet.

The gap between intended and actual is measurable long before it's visible. Early, it might be worth three days of someone's attention. At the reporting date, it's in the quarterly numbers and there's nothing to be done except explain it. Same failure, found twice, at wildly different prices.

Two questions, two moments

So there are two questions here and conflating them is a mistake.

Before you commit: can this organisation, as it exists today, carry this decision? That's a readiness question. It's asked once per decision, it produces a list of things that have to be true, and its output is a verdict plus what to fix first. It's not an opinion on whether the strategy is good, and it shouldn't pretend to be. Given the strategy you've chosen, are you able to execute it.

After you commit: is it still behaving as intended? That's a control question. It's asked continuously, never once, and its output is a deviation that stays visible until the condition actually returns to normal. Not until somebody dismisses an alert.

Same expansion, two jobs. The first finds that regional management has no spare capacity, so you fix that before committing money. Then you go, and the second is what notices hiring has fallen three weeks behind while every report still says green.

Why both are software problems

Neither of these is a thinking problem. Plenty of organisations have people capable of asking all eight questions above, and most have someone who would spot the drift if they happened to be looking at the right thing on the right day.

They're both problems of unowned work. Decomposing a decision into testable conditions and chasing evidence for each one is nobody's job. Comparing intended state against actual state, continuously, across everything in flight, is nobody's job either. They get done when a conscientious person has capacity, which is exactly when a large decision is least likely to leave anyone with capacity.

That's the whole argument, and it's the same one as everything else here. The noticing, the comparing, the chasing and the verifying shouldn't depend on a person remembering. What should stay with people is deciding what matters, which in the case of a large strategic decision is precisely the part they're good at and precisely the part they should be spending their attention on instead.