Every time I sit in a project review meeting and the numbers look bad, someone in the room says it.
"The workers are slow."
"Productivity on site is the issue."
"We need more manpower."
And maybe they're right; partially. But I've spent enough time on construction sites across Malaysia and abroad to know that what's happening on the ground isn't usually the whole story. The workers are there. The materials are (mostly) there. The equipment is running.
What's missing is the hour nobody accounts for.
Let me describe a morning I've seen play out more times than I can count.
The Project Manager arrives at 7:00am. Before he can walk the site, his phone has forty-three unread WhatsApp messages. He spends the first forty minutes piecing together what happened yesterday; chasing the foreman for a headcount, asking the safety officer if the toolbox talk was done, calling the QS to find out if last month's claim has been certified yet.
By 8:00am, he hasn't made a single decision about the project. He's been doing admin.
Then the Construction Manager needs the weekly lookahead. The Planning Engineer is pulling numbers from P6, cross-referencing yesterday's progress update (which came via voice note), and manually typing it into a PowerPoint template. That takes three hours; for a document that will be out of date by Wednesday.
The QA/QC engineer has three inspection requests to chase. He calls the SO's office. The line is busy. He sends a WhatsApp. He waits.
The Document Controller is updating the RFI register; in Excel, on her laptop, which no one else can access while she's doing it.
By lunchtime, half the site's administrative backbone has spent their morning producing, chasing, and compiling information that already existed somewhere; just not in a usable form.
That is the real productivity problem.
I'm not dismissing the challenges of managing labour on a construction site. Anyone who has tried to coordinate five subcontractor packages simultaneously, in the Malaysian heat, with a client breathing down your neck, knows it's not simple.
But here's what I've observed: when you fix the information problem, the labour problem often gets smaller on its own.
When the PM isn't spending an hour compiling the daily report, he's on the ground making decisions earlier. When the Planning Engineer isn't manually assembling a lookahead, he's doing actual schedule analysis; identifying float consumption before it becomes a delay. When the QA/QC engineer has a live NCR dashboard, he's closing defects faster instead of checking physical files.
The bottleneck on most construction sites isn't the people doing the physical work. It's the people managing it; drowning in the overhead of capturing, moving, and formatting information that should move automatically.
There's a number I keep coming back to.
In a study of construction project management time allocation, project managers consistently spent between 25 and 35 percent of their working hours on reporting, documentation, and data collection. Not on problem-solving. Not on stakeholder management. Not on the things that require their judgment and experience. On assembly.
You are paying your most expensive site resource; the person with the most experience, the most accountability, and the highest salary; to do work that a well-designed system should do for them.
That is a productivity problem. It just doesn't show up in any labour report.
The good news is that fixing this doesn't require a transformation programme or a six-figure software investment. It requires something more specific: automating the moments where information gets stuck.
The foreman already sends a message at end of shift. What if that message went into a form instead of a WhatsApp group; and the daily report compiled itself from it? The site engineer already raises RFIs. What if the act of raising one automatically logged it, emailed the consultant, set a response deadline, and sent a reminder five days later without anyone touching it again?
This is what I work on; building tailored workflow automation systems for construction site teams, using tools they already have and processes they already follow. The goal is never to introduce something new. The goal is to take what already works and make it automatic.
The data is already on your site. It's just not flowing anywhere useful yet.
The shift I'd ask any PM or director to make is this: before you look at what's happening on the ground, look at what's happening in the site office.
How long does it take to produce the daily report? How many people touch the weekly lookahead before it reaches the CM? How many hours does your QS spend chasing daywork sheets that should have been submitted the day they were worked?
Add those hours up. Multiply them across your site team. Multiply them across the project duration.
Then ask yourself whether the productivity problem is really the workers.
I've done this exercise on enough projects to know; the answer is almost never where people expect it to be.
