Published figures on lost hours answer someone else's question. Our review of the research explains what they do and do not show. A virtual design and construction (VDC), detailing or fabrication team deciding whether to change its own process needs a narrower record: what its people do, what gets corrected and what accepted output that effort produces.
This is Atlas's proposed method for building that record. It has not been validated as a measurement instrument, and Atlas has no client results from it. Research that informs a step is cited beside the claim; the rest is our recommendation.
Write the question and the boundary first
Start with one question the team can answer from its own records, such as: how much labor goes into correcting released spool packages, and where are the problems caught?
Fix the boundary: participating roles, phase, software, deliverables, revision basis and observation period. State what is excluded, so nobody reads a detailing baseline as a whole-project figure.
Match the denominator to the question:
- Weekly labor burden: total recorded hours for the same people and period.
- Correction effort: labor hours booked against the affected package.
- Output: sheets, spools or release packages accepted for their intended use.
Do not assume a forty-hour week or one project per person. An hours-per-person-week figure needs a stated rule for partial weeks, leave, overtime and split time.
Choose how the time will be collected
Each method sees different things; we recommend combining two.
| Method | What it captures well | Watch for |
|---|---|---|
| Timesheet activity codes | Hours by activity across many packages; one study drew engineering, detailing and drafting hours from staff timesheets on 66 precast and cast-in-place projects.[1] | Billing codes may not match the question. |
| Observation with participant review | What people actually do, including interruptions[2] and missing inputs.[3] | Needs consent, a proportionate scope and the participant's explanation. |
| Interview reconstruction | Iterative work that is hard to time; one study rebuilt fabrication-documentation hours from engineer interviews.[4] | Recalled, not timed; label it so. |
| Event check sheet | Each correction or delay with its cause; one firm logged delay causes across 29 shop drawings.[5] | Reconcile against timesheets. |
Agree the activity categories with the people doing the work
Write the categories with the modelers, detailers and coordinators who will use them, and test them on real examples first. A category that means one thing to the manager and another to the detailer produces a clean number that measures nothing.
In a helmet-camera study of 15 mechanical, electrical and plumbing (MEP) workers and foremen, researchers had participants explain clips of their own footage to validate the classification. Missing prerequisites became visible only across a longer sequence of events.[3]
| Category | Definition | Example | Do not count as waste |
|---|---|---|---|
| Production | Creating the agreed deliverable | Modeling hangers and supports for one zone | Slow work on difficult geometry |
| Required review and coordination | Checks and meetings the process or contract requires | Weekly clash review; pre-release spool check | Required checks that find nothing |
| Searching | Looking for an input that should be available | Finding the current architectural revision | First reading of a new specification section |
| Duplicate entry | Re-entering data that exists elsewhere | Retyping model spool lengths into a shop spreadsheet | Deliberate re-entry used as a check |
| Correction | Redoing work that was wrong or no longer matches its basis | Re-detailing a released spool after a dimension error | Owner- or designer-directed changes; log those as changes |
| Blocked | Unable to progress or switch to other work | Waiting on a design answer with nothing else assigned | A package waiting while its author works elsewhere |
| Unknown | Cause not yet established | An hour booked with no description | Nothing yet; resolve it or report it |
Record why each activity happened, and keep the unknown category. Forcing every hour into a named cause makes a baseline look more certain than it is.
Give every correction one identifier
Record the cause the evidence supports, not the first explanation offered. Log owner-directed changes as changes, not errors, and allow contributing causes.
Treat perception as a starting point. Chin's study of engineering shop-drawing reviews at one firm tested brainstormed causes with a check sheet that recorded delay time against each one. It concluded that the root cause of long reviews was insufficient and unclear information, not reviewers' capability or availability.[5]
| Field | What to record | Format or choices |
|---|---|---|
| Event identifier | One code, reused on every timesheet entry for the fix | Project prefix plus sequence number |
| Package and revision | Affected release package and source revision | Package name, revision, date |
| Caught and corrected | Where it was found and where it was redone | Model review, detailing, shop, field, after completion |
| Cause | The primary cause the evidence supports, plus any contributing causes | Incorrect design input, interface problem, release differs from agreed model, fabrication error against a correct release, directed change, unknown |
| Evidence | Records supporting the cause | Markups, transmittals, model versions |
| Labor by role | Hours from timesheet entries citing the identifier | Hours per role |
| Material and equipment | Cost where available | Amount, marked actual or estimated |
| Cost bearer | Who carried the cost | Company or role |
| Schedule effect | Documented effect on release or installation | Elapsed working days, or none documented |
Keep labor and elapsed time in separate columns
A package waiting two days for approval can hold a release while consuming little labor. Three people fixing a problem for an hour use three labor hours without delaying the project three hours. Report both; never convert one into the other.
In a study of four projects at one design firm, most of a drawing's elapsed cycle time was waiting between activities.[7] That is a delivery problem, not evidence that anyone was idle. Count queue time as blocked labor only when the person had nothing else to do.
Reconcile before drawing conclusions
Start with a small, authorized scope and tell participants what is being measured and why. Report by role and activity, not by named individual: the aim is to find process problems, not to rank people. Keep observation proportionate and within the project's information rules; in the MEP helmet-camera study, sound was not recorded for privacy reasons.[3]
Before presenting a number, check that:
- Coding disagreements have an owner and a resolution.
- Correction-log hours reconcile with timesheets for the same people and period.
- Duplicate events are merged.
- Missing time and unknown causes appear beside the result.
- The period, participant count and coverage are stated.
No universal event count or study length makes a result reliable. The useful sample depends on how much the work varies, how often the problem occurs and the decision at stake. A small pilot is a local baseline, not an industry benchmark.
Judge an improvement by accepted output, not hours alone
Measure accepted output and reviewer effort alongside hours. Fewer production hours with more corrections or longer reviews may just move the cost. Our article on introducing a new tool covers running the trial.
Compare similar work and record what else changed. Sacks and Barak accounted for project type and size, construction method, versions produced and a repeat factor before comparing productivity, and excluded design-change hours from their benchmark.[1] Staff experience, phase and revision volume can explain a difference as easily as a new process can.
Label estimates as estimates. A precast shop-drawing study combined prior-project records, workshop and pilot validation of parts of the process, and practitioners' estimates of a future workflow; its authors placed whole-workflow validation outside the study.[8] A projected saving is a reason to test, not a result to report.
The first deliverable is a local baseline: which activities consumed time, which corrections repeated and where they were caught, what the records missed and which improvement to test next. That is a business case the team can trace to its own work.
Sources
- Sacks and Barak, Quantitative Assessment of the Impact of 3D Modelling of Building Structures on Engineering Productivity, Joint International Conference on Computing and Decision Making in Civil and Building Engineering, Montréal, 2006, pp. 1190–1192. Proceedings paper. Supports timesheet-based activity hours and normalized comparison; its productivity gains come from experiments under different conditions and are not a savings benchmark.
- Josephson and Saukkoriipi, Slöseri i byggprojekt (Waste in construction projects), FoU-Väst report 0507, 2005, p. 27. Report, in Swedish. Supports that design-office work has been observed directly and resisted a value-or-waste split; ten people for one day each, so no design-waste rate follows.
- Seppänen and Görsch, Decreasing Waste in Mechanical, Electrical and Plumbing Work, Proceedings of the 30th Annual Conference of the International Group for Lean Construction, 2022, pp. 86–89. Proceedings record. Full paper. Supports participant-validated classification and privacy-conscious observation of site installers; it is not office detailing and does not validate Atlas's categories.
- Yoo and Ham, Productivity Analysis of Documentation Based on 3D Model in Plant Facility Construction Project, Applied Sciences 10(3), 1126, 2020, p. 8. Journal article. Supports interview-based reconstruction of documentation hours where continuous timing was impractical; the hours are recalled, not independently timed.
- Chin, Identifying Root Causes of Long Review Times for Engineering Shop Drawings, Proceedings of the 17th Annual Conference of the International Group for Lean Construction, 2009, pp. 557–572. Conference paper. Supports testing perceived causes against check-sheet data; one firm and 29 shop drawings, and its delay shares are not measured reviewer idle time.
- Holth, Fosse and Drevland, Carpenters' Workday: Between Value-Adding Work and Physical Strain, Proceedings of the 34th Annual Conference of the International Group for Lean Construction, 2026, pp. 1268–1270. Conference paper. Supports coding direct, indirect and wasted work separately; one crew on one project over five days, not a population estimate.
- Freire and Alarcón, Achieving a Lean Design Process, Proceedings of the 8th Annual Conference of the International Group for Lean Construction, 2000. Proceedings record. Supports distinguishing a drawing's elapsed cycle time from staff labor; its waiting shares are not idle paid hours.
- Nath and colleagues, Productivity Improvement of Precast Shop Drawings Generation Through BIM-Based Process Re-Engineering, Automation in Construction 54, 2015, pp. 55–56 and 67. Publisher record (DOI). Supports labeling a future-workflow estimate as prospective; it is not an observed whole-process saving.
SCOPE
Atlas Construction Consultants provides staff augmentation; building information modeling (BIM) and VDC design; project, model, trade and fabrication coordination; and technology consulting, implementation and training. The categories, record fields and checks above are Atlas's proposed method, not a validated instrument or a measured client outcome. A client measurement would need an agreed scope, participant awareness, information access and a written measurement plan before any collection. This article is not legal or licensed engineering advice.