Progress Monitoring

To value automated progress monitoring you have to be honest about how progress is measured today, which is mostly by impression. On a traditional site the person responsible walks the work, forms a judgement, and reports a percentage - per activity, per floor, or for the project as a whole. That judgement is human in every sense: shaped by what is easy to see (a finished-looking facade reads as "nearly done" even when the services behind it are barely started), by memory of what was planned, by optimism, and by real pressure. Nobody wants to be the one reporting that their trade is behind; a slightly generous number avoids an awkward meeting this week and can, one hopes, be caught up before anyone notices. Multiply that small optimism across every trade and every week and you get the classic pattern: a project that reports itself broadly on track, right up until it visibly is not.

The deeper problem is that this reporting is subjective, infrequent and hard to check. It is subjective because it is a person's estimate, not a measurement. It is infrequent because a careful walk-and-assess takes time, so it happens weekly or monthly, leaving long gaps in which reality drifts from the report. And it is hard to check because there is rarely an objective record to compare against - by the time anyone doubts the number, the site has moved on and the evidence of last month's true state is gone. The consequences are expensive. Slippage accumulates invisibly, so problems surface late, when the cheap early options for recovery (resequencing, adding a crew, chasing a delivery) have passed and only the costly ones remain. Disputes over who caused a delay become arguments about competing recollections, because no one measured. And the schedule - the project's central nervous system - is being steered by numbers that may be quietly fictional. This is the gap automated monitoring aims to close: not because site engineers are dishonest (they are usually doing their best with a hard, fast-moving job) but because impression is a poor instrument for a measurement this important, and there is finally a better one.

Automated progress monitoring is a loop that turns captured reality into a measured comparison against the plan. It has four steps. First, capture the current state of the work: site photos, a 360-degree walk, a drone flight, or a laser scan, ideally on a regular cadence (many teams do a weekly capture) and tagged with time and location. Second, understand what that imagery shows - here the computer vision of the previous lesson does its work, recognising which elements exist and in what state (foundations poured, columns up, blockwork built, cladding fixed), and reality-capture scans add measured 3D geometry of what is physically there. Third, compare that measured reality against the plan. The plan is the schedule, and increasingly a 4D BIM model - the 3D model with each element linked to its planned construction date - so the system can ask, element by element, "is this that should exist by now actually there?" Fourth, report and flag: compute percent complete per element, zone and trade, and highlight where reality is behind (or ahead of) plan.

The result is a very different kind of progress report. Instead of "level three, about 80 percent," it says "level three columns 100 percent, slab 100 percent, blockwork 45 percent against a planned 70 percent, services first-fix not started against a planned 30 percent - level three is behind, driven by blockwork and services." Because it is a measurement tied to specific elements, it is objective, repeatable and granular, and because capture is quick, it can be done often, so slippage shows up in days rather than at the next milestone review. Tied to cost through earned value thinking - value earned is value actually built - it can also give a more honest read of financial progress, not just physical. The essential point is that this only works when there is something to compare against: a reasonably complete, up-to-date model or a well-structured schedule at element level. Point the cleverest vision system at a site with no model and a vague bar-chart programme and it can tell you what exists but not whether that is behind plan - because there is no trustworthy plan to measure against. The comparison is the value, and the comparison needs both a good capture and a good plan.

When it works, automated progress monitoring gives a project several things it has always wanted and rarely had. The first is objectivity. A measurement of what physically exists is far harder to argue with than an estimate, so the weekly progress conversation shifts from "I think we're about there" to "the north wing blockwork is measured at 45 percent." That does not remove judgement - someone still decides what to do about it - but it anchors the judgement in fact rather than optimism, and it strips out the systematic flattering bias that makes projects surprise themselves. The second is frequency. Because a capture is quick, progress can be read weekly or even more often, so the gap between reality and the report shrinks from a month to days. That turns slippage from something discovered at a milestone into something visible almost as it happens.

The third, and most valuable, is early warning. The whole economics of a delay is about timing: caught early, a slipping trade can often be recovered cheaply - resequence the following work, add a crew, expedite a delivery, re-plan the next fortnight. Caught late, the same slip has cascaded into everything downstream and only expensive, disruptive recovery remains. By surfacing a divergence from plan in days, objective monitoring buys back the cheap recovery window that manual reporting quietly loses. The fourth is a durable, time-stamped record. Because every capture is dated and measured, the project accumulates an objective history of what existed when - invaluable for coordination, for honest client reporting, and, not least, as evidence in the delay and payment disputes that plague construction, where arguments usually come down to competing memories. A measured, dated as-built record turns "I recall it was finished" into "the scan of the fourteenth shows it was not." None of this manages the project for you - it does not resequence the work or negotiate with a subcontractor. It gives the human running the schedule an honest, timely, defensible picture of where the build actually is, which is precisely what the manual method fails to provide. For a chronically late industry, an honest early-warning instrument is worth a great deal.

Now the honesty, because automated progress monitoring is over-sold like everything else in construction tech. The first and biggest limit is coverage: the system only measures what the camera or scanner actually saw. Vast amounts of construction are hidden from view - reinforcement inside a pour, pipes and cables inside a wall or ceiling void, waterproofing under a screed, work in enclosed plant rooms, anything completed and covered up before the next capture. A drone measures the shape of a building beautifully and knows nothing about the electrical first-fix behind the plasterboard. So automated monitoring is strong on visible, geometric progress (structure, envelope, gross build-up) and weak or blind on the enormous amount of embedded and enclosed work - which is often exactly the work that hides the real delays. Treated as the whole truth, it can produce a new kind of false confidence: a building that looks complete from outside while the services that make it usable are far behind.

The second limit is the plan it compares against. The measurement is only as meaningful as the model and schedule behind it: an out-of-date model, a schedule that does not break down to element level, or a design that has changed on site without the model catching up will all make the comparison wrong even when the capture is perfect. Keeping the model current is real, ongoing work that many projects do not resource. The third limit is the familiar one: computer vision and scan interpretation make mistakes - misreading a state, missing an element, confused by clutter and occlusion - so the percentages carry error and must be sanity-checked, not banked. And the fourth is the boundary that never moves: monitoring measures, it does not manage. It can tell you level three is behind; it cannot decide whether to resequence, accelerate, escalate or accept the slip - those are judgement calls with cost, contract and safety consequences that belong to the project manager, the planner and the contract. In India, where many sites capture little and models are often thin or absent, the precondition - good, frequent capture and a genuine element-level plan - is frequently the real missing piece, not the analytics. The competent use: treat automated monitoring as an honest, partial instrument for visible progress and early warning, verify it, remember what it cannot see, and keep the schedule decisions with the accountable people.