BRD-05 — Preserved and Best-of-Both Capabilities

Business requirements for the capabilities this program deliberately did not consolidate — care management preserved on the target's platform, utilization management taken best-of-both, and member services coexisting to Day 100 before absorption. Issued February 27, 2024. Scoped this way rather than by function because these three share a problem the absorption workstreams do not have.

A preserved capability has no project team, no budget line and no deadline, and that is exactly why it needs requirements. Every other workstream on this program is protected by having something to deliver: a date, a gate, a status report where a slip is visible. Preservation looks like doing nothing, so it attracts no attention, no resourcing and no reporting — and it degrades quietly while the organization watches the migrations. ⚠ Eighteen months later the capability the transaction was partly undertaken to acquire has lost its people, missed two vendor upgrades and drifted into the acquirer's operating model by default. Every requirement below is a requirement against neglect rather than against a build.

1. Business Case and Objectives

2. Scope — Three Dispositions

The three dispositions here are the ones the Application Disposition Matrix did not resolve by absorption, and grouping them this way is a deliberate choice. They could have been scoped by function — care management with clinical, member services with operations — and were not, because what they share is not subject matter but a failure mode.

Each ends the program still running outside the consolidated estate. Each therefore needs something the absorbed systems do not: a stated reason that survives scrutiny, an owner after the program closes, and recurring evidence that the reason still holds. Scoping them by function would have distributed those obligations across three workstreams, and an obligation split three ways is an obligation nobody carries.

⚠ The grouping pulls care management into a document a clinical reader would not naturally open, which is a real cost. It is accepted because the alternative — three well-placed paragraphs in three other documents — is how a preserve decision becomes undocumented within two years.

AD-07 is the row that has to survive being questioned, because it is the one where the acquirer's system is the one retired. That is uncomfortable in a way the other twenty-one rows are not: it requires ACME to accept that on this capability the smaller company was better, and it will be re-litigated by people with tenure and conviction. The requirement that protects it is FR-01 — the performance measure is stated, baselined and reported, so the decision rests on evidence that continues to exist rather than on the memory of a meeting in June.

3. Why Not Consolidate

Every other workstream on this program is consolidating something, and consolidation is the default the program is funded to deliver. So a decision not to consolidate has to survive a question the absorbing decisions never face: why is this one different, and who says so?

FR-01 answers it by making preservation evidence-based. A capability is preserved only where it can be shown better on a stated measure — a clinical outcome, a cost per case, a turnaround time — against the alternative. If it cannot be shown better on a number, it is consolidated. Not because the belief is wrong, but because a preserve decision resting on belief cannot be defended once the people who hold the belief have moved on, and it will be reopened annually by whoever is looking for savings.

The requirement cuts both ways, and that is the point. It has already removed two candidates from this document that were proposed for preservation on the strength of internal conviction and could not produce a comparison. A rule that only ever protects things is not a rule.

⚠ The measure has to be one the acquirer also accepts. A capability demonstrated better on a metric only the target tracks is not demonstrated better — it is demonstrated different. FR-01 therefore requires the comparison basis to be agreed before the evidence is produced, which is the reverse of the usual order and deliberately so.

The general rule these three share, and the one worth stating when a consolidation looks obviously cheaper: consolidation savings are real and the capability loss is usually invisible until later. A platform retirement shows up in next year's budget; a care management program that quietly stops performing shows up two years out as a medical cost trend nobody can attribute. The discipline is not "preserve when in doubt" — it is to require a measure. If the preserved capability cannot be shown to be better on a number, it should be consolidated. That is why FR-01 exists and why AD-08 splits rather than preserving wholesale.

4. Care Management — Preserve

A preserved capability does not fail dramatically. It fails in three ordinary ways, none of which generates an incident, and all three are visible in this program's structure from the day the decision is taken.

