A Day 100 plan is usually put together with care. The question of who tracks it afterward gets less attention. There is a list of decisions, a sequence, a few owners. Then everyone gets to work. What is often missing is not the plan, but the place where it becomes visible that the plan is falling behind before it is too late.
That is not a matter of discipline. It is a matter of where the information comes together. If three workstreams each track their own progress, no one sees the pattern that emerges when they are waiting on each other. That exact pattern is usually the reason a hundred days become a hundred and fifty.
Without a place that holds all decisions and their status together, one of two things usually happens. The first: decisions quietly slip, without anyone explicitly deciding to postpone them. The second: people make a decision themselves because no answer comes, and that decision deviates from what the integration team actually wanted.
Both are costly, but in a way that does not show up in a progress report. The cost lies in ambiguity: customers who do not know who their contact person is, teams doing double work because systems have not been merged, and key people leaving because no one told them what their role would be. For exactly that reason, which decisions belong in the first hundred days provides not only a list, but also a breakdown of what really needs to be resolved in that period.
Not every decision carries the same weight, and not every decision needs to come first. Some decisions cost little if they fall a few weeks later. Others block everything around them for as long as they remain open. The difference lies in what comes to a standstill while there is no answer — that is the subject of how do you sort decisions by cost of uncertainty, which treats uncertainty itself as a cost item rather than an inconvenience.
An example: a decision about merging a sales team can often wait until week six. A decision about who is authorized to sign customer contracts cannot, because every week of delay means someone is improvising. Anyone who puts those two decisions on the same list without distinction risks giving priority to the wrong decision.
There is usually a small group of decisions that do not cost much in themselves, but do determine whether other decisions can be made. An IT migration that has not been planned holds back the merging of customer data. An organizational structure that has not been confirmed holds back appointments. Which dependencies block the rest describes how to recognize those bottlenecks before they become visible as delay.
It is this category that benefits most from monitoring, precisely because the damage only shows itself late. A delayed bottleneck is often only noticed at the moment when three other decisions have already stalled.
The question of who monitors is an organizational question, not a technical one. An integration office is nothing more than the place where decisions, owners, and status come together, so that someone — often an operating partner or a member of the deal team — can see where things are getting stuck without having to question every team separately. How that place remains workable without becoming a bureaucratic layer itself is described in how do you keep the integration office workable.
Meanwhile, the people side remains a separate source of risk. Key people who carry day-to-day continuity are not always the ones with the most visible title, and who are your key people in an acquisition helps map that group before they leave out of uncertainty. Because ambiguity does not only affect decisions, it also affects people: why do people leave during the unclear months describes that departure is rarely about the decision itself, but about its absence.
The generators for synergy baseline, Day 1 plan, and Day 100 plan, together with the integration office, provide structure: a decision list, benefit tracking, and visibility into dependencies. They do not tell you what to decide, and they do not guarantee a timeline. What they do is keep visible the question of whether something actually needs to be integrated, or whether keeping it separate preserves more value. That question belongs with every component, not as an exception but as a permanent part of the consideration.
This tool is under construction. Anyone who wants to use it already can join the waiting list; there is no completed engagement to point to, only the tool itself and the structure it offers.
Much of the work in the first hundred days consists of tasks that can be broken down: tracking statuses, flagging dependencies, compiling reports from separate sources. For anyone who wants to know which part of that work can realistically be handed over to AI and which part remains human work, the work scan from FTE TO AI calculates that per task, so that the deployment of time and attention in the integration office can be focused on the decisions that need it most.
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.