WorkClear checks that work is genuinely ready before it's released to the field.

By the time the problem became obvious, it wasn't a problem anymore. It was a recovery programme.

On a major LNG expansion, a discrepancy in the early works wasn't fully apparent until construction was well advanced.

By then, the effects had started to spread.

Foundations and underground services were conflicting. Remedial work was competing with planned construction. Major equipment and pre-assembled modules were arriving against a baseline that assumed the site would be ready to receive them.

The original sequence was becoming increasingly difficult to execute.

The problem wasn't simply that the schedule needed updating. There were too many interdependent constraints for a simple resequencing exercise.

Several recovery scenarios had to be worked through — looking at the interaction between resources, work fronts, interfaces, logistics and the remaining construction sequence. Some solutions solved one problem only to create another somewhere else.

Eventually, a practical way forward was identified, agreed and implemented.

The experience reinforced something I've seen repeatedly on major projects:

A schedule can remain logically correct long after the conditions that made it executable have changed.

The challenge is not always knowing what should happen next. It is knowing whether the conditions actually exist to make that next step work.

That is the thinking behind WorkClear:
Connect the pieces. Test the real constraints. Compare the options. Release when the conditions are actually ready.

Because reported progress and execution readiness are not the same thing.

READINESS BEFORE RELEASE.

What's the smallest discrepancy that ever cost your project the most time?

When did you last know a Work Pack was blocked — before the crew arrived?

Not at the next progress meeting.
Not when the weekly dashboard turned amber.
Not at month-end when the variance finally appeared.

The problem isn't that projects lack information. It's that information doesn't necessarily stop work from being released when the conditions for execution aren't there.

That's the gap WorkClear is designed to control.

It sits between the systems that tell you what should be happening — Primavera, SAP, Aconex and others — and the point where work actually reaches the field.

The question isn't “Is this activity on the schedule?”
It's “Is this Work Pack genuinely ready to execute?”

If it isn't, it shouldn't be released.

Bent Flyvbjerg spent decades studying why megaprojects go wrong.
His conclusion became known as the Iron Law:
Over budget. Over time. Over and over again.

His research found that roughly 9 in 10 megaprojects run over budget.

And the pattern is still visible today.

A June 2026 analysis of more than 20 North American LNG export terminals found that completed projects had averaged 59.7% above their original cost estimates. Projects still under construction were already averaging 38% over.

One compounding factor is the increasing pressure to compress schedules by overlapping phases that were once allowed more separation. Engineering, procurement and construction now have to move in parallel, with more interfaces that must remain synchronised in the field.

After 40+ years on major EPC projects, I've watched the same thing happen from a different angle.

The engineering isn't necessarily what fails.

The problem is often the gap between what the schedule says should happen and what the site can actually execute.

The drawing isn't issued.
The material isn't at the work face.
The predecessor isn't complete.
The crane isn't available.

The work pack gets released anyway.

And nothing necessarily looks wrong in the schedule — until the crew stands there with nothing productive to do.

By the time that lost productivity appears in the monthly report, the money is already spent.

That gap is one of the reasons I built WorkClear.
Not another dashboard.
A control layer between the plan and the physical work face — checking whether work is actually ready to execute before release, then feeding verified field progress back into the schedule.

Because perhaps one of the most expensive questions on a major project is also one of the simplest:

Can this work actually be done today?

How are you controlling it on your projects?

16,000+ projects studied across 136 countries. One average: 62% over budget.

Why do we continue accepting that outcome when execution control is a solvable problem?

After forty years across O&G and EPC mega-projects on four continents, I can tell you with certainty:

Projects rarely fail because of complex engineering, difficult logistics or geographic spread.

They fail because what the project believes to be true slowly drifts away from what is actually true.

A drawing is marked Current.

The crew is working from an older revision.

Material is reported Available.

It isn't physically available where the work is about to start.

A Work Pack is shown as Ready.

A predecessor activity hasn't actually been completed.

One incorrect assumption doesn't sink a project.

Thousands of them do.

Across hundreds of Work Packs.

Multiple disciplines.

Multiple contractors.

Multiple execution locations.

Each day, the gap between what the schedule says and what the field can actually execute grows a little wider, until the monthly report finally reveals what the project has already paid for.

