Implementation readiness is a decision about whether the planned service can produce its required outcomes within accepted risk—not a percentage of tasks completed. Launch when critical evidence passes, delay when a bounded gap can be resolved, and rescope when a safe coherent outcome can be released without pretending missing work is complete.
Use explicit thresholds and decision rights. A green status without recovery, data or operational evidence is not readiness.
Define the release outcome
State users, workflows, data, locations, volume, service window and excluded scope. Name conditions that must be true on day one and during stabilisation.
A release cannot be assessed while stakeholders imagine different boundaries.
Use six readiness domains
| Domain | Required evidence |
|---|---|
| Outcome | end-to-end scenarios and owner acceptance |
| Data | migration reconciliation, quality and authority |
| Technology | configuration, integration, performance, security and recovery |
| People | role capability, access, communications and support |
| Operations | monitoring, incident, change, supplier and continuity rehearsal |
| Cutover | sequence, decision, rollback, delta and reconciliation |
Classify evidence
Use ready, conditional, blocked and not applicable with owner, proof, expiry and consequence. A conditional item needs a specific action and acceptance point.
Do not average domain scores. A blocked payroll, identity or recovery control may stop the release.
Test end to end
Run normal, boundary, exception and failure scenarios with production-like roles and data. Trace business and technical outcomes.
Retain defects, workarounds and accepted limitations linked to the scenario.
Verify migration and cutover
Rehearse final extraction, transformation, load, delta, control totals, exception, authority switch and rollback. Measure duration and decision windows.
Include transactions created during cutover and partial failure. A rollback that loses new work is incomplete.
Rehearse operations
Simulate alert, incident, failed integration, access issue, restore, supplier escalation and business communication. Confirm people can use runbooks and evidence.
Operational readiness belongs to the team that will own the service, not only the project.
Check business readiness
Ask representative users to complete critical tasks and managers to use outputs. Confirm access, data, instruction, support and changed responsibilities.
Training attendance does not prove task readiness.
Choose launch, delay or rescope
Launch when mandatory evidence passes and residual risk has authority. Delay when a critical gap has a credible short resolution. Rescope when a smaller complete service can operate without unsafe bridges.
Do not label deferred critical work “phase two” unless the phase-one boundary remains coherent.
Record the decision
Capture scope, evidence, blocked/conditional items, risk, options, owner, date and review. Communicate what changes for users and support.
If the decision is delay, preserve environments and rerun affected tests. If rescope, update contracts, data, training and rollback.
Protect stabilisation
Define heightened monitoring, daily controls, thresholds, decision cadence and exit criteria. Keep project expertise available while ownership transfers.
Readiness is proven again through early operation; launch approval is not the end of acceptance.
Set measurable non-functional thresholds
Readiness needs explicit thresholds for availability, response time, batch duration, concurrent users, integration recovery, backup age, restore time and security monitoring. Test at realistic load and with production-like dependencies. “Performance tested” is not evidence unless the volume, environment, result and acceptance threshold are recorded.
Include accessibility and supported devices where they affect critical work. A release that excludes a required user group is not operationally ready.
Resolve legal, security and supplier conditions
Confirm contracts, data-processing terms, licences, support hours, sub-processors, security findings and regulatory approvals that must be in force. Distinguish a documented residual risk from an unresolved prerequisite. Name who can accept each class of risk and when that authority expires.
Test supplier escalation with real contacts. A document containing an obsolete mailbox is not a support capability.
Check capacity, not just assignment
Named owners may still be unavailable during cutover or stabilisation. Verify rota, time zones, handovers, competing commitments and specialist coverage. Identify decisions that depend on one person and prepare a deputy with the same evidence. Confirm the permanent team has access to monitoring, configuration and supplier channels before consultants leave.
For business teams, include the workload created by reconciliation, dual running and exception handling.
Run the decision meeting from evidence
Distribute the proposed scope, domain status, critical defects, cutover rehearsal, rollback limit, residual risks and recommendation in advance. In the meeting, review only material exceptions and disputed evidence. Record launch, delay or rescope as an explicit decision with conditions and owners—not as the absence of an objection.
Prevent optimistic status conversion after the decision deadline. Any changed evidence should trigger the stated reconsideration route.
Recognise misleading readiness signals
- Test counts are high, but priority end-to-end scenarios failed.
- Data loaded, but control totals and ownership are unresolved.
- Training completed, but users cannot perform critical tasks unaided.
- A rollback document exists, but it has never been timed or rehearsed.
- Support is staffed, but monitoring and escalation access are missing.
- Risks are marked accepted without the required authority.
These signals should change the decision, not merely the presentation colour.
Define stabilisation exit criteria before launch
Specify the incident trend, reconciliation status, performance, support demand, adoption behavior and open-risk level required to leave heightened support. Set review dates and the authority to extend stabilisation. This prevents the project from declaring success while the operating team inherits uncontrolled work.
A disciplined readiness decision is reversible in method even when the business event is not. It preserves evidence, explains trade-offs and protects the ability to recover or reduce scope if assumptions fail.