Five Anchors: How to keep enterprise AI projects from drifting away from their goals

The worst project failures I have seen had no villain in them.

Nobody was lazy, nobody lied, nobody shipped bad code. A sponsor described an outcome. Somebody who was not in that conversation turned it into requirements. Somebody optimising for integration cost turned those into an architecture. The delivery team measured the result against whatever happened to be measurable. Every single step was defensible on the day it was taken, and the thing that shipped met its specification and missed the point entirely.

I call that intent drift. It is not an engineering failure. It is a failure to keep hold of why the work started.

It is a loop, not a slope

One thing worth being precise about: drift does not happen once, and it does not start in the delivery team. It starts with two people in a room who each believe they understand the other.

The customer arrives holding an assumption about what they need. The provider arrives holding an assumption about what the customer wants. Neither assumption gets written down, mostly because neither party knows they are holding one, and the agreement they sign records neither. Downstream, every team that runs into the resulting ambiguity resolves it in whichever direction their own constraints point, which is the only sensible thing to do with what they have. The divergence stays invisible until something is deployed and somebody finally looks at it.

Then comes the part that makes it expensive. The standard institutional response is to escalate and re-specify. More workshops, a longer document, another round of signatures. And the project re-enters at exactly the point it entered the first time, with more paper attached and the intent no better established than before. Every lap costs more than the last, because it is spent later.

The anchors are an attempt to intervene at the entry to that loop rather than at the escalation.

Why AI makes it worse

Ordinary software projects drift too. Three things make enterprise AI unusually prone to it.

You cannot know if it will work. Whether a model hits the accuracy you need is an empirical question, and you only get the answer after spending the money. Every other kind of feasibility can be assessed on a whiteboard.

“Good enough” is a dial, not a switch. Model performance is continuous, so there is always some reading of a mediocre result that counts as success. If nobody wrote the threshold down beforehand, somebody will find one afterwards that the system happens to clear.

The real cost is invisible when you agree to it. These systems couple hard to their data and their environment. The requirement that sounds free in a workshop is the one that turns into a data engineering programme in month four.

The five anchors

Each one is a conversation with a specific counterpart, producing a specific artefact, with a condition that says whether the work continues.

1. Separate ambition from requirements. With the business sponsor. They should describe an outcome, not a system. A sponsor who says “we need a forecasting model” has named a system and hidden the outcome, which might have been fewer write-offs, better service levels, or being able to defend an inventory position to a board. Those admit completely different solutions, and some of them involve no model at all. Write down what they said in their words. Paraphrase is the first increment of drift.

2. Establish what the data will bear. With data owners and IT operations. One rule governs this: a conditional is not evidence. “We could extract that” is a different claim from “that is extracted”, and the gap between them is frequently an entire project. A good share of initiatives should die at this anchor, and this is where dying is cheap. Finding a missing input here costs a meeting. Finding it three anchors later costs a programme.

3. Agree what “good enough” means. With the people who will be measured against the output, and with the risk or safety functions that can veto deployment. The first group says what is useful, the second says what is permissible, and a threshold with only one signature is not a threshold. This happens before anything gets built, for the reason above: agree it afterwards and you have not set a bar, you have written a justification.

4. Design the smallest sufficient architecture. With enterprise architecture and security. Smallest is the operative word. The target is the least architecture that clears the threshold from anchor three, not the most capable one the budget allows. Everything beyond that minimum is a permanent operational liability bought in exchange for a capability nobody agreed to measure. Capital cost you pay once. Running cost you pay every year the thing is alive.

5. Validate the economics. With the sponsor and finance. The bar is deliberately awkward: the business case has to survive with somebody from finance defending it while the delivery team is out of the room. A case that needs its author present to hold up is not a case.

The part that actually matters

Here is the thing. None of those five is clever. Every experienced architect does some version of all of them, and you could have written that list yourself.

What makes it a framework rather than five good meetings is the rule that connects them: the measurement that closes the project has to trace back to the ambition that opened it.

Run the anchors in isolation and you can pass all five and still deliver something nobody wanted, because nothing so far forces the artefacts to have anything to do with each other. Anchor three can fix a threshold that has already drifted away from anchor one, and every individual gate still shows green.

Holding that line makes two different failures visible, and most post-mortems call them the same thing:

• Scope creep is work in the system that nothing asked for.
• Quiet de-scoping is part of the ambition that fell out along the way, that will simply be absent from the closing report, usually without anyone deciding to drop it.

They need opposite remedies. If you cannot tell them apart you will apply the wrong one.

Saying no becomes easy

This gets misread as a promise to build whatever the sponsor first said. It does exactly the opposite.

Once the original ambition is fixed and written down, refusing scope stops being a political act and becomes a factual one. The question is no longer “is this a good idea”, which is arguable and which the most senior person in the room tends to win. It becomes “which part of the agreed outcome does this serve”, which anybody can check on the spot.

Organisations rarely lack the will to refuse things. They lack a defensible basis for it, and they pay for that gap in scope nobody wanted and nobody could argue against.

Is it worth the overhead?

It adds process, so it has to earn its place.

Rather than claim a savings number, work it the other way round: how many of your projects have to turn out non-viable before these checks pay for themselves?

Write $C$ for what it costs to carry a project all the way to deployment, $k$ for the overhead of running the anchors, $c_d$ for what has already been spent by the time an anchor catches the problem, and $q$ for the share of projects that are non-viable for a reason an anchor would catch. A project that dies at an anchor costs $c_d$ instead of $C$, so the expected saving per project is

$$S = q\,(C - c_d) - k$$

which is positive exactly when

$$q > \theta, \qquad \theta = \frac{k}{C - c_d}$$

That $\theta$ is the whole argument. It is the share of your projects that have to be duds before the process has paid for itself. Put the overhead at five per cent of project budget and assume the fatal problem surfaces at anchor two, once two per cent is spent:

$$\theta = \frac{0.05\,C}{C - 0.02\,C} \approx 5.1\,\%$$

About one project in twenty. Push the overhead to ten per cent and let the problem surface a quarter of the way in, and it still only asks for about one in eight.

One dud a year covers the cost of running the anchors across everything. Every dud after that is pure return. You do not need an industry failure statistic to check this, either. Count what you started in the last three years and count what was quietly shelved, deployed and abandoned, or finished without anyone able to say what changed. If that number is under one in twenty, you do not have a misalignment problem and you can ignore all of this.

The longer version

I wrote the formal treatment up as a paper, with the traceability property stated properly, a comparison against CRISP-DM and stage-gate governance, the full break-even derivation, and an honest section on what none of it proves.

It is available here, DOI 10.13140/RG.2.2.31649.36969.