In the first hundred days after a deal, the problem often appears to be a lack of decisions. More often, the problem is the sequence. A decision about the shared ERP system blocks the setup of reporting lines. A decision about who gets the commercial mandate blocks every conversation with shared customers. As long as no one names that dependency, two teams end up waiting on each other at the same time, without anyone noticing.
Not every stalled decision is a problem. Some matters can wait without the rest grinding to a halt — which ones those are, and who gets to decide that, is described on the page about what can wait until after Day 100. A blocked decision is something else: it is a decision on which other decisions depend, and which demonstrably holds those other decisions back. The difference is not always visible from within a single team. Finance does not see that its waiting on a system choice is also holding up the HR integration, because payslips are tied to the same system. Those connections only become visible once someone maps them explicitly, independent of whichever department happens to be up last.
The cost of a blocked decision is rarely a fixed amount per week. It depends on what is standing still: a pricing agreement that cannot be revised until the product portfolio has been merged, a key employee who leaves because no one gives clarity about their role, a customer who switches to a competitor because two account teams are contradicting each other. These are not figures that can be calculated in advance. They can, however, be ordered: which decision affects how many other decisions, and what is the nature of the damage if it takes longer. That ordering — by uncertainty and consequence, not by who shouts loudest — is covered on the page about sorting decisions by cost of uncertainty.
When mapping blocking decisions, there is a question that must not be skipped: should this part actually be integrated. Resolving a dependency by merging two systems is not automatically better than letting them exist side by side. Sometimes the fastest way to remove a blockage is to decide that integration at that point adds no value. That decision should not be made silently because no one asked the question; it belongs explicitly on the table, alongside the question of when and in what order.
A list of blocking decisions is already incomplete on day one of the integration, and becomes more so as more decisions are made. New dependencies arise the moment old ones are resolved: the system has been chosen, and now it turns out implementation depends on a vendor contract that is still running. Someone has to keep that map current, not as a one-off exercise in the first week, but as an ongoing task — otherwise the blockage merely shifts location. Who fills that role, and how that person prevents the map itself from becoming a delaying bureaucracy, is described on the page about keeping the integration office workable.
Blocked decisions are often the reason a Day 100 plan is not met, not because the plan was wrong, but because a dependency was underestimated. Which decisions belong in the first hundred days regardless, and who ensures they are actually made, is described on the page about decisions in the first hundred days. What to do if the deadline is not met after all — which decisions are then reprioritised and who decides that — is described on the page about not meeting Day 100. Flagging a blockage is not the same as resolving it, but without flagging, the delay remains invisible until the moment the report has to be delivered.
The generators and the integration office at mergerintegration.net structure these dependencies: they map out which decision is waiting on which other decision, and which part of the organisation is stalled as a result. This is not a track record — there is no completed engagement that this tool draws on, and none is suggested here. It is a way of sharpening the question before the delay becomes visible in figures no one can correct anymore. Those who want to work with this can sign up for the waiting list; the tool is under construction.
Some of the time lost to blocked decisions goes into work that people do manually while it could also be done automatically: merging customer lists, comparing contract terms, maintaining a dependency map that changes after every meeting. The work scan from FTE TO AI calculates, per task, what share of it can be taken over by AI, making visible where capacity is freed up that could otherwise have been spent on the integration itself.
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.