Every failed project we have seen was missing one of the same three things

Three failures that look different and are not

Ask anyone who has run an operating business for ten years and they will have seen all three.

The plan that never got built. A consultancy spent four months inside the company, interviewed everyone, and delivered a deck. The deck was good and it named the right problem. It also assumed a budget and a timeline that belonged to a much larger company, and its authors left the day it was presented.

Two years later the deck is still right. Nothing has changed.

The build aimed at the wrong thing. A development shop was given a specification and built it well, on time, to the letter. The specification described the process as the manager understood it from her office.

The process as it runs at four on a Tuesday afternoon in the dispatch room is a different process. The software handles the case the specification described and none of the cases that happen.

The system nobody uses. An internal tool, a one-off automation, or a vendor's pilot. It works, it was demonstrated, people applauded.

Six weeks later the team is back in the spreadsheet. The tool asked them to change how they work and the spreadsheet did not. The tool is still running. Nobody has opened it since March.

Each failure has two of the three legs

Put them side by side and the pattern is hard to miss.

• The plan that never got built. Had: strategy. Missing: engineering, and the ground truth about operations that only appears once you build.
• The build aimed at the wrong thing. Had: engineering. Missing: strategy, since nobody owned whether it was the right problem.
• The system nobody uses. Had: strategy and engineering. Missing: operations, the fit to how the work actually runs.

We are not claiming this is a profound observation. We are claiming it is consistently true, and that the way the industry is organised makes it close to inevitable.

The market pays each firm to stop at its edge

Strategy, engineering, and operations are sold by different kinds of firms, at different prices, on different timelines, and each hands work to the next across a gap.

Consultancies sell the plan and are paid when the plan is delivered. They have no reason to stay for the build and every reason to make the plan impressive rather than buildable.

Development shops sell the build and are paid against the specification. They have no standing to argue that the specification is wrong, and finding out is rarely in their scope.

Nobody sells operations. Whether a system fits the people who will use it every day gets filed under change management, a training session, a rollout. It is the part that decides whether anything happened, and it is the part with no owner.

So the legs are not missing by accident. They are missing because the market splits them and pays each seller to stop at the boundary.

What changes when one team holds all three

The alternative is unglamorous. The same small team does all three, in the same weeks, against the same real data.

Strategy stops being a phase and becomes a standing question the whole way through: is this still the problem worth fixing, and will what we are building move the number we said it would. When the first working version shows that the expensive step was not the one everyone assumed, the plan changes that week rather than at the next quarterly review.

Engineering stops being a handoff, because the people who sat with the dispatch team are the people writing the code. They know the address field is free text because drivers phone in from the road, and they build for that because they were there when it happened.

Operations stops being a rollout. The system is used early, by the people it is for, while it is still being built, and it is changed on what they do rather than what they say. If it does not fit the Tuesday afternoon version of the job, it does not ship.

None of this needs a large team. It needs one team small enough to hold all three questions in one head, and willing to say early when the problem is not one they can fix well.

Where this does not apply, and what it costs

This is not the right shape for every problem.

If you have an in-house engineering team and a clear specification, a development shop that builds exactly what you ask for is cheaper and faster than a team that insists on sitting with your operation first.

If the problem is small enough that a spreadsheet macro would fix it, the three-legged version is overkill, and we will say so on the first call.

And the shape has a hard limit on volume. A team that does all three things itself can only do a few engagements at a time. That is the trade we make on purpose, and it is why we are selective about fit.

AI demos are the best machine ever built for the third failure

Most of what we are asked to build now involves language models and agents. That changes none of the above and makes all of it worse.

A model demo is the most convincing artefact ever invented for producing a system nobody uses. It works in the room. It works on the sample. Then it fails on the referral that arrived as a sideways fax, and the team goes back to the spreadsheet.

The gap between a demo and a system in daily use is operations, and it is where most AI pilots die.

The cure is the same as for everything else on this page. Pick the problem by what it costs. Build on the real cases rather than the sample, and keep those cases as a test set so the next change can be checked against them. Put the system in front of the people who will use it in the second week, not the twelfth. Use the model where it beats a simpler approach and plain software where it does not.

The rule

A project with any two of strategy, operations, and engineering, and not the third, fails in the way the missing one predicts. A plan with no build never gets built. A build with no strategy solves the wrong problem. A system with no operations does not get used.

We have looked for a counterexample and have not found one. If you have one, we would like to hear it.

The build harness we use on every engagement is written up in the harness post, which is the engineering leg of this argument in detail. If the failures above sound like something you are living with, this is how an engagement runs.