← M&A Integration Suite Closeout · Artifact 47 · how to read this suite

Lessons Learned

Download Word

Issued April 30, 2025 at program close. This is not a list of things that went wrong. The most useful lessons from this integration are structural — they are about conditions that were fixed before anyone made a decision, and about which parts of the method held when the program was under pressure. Where execution genuinely failed, that is said plainly and separately in section 7.

Contents

Part I — The Structural Lessons
  1. The estimate was constrained by law, not by effort
  2. Getting the risk right does not prevent the risk
  3. Count the levers before you need them
  4. Rank the constraints before they compete
Part II — What Held, and What Did Not
  1. Method that held under pressure
  2. The error class that no process surfaces
  3. Where execution actually failed
  4. What would be done differently
Part I — The Structural Lessons

1. The estimate was constrained by law, not by effort

The identity resolution overrun is the defining event of this program. The deal model assumed a clerical review band of 8% and the measured figure was 26%, which produced a queue that could not be worked inside the transitional services term.

The available reading is that the estimate was poor. It is the wrong one, and getting it wrong matters because it leads to the wrong corrective action.

An acquirer may not examine the target's member-level records before close. That is antitrust law, not a process shortcut. The identity assumption was therefore a Class 5 estimate made under a legal prohibition, and no amount of diligence effort, seniority or rigor could have improved it — the data required to improve it was unavailable to every person on the program until the day the transaction closed. The overrun was not predicted badly; it was structurally guaranteed to be unpredictable. The corrective action that follows is not "estimate better." It is to recognize, at charter, that one number in the deal model is uniquely unknowable, to schedule its measurement as the first substantive post-close activity rather than behind operational work, and to hold contingency and margin proportionate to a variance nobody can size in advance. A program that treats a legally blind estimate the same as a merely uncertain one has mispriced its own risk before it starts.

The transferable form: in any transaction, ask which figures in the investment case are unknowable for legal rather than practical reasons. In healthcare M&A it is member-level data quality. Elsewhere it will be something else. The list is usually short, and every item on it deserves margin rather than confidence.

2. Getting the risk right does not prevent the risk

The Risk Register dated February 5, 2024 carries R-01 — identity resolution volume exceeding the model — scored Critical, with a named owner, a sized exposure and an active mitigation. Ten weeks later it materialized almost exactly as described.

A risk register that predicts a crisis and does not prevent it has not failed. The instinct after an event is to ask why the register did not stop it, and the honest answer is that registers do not stop things — they buy earlier, cheaper responses. Because R-01 was scored Critical in February, the second steward cohort was already approved and recruiting when the profiling completed in April. The program was not deciding what to do; it was discovering that a response it had already started was insufficient on its own. That is a materially different position from being surprised, and it is worth several weeks. The test of a register is not whether the risk occurred; it is whether the response existed before the trigger did.

The corollary is uncomfortable and worth stating: a register with no realized risks is not evidence of good risk management. It is more often evidence that the register was written to be reassuring.

3. Count the levers before you need them

When the queue proved larger than modeled, three responses were obvious and none of them existed.

Apparent leverWhy it was unavailable
Add offshore capacityMember-level data cannot be worked offshore under the state contract. Not a preference — a condition of operating.
Raise throughput per stewardA faster steward produces more false merges, and a false merge is the error nothing in normal operations surfaces. The lever exists and using it is invisible harm.
Hire more onshore stewardsAvailable and already in progress, but recruitment, clearance and training run weeks the remaining window did not have.

Only time remained, and time was the most expensive thing on the program. The lesson is not that the constraint analysis was wrong — it was right. It is that this analysis was performed after the trigger, under pressure, when the answer was needed within days. The same three levers could have been examined in February, when R-01 was first scored, and the answer would have been identical. Knowing in advance that a Critical risk has exactly one response available changes how much margin you defend and how early you escalate. A mitigation column that names an action without testing whether that action is actually available is a plan for a lever that may not be there when reached for.

4. Rank the constraints before they compete

The charter ranked the program's constraints in order: the transitional services contractual maximum, then Day 1 integrity, then the synergy target, then cost, then scope. The ranking cost nothing to write and looked academic for a year.

When the crisis arrived it decided everything. The Steering Committee was not weighing incommensurable goods under time pressure; it was applying an order agreed when nobody had a stake in the answer. Cost and schedule margin were spent to protect data integrity and the contractual maximum, and scope was the first thing put down.

The value of a constraint ranking is that it is written before anyone knows which constraint will be tested. Agreed in advance it is a governance instrument; constructed during the crisis it is a rationalization of a decision already taken for other reasons, and everyone in the room knows it. The tell is whether the ranking ever produces an uncomfortable answer. This one did: it required deferring scope that two workstream leads wanted, and spending margin the sponsor would rather have returned.

5. Method that held under pressure

6. The error class that no process surfaces

Identity matching produces two error types and they are not symmetrical. A false negative leaves a member as two records — irritating, discoverable, fixable. A false positive merges two people into one identity, placing one member's protected health information under another's, adjudicating claims against the wrong history and presenting a clinician with the wrong chart.

Nothing in normal operations reveals a false positive. No claim rejects, no report fails to balance, no member calls to complain about a record they cannot see. The system reports a clean queue and a high match rate, and every operational indicator improves as the error becomes more common. This is why the false-positive rate was audited by someone outside the workstream that set the thresholds — the only measure on the program that gets worse as the thing being measured gets easier, and therefore the only one that cannot be delegated to the team whose throughput depends on it. Any program tempted to resolve a queue faster by narrowing the review band should understand that narrowing does not remove uncertain pairs; it decides them automatically, in the direction that is invisible.

7. Where execution actually failed

Three failures were the program's own, and are recorded without structural mitigation.

8. What would be done differently

  1. Profile identity in the first thirty days post-close, not the first six months. The measurement was scheduled behind platform stabilization, which was defensible and cost the program its entire response window. Nothing about the profiling run required a stable platform.
  2. Test the mitigation levers when the risk is scored, not when it fires. R-01's mitigation named actions that were partly unavailable, and nobody discovered that until the response was needed in days.
  3. Require real-data reconciliation on every non-standard interface before first cutover, not from the second wave.
  4. Specify volume-band alerting alongside arrival alerting wherever a feed is consumed.
  5. Name a sponsor for deferred scope, not just an owner. Owners accepted the deferrals; no one accepted responsibility for recovering the value, and that gap is the most likely place for it to be lost.

None of these would have prevented the overrun, and a lessons-learned that implies otherwise is doing the reader a disservice. The first would have bought roughly five months of response time; the second would have made the shape of the response clear earlier; the rest are quality improvements unrelated to the central event. The overrun itself was going to happen. What the program controlled was how much room it had when it did, and the honest lesson is that it had less than it should have — not because anyone estimated badly, but because the one measurement that could resolve a legally blind assumption was scheduled as though it were ordinary work.

Related artifacts: 46 — Closeout Report · 28 — Risk Register · 31 — Data Profiling Results · 5 — Clean Team Protocol