The dated plan, as at February 26, 2024 — five months after Day 1 and seven months before the planned TSA exit. This is the schedule the work breakdown structure is sequenced into: milestones with owners, the critical path and what actually sits on it, where float exists and where it does not, and the dependencies paced by calendars nobody on the program controls.
The critical path on this program does not run through a technical task. It runs through a queue of records being read by people. Core administration cutover cannot happen until the target's members exist correctly in ACME's systems; that requires identity resolution; identity resolution is gated by a clerical review band worked at a fixed human throughput. Every technical dependency downstream of it can be perfectly executed and the date will still be set by how many records need a human decision — a number produced by data quality nobody was permitted to measure before closing.
Table of Contents
Part I — The Plan
Part II — What Drives the Date
Part III — Control
1. Schedule Structure and Horizon
Detail is planned to the horizon where information exists. Beyond it, work has a position in the sequence but not a defensible date, and is reported as on sequence rather than on schedule.
| Horizon from this date | Planned to | Reported as |
|---|---|---|
| To end May 2024 | Task level, named owners | On schedule / behind, with variance and recovery |
| June – September 2024 | Work package level | On schedule, subject to the identity resolution outcome |
| Beyond TSA exit | Milestone level | ⚠ On sequence — position known, date derived |
2. Milestones
| Ref | Milestone | Date | Status | Owner and note |
|---|---|---|---|---|
| M-01 | Merger agreement signed | Feb 13, 2023 | Met | T. Broadnax |
| M-02 | Antitrust clearance | May 30, 2023 | Met | L. Hollingsworth. ⚠ Clearance to close, not permission to combine. |
| M-03 | State Form A approval | Sep 12, 2023 | Met | R. Cadwallader. One condition attached — data location. |
| M-04 | Closing | Sep 29, 2023 | Met | D. Ashmore |
| M-05 | Day 1 | Oct 2, 2023 | Met | R. Villanueva. Payroll, claims, eligibility, filings. Not integration. |
| M-06 | TSA payroll & HR exit | Jan 2, 2024 | Met | G. Threadgill. First service off the meter. |
| M-07 | Day 100 | Jan 9, 2024 | Met | C. Tyrrell. Stabilization complete; discovery closed. |
| M-08 | Program re-baseline approved | Jan 22, 2024 | Met | Steering Committee. Class 5 estimate replaced by Class 2. |
| M-09 | Landing zone accepted | Jan 15, 2024 | Met | B. Trammell. Ten evidenced conditions. |
| M-10 | Data profiling complete | Apr 2024 | Critical | ⚠ Dr. A. Ravindran. Sizes the review queue. Everything below depends on it. |
| M-11 | TSA general ledger exit | Apr 2, 2024 | Open | S. Beauregard. At a fiscal period boundary. |
| M-12 | EMPI match rules accepted | May 2024 | Critical | Dr. A. Ravindran |
| M-13 | TSA network & compute exit | Jun 2, 2024 | Open | B. Trammell |
| M-14 | Clerical review queue cleared | Jul 2024 | Critical | ⚠ T. Vandiver. The pacing item. Duration is a function of queue size. |
| M-15 | TSA security operations exit | Jul 2, 2024 | Open | A. Quintanilla |
| M-16 | Parallel run reconciled | Aug 2024 | Critical | B. Nkemdirim. Zero variance on outcome and amounts. |
| M-17 | Core administration cutover | Sep 2024 | Critical | W. Ferriday. ⚠ No rollback after this point. |
| M-18 | TSA exit complete | Sep 30, 2024 | Critical | G. Threadgill. Plan date. Contractual maximum is Mar 31, 2025. |
| M-19 | Data center vacated | Sep 30, 2024 | Open | H. Sandifer. Zero workloads; destruction certificate. |
| M-20 | Program closeout | Apr 30, 2025 | Open | C. Tyrrell. Residual scope to line ownership. |
3. Phase View
GOV governanceDATA identityCORE core admin
CLOUD infrastructureINTG interfacesTSA service exit
MARG margin
Track is carried by a monospace code beside every bar, not by color alone. Six categories cannot be reliably distinguished by hue inside a muted palette — and on a schedule chart red is already spoken for by the critical path. Critical bars therefore carry three signals at once: color, full opacity, and a heavier stroke. Redundant encoding costs a few pixels and makes the chart readable printed, projected, or by someone who does not see the palette the way it was designed.
4. The Critical Path
| Seq | Activity | Duration | Why it cannot be compressed |
|---|---|---|---|
| CP-1 | Data profiling | In progress | Requires the full member file loaded and standardized. ⚠ Could not begin before closing. |
| CP-2 | Match rule calibration | ~8 weeks | Thresholds are tuned against profiling output. Guessing them earlier means re-doing the queue. |
| CP-3 | Clerical review queue | Queue size ÷ throughput | ⚠⚠ The pacing item. Onshore only, fixed human throughput, staffing scales in weeks not days. |
| CP-4 | Member load & reconciliation | ~6 weeks | Cannot start until identities are resolved |
| CP-5 | Parallel run | ~10 weeks | Set by claim cycle, not by effort — must span a full month-end and payment cycle |
| CP-6 | Core administration cutover | 1 weekend | Short, and irreversible |
| CP-7 | TSA exit certification | ~2 weeks | Evidence-based; the service ends when the criteria are demonstrated |
Only one activity on this chain has a duration the program can influence, and it is not the one people reach for. Adding engineers does not shorten CP-3, because the constraint is human review of member records at a quality standard that cannot be relaxed. Adding stewards does — but recruitment, onboarding and training run several weeks, so the response is measured in months. CP-5 is set by the claims calendar. CP-6 is a weekend. A schedule recovery conversation that starts with "can we add people to the migration team" has misread which task is critical.
5. Float, and the Difference Between Slack and Margin
| Path | Float | Character |
|---|---|---|
| Cloud migration waves 1–4 | 6 weeks | Genuine slack. Waves finish ahead of the workloads that depend on them. |
| Integration layer build | 4 weeks | Genuine slack, protected because interface defects surface late |
| TSA exits (early services) | 3–5 weeks | Slack per service; they exit independently |
| Provider network rationalization | — | ⚠ Not on the critical path but not compressible either — renewal-dated |
| Identity resolution → cutover | Zero | The critical path. Any slip moves the TSA exit date. |
| TSA plan date → contractual maximum | 26 weeks | ⚠⚠ Negotiated margin, not float. See below. |
The six months between the planned TSA exit and the contractual maximum is not schedule slack, and treating it as float would be the most expensive mistake available on this program. Float is what a network calculation produces — a by-product of dependencies. This margin was bought, deliberately, at signing, by negotiating an eighteen-month term for a twelve-month plan, precisely because the identity resolution work could not be sized before closing. It is a governance asset with an owner: spending any of it is a Steering Committee decision, not a scheduling adjustment a program manager makes on a Tuesday. A plan that absorbs it silently has converted protection into schedule and left nothing for the problem it was bought against.
6. Externally Paced Dependencies
| Dependency | Paced by | Consequence of assuming otherwise |
|---|---|---|
| EDI trading partner re-registration | Each partner's own queue | Clearinghouse exit slips; providers lose electronic submission if forced |
| Provider contract renewals | Contract anniversary dates | Network synergy re-profiles to later cycles — a timing loss, not a value loss |
| Quality measurement year | Accrediting body calendar | ⚠ Switching mid-year invalidates the rates for that year |
| Broker and employer portal | Open enrollment season | Migrating during selling season is self-inflicted revenue risk |
| Open appeals cases | Case duration and regulation | A case must complete in the system that opened it |
| Employee continuation period | Merger agreement | Corporate consolidation cannot start early regardless of readiness |
| Physical transfer appliances | Shipping and ingest cycle | Archive transfer has float only because it started first |
Seven dependencies on this schedule are governed by calendars nobody on the program controls, and none of them respond to escalation. This is characteristic of health plan integration and it catches programs that build schedules from effort estimates alone. You cannot compress an externally governed cycle by adding people to it — and a plan that assumes you can produces dates that were never achievable, discovered late, usually by a workstream lead who has been reporting green against them.
7. Schedule Risk
| Ref | Risk | Effect on the date |
|---|---|---|
| SS-01 | Review queue larger than modeled | ⚠⚠ Moves M-14, M-16, M-17 and M-18 together. The only risk on this schedule that moves the TSA exit directly. |
| SS-02 | Parallel run surfaces variances requiring configuration rework | Extends CP-5. Absorbable within the margin, not within the plan. |
| SS-03 | Trading partner re-registration slower than planned | Delays clearinghouse exit; does not move core admin cutover |
| SS-04 | Retention loss in core administration knowledge | Extends configuration and parallel run; no direct substitute available |
| SS-05 | Restore test fails at a wave gate | Holds the wave. Deliberate — the gate exists to stop exactly this. |
| SS-06 | Cutover weekend overruns | ⚠ No rollback. Hypercare extends; the date does not move because it cannot. |
Five of these six can be absorbed without moving the program's hard date. SS-01 cannot, and that is why profiling is reported to the Steering Committee separately from the migration status. A schedule where every risk threatens the end date is a schedule nobody can prioritize; the value of naming the one that genuinely does is that attention goes there rather than being spread evenly across six.
8. Change and Re-baseline
| Event | Treatment |
|---|---|
| Activity slips within float | Reported as variance with cause and recovery. No change request. |
| Activity slips onto the critical path | Escalated immediately, not at the next cadence |
| Milestone date moves | Change request stating which constraint it protects and which it spends |
| Any consumption of negotiated margin | ⚠ Steering Committee decision, explicitly recorded. Never absorbed into the plan. |
| Re-baseline | Occurred once, at M-08, when the estimate matured from Class 5 to Class 2. ⚠ A re-baseline is an event, not a change request — it replaces the plan rather than amending it. |
The distinction in the last row is worth holding onto, because it is where change control is most often misapplied. The pre-close estimate was made without access to member-level data, at an accuracy the estimating standard describes as concept screening. Replacing it with a real estimate is not a change to the program — it is the first time the program had one. Change control governs movement away from a baseline; it cannot sensibly govern the arrival of the first credible baseline. Everything after M-08 is change-controlled against that plan, and the change log reconciles to it exactly.
Related artifacts: 1 — Integration Charter · 9 — Integration Management Plan · 10 — Work Breakdown Structure · 14 — Resource Plan · 22 — TSA Schedule & Exit Plan · 23 — Data Migration & EMPI Strategy · 35 — Cloud Migration Wave Plan · 28 — Risk Register · 44 — Change Control Log