Why “80% Complete” Is Not Enough: Rules for Measuring Progress

A package has been “80% complete” for three reporting cycles. The percentage sounds advanced, yet the handover date keeps moving. The missing information is usually what the percentage measures, what evidence supports it and which remaining items prevent the next stage from starting.

For data centre project controls, progress needs to support a forecast. A number that cannot be reconciled to quantities, completion criteria or remaining work is a weak basis for predicting readiness.

Define the measurement rule before reporting begins

For repetitive installation, measured quantities can provide a useful basis. For discrete deliverables, agreed milestones may be more appropriate. Where weighted steps are used, agree the weights and evidence in advance. Apply the same rule across reporting periods, and record any authorised changes to it.

Keep different measures distinct. Physical installation, procurement progress, expenditure and elapsed duration answer different questions. Money spent on a package does not establish that its system is ready to test, and time elapsed is not evidence that an activity is physically complete.

Separate installation from the work that follows

Illustrative example: 900 metres of a 1,000-metre containment package have been installed. Installation progress is 90% on that quantity basis. If 300 metres remain uninspected, do not report the whole package as 90% ready for dependent work. Show the installed and accepted quantities separately, with the applicable release criteria.

The same principle applies to rooms. A room can look physically finished while outstanding controls integration, records or defects prevent the relevant system test. Define readiness for the next operation rather than relying on a general room percentage.

Set a reporting cut-off and keep the evidence traceable

Agree a common status date and a practical process for collecting progress. Each reported change should identify the area or system, the quantity or step achieved, the date, the supporting record and the person validating it. Store evidence in the agreed document system rather than embedding everything in a programme file.

Resolve exceptions explicitly. If a reported completion cannot yet be verified, show its status and the required follow-up. Avoid quietly treating unverified progress as accepted work to make a dashboard look consistent.

Use progress to reforecast remaining work

Review remaining durations with the people responsible for delivery. Ask what is still required, which resources and workfronts are available and what changed during the period. A percentage update alone should not substitute for this assessment.

When work has occurred out of sequence, review the actual physical position and the calculation settings used by the scheduling tool. Preserve the update record and explain any changes to logic. Otherwise, the forecast can move because of a software treatment that nobody has discussed.

Five questions for the weekly progress review

• What precisely has been completed since the last cut-off?
• Which evidence supports that completion?
• What remains before the next trade or system can proceed?
• Does the remaining duration match the available workfront and resources?
• Which forecast milestone moved, and why?

The goal is a progress record that a planner, site manager and commissioning lead can interpret consistently. That makes a modest percentage with clear evidence more useful than an impressive percentage with an uncertain meaning.