The First 90 Days of an M&A Separation Office: What It Should Control, Not Just Report

By the MeridianCogent team — this perspective draws on published integration governance research across the industry, with our own view on what a separation or integration office should actually control.

Most separation and integration offices produce excellent reports. Weekly dashboards, RAG status by workstream, a Day 100 milestone tracker. What's less clear, on a lot of programs, is what the office actually controls versus what it's simply narrating back to the people who did the work.

That distinction matters. A reporting function tells leadership what happened. A control function determines what happens next — which items get escalated, which claimed statuses get challenged, and which decisions can't move forward until specific evidence exists. The difference is between an office that primarily reports problems once they're visible and one designed to expose them early enough for leadership to actually intervene.

Build the office before close

PwC's own description of its integration and separation work is explicit that this starts pre-close: defining the governance, plans, and coordination needed to move from strategy to execution, aligning teams on priorities and dependencies from the outset rather than assembling that structure reactively after the deal completes. If the handoff from deal team to separation office is weak, important context — the assumptions behind the value case, unresolved commitments made during diligence, the reasoning behind earlier decisions — can be lost precisely when execution begins and that context is needed most.

What the office should actually own

A useful test: for each of the following, is the office genuinely in control of it, or does it just collect updates about it from people who are?

The master plan. McKinsey's own description of its integration work centres on exactly this: a jointly-led integration office creating a comprehensive plan to manage key risks and interdependencies and speed up integration activities — not a rolled-up summary of individual workstream plans, but the single structure that connects them and sequences the whole program. If workstreams maintain their own plans independently and the office only aggregates them into a dashboard, the office is reporting, not controlling.

Readiness evidence, not self-reported status. A workstream marking itself "on track" is a claim. The office's job is to challenge it: is the owner still correct, has the deadline actually moved, what happens if this slips, and can the team show the next concrete deliverable and the specific standard it needs to meet — or just a general sense that things are progressing. "In progress" is not a useful status unless it comes with acceptance criteria attached.

The decision log. Who decided what, when, and on what basis. This is the record that lets someone eighteen months later understand why a commitment was made, and the mechanism that stops the same disputed question from being re-litigated by three different workstreams independently. A useful, concrete version of this is a decision-rights matrix answering three questions for any material call: who recommends, who decides, and when does it escalate.

The escalation and issue-resolution path. A predefined escalation path reduces the time between identifying an issue and putting the right decision-maker behind it — particularly when a problem crosses functional boundaries, where the natural instinct is for each function to look for a fix inside its own workstream first.

Cross-workstream dependencies. The connective tissue between functions, which by definition belongs to none of them individually. If nobody owns this explicitly, it doesn't get tracked at all, because every workstream is reasonably focused on its own scope.

The value-capture register. McKinsey's own description of its integration practice names this as a distinct capability alongside master planning: building a consistent financial baseline, setting synergy targets, and tracking execution against them. A program can hit every operational milestone on the master plan and still miss the economics the transaction was actually built around, if nobody is holding the connection between initiative, owner, milestone, and financial outcome. A synergy shouldn't be logged as realised because the associated action was completed — it needs a baseline and evidence that the economic outcome actually occurred.

A phased approach to the first 90 days

There's no universal sequence — the right cadence depends on transaction structure, regulatory timing, and complexity. But as an operating model, it's useful to divide the period into a pre-close setup phase and three post-close phases.

Pre-close: build the control system. Decision rights, the master plan structure, and the reporting cadence all need to exist before close, not be assembled under pressure once integration activity has already started.

Days 1–30: establish control. The priority in the first month is authority, not activity. Decision rights need to be explicit and known. The master plan needs to exist as one structure, not five separate workstream plans nobody has reconciled. The reporting cadence needs to be locked before integration pressure actually peaks, because establishing rhythm mid-crisis is how calendars turn to chaos exactly when discipline matters most.

Days 31–60: expose dependencies. Genuinely cross-cutting dependency reviews, not five parallel single-function check-ins, surface the connections that individual workstream reports cannot see by design. This is also where the office should actively challenge claimed statuses rather than simply recording them.

Days 61–90: drive readiness and exceptions. By this point, the office should have enough control over the program to run formal readiness and exception reviews rather than simply collecting status — checking major critical-path dependencies, unresolved decisions, the quality of reporting, the evidence behind key milestones, and the value-capture assumptions against real financial evidence rather than an assertion that synergies are probably on track.

The MeridianCogent readiness test

For any material milestone, we find it useful to ask four separate questions rather than one:

Complete — has the work actually been performed.

Evidenced — is there objective proof it works, not just an assertion that it does.

Unblocked — are its prerequisites genuinely resolved, not just scheduled to be.

Ready — can the downstream outcome this was supposed to enable now actually happen.

Most status reporting only ever answers the first question, because it's the easiest one. The other three require knowing what depends on what, which is exactly the kind of visibility a flat status report doesn't provide on its own.

The test that separates control from reporting

For any item the office is tracking: if it were marked complete today, would the office know what evidence supports that claim, what it unblocks, and who has actually accepted the outcome — or would it simply have the workstream's own green status to go on? A control function has a real answer to that question for the items that matter most. A reporting function only finds out if someone happens to mention it.

Lessons learned

Build the control system before close, not after. The context and reasoning behind commitments made during diligence are easiest to lose exactly at the handoff from deal team to separation office.

"In progress" needs acceptance criteria attached, or it's a placeholder, not a status. Push every claimed status for the next concrete deliverable and the specific standard it has to meet.

Cross-functional dependency review is the office's actual job. It's the one thing no individual workstream is positioned to do for itself, because dependencies sit between functions by definition.

Operational execution and economic execution are not the same thing, and tracking one doesn't guarantee the other. A completed milestone and a realised synergy are different facts, and only the second one is what the deal was actually underwritten on.

Control means the office would know what's behind a claimed status. Reporting means it would only find out if someone happened to mention it.

Sources: McKinsey & Company, "Integration" (M&A capabilities overview — master planning and value capture); PwC, "Integration and separation management" (pre-close governance and planning); Umbrex, "Governance & Integration Management Office (IMO)"; Dealmaker Wealth Society, "Post Merger Integration Checklist for Your First 100 Days."