Here is a pattern I have seen enough times to name it. A project ends. The sponsor signs the acceptance form. The vendor sends the final invoice. Six months later the tool has four active users, the team is back on spreadsheets, and everyone involved still calls the project a success.
Nothing was faked. The problem is that four different events were treated as one.
Four events, four questions
Acceptance is a contractual event. A named person confirms that the agreed scope works against the agreed scenarios. The question it answers: did we build what we said we would build?
Adoption is a behavioral event. The people the tool was made for use it for the real work, in place of whatever they did before. The question: is the work now happening inside the tool?
Value is an operational event. Something the organization cares about has measurably changed against a baseline: less time, fewer errors, faster escalation, a risk that no longer occurs. The question: is the operation better, and can we show it?
Renewal is a relationship event. The client chooses to continue, extend, or start something new. The question: do they want more of this?
None of these proves another. Acceptance does not create adoption. Adoption does not guarantee value. Value does not guarantee renewal, and renewal sometimes happens without value, which is its own problem.
What to measure for each
Each event needs its own evidence, and it should be planned during discovery, not discovered at the end.
- For acceptance: the scenario list, including the failure and permission cases, and the name of the person who verifies them. Written before the build starts.
- For adoption: the share of the real workload that passes through the tool, week by week, and the number of people who touch it. A tool used by one champion is a pilot, not a product.
- For value: the baseline you measured in discovery, and the same measurement after adoption. If there was no baseline, say so honestly and start one now.
- For renewal: a conversation with the sponsor about what they would do next, held before the current work ends, not after.
Why this matters more for workflow software
Consumer apps get adopted or deleted; the signal is fast. Enterprise workflow software can be accepted, installed, and ignored for a year, because the people who bought it are not the people who would have to use it. The certification lifecycle work for BSMR only counts if training providers, verification admins, and finance admins are actually moving submissions through it. The transport platform for Avian only counts if dispatchers and drivers run their day inside it.
So the design of the project has to include the adoption plan: who is trained, who is coached in the first weeks, what the fallback is when the tool is unavailable, and who on the client side owns the change. That is not a consultant's add-on. It is the second half of the build.
For sponsors
When a builder tells you the project is done, ask which of the four events they mean. Then ask for the evidence for the other three. If you get an honest "not yet" with a plan, you have a partner. If you get a puzzled look, you have a vendor.
The champion problem
There is a specific failure worth naming. One enthusiastic person on the client side uses the tool constantly, reports back that it is wonderful, and unintentionally hides the fact that nobody else has logged in. Adoption metrics have to count people and workload, not sessions. If ninety percent of the activity comes from one account, the project is a pilot with a fan, and the honest next step is to find out why the other nine people are still on the old path.
Sign acceptance, then watch adoption, measure value, and only then talk about renewal.