When a system goes live, the work is not finished for the people who have to use it. They are new to it, and the project team is still the only group that knows how it behaves. I treat hypercare as a handover from that team to the people who will live with the system, not as a vigil where we sit and wait for the phone to ring.
What users need first
The needs are few and practical. Users need to be trained, they need documentation they can open without asking anyone, and they need to know whom to reach when something is wrong. On the programmes I have run, that meant training sessions, documentation made available to everyone, and showing users where it was and how to make contact in an emergency.
That last part matters more than it sounds. Documentation that exists but cannot be found is the same as no documentation. I would rather spend a few minutes in a training session showing people where the pages are and how to raise an urgent problem than hand over a long manual and hope.
Hypercare is also where the client forms its opinion of the project. A calm first month, in which questions are answered quickly and by a named person, builds trust that lasts longer than the delivery itself.
What I put in place
- Training sessions for the people who will use the system, held close to go-live so that what they learn is still fresh.
- Documentation that is easy to find. One known place, linked from the training material.
- A route for urgent problems. Named contacts and a channel, shown to users in person and also written down.
- An agreed end. Exit criteria set before go-live, so that hypercare does not drift on.
Knowing when it ends
Hypercare without an end date turns into permanent project support that nobody is paying for. I agree its length and its exit criteria before go-live, for example no open critical defects and a stable period, and I review the open issues in the weekly sync. When the criteria are met, whatever remains moves to the normal support process, each item with an owner.
I also keep a short log of what users ask during hypercare. The questions are an honest review of the training and the documentation: if the same question keeps coming back, the answer belongs in the documentation and not in somebody's inbox.
The same idea at programme level
I have also led a multi-country programme through the handover of programme leadership to the central team. The principle is the same at a larger size: the people receiving the work should not have to ask where things are. In practice that means the open risks, the pending decisions and the working relationships are written down and explained, not only passed on in a folder.
A leadership handover also has a human side. The people in each country should hear from us, not from a document, who their contact is now and what stays the same for them.
A handover is finished when the people who receive it no longer need to call the people who gave it.