Go-Live Readiness Is a Business Decision Supported by Delivery Evidence
A go-live decision should not be driven by calendar pressure or the amount of effort already invested. It should reflect whether the solution, data, people and support model are ready to operate at an acceptable level of risk.
Readiness brings together evidence from testing, migration, integrations, training, cutover, security, support and business ownership.
31.1 Define Readiness Dimensions
Assess solution quality, data, integrations, security, training, business process readiness, support readiness, cutover readiness and operational contingency.
A single overall percentage can hide a critical red area.
31.2 Use Explicit Entry Criteria
Define what evidence must be available before the final readiness review begins. Examples include UAT acceptance, reconciliation, critical-defect status, cutover rehearsal and support staffing.
This prevents the review from becoming a discussion based on memory and opinion.
31.3 Assess Open Defects by Business Impact
Review unresolved defects, accepted workarounds, operational consequences and target fixes.
A low defect count is not meaningful if one unresolved issue blocks a critical business process.
31.4 Validate Business Readiness
Confirm trained users, required roles, permissions, policies, process ownership, communications and local operating procedures.
A technically ready system can still fail if the business is not prepared to use it.
31.5 Confirm Support Readiness
Validate service desk routes, escalation paths, specialist coverage, monitoring, runbooks and hypercare operating model.
Users should know where to go when the first real production exception appears.
31.6 Evaluate Contingencies
Review rollback, fallback, manual procedures and business-continuity options for the highest-risk scenarios.
Contingency plans should be realistic enough to execute under pressure.
31.7 Run a Formal Go/No-Go Review
Present evidence, material risks, conditions and recommendation to the authorized decision-makers.
Document the decision, conditions and owners for any accepted residual risk.
31.8 Treat Conditional Go-Live Transparently
If go-live proceeds with conditions, state exactly what remains open, why the risk is acceptable, what mitigation exists and when closure is expected.
Conditional approval should never become a vague way to bypass readiness criteria.
From the Delivery Floor
A release met its planned date, but the final readiness review found that user access for one large business group had not been fully validated. Rather than ignore the issue, leaders delayed that group while allowing a smaller ready population to proceed.
The controlled decision protected the overall program while avoiding a production incident caused by inaccessible roles.
31.9 The Delivery Leader's View
A delivery leader should make the readiness gap visible early. The value of a go/no-go forum is not the meeting itself; it is the quality of evidence and the willingness to act on it.
Chapter 31 Implementation Checklist
- Are readiness dimensions defined?
- Are entry criteria explicit?
- Is UAT acceptance available?
- Are material defects understood by business impact?
- Is migration reconciled?
- Are integrations operationally ready?
- Are users trained and provisioned?
- Is support staffed and briefed?
- Are contingencies realistic?
- Is the go/no-go decision formally recorded?
Key Takeaways
Go-live is a business-risk decision.
Readiness should be evidence-based and multi-dimensional.
Open defects must be evaluated by operational impact.
Support and user readiness matter as much as technical readiness.
Conditional approval requires explicit ownership and mitigation.
Closing Thought
A strong go-live decision is not fearless. It is clear about the remaining risk and deliberate about why the organization is prepared to accept it.