Hypercare: the first 30 days after go-live

The project plan has a milestone called go-live, and everyone treats it as the finish line. It is not. The first 30 days after go-live, the hypercare period, is where the system is either bedded in or quietly worked around, and the difference is almost entirely about how that month is run.

What hypercare is

Hypercare is a defined period, usually two to four weeks, in which the project team stays in place, on site or on call, with a faster response and a lower threshold for "we'll look at that" than normal support. It ends with a formal handover to business-as-usual support. It has a budget, a rota and an exit criterion, and it is agreed before go-live, not improvised afterwards.

What normal looks like

New users on a new system generate a lot of noise in week one, and most of it is not defects. A typical first fortnight for a 50-user business looks like this:

• Days 1 to 3: forty to eighty questions a day. Login problems, "where is the button that used to be here", printers, a document layout with the wrong address block, someone posting to the wrong dimension. One or two real defects.
• Days 4 to 10: the questions halve and change character: "how do I handle a return", "the price on this order is wrong", "the EDI order came in without a delivery date". Process gaps surface, usually things that happen once a week and were never in a UAT script.
• Days 11 to 20: first month-end. Everything that was posted slightly wrong in weeks one and two is found here. Bank reconciliation, VAT return, aged debtors, intercompany. This is where the finance team decides whether they trust the system.
• Days 21 to 30: quiet. Second-week volume of questions, mostly "can it do X" rather than "it is broken". Time to hand over.

If days 11 to 20 look like days 1 to 3, something went wrong with the data or the testing, and hypercare needs extending rather than ending.

Defect, gap, or training?

Every ticket in hypercare is one of three things, and sorting them correctly is most of the job:

• Defect: the system does not do what the signed-off design says it does. Fixed by the project team, at the project's cost, prioritised by business impact. Showstoppers same day; everything else in a daily release.
• Gap: the system does what the design says, and the design was wrong or incomplete. A process nobody mentioned, an exception that happens monthly. Logged, costed, and either done in hypercare if small or put on the roadmap. This is where scope arguments start, so write down who decides.
• Training: the system does it, the user does not know how. Handled by the super user in the department, not the consultant, and logged so the training material gets fixed.

The daily stand-up (fifteen minutes, project manager, lead consultant, super users) sorts yesterday's tickets into those three buckets and agrees the day's fixes. The sponsor gets one line a day.

The things that go wrong in hypercare

• The spreadsheet comes back. Someone cannot work out how to do something, does it the old way "just for now", and in three weeks it is the system of record again. Super users in the departments catch this; a help desk does not.
• Nobody owns the gaps list. Fifty small improvements, no priority, no budget, no decision. Agree in week one who decides and how.
• The consultants leave on day five. The budget ran out, or the next project started. Hypercare without the people who built the system is just support with a different name.
• Month-end is treated as support. The first month-end in a new system is a project deliverable. The consultant sits with the finance team through it.

Handing over to support

Hypercare ends when: the first month-end has closed and reconciled; there are no open showstopper or high-priority defects; ticket volume has been at business-as-usual levels for a week; the super users can answer the routine questions without the consultants; and the gaps list has an owner, a priority order and a budget. Then there is a handover meeting, a document that lists every open item and who owns it, and the support agreement starts: the response times change, the ticket route changes, and the project is formally closed.

Our support is two-hour response, and it starts from that handover, with the people who built the system still on the other end of the phone. If you are in a hypercare period that feels like it is not ending, talk to us; a day of senior time usually finds why.

More from the blog

• Year-end close checklist in Business Central Finance
• The Business Central release wave checklist Release updates
• A plain-English Business Central glossary Operations