By then, it isn't a variance.

It's a write-down.

That is exactly why I built WorkClear.

Not another dashboard.

Not another reporting layer.

Not another scheduling tool.

A true Project Execution Control System.

Every Work Pack carries a live execution status based on three questions:

Is the drawing current?

Is the material physically available?

Is every predecessor complete?

If the answer to any one of those questions is No, the Work Pack is not execution ready.

The system says "No" before the project pays "Yes."

That philosophy wasn't developed in a software laboratory.

It was developed over forty years of watching the same failures repeat themselves across some of the world's largest capital projects, then engineering those lessons into a practical execution control system.

Not a concept.

Not a prototype.

Not a roadmap.

A working system.

If your project is reporting "On Track," ask yourself one question:

What independently verifies that today's Work Packs can actually be executed, rather than simply reporting that they should be?

The Execution Readiness Assessment answers that question in one week, with fixed scope and fixed cost.

Sometimes the greatest project risk isn't the problem you know about.

It's the one your reporting tells you doesn't exist.

#ProjectControls #CapitalProjects #ExecutionReadiness #EPC

A crew mobilises on Monday morning.

The Work Pack has been on the schedule for weeks.

The Discipline Lead confirmed it in Friday's meeting.

The Foreman has his team ready.

By 08:30 the crew is standing down.

The cable drums are still in transit.

Three line items are short.

Material Control knew on Thursday.

The information didn't reach the Discipline Lead before he committed his crew.

Nobody made a mistake.

The delivery status existed in the system.

The constraint was real and documented.

The problem was that the person making the mobilisation decision and the person holding the material status were operating in completely separate information spaces — and there was no mechanism to connect them before the crew left the yard.

This happens on almost every large EPC project.

Repeatedly.

The cost isn't the standing time on Monday morning.

The cost is everything that happens next.

A crew stood down creates pressure to mobilise elsewhere, often into work that isn't ready either.

Constraints get overridden.

Shortcuts get taken.

The schedule absorbs the damage quietly — until it doesn't.

The root cause is almost never procurement failure.

It's visibility failure.

The information existed.

The decision-maker couldn't see it.

The material status was current.

The delivery tracking was accurate.

The expediting log was up to date.

None of that information was visible to the Discipline Lead at the point when it would have changed his decision.

On a project running fifty active Work Packs across eight disciplines, that gap — between where the status lives and where the decision gets made — is where standing time is manufactured, week after week.

Constraint Management — the silent schedule killer

Every project has constraints.

Most projects don't manage them well, and pay for it.

A constraint isn't a risk. It isn't an issue.

It's a known condition that will stop work before it starts — and on large capital projects, unresolved constraints are responsible for more schedule bleed than most teams ever account for.

The pattern is always the same.

A work pack is issued.

The crew is mobilised.

Materials aren't on site, or already consumed.

The work stops — because the bad decision wasn't visible.

By the time the issue surfaces, the loss and delay are already locked in.

WorkClear treats constraint management as a first-class discipline.

Every work pack carries its constraint register — but more importantly, the impact of each unresolved constraint is visible across the execution chain before it becomes a schedule event.

Field supervisor to programme director.

No translation layer.

Constraints don't resolve themselves.

They resolve when someone owns them, tracks them, and is accountable for clearing them before they become schedule events.

How does your project identify a work pack that cannot start next week — before the crew arrives at the gate?

Schedule says go.

Materials say no.

The silence was painful.

That gap — between what the programme says is executable and what the field can actually build — is where most productivity losses are born.

Not in the schedule.

Not in the design.

In the space between them.

I've watched crews stand idle on billion-dollar projects while someone upstream was still reporting green.

The work was planned.

The resources were mobilised.

The materials weren't there — or already utilised elsewhere.

Execution doesn't fail at the decision point.

It already failed three weeks earlier,

when nobody connected the constraint to the programme.

Most project reporting tells leadership what slipped last week. WorkClear shows what cannot execute tomorrow morning.

That single shift — from lagging indicators to execution readiness — is the difference between managing consequences and preventing them.

On major capital projects, failure rarely begins with a crisis.

It begins with:

a late drawing nobody flagged downstream,

