Manage IT as a delivery program with value gates and decision rights, not as a collection of workstreams reporting status. Status creates the illusion of control. Deals 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:

  1. Day-1 continuity: the business runs without a spike in outages, manual workarounds, or control failures.
  2. TSA exit and independence (carve-outs) or integration readiness (PMIs): you hit the contractual dates that drive cash and risk.
  3. 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

Color-coded workstream status can hide an unowned dependency chain. Identity and ERP can each be yellow while data migration is green, yet cutover is still unsafe when:

  • 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

Repeatedly parked decisions compress unresolved scope into the final delivery window:

  • 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?

Parking a decision does not reduce scope. It delays the choice until fewer safe options remain.

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”

When TSA ownership is divided ambiguously among the deal team, IT, legal, and finance, the agreement can produce:

  • 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

Do not “track everything.” 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 the approved date while maintaining control compliance; enable consolidated reporting by Day 100; unlock the approved 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, production becomes the first business validation environment.

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 makes an unplanned TSA extension visible early: exit readiness, not elapsed time, controls the date and exposes cost before it reaches 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.

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.

Install the operating cadence before close

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

  1. Write the one-page charter (program lead + deal lead). Include gates, non-negotiables, and what is out of scope in year one.
  2. 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.
  3. Stand up the decision pipeline (program lead + exec sponsor). List the next 10 decisions, latest decision dates, and what starts the day after.
  4. 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.
  5. 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.