How to Track Construction Labour Productivity Without Waiting for Month End

Week six on a storm sewer job. The timesheets are clean, every hour is coded to the right activity, and the month-end cost report says the pipe crew has used 48 percent of its labour budget. The obvious question is whether they've laid 48 percent of the pipe. Nobody in the office knows. The foreman thinks it's "a bit under half." The estimator priced the line at a certain number of hours per metre, and six weeks in, nobody has checked whether that number was true.

This is the most common gap we see in contractor job costing, and it hides well because everything looks tidy. Hours get collected with real discipline. Installed quantities, the other half of the productivity ratio, get collected at the end of the job, or never. Productivity is output divided by input. Most contractors only ever measure the input, then wonder why the cost report can't tell them anything until the job is over.

Productivity is a ratio and you're collecting half of it

A labour productivity number needs three things per cost code: the budget (quantity and hours, straight from the estimate), the hours actually spent, and the quantity actually installed. The first two you almost certainly have. The third is the one that turns a labour report into a forecast.

The arithmetic is not the hard part. Budgeted hours divided by budgeted quantity gives you the unit rate you bid at. Installed quantity multiplied by that unit rate gives you earned hours. Earned hours divided by actual hours gives you a productivity factor, where 1.0 means the crew is producing at the estimated rate, above 1.0 means better, below means worse. Estimating and claims professionals have used this framing for decades. It fits on a napkin.

What makes it work or fail is whether the installed quantity arrives every week, from the field, in the same unit the estimate used. That is a process problem, not a software problem, and it's where the rest of this post lives.

Measure what the estimate measured

The single rule that makes quantity tracking survive contact with a real crew: report quantities in the unit the estimate priced them in. If the estimate has 1,200 metres of 600 mm storm sewer at so many hours per metre, the foreman reports metres of pipe laid this week. Not "percent complete," not "we're about halfway." Metres. A number someone could walk the trench and check.

This sounds obvious and is violated constantly. Estimators think in metres, cubic metres, square metres of formwork, number of piles. Field reports, when they carry quantities at all, tend to carry percentages, and percentages are opinions. A crew that has done the easy first half of a run will honestly report 60 percent complete when it's 50, because the hard half hasn't taught them anything yet. Physical units don't have that problem.

A few practical corollaries:

• Not every code gets a quantity. Mobilization, site maintenance, traffic control and similar codes are level of effort. Forcing a unit onto them produces nonsense. Track them against budgeted hours only and stop there.
• Pick the codes that carry the risk. On most civil and marine jobs, a handful of labour codes hold most of the budgeted hours. Track quantities on those first. A code with 40 hours in it can be wrong by half and nobody will notice at year end.
• Write down the measurement rule. Is a pile "driven" when it reaches tip elevation or when it's cut off and capped? Is excavation measured in bank or loose cubic metres? Is formwork counted when it's set or when it's stripped? Decide once, write it on the timecard or in the daily report template, and the numbers become comparable week to week.

Get it onto the same form as the hours

The quantity should live wherever the hours already live. If the foreman fills in a daily report or a timesheet app at the end of the shift, add one line per active code: quantity installed today, in the agreed unit. That's a minute of work while the day is still in their head. Asking for it separately on Friday, or having the project manager reconstruct it from photos and memory, is how the practice dies inside a month.

On a marine job the daily report is often already carrying the number in prose: "drove six piles, bents 14 and 15, refusal on pile 3 at 2 m short." The change is pulling that into a field the spreadsheet can read, next to the hours it took. The information was always there. It just wasn't structured.

The weekly page

Every week, one page per job, one row per tracked code. Columns: budget quantity, quantity to date, budget hours, earned hours, actual hours, productivity factor, and the one people actually read, hours to complete at the current rate compared to hours remaining in the budget.

That last column is the point of the whole exercise. It's the labour half of the cost-to-complete number your WIP report needs, and it comes from arithmetic on measured quantities instead of a project manager's estimate of how the job feels. If the pipe crew has laid 500 of 1,200 metres and burned 48 percent of the hours, you know today that the code will land roughly 15 percent over, and you know it in week six rather than at closeout.

Hold the review to twenty minutes and do it in the same meeting as the look-ahead. The productivity page tells you which crews are struggling; the look-ahead is where you decide what to do about next week.

When the number is bad, ask which of three things is true

A productivity factor below 1.0 is not a verdict on the crew. It has three possible causes, and each one leads somewhere different.

The estimate was wrong. The rate was priced from a rate table or from a job with different soil, and it was never going to happen. The action is in the estimating department, not the field. This is the feedback loop that makes the next bid better, and it only closes if the actual rate gets written down and handed back.

The conditions changed. Unforeseen ground, a redesign, an owner-directed resequence, access that wasn't what the drawings showed. This is the case where weekly quantities pay for themselves several times over. A productivity loss claim lives or dies on contemporaneous records, and the strongest form of that record is a measured rate before the disruption compared to the measured rate during it. You cannot build that at the end of the job from timesheets alone. You build it from the weekly page, without knowing at the time you'll need it.

The crew or method is the problem. Wrong equipment, crew too big or too small for the front, a foreman still learning the work. This is the fixable one, and it's fixable early only if the data is early.

Without quantities, all three look identical on the cost report: labour over budget. With quantities, the diagnosis usually takes one conversation.

The tradeoffs, stated plainly

This costs foreman time every shift and office time every week, and it needs a measurement rule someone will argue about the first time. A hypothetical contractor running two or three straightforward jobs a year with the same crews and the same kind of work might reasonably run on experience and a monthly cost report. That's a legitimate choice if it's made deliberately.

What's harder to defend is the common middle: paying for an ERP that has a quantities field on every cost code, never turning it on, and then buying a productivity dashboard to solve a problem the daily report could have solved. Most job costing systems, including Acumatica and its peers, will take installed quantities and produce the weekly page. A spreadsheet will too. The constraint is the discipline of getting one honest number per code out of the field every week, and no software purchase supplies that.

At Manara we help contractors set up exactly this loop: the measurement rules, the timecard or daily report changes, and the weekly page, wired into whatever they already run. We don't sell the software, so we have no interest in it being more complicated than it needs to be. If your labour reports can tell you what was spent but not what was built, a free discovery call is a sensible place to start.