a procurement hold nobody connected to the workfront it would stop,

a field constraint everyone already knew about — but leadership only discovered weeks later.

The field usually knows the truth first. The silence between that truth and the boardroom is where projects lose millions.

Most project controls systems measure progress. Very few can answer a simpler operational question:

Can the work physically execute tomorrow?

WorkClear does.

One operational layer. Every discipline. Every constraint. Every dependency. Visible before the cost event happens.

And when the questions come later — the answers are already there. Every constraint. Every escalation. Every decision. Time-stamped and traceable.

Not software. Not digital transformation. Earlier operational truth. And a permanent operational record of it.

Last week I shared the problem. This is the answer.

500+ people read that post. More than half opened the demo. The question I kept getting was: what exactly does it do?

So here it is — the WorkClear System Overview. Six pages. No padding.

→ Slide 2: Why EPC projects fail — and it's not poor planning

→ Slide 3: What WorkClear actually is — an execution layer, not another planning tool

→ Slide 4: How the constraint model works — materials, drawings, predecessors

→ Slide 5: Who uses it and what each role gets

→ Slide 6: What a pilot looks like and what it costs to find out

Built by people who've been on these projects. The terminology is deliberate.

After 40+ years working on major EPC projects across four continents, one problem kept showing up again and again.

Not poor planning. Not bad people. Not even tight budgets.

Work being released to the field before it was actually ready to execute.

Materials not on site. Drawings not issued for construction. Predecessor activities not complete. Crews mobilised, work stops, rework follows — and nobody has a defensible record of why.

I've watched it happen enough times to know it's not a people problem. It's an execution-readiness problem.

So I built WorkClear to close that gap.

You already have the systems — P6, SAP, Aconex. WorkClear doesn't replace them, it eliminates the departmental silos between them.

It's the information bridge between what they already know, and the decision to release work to the field. No major system replacement. No new field hardware. Just the phone already in the Discipline Supervisor's pocket, and the PC on everyone's desk.

Where does your project actually find out a work pack isn't ready to execute — at the pre-start meeting Monday morning, or days before, while there's still time to do something about it?

Are you still relying on Excel sheets and filtered departmental reports to make executive decisions?

Every Oil & Gas, LNG, and Mining & Minerals project runs into this somewhere.

Engineering sees one reality.

Procurement sees another.

Field sees another.

By the time it reaches the director's desk, it's been filtered — and it's weeks too late to act on.

We built WorkClear to close exactly that gap.

One system, one version of the truth, from the field to the boardroom — in real time, not at the next progress meeting.

See what that actually looks like on a live project — try it yourself, no sign-up required.

Have you ever lost days because one drawing revision reached site too late?

The Drawing Revision That Cost Three Days

Monday morning.

The work pack was released.

Drawing current. Materials staged. Permit approved. Access cleared. Equipment on site.

Five out of five.

By every check anyone had run, the work was ready.

The crew started cutting.

Tuesday afternoon, a structural engineer discovered the drawing had been superseded eleven days earlier.

A clash on an adjacent tie-in had forced a revision.

The new revision existed.

It simply hadn't reached the crew carrying out the work.

Nobody had ignored a procedure.

Nobody had skipped a step.

The document control register showed the revision had been issued, distributed and acknowledged.

Just not by the one team about to build from it.

Three days of cutting, fitting and welding had to be inspected, partially reworked and re-sequenced around other crews now waiting on the same tie-in.

The schedule said the work was ready.

The document register said the drawing was current.

Neither one verified what was actually in the hands of the people doing the work.

Execution certainty isn't about whether information exists. It's about whether the right information reaches the right people before work begins.

Where does your project verify that the crew in the field is working from the latest approved information before the first tool is picked up?

On most EPC projects, information doesn't disappear.

It gets filtered.

A Discipline Lead reports an issue.

A Construction Manager condenses it.

A Project Manager summarises it.

A Project Director receives the final version.

Nobody is lying.

Nobody is hiding anything.

But every layer makes decisions about what matters, what can wait, and what deserves attention.

The result is that the person ultimately accountable for the outcome often receives the information long after the point where it could have changed the outcome.

That's why projects are full of surprises that weren't actually surprises.

The warning signs existed.

