On the first morning after launch, employees can sign in, transactions are moving, and the project team has completed the cutover checklist. The business has achieved an important milestone. It has not yet shown that the new system can support a complete operating cycle without extraordinary help.
The next test arrives in ordinary work: a customer changes an order, a supplier sends a correction, an employee needs absence cover, or finance closes the period. These events reveal whether the organization can use, support, and improve the system after the concentrated effort of implementation begins to recede.
Executives should treat go-live as a transfer into accountable operation. The program needs explicit ownership of unresolved risks, evidence from real business cycles, and a continuing plan to realize benefits. Ending project attention at deployment can leave the organization with software in production and important operating decisions still unfinished.
Separate three kinds of acceptance
Technical acceptance establishes that the deployed system meets defined technical conditions: the release is installed, essential connections work, access is available, and monitoring can detect relevant failures.
Operational acceptance establishes that people can complete the important business work under realistic conditions, including exceptions, support needs, and recovery. It requires more than a successful happy-path transaction.
Benefit acceptance establishes whether the changed process produces the intended value and whether management has taken the actions needed to realize it. A system can be technically dependable while the organization continues to use old reports or workarounds that prevent the expected improvement.
These three horizons are a working management heuristic, not an industry certification scheme. They help prevent one successful milestone from being used as evidence for a different claim.
The UK Service Manual describes the live phase as sustainable operation with continued iteration and improvement. Its public-service context is different from an enterprise implementation, but the lifecycle principle is relevant: moving into live creates continuing responsibilities. GOV.UK, How the live phase works.
Observe the business calendar rather than an arbitrary number of days
A quiet first week may exclude the transactions that matter most. A monthly close, quarterly contract adjustment, seasonal peak, or annual renewal can expose dependencies that routine daily work does not exercise.
Map the first occurrence of significant business events after launch. For each, identify the process owner, expected evidence, known limitations, and support needed. Keep the scope proportionate to the implementation.
Do not promise that all risks will be resolved after a standard thirty-day period. A fixed period can be useful for planning staffing, but operational acceptance should reflect the events the business actually needs to perform.
Equally, avoid using infrequent events as a reason for indefinite project support. Simulations, rehearsals, and targeted later coverage can provide proportionate assurance. State which evidence is from production and which remains based on testing.
A specialist wholesaler reaches its first returns cycle
Consider a hypothetical wholesaler of scientific equipment. The new system supports order entry, inventory, dispatch, and invoicing. During the first week, ordinary orders complete successfully, and the launch is described as stable.
The first significant customer return arrives later. It involves a partial shipment, a replacement item, and an invoice already paid. Service, warehouse, and finance teams each know part of the process, but the new return reference is not consistently used across their records.
The implementation team can repair the immediate case, but operational acceptance requires a more durable response. The business owner confirms the return states, the warehouse evidence, the approved financial treatment, and the reconciliation between replacement and original transactions. Technical support fixes the relevant mapping and tests related scenarios.
The program records the case as a cross-process defect with an accountable owner, rather than allowing several departmental tickets to be closed independently. It also identifies other open returns that might share the problem and verifies their status before assuming the issue is isolated.
The acceptance review distinguishes the successful daily order flow from the unresolved returns cycle. That does not invalidate the whole launch. It changes the evidence about where the business still needs concentrated support.
The hypothetical example makes no claim about failure frequency. It illustrates why launch success should be evaluated through the business’s actual operating events rather than the absence of immediate technical outages.
Transfer decisions as well as documentation
A handover package can contain extensive documents while leaving nobody certain who decides what. Identify the owner for process policy, data correction, application faults, integration failures, access questions, and commercial exceptions.
Support staff should know the boundary of their authority. They may restore a failed interface but should not invent a new rule for handling a disputed transaction. A business owner may approve a process exception but should not bypass a security control to make it easier to execute.
Record the escalation route for cross-functional problems. A ticket involving several systems needs one coordinating owner even when different teams perform the repairs. Otherwise, each supplier can complete its assigned task while the business outcome remains unresolved.
Make availability realistic. The person who answered every question during implementation may return to a full-time operational role after launch. Replace that informal dependency with scheduled cover, deputies, and an agreed way to obtain decisions.
Keep unresolved work visible without treating it all as failure
Many launches retain a residual list of defects, limitations, improvements, and deferred scope. These categories need different treatment.
A defect prevents an agreed requirement from working. A limitation may be an explicitly accepted boundary. An enhancement adds something new. A deferred obligation may still be required for the intended outcome but scheduled later. Mixing them in one undifferentiated backlog obscures accountability and contractual interpretation.
For each material item, record the business consequence, affected population, workaround, owner, target decision or delivery point, and review trigger. If the item was accepted as a launch risk, preserve the conditions of that acceptance.
Do not allow a workaround to become permanent by default. A temporary spreadsheet may be sensible during stabilization, but it needs an owner, access controls, reconciliation, and a retirement condition. Otherwise, the new system can inherit the fragmentation it was intended to remove.
Measure work completed with ordinary support
Early operating results can be distorted by exceptional assistance. Consultants may correct records behind the scenes, business experts may monitor every transaction, and managers may personally resolve each exception.
That support can be appropriate during transition. The important question is whether performance will remain acceptable when it reduces. Track the additional work so the organization does not mistake project-team effort for a sustainable operating model.
Observe task completion, exception handling, data reconciliation, and support demand by meaningful process type. Ask whether users can recognize and resolve routine problems through the agreed support route.
Include adoption evidence without reducing it to logins. A person may use the application daily while maintaining the real decision record elsewhere. Review whether the new process is the one managers rely on and whether duplicated reporting has actually been removed.
Keep the benefit mechanism under review
Implementation often changes the assumptions behind the business case. A planned automation may require more review than expected. A data-quality issue may delay a reporting benefit. A process improvement may release capacity in a different role than originally assumed.
Update the benefit plan with evidence rather than preserving the original number for appearances. Identify which management action realizes each benefit and who owns it.
GAO’s IT investment guidance considers how investments are selected, managed, and evaluated using cost, benefit, and risk information. The relevant lesson is that evaluation continues after the initial purchase and delivery decision. GAO, Assessing Risks and Returns.
Keep operational improvement distinct from cash savings. Faster work may improve responsiveness or absorb growth without reducing payroll. Those can be legitimate outcomes if they are stated and measured honestly.
Make support reduction conditional on evidence
Concentrated launch support should reduce when the service can be handled through a sustainable model, not simply when a supplier’s planned departure date arrives.
Define the conditions: critical business cycles demonstrated, material incidents controlled, support roles staffed, knowledge usable, and residual risks accepted by authorized owners. The exact conditions should reflect the system and business.
A phased reduction can reveal hidden dependencies. Remove extraordinary monitoring from a low-risk area while retaining it for an unresolved process. Observe whether ordinary teams can handle the work before reducing coverage further.
Do not require an impossible absence of all tickets. New questions and minor defects will continue. The relevant test is whether the organization can detect, prioritize, resolve, and learn from them without relying on an unsustainable project structure.
Preserve the learning from early operations
The first operating cycles produce valuable evidence about assumptions made during design. Capture what surprised users, which exceptions were missing, and which controls or reports proved useful.
Use incident and case reviews to identify improvements without turning every problem into a search for someone to blame. Preserve the conditions that made the error understandable so the organization can improve the process.
Prioritize changes according to consequence and recurrence. Early enthusiasm can create a flood of enhancement requests while important reconciliation or support weaknesses remain unresolved. The service owner should keep those priorities visible.
Avoid making major discretionary changes so quickly that the team cannot distinguish launch defects from new behavior. Stabilize the essential operating baseline, then expand deliberately.
What executives should ask after the launch announcement
Ask which business cycles have been demonstrated, which still depend on testing, and where extraordinary support remains. Ask who owns the accepted risks and when each temporary workaround will be reviewed.
Require a clear statement of operating ownership and benefit responsibility. A completed project report should not be the only place these commitments exist.
Finally, ask what evidence would justify reducing support or expanding scope. The answer should be grounded in the business’s ability to operate, not the desire to declare the program finished.
Go-live is a valuable achievement because it puts the new design into use. The work that follows determines whether the organization can depend on it. Treating that period as accountable operation, with explicit evidence and ownership, is how a successful launch becomes a sustainable business improvement.
