What a vendor means when they say done

A system goes live on schedule. The scope was met, the tests passed, the training sessions were held and attended. Eleven months later somebody asks how many people are using it and the honest answer is a number nobody wants to say out loud.

Nothing went wrong in the sense that anybody could be blamed. The project did what the project was defined to do.

There are two definitions of done, and only one is in the contract

A vendor is done when the agreed scope is delivered and accepted. That is a real, checkable event with a date, and it is what the commercial arrangement is built around. It has to be: you cannot write a contract against a state of mind in somebody else's organization.

The business is done when the work has moved. When the site engineer records the variation in the system instead of in a message, when the month closes from the record rather than from a spreadsheet somebody rebuilt.

The distance between the two is where most of the disappointment in enterprise software lives, and it is nobody's job by default.

The same gap is opening again, faster

This is not a new problem, but it is being reproduced at speed by the current wave of deployments. Deloitte surveyed 3,235 respondents across 24 countries for its 2026 State of AI in the Enterprise and found the two ends moving apart.

Read that as a delivery statistic rather than a governance one. Governance is the part that arrives after the thing is running: who reviews it, who is accountable when it acts, what happens when it is wrong. Three quarters intend to deploy and a fifth have decided who owns the result.

Gartner's forecast points at the same seam.

That is a prediction rather than an observed rate, published in June 2025 about a window that has not closed. Read it as a description of where the risk sits, never as a measurement of what happened. The difference between the two is how most enterprise statistics go wrong.

Escalating costs and unclear business value are both symptoms of the same thing. They are what a project looks like from the finance side when it was delivered and then not used.

Why the vendor is not there when it matters

Not because anybody is cynical. Because of how the work is shaped and paid for.

The expensive, uncertain, unglamorous part of any deployment is the tail: the exception nobody mentioned, the department that quietly kept its old spreadsheet, the field one user refuses to fill in because filling it in makes their number look worse. That work is impossible to scope in advance, which means it is impossible to price in advance, which means it sits outside the contract that was signed.

We say that knowing it describes a commitment we have to fund. It is why our delivery involves a person sitting inside the client organization rather than a handover document, and why that is expensive. A model of how a company works is not something anyone can specify from outside it.

What to put in the contract instead

The fix is not a longer statement of work. It is measuring the second definition of done, in the units the business already runs on, agreed before anything starts.

1. 01A usage measure that is about the work, not about logins. Share of variations recorded in the month they occurred, not seats activated.
2. 02A date for that measure that is well after go-live. Ninety days is when the exceptions have surfaced and the novelty has worn off.
3. 03A named owner inside the business, not inside the vendor, who is accountable for that number.
4. 04An agreed answer to what happens when a department refuses. Somebody will, and the plan cannot be that the vendor persuades them.
5. 05A standing decision about who resolves a conflict between departments once the system is live, because the disagreements do not stop at go-live.

A vendor who will not accept a usage measure in the contract is telling you something useful about where they intend to be in month four. It is worth asking early, when the answer is still cheap.

The honest version of this argument

Every vendor including this one has a commercial reason to describe the last stage of the work as the important one, because it is the stage we sell. That is worth saying rather than hiding.

The test is whether the claim costs anything to make. Promising to stay through adoption is expensive: it means staffing months that produce no new revenue, on work that cannot be scoped. A competitor who copies the sentence has just promised to fund it too.

What that looks like in practice, stage by stage, is on how we work.