A change rollout while operations are running needs a service floor and a hold point. The service floor is the minimum standard below which production stops the change, not the other way around. Without that boundary, the rollout borrows from operations until something breaks that cannot wait.
A change rollout when operations cannot pause is not a scheduling problem. It is a decision about which assumptions must hold while the old system and the new run side by side. Most plans focus on sequencing tasks. The useful question: what must remain true during the transition, and what monitoring tells you if it stops being true.
At 5.40 a.m., a shift supervisor takes responsibility for a plant that cannot stop. At 6 a.m., a new inventory process begins in one warehouse bay while crews still ship the orders that pay for the place. A sponsor fixed the date in a meeting the supervisor did not attend. When dispatch begins to slip, the useful question is who can hold the next release.
I have watched teams inherit that arrangement with a project schedule and a promise that disruption will be brief. The papers do not tell the shift supervisor what service must hold, or who can stop the next wave. A launch date constrains timing but cannot show that the operation can carry the change. A Change Management Process for Rollouts While Operations Run begins by settling those matters.
Change Management Process for Rollouts While Operations Run is a way of making a live change in bounded waves while keeping performance above a stated service floor.
Change Management Process for Rollouts While Operations Run starts with the service floor
The live operation has a job to do during rollout, and that job is usually more important than the project plan. A hospital still treats patients and a warehouse still ships. I would put the operational outcome on the page before looking at a release calendar: what work must continue, and what is its minimum acceptable level? Until that is stated, nobody can tell the difference between a tolerable interruption and damage being passed quietly to the people on shift.
The Project Management Institute's change lifecycle recognises that implementation overlaps with business-as-usual. I have never seen a serious operation wait politely for a programme to finish; orders and patients keep arriving while the programme office updates its plan. The relevant decision is whether this release can proceed while the organisation still meets the obligation it already has.
A client commitment can make a delay expensive. It does not make the programme office's assumption true. As Roger Estall and I wrote in Deciding, a decision needs conditions for proceeding, not confidence in a date. When nobody can state the service floor, the sponsor has accepted an instruction without knowing what it may break. That is where the wider change-management question begins.
State the service floor for your next rollout wave and name who can hold the release if it breaks. Start the Walk →
Change Management Process for Rollouts While Operations Run needs a wave gate
A wave gate is a small decision record for the part of the operation about to change. It does not need an assurance pack written for people who will never use the process. Record the primary change in ordinary language, then record the safeguard that lets the live operation survive it. A new stock process is the change; a parallel reconciliation is the supporting arrangement. I have seen a completed training sheet treated as evidence even though nobody on the night shift could find the stock.
Before a wave starts, name the decision in the terms of the work that must continue. The Universal Decision-Making Method calls for Sufficient Certainty before proceeding. A schedule is not a decision merely because a project office has circulated it.
The assumptions must be precise enough for someone on shift to recognise failure. Can the new work be completed within the existing handover? Can the old procedure still be used by people caught in the changeover? In my experience, a readiness report usually avoids those questions and reports that the team is ready. The report protects the meeting; it does not protect the handover.
The UK National Audit Office's review of central-government reorganisations shows what happens when an ambitious date outruns the work. The Equality and Human Rights Commission opened more than a quarter under complement, short by 140 staff, with only 10 of 25 director posts filled. The capacity needed for the launch was absent. The same review found that the Pension, Disability and Carers Service made finance and HR changes before its operational changes. Phasing matters when it protects the work; dividing an imposed date into smaller boxes does not.
The person carrying the service holds the wave
The person carrying the service holds the wave. Project offices prefer to call that person a stakeholder, because the date then remains theirs while the disruption belongs to somebody else. I have sat with operations managers who were asked to explain missed dispatches after the next phase had already been released. That arrangement is often called governance. It is a transfer of responsibility without the matching authority.
Before release day, write down the response to a missed service floor and the person authorised to use it. The response may be to correct the current wave or hold the next one; it must not become an argument while customers wait. I have watched sponsors treat a red milestone as the emergency while the operations lead was reporting a service failure. The sponsor should state in writing what evidence overrides the schedule. That is the test for a Change Management Process for Rollouts While Operations Run: the release protects the service that is still paying for the business.
The Department of Defense completed deployment of MHS GENESIS while military treatment facilities continued providing healthcare. At the final joint DOD-VA facility, teams had completed 35 tasks and milestones by March 2024, yet the Government Accountability Office found unresolved workflow and integration barriers. In the Defense Department's 2023 survey, the new system scored below the legacy systems for efficiency and quality of care. The task list was complete. It did not prove that the work was easier or safer. That is what a service floor exposes: a programme can finish its work while making Operations worse.
A fixed date can justify a short, declared reduction in service. The sponsor may make that trade-off, but must put it in writing and accept ownership of it. Operations must not discover the new service level after the project has reported success. A change management plan needs named operating limits, not merely dates and owners.
Monitor the current wave before releasing another
Monitoring is where most rollout plans become a status report travelling upward after the people who need it have finished the shift. I regard it as evidence that can reopen the decision. Monitor the assumption that mattered in the current wave, then give the result to someone who can act before the next wave goes live. I have seen a night team improvise around a failed interface while a dashboard reported that the rollout remained on track.
When dispatch slips, do not call it an adoption issue. Ask whether a named assumption for this wave failed. Its owner must then decide whether the next wave still has a case. In my experience, the answer may be a failed handover rather than a bad change, but that distinction is only useful if it changes the decision before more work is released.
Decision monitoring gives the operations lead the record needed to make that call. A Change Management Process for Rollouts While Operations Run only works while that person can use current evidence to hold the next wave. If the service limit is crossed, hold the next wave and decide again with what is now known. That is cheaper than declaring the release complete and spending months repairing the work it damaged.
You could release the next wave on schedule and leave Operations carrying the damage.
Work through your decisionNo sign-up. Just pick your decision and start.
Grant Purdy is the co-author, with Roger Estall, of Deciding (2020), and the architect of the Universal Decision-Making Method.