Blog

Go-live is the most celebrated moment in a project and one of the most misleading. A system can launch on time and within budget while the organization keeps working the old way. This article explains why deployment alone does not equal success, and how project leaders can define adoption, retirement, and value criteria before the project begins. 

Deployed Is Not Delivered 

Picture a familiar scene. A new system goes live on schedule. The steering committee sends a thank-you note, the project closes, and the team moves on. Six months later, half the intended users still keep their own spreadsheets. One department still routes approvals through email because it does not trust the new workflow. Nobody owns the gap, because the project that introduced the change has ended. 

On paper, the project succeeded. In practice, the organization now supports two ways of working, paying for both while receiving the full benefits of neither. 

Go-live proves that a solution has been deployed. It does not prove that people have adopted it, that old processes have been retired, or that the expected value has been realized. 

Unfinished adoption also adds to cumulative change load. Teams running old and new processes side by side have less capacity for the next initiative, a hidden contributor to innovation fatigue. 

Figure 1. Running old and new processes side by side drains the capacity a team needs for the next initiative. 

Why Projects Stop at Go-Live 

These are rarely failures of effort. They are failures of definition and accountability. 

Four Kinds of “Done” 

A better definition separates four outcomes often treated as one. 

These outcomes rarely arrive together. Deployment happens at go-live; adoption can take months; some benefits take longer still. A project can close properly once its deliverables and transition responsibilities are complete, even while adoption and benefits tracking continue under business ownership. 

A project can end. Accountability for its outcomes should not. 

Warning Signs That Adoption Is Incomplete 

The most revealing sign is an unplanned parallel process. The instinct is to enforce compliance, but continued reliance on the old way often points to gaps in training, functionality, data quality, or confidence. Resistance is not always a refusal to change. Sometimes it is evidence that the new process has not yet earned the user’s trust. 

Figure 2. Resistance is often evidence of a trust gap in the new process. 

Five Ways to Reach Real “Done” 

1. Define adoption and retirement criteria before implementation 

Alongside functional requirements, define what successful adoption looks like, how it will be measured, and which legacy processes will end. A target might be 90% of eligible transactions through the new system within 60 days, set to reflect real business needs and agreed exceptions rather than an arbitrary number. 

2. Assign ownership that continues after closure 

Each criterion needs an accountable owner who remains after the project team leaves, usually a business process owner rather than the project manager. Before go-live, agree who will monitor adoption, resolve open issues, approve retirement, and report on benefits. The project manager’s job is to make sure that handover is documented as part of closure. 

3. Set retirement dates and readiness conditions 

A parallel run can be necessary, especially where continuity or regulation is involved. Without an end date, it becomes a permanent operating model. Set the retirement date before go-live, along with its conditions: acceptable defect levels, completed training, validated data, and business-owner approval. Retirement should be a controlled business decision, not just a calendar deadline. 

4. Treat stabilization as a planned phase 

Hypercare is not leftover project time. Give it an owner, a duration, and exit criteria, such as critical defects resolved or accepted, error rates within thresholds, support volumes back to normal, and business owners confirming readiness. 

5. Review adoption and value at 30, 60, and 90 days 

Schedule post-go-live reviews of adoption trends, workarounds, retirement progress, and early results, with owners who can act. Adoption stuck at 60% while workarounds rise signals a deeper problem than launch figures show. After closure, operational governance can run them. 

An Example 

Consider a hypothetical organization replacing paper and email purchase requests with a digital approval workflow. It launches on schedule, but three months later about a third of requests still arrive by email. Several managers keep using the old route because they doubt the new routing reaches the right approvers. 

Rather than mandating adoption, the program office works with business leaders to understand the concern and finds two genuine routing gaps. Managers help test the fixes, a business owner takes responsibility for adoption, and a retirement date for email requests is set, conditional on the fixes and agreed performance criteria. 

Email requests fall below 5%, and average approval time drops from five business days to two. The old process is retired, with approved exceptions documented. The system did not need another launch. What changed was the definition of success. 

When the Old System Cannot Be Retired Yet 

Retention rules, audits, or unfinished integrations may keep a legacy system alive. Retiring a process is not the same as shutting down its technology. When full retirement is not possible: 

The Bottom Line 

Go-live is a milestone, not the finish line. Lasting success depends on what happens afterward: whether people adopt the solution, old processes are retired, and the expected value appears. 

Figure 3. Go-live is a milestone; adoption, retirement, and value continue well after it. 

Good governance asks more than “Did we launch successfully?” It asks: “Is this now the only way we work, and is it delivering what we promised?” 

Author Bio: