Your proof of concept is not almost finished

The most expensive sentence in enterprise technology is "the proof of concept worked, so we are nearly there".

You are not nearly there. You have finished one of five pieces of work, and it is usually the one that was going to be easiest.

What a pilot actually proved

A successful proof of concept establishes technical feasibility. That is a real and necessary result. It is also a narrow one, and the narrowness is disguised because the demo looks like the product.

The demo does not include the thing running unattended at three in the morning. It does not include a control function having reviewed it. It does not include a team having agreed to operate it, a business process having changed to use its output, or anybody having agreed to pay for it next year.

Each of those is a separate distance to travel, and they are largely independent of each other. You can be excellent on one and at zero on the rest.

The five distances

Technical. Can it run reliably on supported infrastructure, with monitoring, failure handling and a real deployment path? A notebook is maximum distance even when the output is perfect.

Control. How many functions must review this, what evidence does each need, and does that evidence exist yet? In a regulated organisation this is usually the largest distance and the least visible during the pilot, because pilots are frequently run in a sandbox precisely so that nobody has to ask.

Operational. Who runs this when it breaks? Who is paged, what is the runbook, what is the service expectation, and has that team actually agreed rather than been assumed?

Consumption. Does anything downstream consume the output in a real process? A model producing predictions nobody acts on is not in production in any sense that matters, and this is more common than anyone admits.

Funding. Is there a committed owner paying for it beyond the pilot, with the ongoing cost understood rather than assumed to be near zero? Inference costs money. Someone should have said so before the demo.

Why the delay looks unexplained

Here is the mechanism, and it is worth being precise about it because the misdiagnosis is so reliable.

Teams optimise the dimension they can see. During a pilot, the only dimension with a visible score is the technical one, because that is what a pilot measures. The other four are not at zero because anyone decided they were unimportant. They are at zero because nobody scored them, and unscored things do not appear in plans.

Then the pilot succeeds, and the work moves into a phase where the other four suddenly become load-bearing. From outside, this looks like inexplicable slowness on something that was declared nearly finished. From inside, it is four projects starting from nothing, in sequence, under time pressure, with an audience.

The frustration then attaches itself to whichever function is visibly in the way, which is usually governance. Governance is not the cause. Sequencing is.

What to do instead

Score all five at the start of the pilot, not the end. Nought to five each. Do it with the control functions in the room rather than on their behalf, because the point is partly to make the pilot visible to them early.

Redefine what "pilot complete" means. Not "the technical dimension reached five". Instead: you know the score on all five dimensions and there is a named owner for each gap. That definition is harder to reach and enormously cheaper than the alternative.

Run control work in parallel. Control requirements are largely knowable in advance. There is no reason for that work to start after the technical work finishes, and every reason for it not to.

Be willing to not run some pilots. A proof of concept with high consumption and funding distance is often a pilot that should not happen, however interesting the modelling problem is. Killing it early is a good outcome that nobody gets credit for.

The uncomfortable part

Applying this honestly will make some of your work look worse than it currently does.

A pilot that everyone regarded as nearly finished will score, say, four on technical and near zero on everything else, and someone senior will find that unwelcome. It is much more pleasant to report that the model works.

But the score was always that. The only choice is whether you find out now, when it is cheap and there is time to act, or in nine months, when the question has become why nothing has shipped.

I would rather have the awkward conversation at the start. It is a shorter one.