Compare planned vs. actual labor hours before the work order closes
Most teams find labor overruns in the post-mortem. The variance report lands weeks after the order closes, and the meeting is about explanations, not decisions. This is the spreadsheet-level method for catching the overrun while the job is still open.
/ 01 · Why after close is too late
A closed work order is a receipt.
Labor variance is only actionable while people are still charging hours to the job. While the order is open you have options: walk the job and find out what changed, re-sequence the remaining work, add a second pair of hands, call the customer about scope. Once the order closes, every one of those options is gone. What remains is variance analysis: accurate, well formatted, and useless for that job.
The gap is usually not effort. Controllers already run variance reports every month. The problem is timing: actual hours get captured weekly or at close, so the first moment anyone can see the overrun is the moment nothing can be done about it. The money is already spent.
/ 02 · The method
Five steps you can run this week.
You can do this with the systems you already have: a routing or estimate, a time-capture source, and a spreadsheet. Budget a morning for setup and about fifteen minutes a day after that.
Pull the planned hours
Start with the standard hours from the routing, or the estimate if you quote job by job. Write down where the number came from and when it was last updated. You will need that later: a flag against a stale standard is just noise, and knowing the standard's age is how you tell the difference.
Capture actual hours daily, by employee and work order
Daily is the whole trick. Weekly batches mean your freshest data point can be six days old, and a job can go from fine to badly over in less time than that. Capture at the employee-and-work-order grain, not a total per order: when a flag fires you will want to know whether one task is struggling or the whole crew is.
If your time data currently comes from payroll, it arrives on payroll's schedule, which is too slow. Pull it from the shop floor or time-clock system instead. Worst case, a shared sheet that supervisors fill in at end of shift beats a precise number that shows up Friday.
Compute variance and pace
Two numbers per open order, every morning. Variance to date: actual hours charged so far, against the planned hours for the work completed so far. Pace: the percent of planned hours consumed, divided by the percent of work complete. A pace of 1.0 means on plan. A pace of 1.5 means the job is burning hours fifty percent faster than the work is progressing.
Percent complete is the soft spot. If you have routings, use operations completed out of total operations. If not, ask the supervisor for a number and accept that it is an estimate. A rough percent complete checked daily is worth more than a precise one computed at close.
Set a flag threshold and write it down
Pick the pace that triggers a flag before you run the first report, so nobody argues the threshold after a job trips it. Somewhere around 1.2 to 1.3 is a reasonable start: tight enough to catch real drift, loose enough that normal early-job lumpiness does not fire it. And skip pace entirely for roughly the first tenth of a job. When almost no work is complete, the denominator is tiny and pace swings wildly.
Decide who acts on a flag, and by when
A flag without an owner is a chart. Decide in writing who sees the flag: the work center supervisor, not just the controller. Decide by when: before the next shift starts. And decide the first move: walk the job and find out why, not fill in a form. If a flag sits for two days with no action, the process has failed even if the math was right.
/ 03 · Worked example
What a flag looks like on day four.
Illustrative only. Round, invented numbers, not customer data.
A work order is planned at 200 labor hours. On the morning of day four, the daily capture shows 90 hours charged, and the supervisor calls the job 30 percent complete.
The job has consumed 45 percent of its planned hours to do 30 percent of the work. That is a pace of 1.5, well past the 1.25 threshold this team wrote down, so the flag fires. Held at this pace, the order finishes at 300 hours, 100 over plan. At an assumed loaded rate of $65 per hour (an assumption, use your own), that is $6,500 of exposure on one order.
The number that matters most is the date. It is day four, and about 210 of those 300 projected hours have not been worked yet. The supervisor walks the job that morning, finds the cause, and there is still something to manage. Run the same math after close and the only thing left to do is write it up.
Day-four snapshot · illustrative
/ 04 · Where this breaks
Four ways the method fails in practice.
The data shows up too late
Time capture rides payroll's calendar, so "daily actuals" are really weekly actuals with a daily label. The fix is unglamorous: get the hours from wherever they are recorded first, even if that source is uglier than the payroll extract.
The standards are stale
If the routing has not been touched since the process changed, every order flags and people stop reading the report. When a flag traces back to a bad standard, fix the standard that week, and keep a tally of how many flags were standard problems versus execution problems. That tally tells you whether to trust your plan at all.
Nobody owns the flag
The report goes out, everyone assumes someone else is on it, and by Friday it is wallpaper. This is why step five is written down with a name and a deadline. A flag that does not change what someone does before the next shift was never really a flag.
Percent complete flatters the job
People tend to call work further along than it is, and an optimistic percent complete makes pace look better than it is. So the error hides overruns rather than inventing them. Tie percent complete to operations closed out where you can, and treat a job that sits at the same percent for days as its own kind of flag.
/ 05 · A note on Takum
Everything above works in a spreadsheet.
The honest caveat is that it keeps working only as long as someone keeps doing it: pulling actuals every morning, chasing percent complete, re-checking standards. That discipline is exactly what erodes first when the floor gets busy. We know the by-hand version well. Before the software existed, our founder surfaced $1.4 million in disputable vendor overcharges at a Bain Capital-backed airline by working through invoices manually, line by line. It worked, and it did not scale.
Takum automates this comparison: it takes in daily actuals by employee and work order, computes pace against plan, and flags the orders that cross your threshold while there is still time to act. If the method makes sense and the daily grind is the obstacle, that is the problem it was built for.
See the comparison run itself.
Takum flags work orders drifting past plan while the job is still open, so your team acts during the work, not after it.