A concise case study on readiness gates, transparent escalation and why protecting a business outcome matters more than defending an arbitrary go-live date.
Process map
DetectIssue found
critical dependency
critical dependency
AssessBusiness impact
risk / options
risk / options
ValidateReadiness gates
evidence
evidence
EscalateChoices and
consequences
consequences
DecideDelay, scope
or proceed
or proceed
RemediateVendor / team
recovery work
recovery work
RetestProve readiness
LaunchControlled
go-live
go-live
The situation
- A CRM program was approaching go-live when a critical integration was found not to be ready and the delivery risk had not been surfaced early enough by the vendor.
- The choice was to protect the date or protect the business outcome.
Use objective readiness gates
- Critical business processes must work end-to-end.
- Required integrations must be functioning and supportable.
- Data migration and reconciliation must be materially complete.
- Security and role-based access must be ready.
- Users and support teams must know what to do.
- Rollback or contingency must be realistic.
Escalate options, not drama
- Proceed and explicitly accept the risk.
- Reduce scope if the affected capability can be safely deferred.
- Delay until the critical condition is met.
- Use a temporary workaround only where it is controlled, supportable and genuinely lower risk.
Manage the recovery
- Separate root-cause review from immediate recovery activity.
- Reset deliverables, owners, dates and acceptance evidence.
- Increase reporting cadence temporarily.
- Communicate the delay quickly and factually to stakeholders and affected users.
Key lessons
- A date is not a control.
- Readiness criteria should exist before the final week.
- Critical integrations are business capabilities, not technical footnotes.
- Transparent delay can strengthen confidence when it demonstrates control.