The constraints were visible.

The risk was known.

Someone, somewhere, was already talking about it.

A delayed material delivery.

A permit still awaiting approval.

A design query sitting unanswered.

A critical activity quietly slipping by a few days.

None of these events are particularly dangerous on their own.

The danger comes when the signal becomes weaker at every reporting layer.

By the time it reaches the project leadership team, the issue has been shortened, summarised, blended together with twenty other issues, and stripped of the context that made it important in the first place.

Most reporting systems were designed to move information upward.

Very few were designed to preserve its original meaning.

And that's where execution starts to drift.

Not because people are incompetent.

Not because people are dishonest.

But because the reporting architecture itself creates distance between decision-makers and the reality of the work.

How many reporting layers exist between your Project Director and the people doing the work?

Most projects already have this reporting chain.

Discipline Leads. Construction Managers. Project Managers. Directors.

What they rarely have is a system that preserves the operational truth as information moves through it.

Every update gets summarised.

Every summary gets interpreted.

Every interpretation creates distance from the work itself.

WorkClear was built to close that gap.

Field to boardroom.

Every discipline.

Every constraint.

Every layer preserved, timestamped and attributable from the moment it is submitted.

Not another reporting process.

A connected execution system.

A major capital project. Four execution centres. Three time zones.

Engineering offshore. Procurement offshore. Client management removed from the field. EPC execution on the ground.

Nobody lied. Nobody was incompetent. Everyone was doing their job.

But materials were arriving in fragments. Partial POs. Incomplete work packs. The field couldn't sequence. The schedule hadn't reflected it yet.

When it finally surfaced, the solution wasn't a system change.

It was headcount.

Permanent staff embedded on-site to manually bridge the visibility gap.

Material control teams expanded to cope with fragmented deliveries the existing structure couldn't track.

Field engineering strengthened for the same reason — incomplete work packs don't just stop materials. They stop execution.

Neither cost appeared as a risk item.

Both appeared on the org chart.

The failure didn't happen in the field.

It happened in the silence between four locations operating without a shared operational picture.

That silence exists on most split-geography projects running today.

The question isn't whether the gap exists.

The question is whether leadership can see it before the project starts hiring to compensate for it.

A Project Director signs off this month's schedule variance report. It shows green.

Nobody lied. Nobody broke a rule. Yet six months later, the project still lost the claim.

Several overrides were logged to get there. Each one, on its own, was defensible — a missing inspection waived, a hold point pushed, a sequence swapped to keep a crew working.

The problem wasn't any one decision. It was that nobody ever saw the pattern.

Individually reasonable decisions were never rolled up, never reviewed together, because there was no single place where every override was captured with a reason attached.

Six months later, when a delay claim lands or an EOT is contested, someone has to reconstruct that pattern from emails, notebooks and whoever is still on the project. That's where disputes are won or lost — not in the schedule itself, but in whether the decision trail is still defensible.

P6 records the plan. Site systems record what happened. What usually disappears is why someone was authorised to deviate. By the time that question matters, the project team has changed and the evidence is scattered.

That's the reason we built WorkClear: every override captured with a reason code at the moment it happens, rolled up so leadership sees the pattern before it becomes a contractual dispute — not after.

Electrical Work Pack A is due to finish on schedule.

Not all the specified cable is on site yet.

A Discipline Lead knows there's a heavier drum in the warehouse — allocated to Work Pack B, still months away.

Using it now means the trench closes today, and three other work-fronts stay open instead of standing idle.

In the moment, it's the obvious call.

Months later, the correct cable for A finally arrives.

Only then does it become apparent: that drum had been selected because Work Pack B's future load required its higher capacity.

Now there are three costly options:

• Accept the limitation and leave Work Pack B under-spec for its future load.

• Rework Work Pack A and procure replacement cable for B.

• Restore both to their original specification, accepting the delay and additional cost.

Nobody made a bad decision. Nobody could see the whole picture.

Substitutions aren't the problem. Invisible substitutions are.

In WorkClear, that same material decision is visible the moment it's made — on the mobile in his pocket:

• which work pack the stock was engineered for

• what it was being held for, and why

• who authorised the substitution, at what level, and why

