Risks, assumptions, issues, dependencies and decisions, as at March 18, 2024. Risks are summarized here and carried in full in the Risk Register; the other four logs live on this page. The point of keeping them together is that they are not four independent lists — they are one item observed at four points in its life.
An assumption is a risk nobody has priced. A risk is an assumption that has been priced. An issue is a risk that has happened. Most logs treat these as three separate registers and lose the transitions between them — which is where the useful information is. This program tracks the conversions explicitly: when an assumption's test date arrives it either closes or becomes a risk with a score, and when a risk materializes it leaves the register and becomes an issue with an owner and a resolution date. A register where nothing ever moves between categories is not being worked; it is being filed.
1. Risk Register — summary
The full register with mitigations, owners and residual ratings is artifact 28. This page carries the movement and the top of the list.
1.1 Movement since Day 1
| Disposition | Count | What it means |
|---|---|---|
| Open or actively tracked | 18 | Scored, owned, mitigation under way |
| Closed | 4 | The exposure no longer exists — the event passed, or the condition was met |
| ⚠ Realized and moved to issues | 3 | Happened. Probability is now 1, so they leave the register entirely. |
| Identified since Day 1 | 25 | 18 + 4 + 3 |
1.2 Closed
| Ref | Risk | Closed | Why it closed |
|---|---|---|---|
| R-C1 | Regulatory approval delayed or conditioned unfavorably | Sep 2023 | Form A approved. ⚠ One condition applies and converted to R-07, accepted. |
| R-C2 | Day 1 payroll or benefits failure | Jan 2024 | Passed. HRIS and payroll migrated at month three without a missed cycle. |
| R-C3 | Platform capacity insufficient for combined volume | Nov 2023 | Load analysis confirmed headroom post-close |
| R-C4 | Landing zone not ready before the first migration wave | Jan 2024 | Accepted against ten evidenced conditions; Wave 1 proceeded |
1.3 Realized — now issues
| Was | Risk | Realized | Now |
|---|---|---|---|
| R-11 | Provider directory discrepancies between the two networks | Nov 2023 | I-01, open |
| R-14 | Trading partner re-registration slower than planned | Jan 2024 | I-02, open |
| R-16 | Discovery reveals integration scope beyond the deal model | Dec 2023 | I-03, closed at the re-baseline |
A realized risk leaves the register rather than being marked "occurred", and the distinction is not bookkeeping. A risk carries a probability and a mitigation; once the thing has happened, probability is 1 and mitigation is no longer the right verb — what it needs is a resolution, an owner and a date. Registers that keep realized risks in place with a red flag accumulate items nobody can close, because there is no closure criterion for something that has already happened. Moving it to the issue log gives it one.
1.4 Top of the open register
| ID | Risk | Exposure | Owner |
|---|---|---|---|
| R-01 | Member identity resolution materially harder than modeled | Critical | Dr. A. Ravindran |
| R-02 | Attrition of retention-covered target staff before TSA exit | Critical | D. Marchbanks |
| R-05 | Core administration cutover slips past the TSA plan date | Critical | W. Ferriday |
| R-03 | Cloud skills gap slows migration or incident response | High | B. Trammell |
| R-08 | Data warehouse go-live without demonstrated recovery | High | H. Sandifer |
The register sits in its own artifact rather than in this table, and the reason is field count. A risk needs probability, impact, exposure, mitigation, residual rating, trigger and owner to be managed; an issue needs four fields and a date. Forcing both into one log means either the risks are under-described or the issues carry empty columns. Splitting them is a practical choice, not a methodological one — and the summary above exists so that a reader of this page is not missing the top of the risk list.
2. Assumptions
Every assumption carries a validation point — the date or event at which it stops being an assumption. An assumption with no validation point is an opinion that has been written down.
| ID | Assumption | Owner | Validation point |
|---|---|---|---|
| A-01 | Target member data quality broadly as represented in diligence | Dr. A. Ravindran | ⚠ Post-close profiling, in progress. Open The last untested assumption from closing, and the largest. |
| A-02 | ACME's platform absorbs the combined volume without re-architecture | W. Ferriday | Load analysis, Nov 2023. Closed Headroom confirmed. |
| A-03 | Target vendor contracts assignable or novatable with consent | H. Castellow | Pre-close sweep. Closed Twelve change-of-control provisions; three termination rights, all resolved. |
| A-04 | No regulatory condition restricting where member data may be processed | R. Cadwallader | Form A terms, Sep 2023. ⚠ Converted A condition does apply — became R-07, accepted. |
| A-05 | Steward throughput of 100 records per day is achievable at quality | T. Vandiver | First full month of queue operations. Open |
| A-06 | Trading partners re-register within 90 days of notice | L. Marchesi | ⚠ Converted Slower than assumed — became I-02. |
| A-07 | Historical archive fits the migration window using physical transfer | D. Fontenot | Appliance rotation to Mar 2024. On track Ahead of plan. |
| A-08 | Cheatham Mutual staff remain available for knowledge transfer through exit | G. Threadgill | Monthly TSA service review. Open ⚠ Not contractually guaranteed beyond named roles. |
Two of these eight have already converted, and that is the log working rather than failing. A-04 became a live regulatory constraint the program now works within; A-06 became an issue with a resolution plan. The value of writing an assumption down is not that it turns out to be true — it is that when it turns out to be false, somebody already owns it and the date it was tested is on the record. An assumptions log with no conversions after five months of execution has almost certainly not been reviewed.
3. Issue Log
| ID | Issue | Owner | Status | Target | Closed | Resolution |
|---|---|---|---|---|---|---|
| I-01 | Provider directory discrepancies between the two networks | A. Boudreaux | Open | May 2024 | — | Remediation ahead of network rationalization; both directories reconciled against the single provider master |
| I-02 | Trading partner re-registration slower than planned | L. Marchesi | Open | Aug 2024 | — | ⚠ Externally paced. Clearinghouse exit re-sequenced two months later; no impact on core admin cutover. |
| I-03 | Discovery revealed integration scope beyond the deal-model estimate | C. Tyrrell | Closed | Jan 2024 | Jan 22, 2024 | Resolved through the January re-baseline, not through change control |
| I-04 | Landing zone security review extended by two weeks | A. Quintanilla | Closed | Jan 2024 | Jan 19, 2024 | Additional privileged-access controls added; funded from contingency |
| I-05 | Interface rework after canonical model change to coverage periods | R. Delacroix | Closed | Feb 2024 | Feb 9, 2024 | Three adapters reworked. ⚠ Root cause was a definition disagreement surfaced late. |
| I-06 | Two workstreams reporting different member counts for the same population | N. Farnsworth | Closed | Dec 2023 | Dec 15, 2023 | One was counting subscribers, the other covered lives. Definition published; both now report the same basis. |
I-05 and I-06 have the same root cause and it is worth naming, because it will recur. Neither was a technical failure — both were two organizations using the same word for different things and not discovering it until something downstream broke. Two companies combining have two vocabularies, and the words that cause trouble are not the obscure ones. They are the ordinary ones everybody is confident they understand — member, coverage period, final, closed. The canonical model exists partly to force those disagreements into the open at design time.
4. Dependency Log
Dependencies on parties the program does not control. Each names the external actor and what happens if it slips — a dependency without a stated consequence cannot be prioritized against anything.
| ID | Dependency | Owner | Status | Impact if missed |
|---|---|---|---|---|
| D-01 | Cheatham Mutual provides TSA services to contracted levels | G. Threadgill | On track | ⚠ Operations of the acquired business stop. No substitute exists. |
| D-02 | Trading partners complete re-registration | L. Marchesi | At risk | Providers lose electronic claim submission if the clearinghouse is exited first. See I-02. |
| D-03 | Rutherford Cloud Operations meets step-down boundaries | B. Trammell | On track | ACME does not reach self-sufficiency; the MSP relationship becomes permanent by default |
| D-04 | State regulator confirms no further conditions on data handling | R. Cadwallader | Met | Additional constraints would re-open the offshore boundary and the landing zone policy set |
| D-05 | Physical transfer appliances returned and ingested to schedule | D. Fontenot | On track | Archive transfer falls back to the circuit, which cannot carry it inside the window |
| D-06 | Provider contract renewal dates fall as modeled | J. Kirkendall | At risk | Network synergy re-profiles to later cycles — timing loss, not value loss |
| D-07 | Accrediting body measurement year closes on the published calendar | E. Wetherby | On track | Quality rates invalidated for the year if the reporting vendor changes mid-cycle |
5. Decision Log
Decisions that shaped the program, with who made them and why. This is the log most often skipped and the one that saves the most time.
| ID | Decision | Decided by | Date | Rationale |
|---|---|---|---|---|
| DE-01 | Mixed integration thesis rather than full absorption | Steering Committee | Jun 2023 | Absorbing everything would destroy the care management capability the transaction was partly undertaken to acquire |
| DE-02 | Preserve the target's care management platform; retire ACME's | Steering Committee | Jun 2023 | Both options consolidate to one platform, so the saving is the same either way. What differs is which capability survives. |
| DE-03 | Replace the enterprise data warehouse rather than absorb either | S. Achebe | Jun 2023 | The alternative was not "keep what we have" but "substantially rebuild one of them anyway" |
| DE-04 | Co-managed cloud operating model with a contracted step-down | B. Trammell | Sep 2023 | Fully managed never builds the capability; self-managed learns cloud during a migration under a contractual wall |
| DE-05 | Member services CRM coexists to Day 100, then absorbs | T. Ruffalo | Jun 2023 | ⚠ Knowingly accepts three months of duplicated cost to protect Day 1 operational integrity — rank 2 over rank 4 |
| DE-06 | Data stewards engaged on staff augmentation, not fixed price | C. Tyrrell | Feb 2023 | Fixed-pricing a review queue pays a vendor to be fast, and in identity matching the fast error merges two people |
| DE-07 | Plan to twelve months, not to the eighteen-month TSA maximum | Steering Committee | Feb 2023 | Margin negotiated at signing exists to absorb what discovery reveals; a plan that consumes it first has converted protection into schedule |
| DE-08 | Re-baseline rather than change-control the estimate movement | Steering Committee | Jan 2024 | Change control governs movement away from a baseline; it cannot govern the arrival of the first credible one |
| DE-09 | Eleven delivery staff added without moving the cost baseline | D. Ashmore | Feb 2024 | The work was already funded in the work packages; the roster had failed to name who performs it |
| DE-10 | Wave 1 scoped to non-production workloads | B. Trammell | Dec 2023 | The first wave proves the path, not the value. Discovering a broken runbook on claims adjudication costs the program. |
The Decision Log is the register that pays for itself, and it is the one most programs never keep. Every entry above will be questioned by somebody who was not in the room — usually six months later, usually under pressure, usually by someone senior with a reasonable-sounding alternative. Without a log, the program relitigates from scratch and the answer depends on who is most insistent that day. With one, the answer is "the Steering Committee decided this in June, here is the reasoning, and here is what has changed since — is that enough to reopen it?" That question can be answered in a meeting. The alternative takes a week.
A decision without a date and a named decider is a discussion someone remembers having. Both columns are mandatory, and "the team agreed" is not a decider — it names nobody who can be asked why. ⚠ Note that DE-06 predates closing: contracting decisions are made when the paper is signed, not when the work starts, and a log that only begins at Day 1 loses the decisions that constrained everything after it.
6. Governance
| Register | Reviewed | Convention |
|---|---|---|
| Risks | Workstream weekly; full register monthly | Maintained in artifact 28. Critical exposure is reviewed at every Steering meeting regardless of movement. |
| Assumptions | At each validation point | ⚠ Closes or converts to a risk. Never simply expires. |
| Issues | Weekly | Reported with age as well as count — a stable count with rising age is a backlog |
| Dependencies | Fortnightly | Escalated to the external party's named contact, not to the Steering Committee first |
| Decisions | Appended on decision | ⚠ Never edited retrospectively. A superseding decision is a new entry that references the old one. |
The last row is what makes this log evidential rather than descriptive. Editing a decision entry after the fact — even to correct it — destroys the only thing the log was for: a record of what was known and decided at a particular moment. A superseded decision stays on the page with its original reasoning intact, and the new one explains what changed. That is also what makes the log readable in a year, when the interesting question is not what was decided but why anyone thought it was right at the time.
Related artifacts: 1 — Integration Charter · 9 — Integration Management Plan · 20 — Application Disposition Matrix · 28 — Risk Register · 31 — Data Profiling Report · 44 — Change Control Log