# How to run five sites at once without living in the pickup

> Running several sites at once fails by design, not for lack of effort. What information a construction director needs, how often, and what can be delegated.

- Author: Felipe Arancibia — Sr. Product Designer
- Published: 2026-08-26
- Original: https://usepaladio.com/en/blog/control-multiobra-director/
- Productivity

---

Multi-site control is the problem of keeping visibility over several simultaneous projects with limited supervision resources. It shows up when a contractor goes from two or three sites to five or more, and it is the point where most mid-sized firms get stuck: adding sites stops improving the result.

The cause is not a lack of ability on the director's part. It is that the information mechanism does not scale.

## Why it does not scale

With two sites, the director can visit both every week and find out everything by talking. Information travels through physical presence, and it works.

With five sites, that mechanism breaks: there are not enough days in the week. And because the formal mechanism —reports— was never really needed before, it does not exist either.

The result is a recognisable pattern: **the director finds out about the problems on the site they visited, and about the other four when the problems are already big.** And since big problems demand attention, they end up putting out fires on one site while the other four accumulate new problems.

It is a self-reinforcing cycle, and it is experienced as a lack of time. It is a lack of information.

## The five numbers per site

A director does not need to know everything about every site. They need to know five things, every week, about all of them.

| Indicator | What it answers | Alarm |
|---|---|---|
| Actual vs planned progress | Is it on time? | Index below 0.90 |
| Actual vs budgeted productivity | Will it cost what was planned? | Below 0.80 sustained |
| Headcount on site vs plan | Does it have the resources? | Sustained drop |
| Lost days and cause | What is holding it back? | More than 3 a month |
| Status of the last payment claim | Is money coming in? | Queried twice in a row |

With those five per site —twenty-five numbers for five sites— a director knows where they have to go this week. Without them, they decide by intuition or by whoever shouts loudest.

## The principle: visit by exception

The change of method is this. Instead of visiting every site on rotation, **you visit the one the numbers point to.**

It sounds cold and it is not. A site that is going well does not need the director; it needs to be left alone to work. A site that has started to drift needs attention this week, not in three weeks when its turn comes round.

The condition for this to work is that the numbers arrive every week from every site. And that is where the real bottleneck sits.

## The collection problem

Asking for five numbers a week from five sites sounds trivial. In practice it turns into the same problem as always: reports arrive late, incomplete, in different formats, and somebody in the office has to consolidate them by hand.

And when consolidation is manual, the predictable happens: it is done well for a month, patchily the next, and by the third the director is back on the phone.

Three conditions for the mechanism to survive:

**The site engineer must not have to do extra work.** If the five numbers come out of the record they already keep, the report does not compete with their day. If they have to fill in another form, it will lose against the site.

**It must consolidate itself.** Any manual consolidation step is where the system dies in the third month.

**The site engineer must get something back.** If the report only serves upwards, it is bureaucracy. If it gives them back their own productivity and their own progress, it is a tool.

## What can be delegated

A good part of what consumes the director does not require their judgement:

| Task | Does it require the director? |
|---|---|
| Checking that the report arrived | No, it is an automatic alert |
| Consolidating information from sites | No, it should be automatic |
| Coordinating supply between sites | No, given visible information |
| Resolving a productivity deviation | Yes |
| Negotiating with the client | Yes |
| Deciding to move resources between sites | Yes |
| Attending a safety incident | Yes |

The first column is what takes up most of the time today, and it is the one that can be eliminated without hiring anyone.

## The advantage that appears with several sites

There is one benefit of running multiple sites that almost nobody takes advantage of: **comparing between projects.**

If the same work item yields 10 m² per man-day on one site and 6 on another, under similar conditions, there is a cause there that can be identified and transferred. It may be the foreman, the supplier, the logistics of the work face or the method.

That comparison is impossible without homogeneous data. With homogeneous data, it is the cheapest source of improvement a contractor has, and it requires no investment: the information already exists, you just need to be able to see it together.

And it also serves for estimating: actual productivity measured across five sites is an infinitely better input than a table from a manual.

## Frequently asked questions

**How many sites can one director handle?**

It depends more on the information mechanism than on the size of the sites. With a structured, reliable weekly report, five to eight is manageable. Collecting information by phone, three already saturate.

**Is an intermediate coordinator worth it?**

It can make sense, with one warning: if the problem is information and not capacity, a coordinator adds a transcription link without fixing the cause. Fix the mechanism first, then reassess the structure.

**How often should I visit each site?**

With reliable weekly visibility, frequency stops being fixed and starts depending on what the numbers show. On critical sites or during risky stages, more often; on stable sites running steadily, less.

**What do I do if a site engineer does not report?**

First check whether the report demands extra work from them. Most failures to report are design failures, not attitude failures. If the mechanism is light and they still do not report, that is a different conversation.

**Is a dashboard useful if the data arrives a week late?**

It is useful for seeing trends, not for deciding. The usefulness of an indicator is inversely proportional to its lag: progress from seven days ago still allows a reaction; progress from thirty days ago is history.