The short answer for anyone running a programme of sites rather than a single job: what scales is standardisation, and what breaks is judgement. Monitoring methods that depend on one experienced person holding the whole picture in their head work beautifully on one site and fail quietly across forty. The fix is rarely a better reporting tool. It is a smaller set of definitions, applied identically everywhere, with reporting built around exceptions rather than around narrative.
That distinction matters more in the UK now than it did a decade ago, because so much delivery has shifted from single landmark schemes to repeatable programmes: social housing frameworks, retrofit and decarbonisation rollouts, estate refurbishment, retail and branch conversions, school and healthcare batches. The government alone reports a portfolio of 227 major projects and programmes with a whole life cost of £834bn in the Infrastructure and Projects Authority annual report on major projects. Private clients run their own equivalents at smaller scale. In every case the delivery unit is no longer the site. It is the programme.
Why the Single-Site Method Does Not Survive Multiplication
On one site, progress monitoring is largely tacit. A project manager walks the job, sees the state of second fix, knows which subcontractor is behind, and writes a report that is accurate because the author already knows the answer. The report is a summary of understanding that exists elsewhere.
Multiply that by twenty and the understanding no longer exists anywhere. Twenty project managers each hold an accurate mental model of their own site and nobody holds a model of the programme. The programme office receives twenty summaries written to twenty different implicit standards, and has no way to tell which of them is optimistic.
This is not a failure of effort. It is a structural consequence of aggregating outputs whose inputs were never comparable. The programme office ends up doing archaeology on reports rather than managing delivery.
What Genuinely Scales
A short list of things survive multiplication, and they share a characteristic: they reduce the amount of judgement required at the point of data capture.
Standardised work packages. If every site breaks the job into the same package structure, the same trades, the same sequence boundaries, progress becomes addable. If each site invents its own breakdown to suit local sequencing, nothing rolls up cleanly. Package structure is the schema of the whole programme, and changing it later is expensive.
Consistent capture routines. The value of any site record comes from its regularity rather than its richness. A walk of the same route, on the same day of the week, recorded the same way, produces a series that can be compared over time and between sites. Sporadic detailed capture produces anecdotes. This is where structured construction progress tracking methods tend to earn their place on programmes, because a routine that one person maintains can be maintained identically by forty people without forty different interpretations.
A single definition of complete. Complete has to mean one thing across the programme, written down, with an owner. Plastered and taped is either complete or it is not, and the answer cannot vary by region.
Exception-based reporting. A programme team cannot read forty status reports properly every month. It can read the six that breached a threshold. Everything else should pass silently, with the underlying record available if anyone wants it.
A common data environment. One place where drawings, records, instructions and status live, with version control. Distributed storage across site-level drives is a slow-motion assurance failure.
| Key insight: On a programme, the useful question is not “how far along is each site?” but “which sites are behaving differently from the rest, and why?” That question can only be answered if every site is measured against the same definitions. Comparability is a prerequisite for exception management, and exception management is the only reporting approach that survives scale. |
What Breaks First
Narrative reporting. Prose status reports are unaggregatable by design. They are also asymmetrically optimistic, because the author is usually the person accountable for the position being described. Narrative has a place as commentary attached to a measured position. It has no place as the measurement itself.
Bespoke per-site formats. Every site that keeps its own spreadsheet imposes a translation cost on the programme office. Twenty translations a month is a full-time role producing no delivery value, and translation introduces errors.
Percent-complete as a judgement. This is the single most common failure. Sixty per cent complete means something different on a site where the assessor is counting installed quantities than on one where the assessor is estimating remaining effort. Both numbers are honest. Averaging them produces a figure that describes neither site.
Assurance by site visit. Visiting works at two sites. At forty it becomes a sampling exercise, and the sample is biased, because the sites visited tend to be the ones already flagged or the ones easiest to reach. Sites that quietly drift receive the least scrutiny.
Aggregation that averages away outliers. A programme reported at 72 per cent complete may contain thirty-eight healthy sites and two that will not complete this year. The average conceals precisely the information the programme needs.
The financial consequence of these blind spots is not abstract. Research from the Get It Right Initiative on the cost of error in construction put the direct cost of error to the UK industry at around £5 billion a year, rising to between £10 billion and £25 billion once indirect costs, latent defects and unrecorded process waste are counted, equivalent to between 10 per cent and 25 per cent of project cost. Error found late is error found expensively, and late discovery is exactly what weak programme monitoring produces.
Comparability Beats Detail
Programme teams often respond to poor visibility by asking for more detail. More fields, more frequency, longer reports. This usually makes things worse, because detail collected inconsistently adds noise rather than signal, and because the cost of collection falls on site teams who then collect less carefully.
The more productive move is to reduce the number of things measured and raise the consistency with which they are measured. A programme that tracks eight indicators identically across every site has better control than one tracking forty indicators that each mean something slightly different in each region.
There is an established precedent for this thinking in independent assurance work. The RICS practice information for lender’s independent monitoring surveyors is built around defined checkpoints and technical due diligence rather than around open-ended narrative reporting. Monitoring for a third party has always required comparability, because the reader has no site knowledge to fall back on. Programme offices are in the same position relative to their own sites.
The Roll-Up Number Is the Least Useful Output
Programme dashboards almost always lead with a single completion percentage. It is the number executives ask for and the number least capable of supporting a decision. Nothing can be done with a programme-level percentage. It names no site, no trade, no constraint, and no owner.
The outputs that actually support decisions are distributions and exceptions: which sites fall outside the expected band for their stage, which trades are consistently late across multiple sites, which delays share a common cause such as a single supplier or a single design detail. Those patterns are invisible in an average and obvious in a comparison.
Wider context helps interpret them. Where the Office for National Statistics construction output figures for Great Britain show output moving in one direction across the sector, a programme slipping in the same direction may be experiencing market conditions rather than site failure. A programme slipping when the sector is not has a specific, local, findable cause.
Practical Guidance for Programme Managers and Client-Side Teams
Fix the schema before scaling. Package structure, completion definitions and capture routine should be settled and documented before site number three, because retrofitting them across thirty live sites is close to impossible.
Write the definition of complete as a test, not a description. It should be possible for two people to apply it independently and reach the same answer. If they cannot, the definition is not finished.
Set exception thresholds explicitly and publish them. Sites should know what triggers escalation, and escalation should be routine rather than adversarial.
Audit comparability rather than progress. Periodically check that two sites reporting the same status are actually in the same condition. Drift in definitions is the quiet killer of programme reporting and it never announces itself.
Keep raw records, not just summaries. A summary answers the question that was asked last month. The underlying record answers the question asked next year, which is usually a commercial one.
Resist per-site exceptions to the standard. Every reasonable local variation is reasonable in isolation, and collectively they dismantle the comparability that makes the programme manageable.
Programme monitoring rewards discipline over sophistication. The organisations that manage forty sites well are rarely the ones with the most elaborate reporting. They are the ones whose forty sites answer the same questions the same way, month after month, so that the differences between them mean something.
