We keep solving Australia's productivity problem the wrong way

Project execution productivity in the Australian energy sector has hit a wall. The instinctive fix is to add people. The instinctive objection is that people here are expensive. So the work moves offshore — and a familiar cycle begins.

It usually goes something like this:

"Productivity isn't where we need it to be." — Let's add more people.

"But labour is too expensive in Australia." — Let's move more engineering work offshore.

"The output doesn't meet Australian project requirements." — Then we'll add people here to review everything.

"That's another layer of engineering, and it doesn't fix the cost problem." — Fine. Just enough people to review the critical path deliverables.

"How much is enough? And what happens when today's non-critical items become tomorrow's critical path?"

A few months later, the project is behind schedule. Those non-critical deliverables have become critical, the local team has no capacity to absorb them, and more local people are hired — this time at urgency rates. Contingency disappears. Procurement goes out with missing or incorrect information. Entire packages are redesigned, rechecked, reissued, or worse, reprocured.

I'm not going to put a number on what that costs, because the numbers I have belong to other people. But you have your own. Pull last month's timesheet data and count the hours booked against reviewing work that had already been reviewed somewhere else. Then do the month before. Most organisations have never looked at that figure, and it's sitting in a system they already own.

I've seen this cycle on more than one project, at more than one company, on more than one continent. That's the part worth paying attention to. It isn't one team's bad luck — it's structural.

Before going further, I want to be clear about something, because this argument is easy to misread.

This is not a story about offshore teams being less capable. I've worked alongside excellent engineers in offshore offices, and I'd work with them again. The failure isn't in their competence — it's in the model we wrap around them. The review layers, the interface points, the distance between the person producing the work and the person who owns the outcome. That's a design problem, and we designed it.

And the cost doesn't stop at money and schedule. It shows up somewhere that rarely reaches a project report: good engineers spend their days checking other people's work instead of solving engineering problems, and they burn out. I've watched top performers leave the project, then the company, and in a few cases the industry altogether. Meanwhile the person who proposed the original resourcing strategy has usually been promoted onto something else.

The problem isn't the cost of engineers

Australia has no shortage of talented engineers. The issue is what we ask them to spend their day on.

Checking document formatting. Updating registers. Copying information between systems. Maintaining monstrous spreadsheets nobody can follow. Chasing people for inputs. Following the same workflow for the four-hundredth time.

None of this requires years of engineering experience. All of it consumes them. In my experience, about 40% of an engineer's day goes to work that follows fixed rules and needs no engineering judgement at all.

That's the real productivity leak. It isn't that Australian engineers are expensive. It's that we're paying Australian engineering rates for administration.

Where GenAI actually fits — and it's closer to offshoring than you'd think

The moment AI comes up, the conversation jumps to replacing engineers. I think that's the wrong conversation. Engineering decisions still require engineering judgement, design responsibility still belongs to people, and quality still has to be verified by someone accountable for it.

Here's the framing I find more useful: using GenAI is not that different from sending work offshore. In both cases you delegate execution to something that doesn't carry your context, and in both cases you have to review what comes back. Nobody who's run an offshore package is surprised by that.

The difference is everything around the delegation.

There's no time zone. The feedback loop is minutes, not days. There's no interface layer to manage, no handover pack to write, no follow-up call at 9pm. When the output is wrong, you correct the instruction once and it stays corrected. And critically, ownership never leaves the project team — the engineer reviewing the draft is the same engineer who's accountable for it.

That's the part the offshore model has never solved, and it's the part that quietly causes most of the damage.

GenAI isn't a magic solution. It's a tool, and like every engineering tool its value depends entirely on how it's applied.

Start with the work that surrounds engineering, not the engineering

The opportunity isn't asking AI to design a system. It's asking AI to remove the repetitive work that sits around the design.

Document control. I've built a working prototype of an AI document controller. It answers questions about the DC procedure and document statuses, creates document numbers, and issues documents to the right people based on the milestone chain and the distribution matrix. It checks for what's missing and reminds the people who owe it. It doesn't replace the document controller — it removes the interruptions that stop them doing the part of the job that actually needs a person.

It isn't in production, so I won't claim results I don't have. What I have done is model the economics properly, and the modelling turned up something I didn't expect.

On a 550-document project over 18 months, the labour is the small half of the problem. Roughly a third of what document control really costs isn't the document controller at all — it's fixing the errors the process produces. Wrong revisions distributed. Wrong issuance purpose. Missed reviews. Most are caught cheaply. Two or three reach fabrication or site, and those run around $12k each once rework, standby and delay are counted.

Past about 1,100 documents, that error cost overtakes the document controller's entire salary.

Which makes the standard response — trim the DC hours, move the function somewhere cheaper — arithmetically backwards. It shrinks the visible line item and grows the invisible one.

The same pattern applies right across a project.

Technical documentation. Most reports follow an established structure and pull from project data that already exists. A well-configured system will get you a credible first draft in minutes — call it 80% of the mechanical work — leaving the engineer to do the part that actually needs them: checking assumptions, improving the visuals, and making the argument land. The engineer isn't replaced. They just stop doing typesetting.

Project governance. Risk registers aren't neglected because people don't care. They're neglected because updating a spreadsheet is nobody's highest priority on a Thursday afternoon. Instead, picture a team member updating a risk in a two-minute conversation with an assistant that records it, updates the register, tracks the action, and reminds the owner when the review is due. The PM stops chasing. The register stays current. The team spends its time managing risk instead of maintaining a file.

None of these examples is about replacing people. All of them are about giving skilled people their time back.

Productivity without adding headcount

Every project carries hundreds of small, repetitive, rule-based tasks. Individually they're trivial. Collectively they consume thousands of hours on a large-scale, multi-centre project. And they don't scale linearly — when the work is split across centres, people rotate and procedures drift, the failure rate climbs faster than the headcount does. The bigger the project, the worse the trade.

That's where I think GenAI has the greatest potential in our industry. Not producing core engineering deliverables. Not replacing experienced professionals. Just absorbing the rule-based work that sits between the deliverables — the work we currently solve by hiring someone, somewhere, more cheaply.

If we can take that load off, we don't just improve a productivity metric. We let talented people spend their time on the work they were actually hired to do.

That seems like a better place to start than asking where we can find cheaper labour.

---

If you want to test this against your own project, I've put the document control cost model on this site as a calculator — plug in your document count, revision profile and rates, and it'll show you where your money is actually going. Every assumption is visible and adjustable, so if you think I've got one wrong, change it and see what happens.

I'm writing a series on where automation actually holds up in project execution and where it falls over. The next one is about the tasks GenAI should never be given.