33. IT program management in carve-outs and PMIs • EL BANTLI

The deal team budgeted $14M of one-time IT cost for a $350M carve-out and told the IC the TSA would be gone inside 12 months.

Month 10, the separation work was “80% complete.” Month 12, the seller raised TSA fees by 20% and forced a six-month extension because the carve-out still couldn’t run payroll independently and the new identity stack wasn’t stable. The buyer spent another $9M in TSA charges and emergency contractors. Two cost programs that were supposed to start in quarter three moved to year two because finance was stuck reconciling data across two ERPs every month.

Nothing “mysterious” happened. The IT workstreams were busy. The weekly meetings were full. What was missing was program management that treated IT as a deal-critical path with explicit gates and decisions.

The primary decision is simple: do you manage IT as a delivery program with value gates and decision rights, or as a set of workstreams reporting status? Status reporting creates the illusion of control. Programs win or lose on decisions, dependencies, and cutover readiness.

What IT program management means in a deal

In carve-outs and PMIs, “IT program management” is not a heavier PMO. It is the discipline of keeping three outcomes true at the same time:

Day-1 continuity: the business runs without a spike in outages, manual workarounds, or control failures.
TSA exit and independence (carve-outs) or integration readiness (PMIs): you hit the contractual dates that drive cash and risk.
Value timing: the technology gates open when the model assumes they open (so synergy programs don’t slip a year).

If your program metrics don’t explicitly track those three outcomes, you are managing activity, not results.

The failure mode: a PMO that tracks tasks, not gates

Most IT PMOs in deals do two things well: they collect status, and they maintain a plan. Deals still fail because neither answers the executive question: “Are we on a path to make the next gate safe?”

Three patterns show up when the PMO is task-driven:

Pattern 1: Critical-path work hides inside “yellow” workstreams

The identity workstream is yellow. The ERP workstream is yellow. The data migration workstream is green. The program is “mostly on track.”

Then cutover rehearsal reveals the dependency chain nobody owned:

Data loads fail because the new identity roles weren’t defined, so batch jobs can’t authenticate.
Finance can’t close because master data is split across two legal entity models.
Support can’t triage issues because there’s no unified incident routing between old and new environments.

Mechanism: dependencies are tracked inside workstreams, not across them. The program has no single view of “what must be true by when.”

Pattern 2: Decisions drift until they become crises

The steering committee keeps “parking” decisions:

Do we build a bridge interface or replace the system?
Do we stay on the seller’s network for 6 more months or stand up our own connectivity now?
Do we accept the seller’s data extract format or force a re-cut?

Park enough decisions and you don’t reduce scope. You compress it into the last eight weeks, when every choice is expensive.

Mechanism: no decision pipeline. Decisions are treated as meeting agenda items, not deliverables with owners, pre-work, and deadlines.

Pattern 3: TSA is treated as “someone else’s contract”

The deal team negotiates a TSA. IT assumes legal owns it. Legal assumes IT owns it. Finance only sees invoices after the fact.

Then surprises arrive:

out-of-scope hours billed at premium rates
seller “project work” required for every data cut and every environment change
fee escalations triggered by delayed exits

Mechanism: TSA has no operational owner who manages consumption, disputes invoices, and runs exit readiness as a gate.

What good looks like: manage four things, not forty

Best teams don’t “track everything.” They manage four program objects aggressively and let everything else flow from them.

1) A one-page program charter that names the gates

Write the program charter like a deal document, not an IT one. One page, five fields:

Objective: “Exit TSA by month 12 while maintaining control compliance; enable consolidated reporting by Day 100; unlock $X synergy programs.”
Non-negotiables: “No material outage at go-live; month-end close must complete in ≤X days; payroll accuracy must be ≥99.9%.”
Gates (with dates): Day-1, first close, first audit, TSA exit, synergy gate(s).
Scope boundary: what is explicitly out in year one (and who approved it).
Decision rights: which decisions the program lead can make vs which require executives.

If you can’t name the gates, you can’t manage the program.

2) An integrated critical path (not a Gantt museum)

Your plan should answer one question: “What is the shortest sequence of dependencies that determines the gate date?”

In deals, the critical path is rarely “build the system.” It is usually one of these:

Data + process readiness: extracting, cleansing, mapping, and validating the few datasets that make finance and operations work.
Identity and access: defining roles, entitlements, and controls early enough to run testing and cutover safely.
Environment and connectivity: standing up networks, security tooling, and access paths that allow teams to work without violating policy.
Business change: training, SOP updates, and operational rehearsal so the business can operate on the new design.

