Coordinators think in locations, so your site software should too.

Ask a project coordinator what is happening on Level 3 and they will not open a dashboard. They will walk it, or they will ring someone who was there this morning.

The information exists. It is in the quality system, logged by the site teams doing the work. What does not exist is a single place that assembles it into an answer, so the coordinator does that part in their head, on the walk, or over the phone.

Location-based construction management organises project information around where the work is happening, rather than around lists of line items. On site, the unit of work is a level, a zone, a room or a riser. When quality data is structured the same way, a coordinator can open a location and see what is live there right now, what is due next, and what has stalled.

Below we cover where location-based thinking came from, why quality management is only now adopting it, and what changes when a location page answers questions instead of listing records.

What is location-based construction management?

Location-based construction management is a planning and control approach that treats physical location as the primary organising unit for work, rather than the activity or the line item. Instead of asking “what is the status of this task,” it asks “what is happening in this space, at what rate, and what happens next here.”

The discipline is not new. It was formalised as the Location-Based Management System in Kenley and Seppänen’s work on location-based planning, scheduling and control, and it underpins flowline scheduling, takt production and a good deal of lean construction practice. Its central claim is worth sitting with: it is not enough to plan production, it also has to be proactively controlled, using forecasts, alarms and control actions rather than status reports after the fact.

Scheduling took that idea seriously decades ago. Quality management is only catching up to it now.

ITP systems, defect registers and inspection platforms inherited their shape from the paper register. A list of items, each with a status, filterable by where it sits. That structure is correct for recording work, and the industry was right to digitise it first. It was never designed to describe a place.

The three questions coordinators ask all day

None of them have a clean answer in a system built around records.

• What is happening on Level 3?
  The records that answer it are spread across every inspection, defect and task logged in that area. Individually they are all accurate. Together they have never been assembled
• What is slipping in East Tower?
  Harder, because slipping is not a status. Nothing in any system is labelled slipping. It is a pattern across records over time.
• Where should I spend my time today?
  Hardest of all, because answering it means comparing everything against everything else.

Trackers answer the completion question, and they answer it well. Template and milestone progress, done or not done, is exactly what reporting upwards needs. Pace is a different question. A package that has not moved in three weeks and one that finished yesterday afternoon both read as incomplete, because completion status was never designed to describe momentum. That is not a gap in tracking. It is a second question that needs its own answer.

The time cost of leaving that question unanswered is well documented. FMI’s 2018 Construction Disconnected survey put 35 percent of construction professionals’ time on non-productive activity, with roughly 5.5 hours a week per person spent looking for project information that already exists somewhere in the business.

Almost none of that time is spent on anything anyone would call quality management.

Location is how the program runs

General Contractors already run program this way. Most site days start with the same conversation: which floor each service should be on today, where the concreters are up to, and who is falling behind. The program is written in levels, so the questions get asked in levels. When quality work is logged against the same locations and stages, trackers show where each trade is up to on each level, not just whether a package is complete across the building. That detail pays off twice.

The morning program check starts from what the records say rather than what people remember, and progress claims can be tested against verified work in each location instead of a percentage estimated for the whole job. A claim that hydraulics is 80 percent through Level 5 is much easier to agree when the inspections on Level 5 say the same thing.

The signals that do not belong to a line item.

A personal task list solves the part of the problem that already has a name against it. Reviews waiting on you, items assigned to you, work you own. That is useful, and most platforms do it.

It does not cover the things that will become your problem without ever being assigned to you:

• A subcontractor who has not progressed their work in this location for several days
• An inspection that has been open for weeks without movement
• A hold point coming up that needs a client representative booked in advance
• A location that has simply gone quiet

None of these belong to a single record. They are patterns across many records, in one place, over time. A task list can only show you what someone has already flagged, which is why the things nobody has flagged are the ones that hurt.

This is the difference between reactive and proactive. Reactive tells you the status of things you already know to look at. Proactive tells you what you have not thought to check.

Teams are already asking these questions somewhere else

Project teams are not waiting for the category to catch up.

They are exporting project data and running it through AI assistants to get exactly this analysis: stalled inspections, overloaded staff, skipped hold points, locations at risk. We have written before about how construction teams are connecting project data to AI assistants, and the behaviour is now common enough to be unremarkable.

It works. That is the point. The capability is no longer theoretical, which means the question is no longer whether project data can answer these questions. It is where the answer should live.

We built the Visibuild MCP because that demand is legitimate. The location overview comes from the same read of it. If teams are asking these questions, the answers belong in the product, on the page where the work gets actioned, rather than in a separate conversation once a week.

What a location overview does

When a coordinator opens a location, the page answers three questions before they touch anything.

• What needs me right now.
  Reviews waiting on them, overdue items, and work in this location that needs them to act.
• What lands in the next two weeks.
  Upcoming items and hold points, so the week gets planned rather than reacted to.
• What is slipping that nobody has flagged.
  Stalled work, quiet areas, and the location-level signals that no individual record carries.

Around those answers sits the context that makes them actionable: live activity in the location, the documents and attachments linked to that level, zone or room, and the current quality status of the work there. Documents and quality data already share a home in Visibuild, so the drawing that governs the work sits on the same page as the inspection that verifies it.

Coordinators rarely own an entire location, so the page scopes to stage and to company. A services coordinator on Level 4 sees Level 4 services, not every trade in the building. Relevance is what keeps a proactive view alive on a real project, because a page that raises things you are not responsible for gets ignored by the end of the first week.

Location is the work surface. It is not the whole data model

One caution, because it matters on complex projects.

Location is how site teams navigate and how they think day to day. It is not how quality data should ultimately be structured for handover. On a data centre, the client’s main interface with the build is commissioning, and what the commissioning agent needs on day one is system readiness and evidence completeness, with location as supporting context.

Both things are true at once. Location is the surface people work on. Commissioning readiness is the output the record has to produce. A quality platform needs to serve the first without compromising the second, which means location views are a way into the data, not a replacement for how it is organised.

Five questions to ask of your own system

• Can you open a location and know its state, or do you have to assemble it? A record store tells you what exists. A work surface tells you what is happening.
• Can it tell you what has stalled, not just what is incomplete? Done and not done is a status. Pace is a signal.
• Does it surface anything that is not assigned to someone? If not, your visibility stops at the edge of your own task list.
• Can a coordinator see only their stage and their trades? Relevance is what makes a proactive view survive contact with a real project.
• Is anyone on your team asking these questions outside the system? If they are, that is not a workaround. It is a specification for what your software should be doing.