Deployment
Scheduling & RACI: Planning a Change Window Minute by Minute

Category: Scheduling, Responsibility Assignment
& Implementation Planning

A production change window is one of the few moments in an engagement
where “we’ll figure it out as we go” is not an acceptable plan. This
case study looks at how a multi-hour production deployment was broken
into a minute-level schedule with explicit ownership at every step - and
how the same document doubled as the rollback plan.

The Structure

The deployment schedule assigned five fields to every activity:

Fourteen activities were scheduled this way across a single change
window, for example:

Step Team Responsible Expected Start Duration Expected Completion Action
1 Systems integrator + client agency 11:30 AM 15 min 11:45 AM Notify client of outage
2 Systems integrator 11:35 AM 10 min 11:45 AM Apply configuration changes
3 Platform vendor ops 11:45 AM 15 min 12:00 PM Stop application container
4 Platform vendor DBA 12:00 PM 120 min 2:00 PM Full production database backup
5 Platform vendor ops 2:00 PM 30 min 2:30 PM Back up config files, clear cache, restart container
6 Systems integrator 3:30 PM 60 min 4:30 PM Import configuration and reference data
7 Systems integrator 4:30 PM 10 min 4:40 PM Synchronize user/role data
8 Systems integrator 4:40 PM 60 min 5:40 PM Smoke test (core workflows, notifications, visual indicators)
9 Systems integrator 5:40 PM 120 min 7:40 PM Migrate historical data, set ID sequences, update reference
tables
10 Systems integrator 7:40 PM 20 min 8:00 PM Notify client and vendor of successful deployment

Notice that Step 4 (120 minutes) and Step 9 (120 minutes) are
the two longest single activities in the window - the database
backup and the historical-data migration. Scheduling those as the two
largest line items, rather than compressing them into a generic
“deployment” block, meant the team could see at a glance where the real
time risk in the window sat.

The Rollback
Plan Is Part of the Same Document

Four additional rows cover the contingency path, mirroring the
forward path step for step: stop the container, restore the database
from the Step 4 backup, clear cache and restart, then verify the site is
back to its original state and notify the client. Because the rollback
plan uses the same backup created earlier in the same
window, its viability isn’t theoretical - the artifact it depends on was
produced, timestamped, and confirmed just hours earlier in the same
document.

Why This Is a Reusable
Template

Three design choices make this schedule useful beyond its original
context:

  1. Person-level accountability, not just team-level.
    “The integrator will handle it” leaves room for ambiguity about who to
    escalate to mid-window. Naming the individual accountable for each step
    removes that ambiguity before the window opens, not during it.
  2. Time-boxing every step, not just the whole window.
    A single “deployment: 4 hours” estimate hides which sub-steps are the
    actual schedule risk. Per-step durations make schedule slippage visible
    in real time - if Step 4 is still running at 2:15 instead of 2:00,
    everyone downstream already knows they’re behind before it becomes a
    crisis.
  3. The rollback plan is pre-built, not improvised.
    Because the rollback steps were scheduled alongside the forward steps -
    using the same backup artifact - “what do we do if this fails” was
    answered before the window opened, not decided under pressure at hour
    three.

Takeaway for Clients

This same structure - team, individual, start time, duration,
completion, and a pre-built contingency path - applies to any bounded
change window, technical or not: a facility cutover, a policy rollout, a
vendor transition. The value isn’t the spreadsheet; it’s that every
participant can see, at any point during the window, exactly what should
be happening, who owns it, and what “on schedule” looks like.