Practical rule: every critical-path item must have a named “acceptance owner” in the business (controller, head of HR, ops lead). If IT signs off its own deliverables, you will discover the gaps in production.

3) A decision log with deadlines (a decision pipeline)

The decision log is the program’s heartbeat. It should be shorter than your risk log and treated as more urgent.

For every decision, capture:

the decision statement (binary if possible)
options and trade-offs (cost, timing, risk)
the decision owner
the latest date the decision can be made without moving the gate
what work starts the day after the decision

Most deal decisions fail because the “latest date” is not written down. People assume there is more time than there is.

4) A TSA consumption and exit scorecard

Treat the TSA like a vendor contract with a burn rate, not like a background service.

A good scorecard has three parts:

Consumption: hours used vs cap, out-of-scope charges, recurring disputes.
Exit readiness: what must be true to exit each service (e.g., “payroll runs for two cycles on new stack; reconciles to prior; controls tested”).
Seller dependency risk: single points of failure (named people, undocumented configurations, manual extracts).

This is how you prevent the classic outcome: “We planned 12 months; it took 18; nobody is surprised except finance.”

Run a two-track delivery model: stability first, value in parallel

In both carve-outs and PMIs, one mistake causes more overruns than any other: trying to run stabilization, separation/integration, and transformation as a single blended plan.

Best teams run two explicit tracks with different rules:

Track A: Stability and gate delivery

This track owns Day-1, TSA exits, and cutovers. It is optimized for reliability.

clear scope boundaries (minimum viable Day-1 and minimum viable TSA exit)
conservative change control in the 6–8 weeks before cutover
full end-to-end rehearsal (including business operations, not just IT testing)

Track B: Value capture enablement

This track owns the technology enablers that unlock synergy programs without becoming gate dependencies.

reporting layer for consolidated visibility
integrations that enable cross-sell motions
tooling that supports procurement compliance

Decision trigger: If a “value” feature becomes a cutover dependency, either move the gate or move the feature. Pretending you can do both is how you get neither.

Carve-outs and PMIs need different program mechanics

Carve-outs and PMIs both use the word “integration,” but the program physics are different.

Carve-outs: the program is a race against the TSA

In carve-outs, the clock is contractual and the seller’s incentives change after close.

Two implications for program management:

The seller is not your delivery team. Their IT staff is paid to keep the parent stable, not to prioritize your exit. Assume you must build your own capability fast.
Exit criteria beats the calendar. A date-based exit without readiness criteria is a bet. The program must define what “ready” means service by service.

PMIs: the program is a race against the business case

In PMIs, the clock is the synergy model and management attention.

Two implications:

Decision latency kills value. If it takes six weeks to decide “which CRM process wins,” value timing slips even if IT delivery is perfect.
The combined company will add scope. Business leaders will ask for “just one more change” because “we’re already touching the system.” Program management must enforce sequencing.

Decision triggers that keep programs out of the ditch

Deals are too varied for universal rules. But a few triggers are reliable because they reflect capacity and dependency logic.

If TSA is <9 months and shared identity is in scope, treat identity as the first critical path. Without it, you can’t test, you can’t cut over cleanly, and you can’t control access.
If the carve touches more than one ERP instance (or more than one chart of accounts), do not make ERP replacement a Day-1 dependency. Use a bridged close and stage the core change.
If you have >25 critical interfaces to re-point, create an “integration factory” with a single owner. Otherwise every workstream reinvents the same integration patterns and testing collapses late.
If the business cannot name acceptance owners for finance, HR, and customer operations, stop planning and fix ownership. You can’t program-manage without sign-offs that matter.

These aren’t “best practices.” They’re how you align ambition with the time and talent you actually have.

What to do in the next two weeks

If you are signed (or close to signing), two weeks of focused program setup will prevent most blow-ups later.

Write the one-page charter (program lead + deal lead). Include gates, non-negotiables, and what is out of scope in year one.
Build the integrated critical path around the next gate (program lead + workstream leads). Limit it to dependencies that move the gate date; assign acceptance owners.
Stand up the decision pipeline (program lead + exec sponsor). List the next 10 decisions, latest decision dates, and what starts the day after.
Assign a TSA owner and start the exit scorecard (CIO/CTO + finance). Track consumption weekly and run a monthly exit readiness review service by service.
Schedule one full operational rehearsal (ops lead + IT cutover lead). Pick a date now. If you can’t schedule rehearsal, you won’t be ready.

IT program management in deals is not about having more slides. It is about making the hard choices early, managing the dependency chain, and protecting gate dates like they are deal terms—because they are.