“We lost two hours on site.”
Two hours doing what? Waiting for a drawing, unloading a late truck, clearing another trade's work or correcting an installation? How many people were affected? Did the whole crew stop? Was useful alternative work available?
Without those details, the daily report records frustration. It gives management little to change.
A delay-code system gives recurring interruptions a consistent identity. Combine that identity with timing, affected resources and evidence, and a vague explanation becomes a decision: remove this blocker, change this preparation step or investigate this recurring failure.
Start with an event, not an accusation
A site delay event occurs when an identified blocker prevents or interrupts planned work within its intended execution window.
Record the observed condition first. “Drawing revision not available to the crew at 07:00” is useful. “The office messed up again” is an allegation without a control action.
Three layers belong in the record:
| Layer | Question | Example |
|---|---|---|
| Observed blocker | What prevented this work? | Required drawing unavailable |
| Contributing condition | What may explain the blocker? | Revised scope reached the coordinator after cutoff |
| Verified cause | What did the review establish? | Revision distribution step had no assigned owner |
The example is illustrative. Its lesson is the separation: the person observing a stoppage can record the condition immediately without pretending the underlying cause is already proven.
A code identifies the type of interruption. It does not establish fault, contractual liability or who should pay.
What counts as lost time?
Keep three different quantities separate:
- Work-package delay: how long the planned activity remained blocked.
- Resource waiting: how long particular people or assets were unable to perform useful assigned work.
- Schedule effect: whether the delay changed a milestone or project completion forecast.
A package can remain blocked for two hours while its crew performs useful alternative work. The package still has a delay, but those two hours are not automatically idle labour.
Likewise, a two-hour interruption does not automatically extend the project by two hours. Sequence, available float, recovery and other work determine the schedule effect.
Do not code normal planned breaks, agreed mobilisation or scheduled inspections as unplanned downtime simply because no installation occurs during them. If an inspection unexpectedly overruns and blocks assigned work, record the excess interruption and its cause.
Use a small, stable code set
Start with codes that lead to different operating actions. Avoid a long menu of near-synonyms that each supervisor interprets differently.
| Code | Category | Use when the immediate blocker is… |
|---|---|---|
| INF | Information | A missing, conflicting or unusable drawing, instruction or technical answer |
| PRE | Predecessor work | Required preceding work or area handover is incomplete |
| MAT | Materials | Required materials are unavailable, incomplete, unsuitable or damaged |
| LAB | Labour | Required people, supervision or competencies are unavailable |
| EQP | Plant and equipment | Required tools or plant are unavailable, unsuitable or out of service |
| TRN | Transport and delivery | The transport movement or delivery arrangement has failed |
| ACC | Access and workspace | The route, workface, unloading area or laydown space is unavailable |
| SAF | Safety and permits | A required permit, isolation, inspection or critical control is unresolved |
| ENV | Weather and environment | Environmental conditions prevent the planned activity |
| CHG | Instruction and scope change | A changed, withdrawn or unresolved instruction prevents proceeding |
| RWR | Corrective-work dependency | Planned work is waiting for correction and acceptance of preceding defective work |
| UNC | Unclassified | Evidence is insufficient to assign a reliable primary code |
This is a starting taxonomy, not a universal standard. Publish your definitions, nominate a code owner and keep a version number. If a code changes meaning, preserve the historical definition so the trend remains interpretable.
Keep actual rework effort separate from waiting for rework. A crew actively correcting an installation is consuming rework hours; it is not necessarily idle. Combining both conceals the difference between correction cost and interruption cost.
Resolve the boundaries before supervisors improvise
Most inconsistent coding occurs between adjacent categories. Agree examples during setup.
MAT or TRN? If a load cannot leave because components were not available, use MAT. If the complete load was ready but the allocated transport failed, use TRN. Record other contributing conditions separately.
PRE or ACC? If another trade has not completed the prerequisite work, use PRE. If the work is complete but the access route is obstructed, use ACC.
INF or CHG? Use INF when the agreed scope lacks usable information. Use CHG when a new or disputed instruction prevents the team proceeding with the previously agreed scope.
RWR or PRE? Use RWR when the preceding work specifically needs correction before the next activity can proceed. Use PRE when the predecessor is simply unfinished.
SAF or another code? Record the immediate start hold accurately, then investigate why it arose. A permit delay caused by a late drawing can have SAF as the observed blocker and INF as a contributing condition. Do not count the same resource interval twice.
Recording a safety hold must never become pressure to bypass it. Required controls determine whether work can proceed; a downtime target cannot override that decision.
One interruption can have several blockers
Suppose an activity lacks both material and a permit. Resolving either one alone would still leave the work blocked.
Keep both constraints in the record. Allocate each affected resource interval once. Assign a primary reporting code only where the evidence and your agreed rule support it. If the controlling blocker cannot yet be established, retain a provisional UNC classification with the observed blockers attached.
When the active blocker changes, split the event into non-overlapping segments. For example, material is the verified blocker from 07:00 to 07:30; after its arrival, access alone blocks work until 08:00. Each segment has its own code and duration.
The purpose is useful attribution, not a forced answer that makes the chart look complete.
Start and stop the right clocks
Start the package-delay clock when evidence shows the blocker first prevented the planned activity. Do not automatically start at site opening if the activity was scheduled later.
For resource waiting, record each affected group's actual waiting interval. Stop that clock when the group resumes useful assigned work, including an alternative activity.
End the package-blocker interval when the blocker is removed and the package is available to proceed. Record actual restart separately if it occurs later. The time between removal and restart may have another explanation.
Pause calculations outside the defined working window. A blocker logged at 16:00 and resolved at 07:30 the next day does not imply that the entire overnight period was paid crew downtime.
Where timing is estimated, label it estimated and record the basis. Apparent precision is less useful than an honest, reviewable interval.
Worked example: a missing component
Consider an illustrative eight-person crew assigned to start at 07:00. Required components are missing. Five people wait until 07:45. Three move immediately to useful preparation work.
Record:
| Item | Entry |
|---|---|
| Planned activity | Defined erection package at Site B |
| Primary code | MAT |
| Observed condition | Specified components missing from delivered load |
| Package blocked | 07:00–07:45 |
| Affected labour | Five people, 07:00–07:45 |
| Useful alternative work | Three people completed assigned preparation |
| Closure evidence | Missing components received and checked at 07:45 |
| Actual restart | 07:50 |
The labour waiting calculation is:
5 people × 45 minutes ÷ 60 = 3.75 person-hours.
It is not eight people multiplied by the entire interruption. Investigate the five minutes between material clearance and restart separately before attributing them.
If a truck also waited 45 minutes, record 0.75 vehicle-hours. Do not add that to 3.75 person-hours and report “4.5 hours lost”. The units describe different resources.
The downtime-cost method can then convert verified resource intervals into a financial view with explicit rates and without double-counting.
Build the record once and reuse it
Use one event ID across the delay register and the daily site report. The supervisor should not have to type conflicting versions into two systems.
Capture these fields:
| Field group | Required information |
|---|---|
| Identity | Event ID, date, site, work-package ID, reporter |
| Planned work | Activity, intended start, intended output |
| Classification | Primary code, provisional/confirmed status, taxonomy version |
| Observation | Specific blocker and contributing conditions |
| Timing | Start, clearance, actual restart, working window, estimated/verified flag |
| Resources | Affected people/assets and their separate waiting intervals |
| Evidence | Relevant instruction, delivery record, inspection or other reference |
| Response | Recovery action, alternative work, accountable owner |
| Review | Accepted classification, verified cause, reviewer and review time |
| Prevention | Linked corrective action, owner, deadline and effectiveness check |
Use additional resource rows when groups have different waiting intervals. Free text is useful for context, but timestamps and affected quantities should be structured fields that can be calculated consistently.
Report measures that support decisions
Lost person-hours by primary code
Sum verified, non-overlapping person-hour intervals for each code over the same reporting period. Keep provisional events visible as a separate status.
Rank by person-hours as well as event count. Ten short events and one large interruption can call for different responses.
Labour delay rate
Recorded waiting person-hours ÷ in-scope scheduled production person-hours × 100.
Define the denominator as the hours assigned to production for the same people, sites and period. Exclude planned breaks, training and other planned nonproduction time consistently. Retain the allocation baseline and identify approved additions such as extra shifts separately.
A zero denominator means N/A. Explain incomplete coverage rather than treating unreported waiting as zero.
Delay events per work package
Confirmed delay events ÷ work packages executed in the period.
Publish the numerator and denominator alongside the rate. Changes in package size or event-splitting rules can alter the figure without changing performance.
Classification completion
Events with reviewed classifications ÷ events requiring review in the period × 100.
Pair this with the open UNC count and age. The aim is to resolve uncertainty through evidence, not to make supervisors choose an unsupported code.
Recurring causes
Track repeat verified causes by work type, location and responsible process. A repeated MAT code identifies a category. Repeated incomplete picks caused by an absent load-verification step identify something management can fix.
Turn the weekly chart into an action
A ranked chart is only the beginning. Select a material recurring cause and inspect the underlying events.
Check whether the time and resource counts are sound. Establish the process failure. Assign one preventive action with an owner and deadline. Then test whether the same cause recurs after implementation under a comparable workload.
For example, a verified pattern of incomplete loads may lead to a package-based pick check before dispatch. Its effectiveness is tested through later completeness records and delay events, rather than by marking “staff reminded” as closed.
Use the 48-hour look-ahead to move repeat blockers into earlier readiness checks. For delivery-related events, connect the corrective action to the dispatch board, where the vehicle, load, destination and delivery slot can be confirmed together.
Avoid three misleading conclusions
“The largest code is the worst department.” Categories identify interruption types. They do not establish accountability without reviewing the evidence and dependencies.
“The new process increased delays.” Better reporting can initially reveal events that were previously invisible. Check recording coverage and definitions before interpreting a higher total.
“Every labour variance is a delay.” Output mix, estimating assumptions, productivity, rework and scope change can all affect hours. Reconcile delay records with planned versus actual labour hours before claiming that waiting explains the full gap.
Implement it over five working days
On day one, agree the code definitions, event boundaries and working-time rules. Test them against a handful of past examples and resolve disagreements.
On days two and three, record current events on a small, defined scope. Check that separate supervisors classify the same facts consistently and that resource intervals can be reconstructed.
On day four, review provisional classifications, missing evidence and duplicate intervals. Correct the records while preserving the original entry and review trail.
On day five, produce the first ranked view with its reporting coverage. Choose one verified recurring cause and assign a specific preventive action. Expand the system when the record is usable, rather than waiting for a perfect dashboard.
The OperatorOS Principle
Name the interruption clearly enough that somebody can change what happens next.
A useful delay record identifies the work, the blocker, the affected resources, the interval and the evidence. A useful review connects that record to a specific process change.
“We lost time” describes an outcome. Consistent delay codes make that outcome traceable, measurable and actionable.