1. Gate on behaviour, not status
A readiness review built from status reports and surveys tells you what people believe about the change. It doesn't tell you whether the change works. Canada's Phoenix pay system is the case to remember: the planned pilot was cancelled without an impact assessment, the system was never tested as a whole, and a fifth of the functions reviewed failed testing and weren't retested. A year after go-live, about half of employees had errors in a single pay run. DGN-RDY-03
Make a behavioural test a gate criterion: a pilot, a dress rehearsal or a parallel run, sized to the risk. If someone cancels it, require a written impact assessment and a fresh decision from the accountable executive. Read readiness as two things, commitment to the change and confidence in doing it together, and report how it varies across sites and roles, not just the average; the site that scores lowest is where the first week goes wrong. DGN-RDY-01 · DGN-RDY-02 · SWD-REL-01
If scope is cut late, the benefits case and the readiness diagnosis were made for a different project. Re-run them. DGN-RDY-04
For physical assets the same rule applies to the records: commission the information with the asset. A pump station handed over with a working pump and an asset register that doesn't match it hasn't gone live; it has moved the problem to the first night-shift call-out. UTL-REQ-04
2. Plan for the system that runs, but runs wrong
Phoenix had a contingency plan, finalised less than two weeks before launch, and it mostly covered what to do if the system failed to operate. What actually happened was worse and slower: a system that ran, produced wrong results, and couldn't keep up with the volume. GOL-HYP-04
Write the contingency for process and volume failures: the manual workaround, the paper fallback, the extra staff, and the trigger that switches them on. Rehearse the trigger, not just the plan. Before automating, simplify and standardise the rules; automating a messy process makes the mess faster. GOL-HYP-04 · GOL-HYP-07 · CYBER-11
| Risk tier | Examples | Before go-live | Hypercare |
|---|---|---|---|
| Low | Dashboards, templates | Smoke test and a rollback plan | About two weeks of watching |
| Moderate | Common data environment, RFI and submittal tools, field apps | A pilot crew | Four to six weeks |
| High | ERP, payroll, MES | A full pilot, tested and retested; a volume contingency | Clean reconciliations for two business cycles |
| Safety-critical | SCADA, new lines, fall protection, lockout | Hazard analysis and independent sign-off | Observed procedure fidelity; exit on criteria only |
A design synthesis, not a validated method: use it as a starting point and adjust from your own stabilisation data. In every tier, the calendar triggers a review; the data decides the exit. GOL-HYP-08 · GOL-HYP-01
3. Sort every ticket
The most expensive habit in hypercare is filing everything under "user training". Phoenix's department initially believed the problems came from other departments not knowing how to use the system. A support desk that sends every problem to training hides the defects, and the people who reported them stop reporting. GOL-HYP-02 · DGN-FRM-03
Report the mix weekly. A hypercare where "training" keeps rising while "defect" stays flat is usually misclassifying. GOL-HYP-02 · GOL-KCS-01
Give bad news a route of its own. Phoenix's auditor linked the failure to public servants afraid to tell their political masters about problems. Set up a channel for frontline staff and the support desk that bypasses the project's own sponsors, and log what's reported and what's decided. GOL-HYP-06
4. End hypercare on the data, not the calendar
No source supports a standard hypercare length, including the popular 30 days. Exit when the data says so: ticket arrivals back to the forecast baseline, no open severity-1 or severity-2 defects for a set period, backlog age under target, and workflow errors within tolerance. If a contract fixes the hypercare term, honour it, but still report stabilisation. GOL-HYP-01
In a phased rollout, let each wave's stabilisation data gate the next wave. A second site that goes live while the first is still unstable splits the support team and doubles the backlog. GOL-HYP-05
Expect a productivity dip, but don't plan around a folklore number. The widely quoted "plan for a 30% drop" is trade-magazine opinion; real studies range from no long-term loss to a loss that never recovered. Baseline productivity before go-live, then report the trend by role over twelve months rather than one snapshot. GOL-HYP-03 · DGN-BSL-01
"Hypercare closes Friday; the project team rolls off Monday." The backlog moves to a general help desk with no context, and severity-2 defects become permanent workarounds.
"Hypercare closes when tickets are back to forecast, there have been no open severity-1 or -2 defects for ten working days, and the backlog is under five days old." The date is a forecast, not a promise.
5. Champions with a job description
Champions help, modestly. A Cochrane review of local opinion leaders found they probably improve compliance with good practice by a median of about 11 percentage points, with a wide range, and mostly among physicians. There's no evidence for any champion ratio, including the popular one per twenty users. Where the problem is a system defect, a champion can't fix it. GOL-CHP-01 · LSC-MNT-05
- Write down what champions do: which questions they answer, what they escalate and to whom. GOL-CHP-02
- Pick for credibility, protect their time in the schedule, and plan rotation before they burn out. GOL-CHP-04
- Judge the network on errors, rework and cycle time, not on sessions held or messages answered. GOL-CHP-03
6. After hypercare: keep it from sliding back
Skills fade, buildings drift and workarounds come back. Plan for relapse from the start. GOL-ADP-03
- Measure adoption by the work done in the new system, not logins or course completions. GOL-ADP-01
- Invest in the transfer climate: manager support, chances to use the new skill, and peer help. Measure transfer with independent sources, such as supervisors, records or observation, not the learners' own ratings. GOL-TRF-01 · GOL-TRF-03
- Check leading indicators at 30, 90 and 180 days in live work, and judge outcomes over six to twelve months. A safety change shouldn't be judged on a three-month window. UTL-ADP-02 · GOL-AID-01
- Set refreshers by task type and by how long since the skill was last used; legal refresher intervals are minimums, not the right schedule. Short retests work as refreshers. GOL-DEC-01 · GOL-DEC-03 · GOL-DEC-04
- Capture knowledge while solving tickets, not as a separate project, and treat vendor savings claims for this as claims until you've baselined your own. GOL-KCS-01 · GOL-KCS-02
- Use coaching for behaviour change, and expect small to moderate effects. Use cheaper job aids for simple procedural gaps. GOL-TRF-04
The habits. Make a behavioural test a gate. Plan for the system that runs wrong, not only the one that stops. Sort every ticket into defect, data, process, training or access. Give bad news its own channel. End hypercare on stabilisation data. Give champions a written job and judge them on errors and rework. Measure adoption in the work, and plan refreshers before the skills fade.