The field still makes the call. WorkClear makes sure nobody downstream finds out too late.

A Construction Manager authorizes a Piping Work Pack to proceed.

The specified valves aren't on site.

To keep the crew productive, dummy spools are fabricated instead.

In the moment, it's the right decision.

Nobody stops to record it.

A year later, during close-out, the rework and material costs surface.

Nobody can explain who authorised the deviation.

Nobody remembers why it was necessary.

The people involved have long since demobilised.

Another write-down quietly erodes the project's margin.

Field decisions aren't the problem. Untraceable field decisions are.

On one project — actually on four — the same thing happened.

Engineering was chasing perfection. Or stretching the work. Either way, the design kept moving.

Procurement had already locked material against AFC 1. By the time AFC 3 was issued, the orders were placed. The equipment was already coming.

Field couldn't wait. Work Pack A material started disappearing into Work Pack C. Crews kept moving. Progress still looked acceptable. The weekly report said so.

Nobody flagged it. Each decision was locally rational. Collectively, they were consuming float that no longer existed.

Then a night shift appeared.

Small crew. Quiet.

Nobody questioned it.

It solved a problem. Materials were staged and ready every morning.

Dayshift productivity appeared to improve.

The project had quietly built an entire parallel labour structure whose sole purpose was compensating for a visibility failure nobody had formally acknowledged.

It showed up on the payroll. Not on the risk register. At least not yet.

By the time leadership recognised the pattern, the float was gone. The extension wasn't a forecast anymore. It was already baked in. The reports just hadn't caught up yet.

This happened in Africa, Iraq. In Kazakhstan. On a major LNG project in Australia.

Different clients. Different contractors. Same sequence.

Most reporting systems never register these moments as risk signals. By the time they surface, the extension is usually already inevitable.

How many people on your current project exist purely to compensate for a problem nobody has formally acknowledged yet?

A dashboard tells you a project is behind.
It can't tell you why the crew stood down this morning.

Most project reporting tells you what has already happened.

The schedule says the activity is late.
The cost report shows the variance.
The dashboard turns red.

But the field doesn't work from yesterday's status.

Before a Work Pack reaches the crew, someone needs to know:

Is the drawing current?
Is the material actually on site?
Is the predecessor genuinely complete?

If the answer is no, the work isn't ready — regardless of what the schedule says.

That's the distinction I'm interested in:

A reporting system tells you what happened.
An execution control system determines what is ready to happen next.

The value isn't another red status. It's preventing work from being released when the conditions for execution aren't there.

Where does your project currently establish that a Work Pack is genuinely ready — before the crew finds out that it isn't?

A delayed work pack rarely appears as a delayed work pack in the final cost report.

It appears as something else.

Lost productivity.

Re-sequencing costs.

Additional supervision.

Equipment standing time.

Overtime.

Acceleration.

Contractor claims.

The original cause disappears beneath layers of secondary cost — and by the time the cost report reflects the damage, the trigger event is six months in the past and three management layers removed from anyone still paying attention to it.

That's why project overrun investigations are so consistently frustrating.

Everyone agrees the overrun is real.

Nobody agrees where it started.

The argument consumes months of senior time, generates competing narratives, and usually settles somewhere between an uncomfortable negotiation and a formal dispute — neither of which recovers the money.

The trigger is almost never where the cost landed.

A material delivery that slipped by four days.

A constraint that sat unresolved for two weeks because the right person never saw it.

A work pack released to field before it was genuinely ready because the schedule pressure was real and the visibility wasn't.

A crew mobilised into work that couldn't start.

None of these events look catastrophic in isolation.

On a large EPC project running hundreds of active work packs, they barely register at the time.

The commercial damage wasn't created by the event itself.

It was created by the decisions made afterwards.

The re-sequencing.

The overrides.

The pressure to recover.

The shortcuts taken under schedule duress.

And those decisions were only as good as the information available when they were made.

That's the chain.

Information distortion.

Visibility gaps.

Poor decisions.

Commercial consequences.

Most post-project reviews identify the consequences clearly.

Very few trace the chain back far enough to identify where it actually started.

The project was reporting green.

