Construction labor productivity grew about 1% a year for two decades. Manufacturing grew 3.6%.
Construction productivity has barely moved in twenty years while other industries pulled away, and a large share of preconstruction time still goes to counting symbols by hand off a file that already knows where they are. LumenTakeoff counts every repeated fixture symbol exactly and leaves the judgment to the estimator.
The figure
Construction labor productivity grew about 1% a year for two decades, against 2.8% for the world economy and 3.6% for manufacturing.
Source: McKinsey Global Institute, Reinventing Construction, 2017
McKinsey Global Institute's Reinventing Construction compared construction labour productivity against the world economy and manufacturing over two decades. Construction grew about 1 percent a year. The world economy managed 2.8 percent and manufacturing 3.6 percent. McKinsey's 2024 update put the total improvement across those twenty years at around 10 percent.
Numbers that broad are easy to nod at and hard to act on, so here is the version I can see from my own desk. I am 18, I work in electrical preconstruction, and I count lighting fixtures by hand, sheet by sheet, on every revision. The drawing already knows where every fixture is. The engineer placed each one as an exact set of lines and arcs at exact coordinates and saved it into a PDF, and then a person reads it off a screen and makes tally marks on a printout. The information is machine readable. The method is not.
That is where a share of the 1 percent lives. Not in the field, where the labour is actually productive, but in the office, in work that was digitised in form and never in substance. Then revision 3 lands on Thursday, one sheet changes, and the whole count goes through again, because a total cannot tell you which part of itself is still good.
What LumenTakeoff does about it
LumenTakeoff opens the PDF, reads the vector geometry inside it, and counts every repeated symbol exactly. A symbol that differs by two line segments becomes its own family instead of being folded into the one beside it, which is the Type F against F1 against FA problem that makes lighting takeoff slow in the first place. On the demo sheet in the launch film that is 51 fixtures in four families: 51 drawn, 51 found, each one shown where the engine actually found it.
Then the estimator decides, and the tool is built so that deciding is fast. One unnamed family at a time, most frequent first, with a large ringed crop. Type the code and the set's own fixture schedule completes it, with the schedule description filled in. Enter confirms, Esc marks not a fixture, the arrows skip or go back, and a counter says 8 of 10 decided, 2 to go.
Four numbers per family stay separate and are never blended: detected instances, production count, in bid scope, and how many times the schedule tag appears on the sheet. What the engine cannot count, it reports, so a scanned page comes back as unsupported rather than as a smaller number. Export waits on a reconciliation check.
Every count stays tied to the sheet and the position it came from, which is what turns revision 3 into a check of what changed instead of a recount of the set. That is the part of the 1 percent I think is actually available.
Demo phase, tested against real electrical plan sets. The machine counts. You decide.
The machine counts. You decide.
Bring a plan set
See what LumenTakeoff finds.
Run a real lighting takeoff and review the result against the way your team works today.
- Supported vector plan sets
- Lighting fixture families and counts
- Evidence you can check against the drawing
Built for electrical estimators. Your address is used to reply about LumenTakeoff and nothing else.