By Ritvars Mētra, Founder of ReadinessCompassHypercare ends on a Friday. The war room is stood down, the daily call is cancelled, the tracker is archived, and the project team demobilises over the following fortnight. Somebody sends a thank-you email.
Six months later the business case is short and nobody can say exactly when it went wrong — because measurement stopped on the same Friday that support did.
The end of hypercare gets treated as the end of the change. It is not. It is the point at which the change stops being supervised and starts being tested.
Hypercare measures support load, not adoption
Start with what hypercare actually is: a temporary service posture. Elevated support, faster escalation, people on standby. Its natural metrics are service metrics — incident volume, resolution time, backlog, severity mix.
Those measure the support function. Adoption is a behavioural state in the business. The two decouple in both directions, which is why one cannot stand in for the other:
- Low tickets, low adoption. People stopped asking because they built a workaround. Quiet reads as success and is the opposite.
- High tickets, high adoption. People are genuinely using the system and hitting genuine defects. Noisy reads as failure and is often the healthiest state available in week three.
So “tickets are down, we can close hypercare” is a conclusion about the service desk that has been quietly promoted into a conclusion about the organisation. Distinguishing the two cases requires adoption and workaround data alongside the incident data — the separation covered in what to measure after go-live.
Hypercare is shorter than habit formation
There is a timing problem underneath this, and it is more specific than “change takes time.”
Lally and colleagues modelled how habits actually form in the real world in the European Journal of Social Psychology, tracking participants performing a chosen behaviour daily in a consistent context. Automaticity rose along an asymptotic curve, and the time to reach 95% of each person’s plateau had a median of 66 days and a range from 18 to 254.
Typical hypercare runs four to eight weeks — 28 to 56 days. Which puts the standard withdrawal of support before the median new behaviour has become automatic, and a very long way before the slower half of the distribution.
Two honest caveats. That study concerned personal health behaviours performed daily in a stable context, not workplace processes, so it is indicative rather than a formula. And the direction of error runs the wrong way for comfort: those participants had a daily opportunity to repeat the behaviour. Someone performing a month-end task has had two or three attempts by the time hypercare closes, so the mismatch is understated, not overstated.
The practical implication is not that hypercare should last a year. It is that the end of hypercare falls inside the fragile window, not after it — so something lighter has to continue past it.
The measurement cliff
What usually continues is nothing, and the reason is structural rather than negligent.
The project owned the instrumentation. The project built the dashboard, ran the survey, maintained the workaround register, and had a specific person who compiled it every Thursday. When the project demobilises, all of that leaves with it. Nobody decided to stop measuring adoption; the capability to measure it simply left the building.
PMI’s research on sustaining benefits beyond the project makes the general point that post-project work needs the same ownership and leadership attention as delivery work, and that too few organisations do it. The measurement version is the sharpest instance: the handover transfers the system and the process, and forgets to transfer the instrument that tells you whether either is working.
What leaders still need to track
The answer is not the hypercare dashboard at lower frequency. It is a deliberately small set — five or six measures, monthly, owned by named business people, for two to three quarters.
| Track | What it catches | Natural owner |
|---|---|---|
| Usage by critical role | Quiet reversion in the roles the benefit depends on | Function head |
| First-time-right or error rate | Proficiency decaying once support is withdrawn | Process owner |
| Open workarounds | A second operating model becoming permanent | Process owner |
| Is the old artefact being requested again? | Manager reinforcement lapsing | Function head |
| Novel-issue rate | Something new starting to break after a period-end or upgrade | Service owner |
| The business outcome the case promised | Whether any of it converted to value | Benefit owner |
Six numbers, most of which come from systems rather than surveys. The fourth is the cheapest and among the most informative: as long as somebody senior keeps asking for the old report, it will keep being produced, and the new way stays optional.
The discipline that matters is the owner column. A measure owned by “the PMO” after the PMO has disbanded is not owned. Each line needs a person in the business who reports it in their own operational review, not in a change report that no longer exists.
Three moments when adoption actually fails
Reversion is not a gradual drift. It clusters at three identifiable points, all of them after hypercare has closed.
The first unsupported period-end. Month-end or quarter-end is when the process is most complex, most time-pressured and least forgiving — and the first one without standby support is the moment people reach for whatever worked before. If you track nothing else, track the first two period-ends after hypercare ends.
The first turnover. New joiners are trained by colleagues rather than by the programme, which means they learn work-as-done including its workarounds. Adoption can be solid among the original cohort and decay steadily as the population turns over, invisibly, because nobody re-measures.
The first infrequent task. This one has hard evidence behind it. Arthur and colleagues’ meta-analysis of skill decay in Human Performance, covering 189 data points, found substantial skill loss over periods of nonuse — and, critically, that cognitive and accuracy-based tasks decay more than physical or speed-based ones.
Nearly everything an ERP or finance process asks of people is cognitive and accuracy-based. So a quarterly or annual task learned once during hypercare and next performed five months later is exactly the profile that decays most. Those processes need a scheduled refresher before each run, not a training record from last spring.
What to do when a number slips
The instinct after the project has closed is either to do nothing, because there is no vehicle, or to relaunch something, which is disproportionate and signals that the change failed.
The right response is small and local. One function, one process, one cause. Reinforcement in that team’s routine, a short refresher for the specific task, one workaround closed with its owner named, or a decision finally taken on the exception that nobody ever ruled on. Reinforcement is the fifth element of Prosci’s ADKAR model precisely because it is ongoing rather than an event, and post-hypercare interventions should look ongoing too — small, routine and unremarkable.
Escalate only where the slip is structural: an unfixed defect, a missing decision, a manager who has reverted to asking for the old artefact. Those need someone with authority, not another comms push.
When can you stop tracking?
The sustainment set needs its own exit criteria, or it becomes permanent overhead and quietly stops being read.
Three conditions, all of which should hold:
- Stable across at least two full cycles, including the period-ends where the process is hardest.
- No open workarounds without an owner and a closure date.
- The measure has migrated into normal operational reporting — a business owner reports it in their own review because it tells them something they need, not because a change programme asked.
That third condition is the real one. A measure only survives if somebody wants it for their own reasons. Anything still being collected purely because the programme mandated it will lapse within a quarter of the last person who cared moving on.
The reframe
Hypercare answers a support question: can the organisation operate without elevated assistance? That is worth answering, and closing it is a legitimate milestone.
It does not answer the adoption question: has the new way of working become how this organisation actually works? On the evidence about how long behaviours take to become automatic, that question is still open on the day hypercare closes — usually by some margin.
Six numbers, six named owners, monthly, for two or three quarters. It is a small ask, and it is the difference between knowing the change held and assuming it did because nobody complained.
For the decision about when hypercare can end at all, see the exit criteria in the go-live recovery playbook; for what quietly consumes the business case once tracking stops, why benefits leak after go-live. And because refreshers rather than re-explanation are what infrequent tasks need, training is not adoption remains the relevant caution.
Much of this is decided before go-live rather than during it. If hypercare is generating the wrong signal, the cause is often that the support model was never sized for what day one actually produces — confidence checks and blocked tasks rather than defects.
For the longer-run test of whether the change held, see how to know whether a transformation is truly embedded.