Hypercare and handover

Go-live is not the end of the project. It is its most dangerous point.

The system works, the team is exhausted, the customer wants to declare completion, and the real problems have not appeared yet — because the month has not closed, payroll has not run, and no supplier has been paid.

Hypercare is not “intensive support”. It is a project phase with an entry, an exit and a criterion.

What you are waiting to appear

Three events that cannot have happened before go-live however much you tested, and all three land in the first month.

Event	When	What it exposes
The first monthly close	End of month 1	Everything untested in accounting, all at once
The first payment and payroll run	Per the cycle	Bank integrations and permissions
The first report management asks for	Weeks 2 to 6	Is the data good enough for a decision?

The third is the real examination. Until that moment the system is measured by what staff can enter. At the first report it is measured by what management can decide — which is why the system was bought.

So plan the first monthly close as a project milestone rather than an operational event. With the full team present.

How long hypercare runs

Two complete financial cycles, rather than a number of weeks.

A duration measured in weeks usually ends before the second close. The first close exposes the problems and the second proves they were fixed — and one cycle is not enough to judge.

In practice: six to eight weeks for a company closing monthly.

The exit criterion

A number written into the charter and reviewed here, not an opinion.

Zero open grade-one defects, a daily ticket rate below 20% of the week-one peak, two monthly closes completed within the normal duration, and the share of documents created inside the system above 95%.

The last indicator is what exposes silent failure, defined at station eight: a company running itself on a spreadsheet beside a working system is a failed project that appears in no fault report.

Handover to support

The move from project team to support team is where knowledge disappears.

Four things are handed over in writing, or there is no handover.

• The decision log from station two — the only thing that answers “why is it like this?”.
• The customisation list with what each does and what must be tested at every upgrade.
• The known-issues list with workarounds.
• The phase-two list — everything deferred, ready to plan.

The first is the most valuable. A year later somebody asks: “why aren’t invoices under a thousand approved?” — with the log you answer in thirty seconds with who decided, why, and what alternative was rejected; without it you reopen the argument and reverse a decision that was right.

The closure report — two pages, written once

Most projects end with no closure report, so every piece of knowledge that was paid for is lost.

Six items.

• What was actually delivered against the charter — with the gap written plainly rather than managed.
• Dates: planned and actual per milestone, with the reason for each variance in one line.
• Budget: planned and actual, and what consumed each line.
• Change requests: how many accepted and how many deferred, and for how many days.
• What we learned — three lessons phrased so the next project can act on them, not generalities.
• The phase-two list, ranked by value.

The fifth is the only item that helps somebody other than you, and the first to be filled with empty phrases. “Communication mattered” is not a lesson; “the chart of accounts decision slipped three weeks because its owner was not named, so make it an item in the charter” is.

And the first item is written honestly or not at all. A closure report claiming everything was delivered as planned is contradicted by everyone who was there, and loses both its own value and its author’s credibility.

Measuring what was promised

The final step, and the most neglected in this profession.

At station two a success criterion was written as a number. Go back to it six months after go-live and measure it.

It is measured six months on rather than at handover, because the system’s effect does not show before usage settles. And it is measured even when the answer is uncomfortable — a measurement taken only when the result is good is not a measurement.

Three outcomes are possible, and all three are useful: the target was met, so you have a written case to build on; or it was not, for reasons outside the system, so the real causes are now known; or it was not, for reasons in the implementation, so you have a phase-two work list.

What you actually do in this station

• Plan the first monthly close as a project milestone with the full team present.
• Set hypercare at two financial cycles rather than a number of weeks.
• Write the exit criterion as a number and present it to the steering committee before go-live.
• Prepare the four handover documents and hand them over in a session rather than by email.
• Put the success measurement date in the calendar six months out, now.

The three commonest mistakes

One: ending hypercare before the second close. A system is handed over that has not been shown to close.

Two: a verbal handover. The “why” behind every decision disappears, and settled questions are reopened a year later.

Three: never measuring the success criterion. The project is left unjudged, and the next decisions rest on impressions.

The acceptance test for this station

1. Name the three events awaited in the first month and why the third matters most.
2. State the hypercare duration and its justification.
3. Show the exit criterion in numbers and its status today.
4. Show the four handover documents.
5. State the charter’s success criterion and its measurement date in your calendar.

What comes next

The path is finished. What follows is a choice: to see how a project is lost despite doing everything above, read why ERP projects fail — seven reasons, four of them management decisions rather than technical ones. And for the other side of the table, the ERP sales path reads the same deal from the seller’s side.