Its people leave. The staff who run a preserved capability work for the organization being acquired, in a function explicitly excluded from the consolidation everyone else is being moved into. That reads as security to a planner and as a siding to the person in it — no migration to work on, no new platform to learn, no visible future. Retention covers sixteen roles and cannot cover a whole function indefinitely, so attrition here is ordinary rather than exceptional, and it removes exactly the knowledge that justified preserving the capability.

Nobody owns it. The program has an owner for every migration and, once the program closes, no owner for the thing that did not migrate. Line management inherits it by default, alongside systems they chose and understand. An inherited capability competes for attention with owned ones and loses quietly, because nothing about it is anyone's objective.

It falls out of vendor support. A preserved platform stops receiving investment first from the program and then from its own supplier, whose roadmap is built around the customers still buying new licenses. Versions age, then fall out of support, and the upgrade that would fix it is a project nobody has budgeted — so the practical choice arrives years later as migrate now, urgently, at a cost nobody planned for.

⚠⚠ What all three share is that they are slow, and that the program is not watching. Everyone's attention is on the migrations, which have dates, owners and status reports. The preserved capability has none of those, so its degradation produces no status — and by the time it is visible, the decision that created it is two sponsors old and nobody remembers the evidence it rested on. That is what §8's ongoing obligations exist to prevent, and why they are written as recurring evidence rather than one-time acceptance.

FR-04, FR-05 and FR-06 are the requirements that make "preserve" a decision rather than an omission, and none of them is technical. A preserved platform fails in three ordinary ways: its people leave, because retention attention follows the systems being migrated; nobody owns it, because the program that decided to keep it ends and hands it to no one; and it falls out of vendor support, because upgrades are deferred while the organization is busy elsewhere. ⚠ Each is individually reasonable in the moment and together they retire the platform anyway — just slowly, without a decision, and without anyone able to point at when it happened.

5. Utilization Management — Best-of-Both

Best-of-both sounds like the safe option and is the hardest of the three dispositions to implement, because it fails at the seam rather than in either system. Each half can be individually excellent and the combination still be wrong.

The seam is where a case moves between the two: the target's authorization logic handing to the acquirer's clinical review, or a case that qualifies under one set of criteria and is worked under the other. Both halves behave correctly by their own rules. The failure is that the rules were written by different organizations for different populations and were never designed to compose — so a case can satisfy both and still be handled inconsistently, or satisfy neither and fall between them.

Which is why the requirements here concentrate on the boundary rather than on either capability: what state a case carries across, which side owns a decision when both could claim it, and what happens to cases that qualify under neither. The requirement that no case may be in flight in both systems simultaneously looks defensive and is the one that prevents the failure mode nobody detects — two reviewers reaching different conclusions about the same member, each correctly.

⚠ Best-of-both also doubles the surface that has to be preserved. The three failures in §4 apply to two platforms rather than one, and the seam belongs to neither owner. Where the evidence for best-of-both is marginal, consolidation is the better answer precisely because a single mediocre capability is easier to keep alive than two good ones joined at a boundary nobody owns.

FR-11 exists because best-of-both is the disposition that sounds best in a steering meeting and is hardest to deliver. Taking the strong half of each system is genuinely the right answer here — and it creates a join that neither vendor designed, neither team owns, and no runbook covers. Every failure in a best-of-both arrangement happens at the seam: a criteria change that the workflow does not know about, a status the workflow shows that the criteria engine does not recognize, a turnaround clock that starts in one and stops in the other. ⚠ Specifying the seam before build is the difference between a deliberate hybrid and two systems loosely stapled together.

6. Member Services — Coexist to Day 100

This disposition carries an end date, and that is the only thing separating it from the failure mode this document is most concerned with.

A coexistence decision is never taken. It is passed. Nobody sits in a room and decides to run two member service platforms permanently — the decision that produces that outcome is a series of reasonable deferrals. The consolidation is scheduled, then moved because a migration wave is late, then moved again because open enrollment is close, then again because the people who would do it are working the review queue. Each deferral is individually correct. None of them is a decision to coexist, and their sum is exactly that.

