RPT 204 · Practitioner · Operations track · 12 min read
Labor Productivity Report
The report that compares labor hours spent against work put in place, exposing whether crews are outperforming or falling behind the estimate while there is still time to change the outcome.
Definition — what it is
A labor productivity report compares the labor hours actually spent on a scope of work against the work quantity put in place, and measures both against the productivity assumed in the estimate. It is usually expressed as a unit rate - labor hours per unit of work, such as hours per cubic yard placed or per linear foot installed - or as a performance factor comparing earned hours to actual hours. Its purpose is to reveal whether crews are keeping pace with the estimate while there are still hours left to influence, because labor is the most volatile and controllable cost on most self-perform work. It is not a cost report: it deliberately isolates hours from dollars, because a crew can be under budget in dollars while burning hours faster than the work is progressing, and only the productivity view sees that.
Also known as: Productivity Report, Labor Performance Report, Unit Rate Report, Earned Hours Report
Why it matters — what it protects
Labor productivity is where self-perform contractors win or lose money, because labor is the cost with the most variance and the most that management can actually change. Material prices are fixed at buyout and subcontracts are fixed at award, but labor productivity moves every day with crew composition, sequencing, weather, and morale - and a crew running 15 percent below the estimated rate is burning margin that no other report will catch until the money is already spent.
The report is the only one that separates progress from spending. A job cost report shows labor dollars against budget, but dollars conflate rate and productivity: a crew can be under budget because it is understaffed and behind, which looks fine on cost and is a schedule disaster. Measuring hours against installed quantity exposes the crew that is falling behind before the budget shows it, which is the entire reason the report exists.
Productivity is a leading indicator of schedule. Falling productivity means the work will take more hours than planned, which means more crew days, which means a longer duration on the activity and pressure on the critical path. Reading productivity trends is often the earliest warning that a self-perform activity is going to slip, weeks before the schedule update shows it.
Productivity data is the calibration loop for estimating. The unit rates a company actually achieves, captured job over job, are the only honest basis for the rates it should bid. A contractor that never measures achieved productivity re-bids the same optimistic assumptions and re-loses the same money, while one that closes the loop tightens its estimates and its margins with every job.
Lifecycle — how it moves
Estimate basis
The estimated productivity rate is set at bid - hours per unit for each labor operation. This is the baseline every later comparison is against, and if the estimate's units do not match how quantities will be tracked in the field, the whole report is undermined from the start.
Quantity definition
The trackable quantity for each operation is defined - cubic yards, linear feet, each, square feet - along with how it will be measured in the field. Poorly defined quantities are the most common reason productivity reporting collapses, because nobody can say honestly how much work was put in place.
Hour capture
Labor hours are captured from timecards and coded to the specific operation. Hours coded to a generic bucket rather than the operation they were spent on make productivity impossible to compute, so cost-code discipline in the field is the foundation of everything downstream.
Quantity capture
Installed quantities are reported from the field, ideally by the foreman who did the work. This is the weakest link: quantities are often estimated, guessed, or reported late, and a wrong quantity produces a wrong productivity that misleads worse than no report.
Rate calculation
Actual hours per unit are computed and compared to the estimated rate, yielding a performance factor. A factor above 1.0 means beating the estimate; below means falling behind. The trend of the factor matters more than any single period's value.
Variance review
The superintendent and PM review operations whose productivity is drifting, and diagnose why - crew mix, sequencing, access, rework, weather, or a bad estimate. Diagnosis is where the report becomes action or stays a number.
Forecast update
Confirmed productivity trends update the labor cost-to-complete: if a crew is achieving 1.2 hours per unit against an estimated 1.0, the remaining quantity is forecast at the achieved rate, not the estimate. Failing to reforecast is how a productivity problem becomes a closeout surprise.
Post-job feedback
Final achieved unit rates are captured as historical productivity data and fed back to estimating. This closes the loop that turns field performance into better bids, and skipping it is why the same rates get missed every job.
Anatomy — the data it carries
- Operation / activity
- The specific work being measured, tied to a cost code. Must match how hours are coded and quantities are tracked, or the rate is meaningless.
- Estimated unit rate
- Hours per unit assumed in the bid. The baseline the report measures against - its accuracy sets whether variances mean anything.
- Budgeted hours
- Estimated rate times total quantity. The total labor hours the operation is allowed.
- Actual hours to date
- Timecard hours coded to the operation. Reliable only with disciplined field coding.
- Quantity installed to date
- Work put in place, in the operation's unit. The most error-prone field and the one that most affects the answer.
- Total quantity
- The full scope quantity. Used to compute percent complete by quantity and to forecast remaining hours.
- Earned hours
- Quantity installed times the estimated rate - the hours the completed work should have taken. The basis for the performance factor.
- Actual unit rate
- Actual hours divided by quantity installed. The core measured output, compared directly to the estimate.
- Performance factor
- Earned hours over actual hours. Above 1.0 is ahead of the estimate, below is behind - the single number crews watch.
- Percent complete by quantity
- Quantity installed over total quantity. A physical progress measure independent of hours or dollars.
- Forecast hours to complete
- Remaining quantity at the achieved rate. Where the report drives the cost-to-complete.
- Crew size / composition
- Who is doing the work. Changes in crew mix explain many productivity swings and belong alongside the rate.
Failure modes — how it breaks
Guessed installed quantities
Foremen report round-number quantities from memory rather than from measurement, or report them a week late. The resulting unit rate is fiction, and a fictional productivity that shows a crew ahead when it is behind is more dangerous than no report at all because it suppresses action.
Hours coded to the wrong operation
Labor lands on a generic or adjacent cost code, so one operation shows impossible productivity and another shows a phantom overrun. The report becomes an argument about coding rather than a read on performance, and trust in it erodes.
Dollars mistaken for productivity
Management reads the labor cost report, sees the operation under budget, and assumes the crew is performing - when it is under budget only because it is understaffed and behind. The productivity view would have caught it; the cost view actively hid it.
Bad estimate blamed on the crew
The estimated unit rate was unachievable from the start, so every crew shows a poor performance factor and morale collapses under a target that was never real. Without checking the estimate basis, the field is blamed for an estimating error.
Learning curve read as decline
Early productivity on a repetitive operation is poor because the crew is still climbing the learning curve, and management overreacts before the rate naturally improves. Reading a single early period instead of the trend triggers the wrong intervention.
Rework hours hidden in the operation
Hours spent redoing defective work are coded to the original operation, so productivity looks poor and the real problem - a quality issue driving rework - is never named. The report shows a symptom while the cause stays invisible.
No reforecast from the trend
A crew is confirmed to be running well below the estimated rate and everyone agrees, but the labor cost-to-complete is never updated. The overrun is acknowledged and then forgotten until it surfaces as fade at the WIP true-up.
Metrics — how it is measured
Performance factor
Earned hours divided by actual hours, by operation. Above 1.0 ahead of estimate, below behind. The headline productivity metric.
Actual vs. estimated unit rate
Achieved hours per unit against the bid rate. The direct measure of whether the estimate's productivity is holding.
Cumulative vs. period productivity
Trend over time versus a single period. Rising or falling trend matters more than any one week's rate.
Percent complete by quantity
Physical progress independent of hours and dollars. Cross-checks whether reported progress is real.
Forecast hours variance
Forecast hours to complete against budgeted remaining hours. Translates productivity into a labor cost impact.
Quantity reporting timeliness
How current the installed-quantity data is. Stale quantities make every productivity figure unreliable.
Rework hours share
Hours spent on rework as a share of the operation. Isolates quality-driven productivity loss from genuine pace.
The AI shift — what actually changes
Conversational
The report stops being a unit-rate spreadsheet and becomes something you interrogate. You ask which operations are trending below the estimated rate, whether a poor factor is a learning curve or a real decline, and which crews are burning hours faster than they are installing quantity - with the timecards and quantity reports cited so a bad number can be traced to a coding or reporting problem rather than believed blindly.
Generative
Productivity narratives and reforecasts are drafted from the underlying data: an operation-level explanation of why the factor moved, distinguishing crew mix, sequencing, rework, and estimate error, with a proposed labor cost-to-complete at the achieved rate - written for the PM to confirm rather than compute from scratch.
Orchestrated
Productivity stops living apart from schedule and cost. A confirmed productivity decline is checked against the schedule activity it affects, matched to any rework driven by quality issues, translated into a labor cost-to-complete, and pushed into the forecast and WIP so a real trend updates the projection automatically - and the achieved rate is captured for the estimating feedback loop.
Autonomous
The routine motion runs continuously: hours screened for likely miscoding against the operation, installed-quantity reports checked for plausibility against schedule and prior periods, performance factors recomputed as data lands, operations trending below rate flagged with a drafted cause and forecast, and rework isolated from genuine pace - while humans confirm what is real, own every reforecast, and decide every crew or sequencing intervention.
Prompts — put it to work
Tool-agnostic and copy-ready. Adapt the specifics — thresholds, contract windows, cost codes — to your own project before you run them.
Conversational — Weekly self-perform review on a job where labor is the whole margin.
Review labor productivity across all self-perform operations on this job. For each operation, show the estimated unit rate, the actual unit rate to date, the performance factor, percent complete by quantity, and the forecast hours to complete at the achieved rate. Flag every operation with a performance factor below 0.90, but before you alarm me, tell me which of those are early-stage learning curve versus established declines by looking at the period-over-period trend, not just the cumulative number. Separate any operation where the installed quantity looks implausible against the schedule so I know which numbers to trust.
What good output looks like: A performance-factor review that separates learning curve from real decline and flags untrustworthy quantities, with the labor cost impact quantified - not a raw unit-rate dump.
Follow-ups:
- For the worst-performing operation, is this crew mix, sequencing, access, or rework?
- Which operations are under budget on dollars but behind on productivity because they are understaffed?
- What is the total labor cost impact if the current rates hold to completion?
Generative — You need to write the productivity variance explanation and reforecast for a struggling operation.
For the cast-in-place concrete placement operation, the performance factor has held at 0.82 for four straight weeks against an estimated rate of 0.9 hours per cubic yard. Draft the productivity variance explanation and the reforecast. Read the timecards and installed-quantity reports, check whether rework hours are inflating the operation, distinguish crew-composition and sequencing effects from a possibly optimistic estimate, and compute the forecast hours to complete the remaining quantity at the achieved rate. State the labor cost impact plainly and recommend whether to reforecast or to pursue a recovery. Four to six sentences, factual, with the specific data cited.
What good output looks like: A grounded explanation that names a specific driver, separates rework and estimate error, and produces a reforecast at the achieved rate with the cost impact - not a generic 'productivity was low' note.
Follow-ups:
- Redraft assuming we add an experienced foreman and the rate recovers to 0.88 - what changes?
- Write the version that argues the estimate was low and quantifies how much of the variance that explains.
- Summarize into a one-line status for the owner's progress meeting.
Orchestrated — A productivity decline is confirmed and you need to know everything it touches.
The masonry operation's performance factor has dropped to 0.85 and it is confirmed real. Trace it end to end: check the installed-quantity trend against the schedule activity's planned progress, determine whether the decline threatens the activity's finish and any downstream critical-path work, isolate any rework hours that a quality issue is driving, translate the achieved rate into a labor cost-to-complete, and push the revised forecast into the WIP. Also capture the achieved unit rate for the estimating history. Return one summary with each conclusion tied to the record that supports it and flag anything uncertain.
What good output looks like: A cross-referenced trace linking productivity to schedule, rework, cost-to-complete, WIP, and estimating history, with citations and uncertainty flagged.
Follow-ups:
- If this threatens the critical path, what schedule recovery options exist and at what labor cost?
- If rework is the driver, open the non-conformance link and quantify the rework hours.
- Which other operations on this job share the crew and might show the same decline?
Autonomous — Standing policy for continuous productivity monitoring on self-perform work.
Monitor labor productivity continuously across self-perform operations under these rules. Screen posted hours for likely miscoding against the operation and hold suspects for review. Check each installed-quantity report for plausibility against the schedule and prior periods, and flag quantities that look guessed or stale rather than computing a rate from them. Recompute performance factors as data lands, and flag any operation trending below 0.90 with a drafted cause and a forecast at the achieved rate, distinguishing learning curve from established decline and isolating rework hours. Never change a labor cost-to-complete, never reclassify hours, and never adjust an estimated unit rate without my approval, and route every confirmed decline to me with your reasoning.
What good output looks like: A continuously current productivity watch with a short exception queue and audit trail, where every reforecast and rate change stays with a person.
Follow-ups:
- Show me everything you flagged and every quantity you held as implausible this week.
- Which of your flagged declines turned out to be learning curve, and how should you adjust?
- Roll your confirmed declines into a draft labor cost-to-complete update for my approval.
Get the full Construction AI Prompt Catalog — every prompt in the library in one document.
Maturity — locate yourself honestly
Level 0 - Dollars only
Labor is tracked in cost dollars against budget with no quantity data. Productivity is invisible, and understaffed-but-behind crews look healthy on cost.
Level 1 - Rates computed
Installed quantities are captured and unit rates computed against the estimate, but quantities are often guessed and the report lags the field.
Level 2 - Trended and forecast
Performance factors are trended over time, learning curve is distinguished from decline, rework is isolated, and confirmed trends update the labor cost-to-complete.
Level 3 - Assisted
Hours are screened for miscoding, quantities checked for plausibility, factors recomputed automatically, and variance explanations with reforecasts drafted for review.
Level 4 - Operated
Productivity monitoring runs continuously inside guardrails - screening, plausibility checks, trending, and flagging - while humans confirm what is real, own every reforecast, and decide every intervention.
Common questions
Why not just track labor in dollars like everything else?
Because dollars conflate labor rate and productivity, and a crew can be under budget in dollars for the worst possible reason - it is understaffed and falling behind. Productivity isolates the physical relationship between hours spent and work installed, which is the thing management can actually control. A crew running the estimated dollars but installing half the planned quantity is a schedule disaster that the cost report shows as green; only the productivity view sees it, which is why self-perform contractors track both.
What makes installed-quantity data so unreliable, and how do you fix it?
Quantities are usually reported by busy foremen at the end of a shift, often from memory and sometimes rounded to make the numbers look tidy, and a wrong quantity produces a wrong productivity that misleads worse than no data. The fix is to define trackable quantities that match the work, make quantity reporting a routine part of the daily field process rather than an afterthought, and cross-check reported quantities against physical progress and the schedule so implausible figures get caught before they drive a bad forecast.
How does labor productivity relate to earned value management?
Labor productivity is essentially earned value applied to hours instead of dollars: earned hours are installed quantity times the estimated rate, and the performance factor is the labor equivalent of a schedule or cost performance index. Full earned value management extends this across all cost types and integrates it with schedule, while a labor productivity report focuses tightly on the self-perform hours where the most variance and the most control live. The two share the same logic, and a shop that runs good productivity reporting is most of the way to EVM on its self-perform scope.