The Crew Lost Four Hours. What Actually Caused the Loss?
Lost time only becomes useful management information when the project identifies the real cause. Waiting for design, material, access, plant, predecessor work or instruction requires very different action.
The short answer
Lost hours only become useful when the project understands what actually caused them.
“Waiting” is not a cause.
A crew may be waiting for design, material, access, plant, predecessor work, instruction or another trade.
Each cause requires a different management response.
The objective is not to allocate blame. It is to make recurring production loss visible enough to remove it.
Four lost hours can mean six different problems
A site report may say a crew lost four hours.
That number creates concern.
It does not create understanding.
If the crew waited for a revised drawing, the project has an information-flow problem.
If it waited for material, the issue may sit in procurement or logistics.
If it waited for a crane, the problem may be plant allocation.
If it waited for another trade to finish, the issue may be sequence or lookahead reliability.
One number can describe completely different management problems.
This is why lost-time recording needs a credible cause.
Cause classification should be simple enough that the site will actually use it
There is a temptation to create detailed delay codes.
Too much detail can make the system unusable.
The site needs a small number of categories that reflect real management actions.
For example:
- design/information;
- material;
- access/workfront;
- plant/equipment;
- predecessor/interface;
- instruction/approval;
- rework/quality;
- external condition.
The exact list should suit the contractor.
The important point is consistency.
If similar events are classified differently each day, trends become meaningless.
The recorded cause should match the evidence
Delay classification can become political.
Different parties may prefer different explanations because the commercial consequence changes.
That is why contemporaneous evidence matters.
What was the planned activity?
When did the crew become unable to continue?
What condition was missing?
What alternative work was available?
When was the issue resolved?
A few factual points can make the cause much clearer.
The goal is not to produce a legal case every day.
It is to prevent production data from becoming opinion.
The broader site-production model becomes stronger when lost hours can be trusted.
Waiting is sometimes a symptom, not the root cause
A crew may record “waiting for material”.
That can be true without being the full explanation.
Why was the material late?
The purchase order may have been late because approval was late.
Approval may have been late because the design changed.
The immediate cause and root cause can be different.
Management needs both levels when the loss repeats.
The site report can capture the operational cause quickly.
A weekly or periodic review can then investigate recurring patterns more deeply.
This prevents teams from endlessly solving symptoms.
Not all lost time becomes programme delay
This distinction is important.
A crew can lose hours and the project can still protect the overall programme.
Alternative work may exist.
Float may absorb the loss.
Another sequence may recover it.
The lost hours still have cost.
That means production and programme should not be confused.
A project can remain “on schedule” while consuming significant unplanned labour and plant.
This is one reason productivity control matters even when milestone dates remain healthy.
Programme status answers a time question.
Lost hours answer an efficiency question.
Both matter.
Recurring small losses can be more expensive than one obvious delay
This is where cumulative analysis matters. A twenty-minute recurring wait may never trigger a formal delay event, yet over hundreds of labour hours it can consume meaningful margin.
The project should not need a dramatic incident before it acts. Repetition itself can be enough evidence that the production system needs attention.
Large disruptions attract attention.
Small losses often do not.
Twenty minutes waiting every morning for access.
Thirty minutes moving material because storage is poorly located.
Short interruptions while another trade passes through.
These events can become normal.
Over weeks, the cumulative hours are substantial.
A good lost-time view helps management see these repeated patterns.
The project can then decide whether changing the process is worth the effort.
Often the best productivity opportunities are not dramatic.
They are recurring friction that everyone has learned to accept.
The useful conversation is “what should change?” not “who caused it?”
Blame can make lost-time data less reliable.
If teams believe every recorded hour will be used against them, they become defensive.
The data gets argued over rather than used.
A stronger production culture focuses first on removal.
What recurring condition is consuming time?
Who can change it?
What will the site do differently?
Commercial responsibility can still be addressed where necessary.
But the operational value comes from preventing the same loss tomorrow.
That is what turns delay data into management action.
Cause data can also improve the conversation between projects and head office.
If several projects repeatedly lose time for the same reason, the issue may require a business-level response.
Repeated material waiting may indicate procurement lead-time assumptions need revision. Repeated access conflict may point to weak logistics planning. Repeated design waiting may show design coordination is starting too late.
The individual site sees one delay.
The business can see a pattern.
That is where consistent classification becomes especially valuable: it turns local production loss into evidence for wider operational improvement.
Delay-cause data becomes powerful when the same issue appears across several packages
One lost-time event may be anecdotal.
A repeated pattern is management information.
If three different trades lose hours waiting for the same access route, the project has an access problem.
If several packages repeatedly wait for late technical information, design flow may be the constraint.
If crews across different areas lose time waiting for one shared plant resource, capacity or allocation may be wrong.
This is why consistent cause classification matters.
It allows management to aggregate production loss across the project without losing the operational meaning.
The same principle can apply across multiple projects.
A contractor may discover that one type of issue appears repeatedly in different jobs.
That evidence can change tender assumptions, standard logistics planning, procurement strategy or design coordination.
The site record then contributes to organisational learning.
There is also a cultural benefit.
When teams can see that a cause is systemic, the discussion becomes less personal.
Instead of arguing about which crew “performed badly,” management can see that several crews were exposed to the same condition.
That makes corrective action easier.
Good lost-time data should reduce blame and increase clarity.
The objective is not to prove who caused yesterday’s loss.
It is to make tomorrow’s loss less likely.
A useful review can therefore rank causes by cumulative hours as well as by individual severity. The largest opportunity may be a recurring small loss that has never looked urgent on any single day.
That perspective helps management target process improvements with a measurable production payoff.
A useful lost-time review should also consider frequency alongside total hours. One six-hour event is highly visible. Twelve separate thirty-minute interruptions consume the same time but may never attract equivalent attention.
Frequency often points to process weakness. If the same small interruption appears every shift, the project has a repeatable opportunity to improve production rather than an isolated event to explain.
That makes the corrective action more credible because management can see both the immediate event and the repeated pattern behind it.
Where Epicor Saturn fits in lost-time analysis
Epicor provides the enterprise-grade ERP foundation for resource cost, finance, approvals and core governance. Epicor Saturn adds the construction and engineering project context that connects lost hours with workfronts, labour, plant, site events and project cost.
That connection helps the project see recurring production loss as part of the project record rather than isolated diary notes.
For lost-time analysis, Epicor Saturn provides the construction-industry project context needed to connect resource loss with site cause and cost, on top of Epicor's enterprise-grade ERP foundation. Explore Epicor Saturn for construction and engineering.
Frequently asked questions
Is “waiting” a useful delay category?
Not by itself. The project should identify what the crew was waiting for.
Should lost hours always be treated as programme delay?
No. They may be absorbed by float or alternative work while still creating cost.
How detailed should delay codes be?
Detailed enough to support action, but simple enough for consistent site use.
Why distinguish immediate cause from root cause?
Because removing the symptom may not stop the same loss from recurring.