The board was satisfied. Progress curves holding. Weekly report signed off. Nobody had told them that three critical work packs had been blocked for eleven days. That field productivity was already deteriorating and nobody had connected it to the constraint register. That two discipline interfaces had silently diverged six weeks earlier — Engineering knew, Procurement knew, Field supervision knew — but it never reached the desk where the decision lived.

By the time it did, the options were gone.

I've watched this happen across four continents over 40 years.

The teams weren't incompetent. The projects weren't unlucky.

The execution layer was fragmented — and management was always the last to know.

That is not a people problem. It's an information architecture problem. And it destroys projects the same way every time — not in a sudden collapse, but incrementally, silently, until the remaining options become expensive, political, or impossible.

The money wasn't lost when the report showed the damage.

It was lost three weeks earlier, while the project still reported green.

Most organisations already know they have this gap.

They're absorbing the cost of it — project after project — while the fix keeps getting deferred because the reporting structure still appears to be functioning.

Right up until it isn't.

And once delay becomes visible in formal reporting, recovery is already exponentially more expensive.

WorkClear was built to close this gap.

Not another dashboard someone manually feeds on Friday afternoon. Not another reporting layer explaining last week's problems in this week's meeting.

A single live execution environment where the Project Director sees what is executable, what is blocked, what constraint is causing it, and how far the impact will propagate — before it becomes visible in traditional reporting.

A previous generation of this concept was developed inside a major Gulf EPC organisation at significant corporate investment. The concept worked. The implementation was flawed. Every lesson learned over the past decade has been built into WorkClear — and it's now available to you.

I have capacity for a limited number of structured pilot deployments this quarter.

After 40 years across O&G and EPC mega-projects on four continents, I can tell you this with certainty:

The projects that bleed aren't usually the ones with the hardest engineering challenges or logistics.

They're the ones where the execution layer goes dark.

One project I worked on moved from roughly $23B to over $30B between approval and first gas.

Not because the geology changed. Not because the market collapsed.

Because visibility between the field and the boardroom broke down.

And every experienced Project Director already knew the job was slipping long before the reports confirmed it.

The problem was never instinct.

The problem was proving it early enough to stop the bleeding.

The most dangerous moment on any mega-project isn't the crisis.

It's the silence.

The weeks where:

progress appears normal,

reports still look acceptable,

but execution reality has already drifted away from the plan.

That gap is exactly what I've spent the last two years solving.

WorkClear was built from real project experience:

field execution,

constraints,

interfaces,

labour performance,

contingency control,

and operational visibility across the entire delivery chain.

Not another dashboard. Not another reporting layer.

Execution discipline — built from the field up.

First production database now live. Pilot deployments are intentionally limited.

The site team is always the last to know.

I've worked on projects where engineering, procurement, and site execution were spread across multiple time zones — each team running their own tracking, in their own format, for their own visibility. By the time a revision made the journey to site, work had already moved on. The workaround was duplicating resources just to bridge the gap.

On another project, the back office was closer — but still removed. A dedicated engineer spent his days fielding queries and reconciling what procurement had delivered against what drawings had changed. The construction manager, who should have been leading execution, was chasing materials and making judgment calls in the dark.

Different geographies. Different setups. Same result: the people doing the work were the last to know what had changed, what had arrived, and what was actually cleared to execute.

This is not a technology problem. It never was. It's a visibility problem — and it plays out on complex projects everywhere.

WorkClear was built from exactly these experiences. Not as another reporting tool for the back office — but as a field-execution platform for the people on the ground. RAG-status work packs. Live constraint tracking. Clear role-based visibility at every level, from field supervisor to project director.

I've seen a project stall as early as 75% complete.

I've seen another sit at 98%, with crews standing around waiting for scraps of work that never seemed to run out.

And 90% is where I've seen the gap become particularly difficult to ignore — actual progress starts quietly pulling away from the completion forecast, and nobody wants to be the one to say so.

None of those percentages were wrong. That's what makes this dangerous.

A percent-complete figure is honest about what's been finished. It says nothing about whether what's left can actually be executed.

By the time a project is deep into execution, the easy work is long gone. What's left is disproportionately the hard, interface-heavy, schedule-critical scope — drawings still catching up, material still in transit, predecessors that are “done” on paper but not yet in the field.

