Deploy into Operations

A launch date does not establish readiness

A capability can satisfy its technical acceptance criteria while the operation remains unprepared to depend on it. Staff may be unsure when to trust it, support may end before the work does, or a fallback may require capacity that no longer exists.

Treat deployment as a controlled change in how work gets done. Define the first live scope, the people and cases affected, the consequences that must remain contained and the evidence required before expanding. Include the Operating owner in the decision to begin and in every material change of scope.

A bounded release should still reveal real operating conditions. A trial that excludes every difficult handoff may demonstrate technical function without testing the mechanism that creates value.

If the capability becomes unavailable at the busiest moment, how will the work continue?

Five conditions for entering live work

Is the initial scope both limited and informative?

Choose a process segment, case type or team that contains the consequences of failure and exposes the critical dependencies. Record exclusions and the conditions that require a pause. Avoid widening the release simply because deployment is technically easy.

Can people use and challenge the capability?

Prepare the actual operators through realistic practice: ordinary cases, uncertainty, overrides and unavailable services. Explain what has changed in their role and what remains their responsibility. Provide a channel for reporting misleading outputs and unsafe or impractical workarounds without turning every report into a user-training problem.

Will the operation see a problem in time?

Monitor the agreed business outcome, quality guardrails, exception queues and support effort alongside technical reliability. Establish a comparison and record other changes that could explain the result. A faster system response can coexist with a growing approval backlog.

Can the controls be exercised under pressure?

Test access restrictions, pause and override mechanisms, incident routing and recovery. Name who is authorized to act and who covers absences. A fallback must specify how current work is reconciled, how duplicate actions are prevented and how normal service resumes.

What evidence permits expansion?

Agree the review point, minimum operating evidence and unacceptable failure types before launch. Include peak demand or relevant variations where practical; document what the observation period has not covered. A decision to expand should state the new scope and the additional obligations it creates.

Go live without losing the ability to recover

Hypothetical example, continuing the invoice opportunity.

The team deploys the assistant to one invoice category. It prepares exception requests while Finance retains payment approval. Operators can see the source evidence and route unresolved cases through the existing queue.

During a busy period, request preparation becomes faster but Procurement's unresolved queue grows. The operating owner pauses expansion and reviews the handoff. The useful response may be a change in routing or capacity, rather than a further improvement in extraction speed.

First exercise: interrupt the assistant's service during a rehearsed work period. Check that staff can identify unfinished cases, continue within existing authority and reconcile work after recovery. Record what fails in that exercise before the operation becomes dependent on the new capability.

• Is the first live scope small enough to contain consequences and realistic enough to test the operating case?
• Can operators explain when to rely on the capability and when to intervene?
• Are outcome, quality, queue and support measures visible to an Outcome owner?
• Have pause, fallback and recovery been exercised, including unfinished and duplicate work?
• Is support coverage adequate for the hours and consequences of the operation?
• Does the expansion decision depend on operating evidence, with untested conditions clearly recorded?

Choose the next commitment

Continue or expand when live evidence supports the operating case and the next scope can be supported. Hold when the observation is incomplete or review capacity is under strain. Redesign or roll back when outcomes, controls or recovery are inadequate.

Move toward ownership transfer once the operation can sustain the capability. Transfer preparation should already be underway; it is not a task to begin after the launch team leaves.

Record the review decision as Expand, Continue, Narrow, Redesign or Stop. The phase gate states the next delivery commitment; a pause, fallback or rollback remains an operational control.