Managing several construction projects in parallel, without losing reliability
The challenge
Specialised contractors rarely work on one project at a time. Most run several sites in parallel, each with its own clients, constraints and deadlines. When this isn't managed deliberately, projects start competing for the same people and the same time. Planning becomes reactive, teams shift from one urgency to the next, and both clients and internal teams lose confidence in what will actually get done.
Where we focused
Rather than adding more tools or reporting, we worked with the team to rebuild how they planned together. We introduced a weekly team meeting, built on Lean and Agile principles, structured around three questions:
What happened last week, and what do the KPIs show?
What's coming in the pipeline, and how should it be planned?
What do the running projects need in the weeks ahead?
Each team member plans their own activities directly in this meeting, based on their own constraints and workload — planning is owned by the people doing the work, not assigned to them from a spreadsheet.
To support this, the team set up a dedicated cockpit room ("Obeya"), where all planning boards live and where the weekly meeting takes place. Having one visible, physical reference point turned planning from a series of disconnected updates into a shared picture everyone could act on.
What changed
Planning reliability improved quickly: the share of planned activities actually realised rose from 65% to 90%.
Planning and activity status became transparent to the whole team, not just to project managers.
The team aligned around client expectations from the start of each project, giving ownership to the people delivering it — for external clients as well as internal ones, using pull planning to connect workshop output to site needs.
Workload could be anticipated rather than absorbed: peaks were planned for, and low-activity days were used deliberately instead of passing unnoticed.
Project managers gained a clearer, shared view of resourcing across projects — who is needed on which site, and when.
The team moved from siloed, project-by-project work to a genuinely shared way of managing a multi-project environment.