Before the next Work Pack releases, four things have to be true. Not roughly true. Not “on track.”

Drawing current.
Material physically on site.
Predecessor genuinely complete.
Quantities actually counted — not estimated.

The percentage doesn't release the crew. Execution readiness does.

What's the highest percentage complete you've ever seen on a project that still couldn't release the next work front — and what got you there?

A recent analysis of more than twenty LNG terminals across North America found average cost overruns of 59.7% on completed projects — and 38% on those still under construction.

This isn't a legacy problem the industry has grown out of. It's happening on today's builds.

One project I worked on scope-crept by more than $7 billion between approval and first gas. Two trains. No single decision explains it.

Late engineering changes flowed into construction. Process decisions landed after the work they affected had already started. By commissioning, the gap between design intent and installed reality had to be found the hard way.

A loop-check is usually where that gap surfaces first.

An instrument tag doesn't match the latest P&ID revision — it was installed against an earlier iteration. Cable routing was field-changed months earlier and never made it back into the loop folder.

The technician signing off has no way to tell whether it's a paperwork lag or a real installation error. So it goes to query. And it waits.

Multiply that across every loop, every train, every discipline interface, and "a few days behind" in the weekly report becomes the number nobody wants to explain a year later.

A Piping Work Pack is marked complete.

Structural sign-off is on file.

The pipe supports aren't there.

The steel contractor had closed out three days earlier because, in his system, "complete" meant his scope was finished — not that the interface with the next trade had been verified.

The Piping crew mobilises. They find the supports missing.

Two days are lost waiting for Structural to remobilise a crew that has already moved to another package.

Nobody lied. Nobody broke a procedure. Both contractors did exactly what their own scope required.

The gap wasn't in the work. It was in what "done" meant when one contractor handed the work to the next.

Piping was ready to start. Structural wasn't ready for Piping to start. Both records said complete.

Everything was green. That's what the report said.

Sometimes that means the project is healthy. Sometimes it means nobody has reported the problem yet.

I worked a mega-project where Construction declared a system 100% installed. Completion certificates were signed. On paper, it was done.

Then Commissioning started verifying it before taking ownership — and it wasn't fine. A defect that should have stopped the handover cold, but didn't.

By then, first gas was scheduled. An official visit was booked. Nobody wanted to be the one to raise the flag that cancelled a ceremony already on the calendar.

So the field found a way to get one train ready in time to hold the schedule. The board didn't know until months later. The ceremony had already happened. The vessel had already sailed.

Nobody lied on that report. The certificate was signed in good faith.

The problem wasn't dishonesty. The problem was that "Installed" and "Verified" were treated as if they meant the same thing.

They don't. One confirms the work was completed. The other confirms the system is actually ready to hand over.

Between those two words is where some of the biggest execution failures begin.

Most project reporting systems have the same fundamental design assumption.

Information flows upward.

The Discipline Lead feeds the Construction Manager. The CM feeds the Project Manager. The PM feeds the Project Director. Each layer receives a version of what the layer below it chose to pass on.

The assumption built into that design is that everyone needs the same information — just at different levels of detail.

That assumption is wrong. And it's part of why execution drifts.

A Discipline Lead doesn't need portfolio RAG status. He needs to know, three to seven days out, whether his materials are on site, his drawings are current, and his predecessor work pack is trending toward ready — so he can commit his crew without standing them down on Monday morning.

A Construction Manager doesn't need the same depth on any single discipline. He needs to see across all of them simultaneously — what is ready, what is drifting, and critically, what cascade risk a constraint in one discipline creates for the three disciplines that follow it.

A Project Manager needs control over what goes to field and when. Override authority. Constraint visibility at a level where commercial decisions can be made with full context.

A Project Director needs exceptions, portfolio exposure, and the ability to drill straight through to source data at any layer, any time, without waiting for a report or requesting a breakdown from the team below.

These are not the same job. They are not the same decisions. They should not be the same view.

The problem on most projects isn't that information is unavailable.

It's that the wrong people are looking at the wrong slice of it, at the wrong time, assembled from the wrong sources.

A system designed around how decisions actually get made — with each role seeing exactly what they need and nothing they don't — doesn't just improve reporting. It changes the quality of the decisions themselves.