Kennisbank

Which dependency holds up the rest of the plan

A Day 100 plan does not consist of a hundred separate tasks. It consists of a small number of decisions that a great deal depends on, and a large number of tasks that can only start once those decisions have been made. The choice of system for the financial administration is one such decision. The setup of reporting lines is another. As long as these are not settled, a series of other tasks waits — sometimes visibly, more often invisibly, because no one is tracking the queue.

The question "which dependencies block the rest" is therefore not a matter of drawing a plan with arrows. It is a matter of establishing which knots are truly knots, and which tasks only appear to be waiting on each other because no one has disentangled them.

What makes a dependency a blockage

Not every sequence is a dependency. Some tasks appear one after another in a plan simply because that seemed convenient, not because one needs the other. A genuine blockage meets a simple criterion: task B can only start, or only start properly, once decision A has been made. The reverse also holds — if B can also proceed without A, with a temporary assumption, it is not a blockage but a choice to wait.

That distinction is precisely why which decisions belong in the first hundred days is a question that precedes this one. A list of a hundred tasks without any distinction between blocking and non-blocking produces a plan that suggests the same pressure everywhere. That is rarely true. Usually a handful of decisions block a multiple of tasks, and the rest can proceed in parallel.

What waiting costs, and why that is not the same everywhere

Not every deferred decision costs the same. A decision about house style can wait months without anything breaking. A decision about who may sign customer contracts can bring a department that depends on it to a standstill within weeks. The question is not only what a decision blocks, but what it costs not to make it — and that cost is not the same everywhere, not even among decisions that look equally weighty on paper.

It is therefore useful to sort decisions not by importance, but by what uncertainty costs while it remains open. How do you sort decisions by the cost of uncertainty describes that sorting: not what the decision itself costs, but what it costs not to have made one yet. That distinction often changes the order. A decision that is substantively weighty but blocks little else can go to the back. A decision that seems light but leaves three teams waiting belongs at the front.

Who monitors that, and why that is not automatically anyone

A dependency that no one tracks does not become less blocking — it only becomes visible later, usually by the time the delay has already built up. Monitoring is not a task that automatically falls to one of the teams involved, because both teams only see their own side of the dependency. The team that is waiting knows it is waiting. The team whose decision it depends on often does not know that someone is waiting on it.

That monitoring is the core task of the integration office: not carrying out the work, but seeing who is waiting on whom, and keeping that visible for as long as it is at play. How that office remains workable without becoming a delaying layer itself is described in how do you keep the integration office workable. And because dependencies are often tied to individuals — one signature, another approval — it is also a question of who in the organization can actually cut through those knots, which connects to who are your key people in an acquisition.

The flip side: not everything needs to be untangled

Every dependency carries a question that is easily skipped: should this part actually be merged at all. Resolving a blockage by integrating two systems is not necessarily better than letting the blockage persist by keeping the systems separate. Sometimes the cheapest solution is not to untangle, but not to merge. That question should be asked at every knot, not as an exception but as a standard part of the assessment — otherwise integrating becomes a goal in itself rather than a means.

What a missed Day 100 date actually means, and who can then be held accountable for it, is connected to how those blockages were followed up. That is worked out in what do you do if Day 100 is not met, and who monitors that. And the uncertainty that arises while decisions remain open has a human side that does not fit into a plan: why do people leave during the unclear months describes what waiting costs people, not just tasks.

Mergerintegration.net is under construction. Anyone who wants to use the generators and the integration office as soon as they become available can sign up for the waiting list.

Once the dependencies are mapped out, the question remains who actually carries out the work once the knots have been untangled. Many of the tasks waiting on a decision — data transfer, document review, reporting setup — consist of steps that can be repeated once the rules are fixed. The work scan from FTE TO AI calculates, per task, what portion of that work can be taken over by AI, making clear where people remain needed and where capacity is freed up for the decisions that cannot do without it.