So the requirement is not that coexistence end on a date — dates move. It is that each deferral be an explicit decision with a named approver and a recorded reason, taken at a forum rather than absorbed into a schedule update. The mechanism does not prevent deferral. It prevents deferral from happening invisibly, which is the only form it takes when it becomes permanent.

⚠ Day 100 is a checkpoint, not the consolidation date, and the distinction is deliberate. The requirement is that by Day 100 the program states either that consolidation is proceeding on plan or that it is not, with a reason. A checkpoint that can only report "on track" is not a checkpoint; the value is entirely in its ability to say the other thing early enough for someone to act on it.

FR-17 is written this way because a coexistence decision point almost never gets taken; it gets passed. Day 100 arrives while the program is mid-migration, the decision is not urgent because both systems work, and the honest answer — "we have not looked at it" — is embarrassing enough that the item quietly moves to the next review. Two years later the organization is still running two member service platforms, and nobody can name the meeting where that was chosen. ⚠ Requiring the decision to be recorded including when the decision is to extend is what stops coexistence becoming permanent by omission.

7. Provider Network Analysis

FR-23 is why network synergy re-profiles rather than fails, and it is a useful thing to be able to say precisely. Rate alignment cannot be accelerated: a contract renews when it renews, and approaching a provider early to reopen terms is a negotiation conducted from a weak position. So a delay here is a timing loss rather than a value loss — the synergy lands in a later period at the same annual run-rate. ⚠ That distinction matters when reporting: a workstream reporting behind plan on cumulative capture while its run-rate commitment is intact is in a very different position from one that has lost the value, and conflating the two produces the wrong intervention.

8. Non-Functional Requirements

9. Testing and Validation

10. Acceptance Criteria

1. Every Must requirement demonstrated.
2. ⚠ Clinical performance baseline established pre-onboarding and first quarterly comparison reported.
3. No care management episode interrupted by a migration event.
4. ⚠ Named owner and budget line for the preserved platform, confirmed before program close.
5. Utilization management seam documented and tested end to end.
6. ⚠ Day 100 member services decision recorded with evidence and a named decider — including if the decision is to extend.
7. Network adequacy verified before any provider termination.
8. Preserved platform confirmed within vendor-supported versions.

11. Constraints, Assumptions and Dependencies

This document's requirements survive only as long as somebody keeps producing the evidence that justified them, and that is a dependency on a person rather than on a system.

The third signature makes the exchange explicit: the program preserves on evidence, and she produces it — the initial comparison under FR-01, and the recurring measures under §8 that show the capability is still better. It is a bargain, and stating it as one is the point. A preserve decision without that exchange is a favor, granted by a sponsor to a function that argued well at the right moment.

⚠⚠ Favors do not survive a change of sponsor. The next person in the chair inherits the cost of the preserved capability without the conversation that created it, sees a system running outside the consolidated estate, and asks why. Evidence answers that question and a favor cannot — which is why the recurring obligation matters more than the original decision, and why it is written as a requirement on this workstream rather than as an expectation of good behavior after the program closes.

12. Traceability

13. Sign-Off and Approval

The third signature is the one that makes this document work, and it is being asked of the person with the least reason to trust it. Dr. Nwachukwu runs the capability ACME chose to keep, at the company ACME acquired, and is signing a requirement that measures her program quarterly against a baseline she sets — knowing that if the advantage does not persist, the decision reverses and her platform is consolidated after all. That is a fair bargain and it should be stated as one: the program is committing to preserve the capability on evidence, and she is committing to produce the evidence. ⚠ A preserve decision without that exchange is a favor, and favors do not survive a change of sponsor.

Related artifacts: BRD-01 · BRD-03 · BRD-04 · 20 — Application Disposition Matrix · 2 — Deal Summary · 13 — Synergy Realization Plan · 26 — Quality Plan