Craft Labor Productivity Software: Finding the Cost Code Running at Half the Bid Rate Before Closeout

Three weeks of margin you cannot get back

A concrete crew has been forming and pouring foundation walls on a wastewater job since the start of the month. The foreman fills a paper timecard at the end of each shift with hours against cost codes. Quantities go in a column he completes from memory while the crew loads up. The cards go to the trailer, then to the office, then into payroll, and the job cost report appears after the accounting close.

Three weeks in, the project engineer notices that wall forming has burned 61 per cent of its budgeted hours against roughly a third of the quantity. That code was bid at a production rate somebody derived from historical jobs. The crew is running at close to half of it. The reasons turn out to be mundane: a form system that does not suit the wall configuration, a rebar subcontractor consistently one day behind, and two green hands added in week two.

Every one of those was fixable in week one. None of them was visible in week one. By the time the number surfaced, three weeks of the crew's time were spent, and on a self performed scope of any size, three weeks at half production is a margin event rather than an operational inconvenience.

The denominator is the whole problem

Contractors measure hours precisely because payroll demands it. Hours are accurate to the quarter hour, coded, approved and audited. What almost nobody measures with the same rigour is what those hours produced.

Productivity is earned hours over spent hours, and earned hours require a quantity times a budgeted unit rate. The quantity is where the whole thing falls apart. It is estimated at the end of a shift by a person who has been working outdoors for ten hours, in units that may not match how the work was bid, sometimes for work partly complete with no agreed definition of partly. Feed a fuzzy numerator into an exact denominator and you get a number people learn to ignore, which is exactly what has happened at most contractors that tried this and gave up.

Fixing it is mostly definitional work rather than software work. Every cost code needs a unit that a foreman can count without judgement, a rule for partially complete work, and a budget rate that came from the estimate. Cubic yards placed is countable. Percentage complete on foundations is not. A build forces those definitions, and that discipline is why field productivity systems succeed or fail long before anyone writes code.

Problem one: the estimate never reaches the field in usable form

The bid contains production rates by activity, built from historical performance and the estimator's judgement. Those rates are the target. Yet in most contractors the foreman has never seen them. He knows he has a schedule and a crew, and he finds out he is behind when the office tells him.

A build closes that gap by putting the budgeted unit rate on the foreman's screen next to what his crew achieved yesterday. That single change alters behaviour more than any report the office produces, because a foreman who can see he is at 0.9 hours per unit against a budget of 0.6 will usually diagnose the cause himself. He knows what changed. Nobody in the trailer does.

It also runs in reverse, which is where the compounding value sits. After two years of clean data you have actual production rates by work type, crew size, season and site conditions, from your own jobs. Estimating currently guesses at this from memory and closed job reports of doubtful quality. Feeding real historical rates back into the bid is the highest return outcome of the entire project, and it only exists if the data was captured honestly rather than reverse engineered to look acceptable.

Problem two: crew hours are not earned hours, and unions complicate both

A crew is a foreman, four journeymen, two apprentices and an operator, some of whom are on the code all day and some for two hours. Classifications carry different rates and different fringe obligations, and reciprocity between locals affects how those fringes are reported. On prevailing wage work the classification is not just a rate, it is a compliance statement in a certified payroll submission.

What this means for productivity is that hours must be attributed to cost codes at the individual level rather than the crew level, and the same entry has to serve both purposes. Ask a foreman to enter time twice, once for payroll and once for productivity, and you will get one accurate entry and one fabricated one. The build must produce a single daily record that satisfies payroll coding, union classification and cost code attribution together, then feed payroll rather than duplicate it.

Problem three: the foreman has four minutes and is wearing gloves

Every failed field system failed here. A foreman at the end of a shift will spend a few minutes on a phone or tablet, in bad light, with dirty hands, often without signal. If your interface requires a search through 400 cost codes, he will pick whichever one is nearest the top and the data becomes worthless.

What works is narrow and boring. Show today's crew, pre populated from the plan, with time defaulted to the shift and adjustable by exception. Show only the cost codes active on his work area, four or five of them, not the full job. Ask for one number per code in a unit he can count. Support offline entry with reliable sync, because rural civil sites and deep basements have no coverage and a system that loses a day's entry gets abandoned in a week.

Voice entry is the one place a language model is worth having here. A foreman narrating what happened, transcribed and parsed into hours, quantities and a note about a delay, is faster than typing and captures the context that structured fields lose. That note field, where a foreman explains that rebar was late again, is often the most valuable data in the system, because it is the only place the cause is recorded.

Problem four: daily numbers are noisy and daily reaction destroys trust

One day means little. Weather, a late delivery, a crew split across two areas: all produce a bad number that means nothing. Contractors who react to daily figures teach their foremen to smooth the numbers, and once that starts the system is finished.

The right design reports a rolling trend rather than a daily verdict, flags sustained deviation rather than single day noise, and treats the alert as a question rather than an accusation. In our experience the projects that get value from this treat the first flag as a prompt for a superintendent to walk the area and ask what is happening. The ones that fail treat it as evidence for a meeting. Same data, opposite outcome.

Problem five: the tools you own may already do this

HCSS HeavyJob is the reference product for heavy civil field time and production and it is genuinely well built, with deep adoption among contractors who bid with the same vendor's estimating tool. InEight Progress covers similar ground in a broader enterprise stack. Riskcast is strong on the workforce and productivity side, and LaborChart addresses labour planning and dispatch, which is a related but different problem from unit rate performance.

Buy one of these if your work fits their model. The build case is specific: contractors whose cost code structure and quantity definitions do not map to a packaged model, contractors with unusual self performed scopes where the unit of production is not a standard civil quantity, contractors running a payroll or union arrangement that packaged tools handle badly, and contractors who want the estimating feedback loop closed against their own historical database rather than living inside a vendor's product. If none of those describe you, buying is the honest answer and we say so.

What it costs and how long it takes

A focused first release covering daily field entry of hours and quantities with offline support, earned hour computation against budget rates, and cost code performance reporting runs $55,000 to $120,000 and ships in 10 to 16 weeks. A full platform adding crew planning and dispatch, equipment hours, payroll integration with union classifications and certified payroll support, forecasting at completion by cost code, and the historical rate database for estimating runs $140,000 to $320,000 phased over 6 to 10 months.

What drives cost up: certified payroll and prevailing wage handling, which is detail heavy and unforgiving. Multiple union agreements with different fringe and reciprocity rules. Equipment time and internal rate allocation. Integration with an older accounting platform. And the number of distinct self performed disciplines, since each brings its own units and definitions.

What keeps cost down: starting with your two largest self performed disciplines and their top 40 cost codes by budgeted hours. That covers most of the money and teaches you where the definitions are weak before you commit to the rest.

How to choose a developer

Ask them to explain earned hours without prompting. If they cannot describe the relationship between quantity, budget unit rate and spent hours, they will build you a digital timecard, which you already have in paper form.

Ask what happens when a foreman has no signal for two days. The answer needs to include local storage, conflict handling on sync and a visible sync state, because this is not an edge case in field construction, it is Tuesday.

Ask how the same entry serves payroll and productivity. Any design that asks the field to enter time twice will produce one honest set of numbers and one invented set, and you will not be able to tell which is which.

Ask who owns the code and get it in writing before kickoff. You should own the repository, the infrastructure accounts and the right to hire another firm, and you should own the historical production database outright, because after three years that data is worth more than the software that collected it. At Digital Heroes the client owns both from the first commit.