Kennisbank

If Day 100 is not achieved

Day 100 is a date that integration teams impose on themselves, not a law of nature. When that date approaches and the plan is not finished, unease usually follows: has something gone wrong, does the pace need to increase, does someone need to account for it? These questions are understandable but often not the right ones. The first question is more precise: which part of the plan was not achieved, and what does that mean for the rest.

Not every missed component weighs the same

A Day 100 plan consists of decisions that depend on each other and decisions that do not. If an IT migration is delayed but the rest of the organization does not wait for it, that is a different problem than when a personnel decision is delayed while five other teams are waiting for it before they can proceed. Before you conclude that Day 100 has failed, it is worth looking at which of the original decisions actually were on the critical path and who monitored that. A missed deadline on a decision that blocked nothing is not a crisis. A missed deadline on a decision that everything was waiting for, is.

This distinction is rarely made sharply in advance. Plans are written as a list of dates, not as a network of dependencies. Whoever has to figure out afterward what a delay truly costs, often discovers that the dependencies were never explicitly recorded. That is exactly why it pays to determine in advance which dependencies block the rest of the process and who watches that. Without that map, every delay is a surprise rather than an expected outcome of a known risk.

The costs of waiting are rarely distributed equally

Not all postponed decisions cost the same. A decision about a shared CRM system can wait without much being lost, while a decision about who manages the customer relationship is relevant from day one, and postponing it is felt immediately by customers and employees. The distinction between what can wait and what cannot is not fixed: it depends on the sector, the extent of overlap between the organizations, and how much uncertainty a longer wait creates for the people waiting on a decision.

To make that distinction, it helps to sort decisions by what uncertainty truly costs, not by what is easiest to tackle first. A number of teams tackle the decisions that can be made fastest first, while the most expensive uncertainty lies elsewhere. One way to avoid that is to order decisions based on what uncertainty costs per day that a decision remains outstanding. That produces a different order than a schedule that simply wants to complete everything within a hundred days.

There is also another side: not every decision belongs within a hundred days, and forcing it can cause more damage than postponing it. Some integration choices are made better after a period of observation, when it is clearer how the two organizations actually work together. It is therefore just as important to know what can wait until after Day 100 without the process stalling as it is to know what cannot wait. A missed deadline on a decision that was better taken later anyway is not a failure — it is a correction.

What a missed Day 100 truly says about the integration office

When Day 100 is not achieved, the question often does not lie with the decision itself, but with the structure that should have monitored decisions. An integration office that only keeps dates on a list only sees a missed deadline once it has already been missed. An integration office that tracks dependencies and uncertainty costs sees a delay coming and can determine in time whether course correction is needed or whether postponement is acceptable.

This touches on a broader question about how the integration office itself is organized. An office overloaded with status updates and reports loses overview at exactly the moment it is needed. It is therefore relevant to consider how the integration office remains workable and who keeps an eye on that, so that a missed deadline becomes a signal instead of noise in an overflowing inbox.

There is also never a single answer to the question of what should happen when Day 100 is not achieved: the answer depends on which decision is involved, what is waiting on it, and whether delay actually costs value or instead protects value by avoiding a hasty choice. Whoever is looking for structure at this point rather than a ready-made answer will find a detailed approach on the page that specifically addresses what to do when Day 100 is not achieved and who monitors that process.

Integrating is not always the right choice

With every missed component of a Day 100 plan comes the underlying question of whether it was even necessary to merge that component. Some systems, teams, or processes gain nothing from integration and do lose time and attention needed elsewhere. A missed deadline is a good moment to ask that question again, not just to push harder toward the original date.

To determine which part of the work around such an integration process should be done by people and which part can be supported by AI, FTE TO AI offers a work scan that calculates per task which share can be taken over. For teams that, after a missed Day 100, want to know where capacity is stalling and where it can be freed up, that is a concrete starting point.