Assurance Was Always a Capacity Problem

I've spent most of my career around projects in trouble, and the thing that strikes me is how rarely the cause is surprising. It is almost never an exotic risk that nobody could have modelled. It is basic stuff: scope that isn't in the schedule at all, logic that doesn't reflect how the work will actually be built, productivity assumptions that were never checked against anything. All of it visible months before it bites.

On the other side, I have never once walked onto a project and found the project controls team over-staffed and short of things to do.

Assurance isn't a knowledge problem

The industry is not confused about what good assurance looks like. Nobody needs to be told that you should reconcile scope to the WBS, interrogate the logic, benchmark the durations, and stress-test the critical path before you commit to a date. Ask any experienced planner what a proper review involves and you'll get a clear and largely consistent answer.

What's missing is hours. Assurance is done late, done thinly, or not done at all — not because the team lacks judgement, but because the monthly report has a deadline attached and assurance doesn't. It's the work that gets deferred, every month, for entirely rational reasons.

A technically compliant schedule is not a good schedule

The DCMA 14-point assessment, and the family of similar programmatic checks that have grown up around it, are genuinely useful. They are fast, objective, repeatable, and they catch real problems: open ends, hard constraints quietly doing the scheduling for you, lags standing in for missing logic. I am not arguing against running them. We run them too.

But they should not be mistaken for assurance.

Those checks read the structure of a network. They cannot read the sense of it. They will not tell you:

• that an entire package of scope is missing from the schedule
• that a relationship exists because it made the bars line up, not because one activity genuinely constrains the other
• that the earthworks productivity varies by 40% for the same kind of work by the same contractor
• that the durations were reverse-engineered from the contract dates rather than built up from quantities and outputs
• that the sequence in the schedule is not the construction method the team actually intends to use
• that procurement, approvals and consents are simply not modelled

Some of the worst schedules I have ever seen were technically compliant. That is not a coincidence. A pass rate is a comfortable number to put in a report, and that is exactly what makes it dangerous: it quietly converts "we didn't have the time to assess this properly" into "the schedule passed".

Real assurance is an act of judgement. Someone has to read the thing, understand what is being built and how, compare it against what has actually been achieved before, and form a view. Until very recently that meant an experienced human and a great many of their hours — which brings us straight back to capacity.

What changed

Until about a year ago there was no way around that constraint. If you wanted the thinking, you bought the hours, and the hours were scarce and expensive.

That is no longer true. Agents — with the right domain training, the right specialisation, and the right tools to actually open a schedule and interrogate it — can now take on a large part of that assessment work. Not the final judgement call, but everything that has to happen before it: reconciling scope, testing whether logic is causal, benchmarking durations and productivity against history, running the what-ifs, and writing the whole thing up.

This isn't speculation about where the technology might go. It already happened in software engineering and in cyber security, where agentic systems now outperform people across a wide range of genuinely hard tasks. Those domains went first because they had tight feedback loops — the code runs or it doesn't, the exploit works or it doesn't. Project controls has more of that structure than it gets credit for: a schedule is a machine-readable artefact with rules you can test against and a history you can compare it to.

What it looks like on a real project

The work we are doing with Consultants, Contractors and Asset Owners is this new way of doing assurance. Instead of ticking boxes, AI Coworkers run the analyses, the benchmark studies and the pre-mortems that the project controls team always wished they had the time for.

The day-to-day change is where it becomes obvious. Controls teams spend the bulk of their time — on the projects I see, something like 80% of it — on manual data handling: moving numbers between P6, Candy, Excel, …, and the reporting pack. That work is repetitive and rule-bound, and it is exactly what should be delegated. What's left is the part that needs a person: evaluating the outputs, and solving the problems they surface.

It is also a great deal faster. You get to your desk in the morning and your team of agents has spent the night working through every supplier schedule, running the time impact analyses, producing the change reports, identifying mitigation options, and writing all of it up in your reporting formats, ready for review. Not a blank page to start from, and not a draft to rewrite — a piece of work to review, challenge, and either sign off or send back.

That is the real unlock. It isn't that the analysis got cheaper. It's that it is finally complete, applied consistently across every schedule rather than the two you had time for, and it arrives before the decision instead of after it.

Supervision is the job now

It does not mean the expert leaves the loop — the opposite. Their judgement stops being the scarce resource that rations how much assurance a programme can afford, and starts being applied to everything.

And it does not mean taking the output on trust. Anything producing assurance output has to show its working: which activities, which numbers, which comparison, traceable back to the source schedule. The reviewer needs to be able to check a finding in seconds rather than reproduce it from scratch. If they can't, you haven't moved the work — you've just moved where it's done.

Get that right and the two most persistent bottlenecks on any large programme — the capacity of the controls team, and the length of the decision-making cycle — stop being fixed constraints. That, far more than any individual analysis, is what changes how projects get managed.

If you're thinking about what this means for your assurance function, I'd be glad to talk it through — get in touch.