PBP study materials
PBP study resources

Eleven Days to Cutover

PBP · Put your knowledge to work in context.

All case studies

Eleven Days to Cutover

Wave 2 of an ERP rollout covers 14 sites across six go-lives, the first in 11 days. The last two cutover rehearsals failed the same two exit criteria: migrated record rejects at 3.1% against a 0.5% threshold, and interface latency at 9 seconds against a 2-second service level. The systems integrator classifies both as 'configuration issues' rather than defects, which keeps them outside the warranty remedy and shifts effort to your team. Site 7 has an unresolved union consultation about role changes, and its works council has not confirmed the go-live. The lead data-migration tester resigned on Friday. At the steering meeting the sponsor proposes proceeding with a 'tolerance' that accepts rejects up to 4% for the first month, arguing that the business case loses 90,000 for every week of delay.

1. What is your go/no-go recommendation for the first go-live in 11 days, and how do you justify it?

Read the worked answer

A conditional no for site 1 on day 11, with a specific path to yes - not a tolerance that accepts a known breach of the exit criteria.

  • Exit criteria exist for a reason. Rejects at 3.1% against 0.5% is a six-fold breach. The question is what is inside the 3.1%. If rejects include financial balances, statutory records or customer entitlements, the tolerance is not a schedule decision; it is a data-integrity risk that survives go-live and compounds daily. Ask for the reject taxonomy before anything else.
  • Latency. Nine seconds against a 2-second service level will drive a user workaround - parallel spreadsheets, batch double-entry - and workarounds are how post-go-live reconciliations fail. Assess impact per task, not the average.
  • Tolerance needs a named acceptor with authority, a documented rationale, a compensating control and a hard stop date. A tolerance agreed verbally in a steering group is not risk acceptance.
  • Site 7 is a hard stop regardless. Proceeding without works council confirmation exposes the organisation to a legal challenge and a stoppage mid-cutover.
  • What I would put to the group: defer the first go-live by two weeks, use the time to diagnose the reject driver and fix the interface, and re-run the rehearsal against the same thresholds. The 90,000 per week is real, but it is smaller than a failed cutover and rollback - quantify both so the comparison is like-for-like.
  • Name the decision owner and record the recommendation, including dissent.

2. The integrator says the issues are 'configuration', not defects. How do you handle that classification dispute?

Read the worked answer

Separate the technical question from the commercial label.

  • The classification determines who pays, not who fixes. Engineering priority should follow user and financial impact; the warranty argument follows contract interpretation. Letting the integrator's label set the priority imports a commercial incentive into technical triage.
  • Run a joint triage using severity definitions lifted verbatim from the contract schedule, with an independent technical assessment if the two sides cannot agree. Ask for the evidence behind 'configuration'. Under most schedules, configuration errors arising from the supplier's own design are still the supplier's work; the workable distinction is between a defect in the deliverable and a change to agreed requirements.
  • Document contemporaneously: who said what, when, on what evidence. If this ends in a claim, the record decides it.
  • Escalate through the contract manager or commercial lead in parallel with the technical track, with a named decision date so the dispute does not drift past go-live.
  • Protect the programme meanwhile: assign your own engineers to the latency with a temporary workaround, and log the cost so it can be recovered if the classification is later reversed.
  • The 90,000 per week is legitimate context for sequencing. It is not evidence about causation, and should never be allowed to stand in for it.

The professional point: never let the party with a financial interest in the label also own the diagnosis.

3. How do you recover the rest of wave 2 - five more go-lives across 14 sites - from here?

Read the worked answer

Recover by reducing concurrency, not by compressing it.

  • Sequence. Run one site as a controlled pilot for two weeks with hypercare and daily reconciliation. Release the remaining sites on evidence from that pilot, not on the calendar.
  • Re-baseline. With a tester down and two unresolved exit criteria, the plan has no float. Publish the revised sequence with the assumption behind each date and the decision date for each site.
  • Backfill the tester now. Internal secondment is usually faster than recruitment. Pair the replacement with the departing tester during their notice period - a handover document is a poor substitute for two weeks of pairing on real migrations.
  • Hold the exit criteria at their current thresholds. Lowering them to fit new dates converts a schedule problem into a quality problem that will present itself after go-live.
  • Set a formal go/no-go checkpoint per site, with named decision-makers and a rollback plan rehearsed at least once.
  • Report the cost of delay and the cost of failure side by side at every steering meeting, so the trade-off is visible rather than implied.
  • Watch the pattern: two failed rehearsals on the same criteria usually means a root cause nobody has diagnosed, not bad luck. Insist on the diagnosis before the third rehearsal.

That approach costs two weeks now and buys a repeatable cutover pattern for the remaining five, which is the cheaper of the two paths.