The system runs. The operation goes around it.
Most implementation contracts end at hypercare, roughly day 90. The behaviours that decide whether the investment returns anything form on day 91 and in the ninety days after it — when the project team has gone and the operation decides, without supervision, whether the new process is worth the effort.
If nobody owns adoption at that point the operation reverts — not dramatically, but incrementally, through workarounds that are individually reasonable. Change management is what makes that not happen, and it needs a named owner, a budget line and a metric of its own.
How adoption is lost.
Training in the final month
Users see the system for the first time two weeks before go-live, with no chance to influence it.
No owner after the project
The project team leaves at day 90 and no internal role inherits responsibility for whether the process is followed.
Authority given up without discussion
A new process removes discretion from a manager who was never consulted, so they route around it.
The old report still exists
The parallel spreadsheet is never switched off, so there is no reason to trust the system.
Adoption measured by logins
Usage statistics look healthy while the operating decisions are still taken outside the system.
No feedback loop
Genuine design faults are reported and nothing changes, so users stop reporting and start working around.
What the engagement actually includes.
Stakeholder work
Identify who materially loses discretion and hold that conversation early, in the room, before the design is fixed rather than after.
Role redesign
Where the process changes what a role does, the role is redesigned explicitly — including the job description and the metric it is judged on.
Capability building
Role-based training with named super-users in each unit, delivered against the real process rather than a generic system tour.
Switch off the alternatives
The parallel spreadsheet and the legacy report are retired on a dated plan. Adoption is not possible while the old path still works.
Adoption measurement
Measured on operating behaviour — is the decision taken in the system, is the parallel record gone — not on login counts.
Day-91 handover
A named internal owner, a weekly review, a feedback route with authority to change the design, and a control catalogue they can maintain.
A workstream, not a phase.
Adoption is measured on operating behaviour, not logins. These are the tools that support the workstream.
Ranges observed on Al Jawad engagements. Your targets are agreed in assessment, before the work starts.
Is this just training?
No. Training is one deliverable inside it. The work is stakeholder alignment, role redesign, retiring the alternatives and owning adoption after the project team leaves.
Can we add it later if adoption is poor?
You can, and it costs more. The conversations that matter — who gives up discretion, and what they get in return — are far cheaper before the design is fixed.
Who should own adoption internally?
Someone whose own metric depends on it — usually the manager of the function, not a project role that ends at go-live.
How do you measure adoption honestly?
By whether the operating decision is taken in the system and whether the parallel record still exists. Login statistics measure attendance, not adoption.
Start a conversation.
Choose the one that fits where you are. None of them is a sales call. Each is an advisory conversation calibrated to a specific question.