Every synergy baseline has lines that fall behind. That's not a failure of the model, that's what happens when assumptions meet practice. The question is not whether that happens, but what you do the moment you see it — and whether you see it in time.
Before you fix anything, there's a question that often gets skipped: should this synergy have been there in the first place. Not every synergy on the baseline is worth pursuing. Some cost more in integration effort, attention from key people, and disruption to existing processes than they yield. A synergy that doesn't land is sometimes a signal that the assumption was too optimistic. Sometimes it's a signal that the synergy should never have been pursued in the way that was envisioned. Those two are not the same, and the distinction determines what you do next.
Every synergy amount rests on an assumption: a volume estimate, a price expectation, a procurement saving, an overhead reduction. If a synergy doesn't land, the first step is not to adjust the amount, but to look up the assumption behind it. Was the assumption too rosy, or did execution fall short of an assumption that was reasonable in itself? That distinction determines whether you revise the amount, revise the approach, or hold the owner accountable for execution. How you find and test that assumption is described in which assumption sits under a synergy amount in a buy-and-build. Without making that assumption explicit, every discussion about a disappointing synergy remains a guessing game about who's right.
A synergy without an owner is a wish. A synergy with an owner who is not held accountable is also a wish, just with a name attached. If a synergy doesn't land, the second question is who can be held accountable for that, and whether that person had the authority to make the synergy land. Sometimes the delay doesn't lie with the owner but with a dependency that hadn't been resolved — a system not yet connected, a contract still running, a team not yet merged. How ownership is assigned, and why that's often harder than it looks in a buy-and-build, is explained on who owns a synergy in a buy-and-build.
A synergy that doesn't land is less of a problem if you saw it coming three months earlier, and much more of a problem if it only surfaces at year-end close. The difference lies in how you track it. A synergy that exists only as an amount in a spreadsheet gives no signal until it's too late to steer. A synergy that is tracked by phase — planned, in progress, partially realized, stalled — gives that signal much earlier. How such a breakdown works and what steering information it delivers is described at how you track synergies with traffic lights. The point of such a system is not that it makes synergies succeed. The point is that it lets you see earlier which ones don't, so you can still adjust or decide to drop the synergy.
In a buy-and-build, synergies are often repeated across acquisitions: the same procurement gains, the same overhead reduction, assumed again and again without retesting whether the underlying logic still holds for this specific addition. A synergy that doesn't land on the third acquisition is sometimes an execution problem, but more often a sign that the underlying case grew thinner with each subsequent deal. How you build a sturdier case for a synergy in a buy-and-build than by copying the previous one is covered at how you build the case for a synergy in a buy-and-build.
A synergy that doesn't land doesn't need to be rescued. It is a valid decision to drop a synergy if the cost of still realizing it exceeds the benefit, or if holding on to the amount costs more attention than it's worth. That decision belongs just as much as the decision to push ahead. The tool that supports this kind of judgment does not keep a track record and does not claim that integration succeeds because of it — it structures the question, it does not prove experience.
A synergy that doesn't land is often connected to something that wasn't set up properly on Day 1: a system, a contract, a responsibility that wasn't nailed down at the time. What needs attention there is covered at what needs to be arranged on Day 1, and which contracts are often overlooked in that process is covered at which contracts need Day 1 attention.
A synergy that works on paper but doesn't land often comes down to people and time: who does the work now, how much time that takes, and whether that still needs to be the case after the acquisition. Anyone who wants to examine that before the synergy goes onto the baseline, or after it has stalled, can use the work scan from FTE TO AI to calculate, per task, which part of the work can be taken over by AI — a way to see whether the assumption underlying a labor synergy still holds, or whether the time someone spends on a task is shifting.
Vraag maar wat er op Day 1 moet staan, of wat integreren juist kapotmaakt.
Answers come from this site’s knowledge base. Not tailored advice, and not a scan of your company.