The first 90 days after go-live should stabilise the service, establish reliable operating habits and test whether expected outcomes are appearing. It is not the time to accept every enhancement request or dissolve the implementation team immediately.
Use three phases: stabilise the service, learn from real work and optimise within governance. Keep thresholds, owners and review dates visible.
Before day one: establish the control room
Name service, process, data, support, supplier and decision owners. Publish channels, severity, daily review, dashboards, rollback boundary and user communication.
Freeze nonessential change and retain implementation evidence and specialists.
Days 0–10: stabilise
Monitor service, integration, data reconciliation, access, critical workflows, queue and user impact. Triage defects by consequence and first cause.
Separate incident, data issue, learning need, process gap and enhancement. Do not let the enhancement backlog distract from stability.
Use a daily control set
| Control | Question |
|---|---|
| Service | Are critical paths available and performing? |
| Data | Do inputs, outputs and control totals reconcile? |
| Access | Can the right roles act without excess privilege? |
| Workflow | Are cases stuck, duplicated or bypassed? |
| Support | Which issue affects the most important outcome? |
| Communication | Do users know current state and next action? |
Protect data corrections
Use authorised source and controlled change. Record before/after, reason and downstream replay. Avoid direct target fixes that the next interface overwrites.
Review recurring defects and change capture, mapping or ownership.
Days 11–30: establish habits
Managers should use the new evidence in real reviews. Users should complete critical work and update authoritative state. Retire parallel spreadsheets and routes deliberately.
Measure adoption by role and behavior, not logins. Interview users at the point of workaround.
Control support and knowledge
Turn recurring resolved issues into owned guidance, product change or process fix. Track repeated contact and unresolved age.
Keep a clear route for sensitive or exceptional cases. Do not force self-service to improve a deflection number.
Days 31–60: learn
Compare actual volume, exceptions, administration, cycle time, quality and outcome with the business case and pilot. Annotate seasonal or scope differences.
Prioritise the constraint that limits value. Run one bounded improvement with guardrails.
Govern enhancements
Require problem, affected users, evidence, expected outcome, owner, cost and priority. Distinguish configuration correction from new scope.
Group requests by root cause. Ten requests for another field may indicate unclear process rather than a requirement.
Days 61–90: optimise and transfer
Confirm operating ownership, service levels, data stewardship, release, access review, supplier governance, continuity and improvement cadence. Reduce heightened support only when exit criteria pass.
Close or transfer residual project risks and commitments.
Run the 90-day value review
Review target outcomes, adoption by role, exception and rework, operating effort, cost, unintended effects and unresolved conditions. Decide retain, optimise, rescope or revisit the solution.
Record evidence and next review. A benefit not yet measurable should keep its owner and date rather than become a success claim.
Preserve operational memory
Keep architecture, configuration, data lineage, acceptance, runbooks, decision log, known limitations, contract commitments and rollback/archive evidence under ownership.
The first 90 days succeed when the service is stable, people use it to run work, problems create learning and the permanent team can change it safely.
Build a balanced early-life scorecard
Combine service health, data quality, process completion, user behavior, support demand and business outcome. Use a small number of measures with definition, owner, baseline and action threshold. Examples include failed integration events, unreconciled records, cycle time, manual bypass, repeated contact and percentage of critical tasks completed in the intended route.
Avoid one aggregate adoption score. It can hide a critical role that has not moved or a location that is working around the system.
Triage by consequence and cause
For each issue, record affected outcome, users, frequency, severity, containment, suspected cause, owner and next decision. Similar symptoms may come from access, data, configuration, integration, instruction or process design. Fixing the screen will not resolve a master-data authority problem.
Review major incidents and recurring minor issues. A cluster of low-severity workarounds can create more operational risk than one visible defect.
Study adoption by role and moment
Observe what people do when a case is urgent, incomplete or unusual. Compare intended and actual routes for frontline users, managers, administrators and occasional approvers. Ask what information or authority was missing at the point they left the process. Use this evidence to choose training, content, workflow or product changes.
Protect useful local knowledge: the goal is to remove unsafe workarounds, not to dismiss why they developed.
Review controls after real use
Sample approvals, access changes, exceptions, exports and administrative actions. Verify segregation, evidence and timely review under actual workload. Confirm temporary cutover access has been removed. Test backup restoration and continuity again after material early configuration changes.
Where a control creates excessive delay, redesign it without removing the risk decision it was meant to support.
Manage the supplier as an operating dependency
Track cases by consequence, response, workaround, root cause and permanent resolution. Review service commitments and upcoming releases. Require impact assessment for supplier changes during stabilisation. Keep internal ownership: the vendor may diagnose the product, but the organisation decides business priority and accepts operational risk.
Preserve evidence needed for service reviews and commercial remedies.
Retire old routes deliberately
Inventory spreadsheets, forms, mailboxes, interfaces and reports that the new service replaces. Retire each only after data, retention, downstream users and contingency are resolved. Communicate the authoritative route and monitor attempts to use the old one. If dual running remains necessary, define duration, reconciliation and exit.
Uncontrolled parallel operation creates conflicting records and delays adoption feedback.
Close the implementation without losing learning
At day 90, hold a retrospective that separates product limitations, implementation decisions, data conditions, process design and change management. Record what should become operating policy, reusable delivery practice or future backlog. Close actions only with evidence and transfer unresolved work to named governance.
The strongest outcome is not a quiet support queue. It is a service whose data can be trusted, whose users understand their responsibilities, whose controls work under real conditions and whose owners can improve it without recreating project dependency.