A construction company is not a factory with a fixed line and a fixed team. The largest part of the organization is spread across projects that each have their own schedule, their own subcontractors and their own risks. Merging two construction companies does not mean placing two organizational charts side by side, but combining two sets of ongoing projects that each have their own life cycle and are finished at their own moment. Some projects have just started, others are nearly completed. That asynchronicity makes it difficult to choose a single integration moment: there is no one day on which everything stands still and can be transferred.
Add to that the fact that the value of a construction company lies largely in relationships that don't appear on the balance sheet: subcontractors who have been working together for years, suppliers who know how a particular team works, supervisors who plan hired equipment per project. Those relationships are difficult to copy and easy to disrupt. An integration that runs through them unnoticed can do more damage than an integration that deliberately leaves a number of things as they are.
Every construction company has its own way of tracking projects: how additional work is recorded, how progress is measured, how work in progress is valued. Those systems rarely connect seamlessly, and an incorrect link directly affects revenue accounting. For this kind of bottleneck, the distinction between what was agreed before the deal and what actually happens after the deal matters: the synergy baseline records where the assumptions come from, so that a deviation can later be traced instead of disappearing into an average.
Both companies have a network of subcontractors, and that network partially overlaps. Two plumbing companies that both work with the same subcontractor may end up competing with each other for that subcontractor's capacity once they are under one roof. At the same time, it is not a given that you can simply deploy subcontractors from one side on projects from the other side: price agreements, quality level and way of working differ. This kind of dependency needs to be mapped out early, not as an isolated observation but as part of a list showing what is waiting on what. Anyone comparing this with the bottlenecks in wholesale will see a similar problem with supplier relationships, only without the project-based uncertainty that characterizes construction.
Equipment is often partly owned, partly rented, and its scheduling runs per project. Merging two vehicle fleets and two sets of crane rental contracts only produces something worthwhile if the scheduling logic also comes together, and that is a different kind of work than adding up assets. A Day 1 plan that ignores this risks equipment being double-booked or left unused. A Day 100 plan can be more concrete here, because by then there is more insight into which projects can actually use combined equipment.
Construction companies work with safety protocols and certifications that are tied to a specific way of working. Merging teams without first comparing those protocols can lead to a mistaken picture of what can be standardized. Some processes differ for a reason that has to do with a specific type of project, and that reason does not disappear because a merger has taken place. For every process on the decision list, the question of whether merging actually yields a benefit should therefore come first, before looking at how. That is the same question that recurs with manufacturing, where production lines likewise cannot simply be merged without losing specific expertise.
Part of the workforce is tied to a project rather than to a fixed department, which means an integration plan must take fluctuating availability into account. Anyone who announces a new reporting line on Day 1 while a crew happens to be at an external site risks the message only properly landing weeks later. That differs from sectors with a fixed physical office, as seen in the bottlenecks in professional services, where communication is easier to organize at a single moment.
The synergy baseline, the Day 1 plan and the Day 100 plan are generators, not an executed process: they structure the questions that in a construction integration are often asked too late, such as which subcontractor relationship gets priority and which equipment is waiting on which decision. The integration office keeps track of which synergy is actually realized, which dependencies are still open, and which part is deliberately not merged because it yields nothing. The latter is more the rule than the exception in construction: not every process should be merged, and the decision list exists to make that choice visible rather than letting it happen implicitly.
This tool is under construction. Anyone who wants to use it once it becomes available can join the waiting list.
An integration in construction inevitably brings with it a stack of administrative work: merging reports, tracing project statuses, comparing subcontractor contracts. Much of that work consists of fixed, repeatable steps, and that is exactly what the work scan from FTE TO AI looks at: for each task it calculates what portion of it can be taken over by AI, making clear which work remains for people and which work does not need to be done manually again after a merger.
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.