Budget Backwards From Exit: Implemented is not the Same as Operational

October 15, 2026 - by Manan Thakkar

An implemented system that lacks operational readiness at exit becomes a diligence finding rather than an asset. Stop treating implementation and operationalization as sequential phases. Build operational readiness in parallel and plan every technology investment backward from the exit date.

Picture a project plan where every line is green: the platform is live, the vendor has signed off, and the steering committee has moved on to the next initiative. However, when someone asks who owns data quality in the new system, who gets the call when it breaks, and whether the reports leadership relies on can be trusted, nobody has a clear answer.

“Live” is a milestone on a project plan. “Operational” means the business can run the system reliably. They are not the same thing, and the gap between them is where portfolio companies quietly lose value.

I received a question on exactly this topic at the close of Synoptek’s recent session, hosted by ACG. It asked how to balance implementation timing against operationalization. My answer was that balance is the wrong frame, because it treats the two as phases competing for the same calendar.

Implementation and Operationalization are not Sequential Phases

If you wait until the system is built to think about how the business will run it, you have already waited too long.

Treating the two as consecutive phases creates a handoff at the worst possible moment. The project team is leaving, the business is least prepared to take over, and the first real test of the system happens in production, with customers and employees watching.

The alternative is to run them in parallel from the start.

What Operational Readiness Looks Like During the Build

Five things need answers while the system is still being implemented:

Process ownership.
Who supports it, and who owns it once the project team leaves?
Training.
Who needs training, and what does the plan cover?
Controls and data quality.
What data standards apply, and who monitors them?
Reporting.
Which reports will leadership rely on, and how will the team validate them?
Escalation.
What happens when something breaks, and who handles the escalation?

Then bring the people who will use the system into the final-state design decisions and the pre-go-live checklist. They find practical issues that the implementation team usually does not see. Better to hear about them before launch than after.

Safe to Go Live is Not the Same as Fully Mature

Parallel does not mean perfect on day one. You do not need every operational capability fully mature at go-live.

What you need is a clear line between two lists. The first is what must be ready for a safe go-live. The second is what can mature over the next 30, 60, and 90 days, with a plan to address over time.

I think of this as progressive operationalization. Define the operating model early. Embed readiness into role milestones. Then mature it deliberately over time. Go-live should not be the point where business adoption begins. Adoption should already be underway.

The Second Clock Running Inside Every Portfolio Company

My colleague Eric Codorniz added a point that reframes the question for sponsors and operating partners.

In a portfolio company, there is a second clock running. The exit date sets that clock, not the project plan. Here is why. A buyer’s team tests whether contracts and licenses transfer, reviews incident history, and checks how much of the business depends on one person or one vendor. Anything asserted without evidence gets discounted: a run rate described as normalized, integration work described as handled, and other unproven claims.

An operational system produces evidence: an owner, a support history, documented controls, and reports that reconcile. An implemented system produces a claim.

Eric’s conclusion was simple. Budget backwards from exit, not forward from kickoff. Work started a year out gets credited to earnings. The identical work started three months out shows up as a finding.

Where the Integration Money Actually Goes

One slide in the session drew on an EY study of 229 deals. Companies that exceeded their synergy targets invested about 8 percent more in integration than those that fell short.

Eric’s read of that number is that the extra spend is not implementation. It is operationalization: the training, the ownership, the controls, and the adoption work that turns a live system into a working one. That is his interpretation, not a finding of the study, which reports the spending gap and not what the money bought. But it points to where the discipline pays.

A Practical Test for Every System in Flight

For any system currently being implemented in your portfolio, three questions will reveal whether the system is operationally ready:

1
Who owns this system, its data, and its support after the project team leaves?
If the answer is “the vendor” or “we will figure it out,” operationalization has not started.
2
What must be true at go-live to be safe, and what is the 30-, 60-, and 90-day plan for everything else?
If there is only one list, the plan ends at launch.
3
Working backward from the planned exit date, will this be an operating asset or an open question for the buyer’s team?
If you cannot say, the second clock is already running against you.

The Question That Changes the Conversation

The question most steering committees ask is whether a system is live. The more useful question is whether it works without us.

Systems that pass that test are assets a buyer can verify. Systems that do not are findings a buyer will price. The difference is decided long before the sale process starts, by whether anyone budgeted for the work that comes after go-live.

Watch the full session on demand, including the live Q&A discussed here: Managing IT Value, Risk, and Spend Across the Deal Lifecycle.


About the Author

Manan Thakkar

Manan Thakkar

Director of Consulting

Manan Thakkar is the Director of Consulting at Synoptek. An IT professional with strong technical, analytical, and administrative skills and a self-motivated and energetic performer, Manan has a strong hold on designing systems for Cloud, Enterprise Mobility, Finance, and Risk sectors. He exudes expert consulting skills in creating sales pipelines, building strategic roadmaps, handling client discovery, and managing risk and compliance.