The future of project controls, when AI does the gathering

The critical path method was published in 1957, by two engineers at DuPont and Remington Rand who wanted to know which activities in a plant shutdown actually decided its length. PERT followed a year later, for the Polaris programme, adding the idea that a duration is a distribution rather than a number. Almost seventy years on, both methods are still right. A schedule is a network. Float is where the slack lives. The path with none of it decides the date. Nobody has improved on that, and nobody needs to.

What has not aged well is everything around the method. The schedule is still updated on a cycle, usually monthly, because updating it is work. The cost report lags the schedule because reconciling it is work. The risk register is reviewed quarterly because reading the letters that would change it is work. The contract's deadlines are tracked in a spreadsheet by one person who knows where it is. The method is instant; the cadence is slow, and the cadence is slow because gathering is slow. This post is about what happens to the discipline when the gathering is done by machines, continuously, and the people are left with the part that was always theirs: deciding what the record means and signing for it.

It is the third and last post in this series. The first described a night shift of agents, each with one job and one tool belt, meeting in a morning brief. The second described a project simulated a thousand times every night so that every decision is rehearsed before it is made. This one steps back and asks what project controls looks like as a profession, a department and a cost line when those two things are ordinary.

What does not change

Before the shifts, the constants, because the loudest predictions about AI in construction tend to forget them.

The record. There is still one project record: the schedule, the cost book, the risk register, the contract with its dates, the model with its progress. It is the thing the client audits, the thing a tribunal reads, the thing a new project director inherits. Machines will keep it current; they do not replace it with a conversation.

The baseline. A baseline is a promise with a date on it. It is locked for a reason: so that drift can be measured against something that does not drift. No amount of intelligence changes the need for a fixed point. If anything, a record that moves every hour needs a baseline more than one that moves every month.

The contract. Notices still have deadlines. Clause 8.4 still says fourteen days. A machine that becomes aware of a delay at 19:40 on a Tuesday does not change what the clause requires; it changes whether anyone noticed that the clock had started.

The person who signs. Every decision that changes the project carries a name and a time. That is not a limitation imposed on the machines for comfort. It is the definition of a decision. A change nobody signed for is not a decision, it is an accident, however well computed.

Hold those four steady and the rest can move a long way.

Four eras, one measurement

The honest way to measure a project controls system is not by how pretty its reports are but by decision latency: the time between a fact happening on the project and a person deciding with that fact in front of them. The first post in our other series, on how old the news you decide on is, put that gap at weeks for a monthly cycle. Here is how it has moved across the eras of the discipline.

Two things stand out in the table. The first is that each era was limited by something that was not the method: compute, then copies, then charts, and now trust. The second is that the last row is the first one where the latency is shorter than the time it takes to hold a meeting. That is the threshold that changes the job, because it means the question asked in the review can be answered in the review.

The five shifts

What follows are the five changes we think define project controls in 2030. Each is paired with the thing that keeps it safe, because a shift without a safeguard is just a new way to be wrong faster.

Reporting to sensing. The monthly report exists because facts had to be gathered by hand, and gathering by hand has to be batched. When a supplier's letter is read the minute it arrives and linked to the purchase order, the clause and the activity it touches, there is nothing left to gather at month end. The report still gets written, but it is written from a record that was already current, which makes it a summary rather than an investigation.

Periodic to continuous. A schedule engine runs a twenty-thousand-activity network in milliseconds. The only reason it ran monthly was that feeding it took a month. Fed continuously, it runs continuously, and the natural unit of its output becomes the scenario: here is the plan, here is the plan with the valve slip, here is the difference. The plan itself does not move until somebody approves a scenario onto it.

One number to a distribution. This is the oldest idea in the list and the slowest to arrive. PERT said in 1958 that durations are uncertain. The industry agreed and then spent sixty years printing single dates, because running the uncertainty was expensive. It is not expensive now. A milestone in 2030 is a spread of dates, refreshed every night, and a recovery option is compared by the shape of its tail, not by its median. The second post in this series is about nothing else.

Tools to agents with tool belts. The scheduling tool, the cost tool, the document store and the register do not go away. What changes is who carries facts between them. Today it is the planner, with a keyboard. In 2030 it is a set of narrow agents, each allowed to call particular tools and report to a particular place, none of them allowed to change anything. The first post in this series describes five of them, hour by hour.

Dashboards to decisions in the room. A dashboard shows what someone decided to chart. A record that can be asked shows whatever the question needs, computed at the moment of asking, with its sources, and with the asker's own permissions. The practical effect is small to describe and large to live with: the review meeting stops producing action items to check things and starts producing decisions.

A working day in 2030, on a fictional project

Northgate Terminal is the fictional EPC project we use throughout this series: four storage tanks and a marine berth, about twelve hundred activities, a contract with delay damages, and a mechanical completion milestone called M4. The people are fictional too. Here is a Wednesday in 2030, by role.

07:00, the planner. L. Ferreira opens the brief. Overnight, a letter from Valvex, SUP-0877, moved the V-12 gate valves from week 39 to week 41. The schedule agent has already run the scenario: the hook-up's eight days of float are now minus six, and M4 moves to 23 November if nothing is done. Three recovery scenarios were tried against the whole schedule and ranked by days saved, each with its spread from a thousand runs. The planner's morning is not spent building any of this. It is spent on the question only a planner can answer: which recovery the site can actually execute, and what it does to the crews already committed on tank T-103.

08:10, the risk owner. M. Chen opens the proposed risk, R-0231, late gate valves on the T-102 hook-up. The proposal carries its evidence: the letter, the clause, the activity, and Valvex's two previous slips on this project. One of those past slips is a duplicate entry; M. Chen knows because it was his package. He corrects the probability, accepts the risk, and the acceptance is recorded with his name and the time. The register was wrong for about twelve hours, overnight, when nobody was deciding anything from it.

09:00, the review. S. Okafor, the project director, runs the weekly review in Teams. The question that used to end these meetings with an action item is asked out loud: what is driving the risk on mechanical completion. The record answers in the room, with the scenario, the risk and the letter as its sources, and with each participant seeing only what their access allows. The meeting decides on recovery S-3, erecting bents five to eight before T-103, because its spread has the shortest tail even though its median is not the fastest. The decision is recorded. The schedule does not change yet.

09:40, the approval. L. Ferreira approves S-3 onto the live schedule. Revision 14 is created with her name and the time. Every application that depends on the schedule updates from the same record: the forecast, the look-ahead, the model, the contract calendar.

11:00, the client call. The client asks whether the valve slip will be claimed. S. Okafor has a drafted notice under clause 8.4, prepared at 02:30 with the deadline computed from the moment the letter was linked, 6 November. She decides not to send it yet, records why, and the deadline stays on the calendar in case the position changes. The contract manager spent none of the morning finding the clause.

12:30, the cost engineer. The forecast for the affected cost lines was recomputed when the scenario was created and again when revision 14 was approved. The cost engineer's work is not the recomputation. It is the judgement about what the client will accept as a compensation event, and whether the crane extension for S-3 is cheaper than the damages it avoids. The figures for both sides of that question are in front of him, with their sources, before lunch.

14:00, the site. Two pours reported complete yesterday on the T-103 foundation were held overnight because no photograph showed them. The section engineer uploads the photographs that failed to sync, the hold clears, and the model turns those elements from reported to confirmed. A held update is a question; it was answered by the person who knew.

16:00, the forecast moves. With the pours confirmed and S-3 approved, the nightly simulation will run on a different project than it ran on last night. The spread for M4 narrows. Nobody wrote a report to make that happen. The report, when it is written for the month end, will be a summary of decisions that were already made with the figures in front of the people who made them.

The planner of 2030 is not the person who fills the record. She is the person who decides what it means.

What this does to the job, and to careers

The fear is obvious and worth stating plainly: if machines do the gathering, what is left for the people who were paid to gather. The answer is the part of the job that was always the valuable part and was always crowded out.

A planner today spends most of the week on four things: gathering facts, reconciling versions of the truth, writing them up, and deciding and explaining. The first three are where the hours go and the fourth is why the role exists. The shift moves the hours. Gathering and reconciling fall to the machines, writing up becomes editing a summary the record already produced, and deciding and explaining expand to fill the week.

That changes what a good planner is. Today a good planner is someone who knows where everything is and can rebuild the picture from scattered pieces under time pressure. In 2030 a good planner is someone who can read a scenario and say whether the site can do it, who can look at a distribution and tell a director what the tail means for the promise she made the client, and who can look at a proposed link and know it is wrong because the valves on that drawing are not on that tank. The knowledge is the same. The use of it is different.

Three consequences for careers follow.

• Domain knowledge becomes more valuable, not less. The machine proposes; the person who knows which proposals are nonsense is the one who makes the system safe. A planner who has walked the site is worth more than one who has not, because the site is the one thing the record cannot read.
• The entry path changes. Junior planners learned the project by keying its progress. That route closes. The replacement is reviewing proposals: a junior who checks a hundred proposed links a week learns the project faster than one who typed them, provided someone teaches them what to look for.
• Writing and explaining become core skills. When the figures are ready before the meeting, the meeting is about what they mean. The planner who can say in two sentences why the slower recovery is the safer promise becomes the one the director calls.

What does not follow is a smaller profession. A project that senses continuously produces more decisions, not fewer, because facts that used to arrive too late to act on now arrive in time. Those decisions need people who can make them.

The economics: a department, or a service that keeps the record

Here the future is already arriving in the shape of a question every owner and contractor will face: build a controls department, or buy the kept record as a service.

A controls department is a fixed cost that scales with the number of systems it has to reconcile. Each new source, a second mailbox, a subcontractor's schedule, a new ERP export, adds people whose job is carrying facts between copies. The department's output is a report, and its quality depends on how recently the gathering was done.

A service that keeps the record on its own platform is a different shape. The service's team runs the record: reading what arrives, keeping the schedule, the cost, the risk and the contract current every day, and delivering the figures, forecasts and reports. The client's own people log in, see everything live, and make the decisions. The service does not sit in the client's meetings and does not negotiate on the client's behalf; it is the information layer, not the authority. Its cost scales with the project, not with the number of systems, because the systems are read by machines rather than reconciled by people.

We are not going to put numbers on that comparison here, because the honest numbers depend on the project, the contract and how many people the owner already has. The structural point stands without them. In the department model the owner pays for gathering and gets a report. In the service model the owner pays for a kept record and keeps the decisions. The second is cheaper to run and, more importantly, it is faster to decide with, which on a capital project is where the money actually is.

There is a third shape, which is the department using the service's platform directly, with no team behind it. That works for owners who already have strong controls people and want them to spend their hours on judgement rather than gathering. The choice between the second and third shapes is one to make on a first call about the specific project, not from a brochure.

The risks, and the safeguard for each

A post about the future that lists no risks is an advertisement. These are the seven we take most seriously, each with the design that answers it. Several of them are not technical at all.

Invented figures. A language model asked for a float will give a number whether or not it has read the schedule. Safeguard: the model is not allowed to answer a figure question. It chooses the tool; the tool computes; the sentence carries the computed figure and its source. An answer that cannot be computed says so.

Automation bias. People approve what a machine proposes because it looks finished. Safeguard: proposals arrive with their evidence and their weakest link flagged, approvals carry a name and a time, and a sample of approvals is reviewed after the fact. A proposal that was approved in four seconds is a proposal nobody read, and the record can show that.

Lineage. When the record changes every hour, the question in a dispute becomes: what did we know, and when. Safeguard: every entry carries the document, the import and the time it came from; every change carries who approved it; baselines are locked. The record of 2030 is more auditable than the monthly report, not less, because nothing in it was retyped.

Model drift. The models that read documents improve, and sometimes change behaviour, between versions. Safeguard: the reading is separated from the computing. A new model version can misread a letter; it cannot miscompute a float, because the engine does that. Misreadings surface as flagged links and wrong proposals, which are cheap, visible and reversible by design.

Vendor lock-in. A kept record is only valuable if the client can take it away. Safeguard: the record is the client's, exportable in the formats the industry already uses, schedules as XER and XML, registers as spreadsheets, documents as documents. A service that keeps the record must be able to hand it back.

Contractual liability for notices. Under NEC the early warning and compensation event clocks are short and the consequences of missing them are severe; under FIDIC the notice provisions in clause 20 are no gentler. A drafted notice that is sent automatically is a liability nobody signed for. Safeguard: notices are drafted, dated and never sent by a machine. The contract manager sends or holds, and records why. The machine's job is to make sure the clock was noticed, not to act on it.

Access and confidentiality. A record that can answer any question will answer the wrong person's question if it is allowed to. Safeguard: every answer is given with the asker's own access and never more, in a meeting, a chat or a report, and each organisation's data is isolated at the row level. Verian's SOC 2 and ISO 27001 certifications are in progress; the access rule is enforced by the platform today regardless.

Notice the pattern. Each safeguard is a rule enforced by the platform rather than a promise about the model's behaviour. That is the design principle underneath the whole future described here: do not ask the model to be careful, build the system so that it cannot be careless in the ways that matter.

What to do in 2027

None of this requires waiting for 2030. A controls team can start moving in the right direction with what it has, and be ready when the machines arrive. In order.

1. Write down who may change what. For the schedule, the register, the cost book, the contract calendar and progress, name the one role that may change each and the roles that may only propose. This document is the foundation of every safeguard above, and most teams do not have it.
2. Put sources on figures now. Every date and number in the weekly report gets the revision, the document reference or the register row it came from. It is tedious by hand and it is exactly the habit the record will automate; a team that already thinks in sources will trust the automated version and catch its mistakes.
3. Pick one source and stop retyping it. Usually the schedule: take the XER directly rather than a planner's summary of it. Then the registers. Each source that reaches the record without a keyboard is one less version of the truth to reconcile.
4. Run the risk analysis more than once a year. Even quarterly changes the conversation from a date to a spread, and teaches the directors to read a tail before a machine shows them one every morning.
5. Write the review's standing questions down. What is driving the risk on the next milestone, which notices are due, what moved since last week. These are the questions the record will answer in the room; a team that has agreed what they are will know what to ask.
6. Decide, as a leadership question, whether you are building a department or buying a kept record. The answer shapes hiring for the next three years. It deserves a first call about a specific project rather than a slide.

Where this stands

Verian is a project controls service run on Verian's own AI platform. Today, Verian's team keeps a client's project record current on that platform: the schedule, the cost, the risks and the contract read from the documents and systems the project already produces, documents linked to the work they touch the day they arrive, risks proposed from evidence, recoveries tried as scenarios against the whole schedule, notices drafted against the contract's deadlines, and progress that does not add up held with a question. Verian's team delivers the figures, forecasts and reports. The client's people log in, see everything live, and make the decisions. Verian does not sit in the client's meetings and does not negotiate for the client.

Of the five shifts above, the first and the last are how the service works now. Sensing instead of reporting is what the team does every day; answering in the room is what the platform does in a review when it is asked. The second and fourth, continuous re-running and agents with tool belts, are on the platform as abilities and are being organised into the unattended night shift the first post described. The third, a nightly distribution for every milestone, is the direction the second post set out, and the pieces are the scenario and simulation machinery already in use.

What will not change on the way there is the rule this whole series rests on. Figures come from tools and sentences from the model. The machine proposes and a person decides. Every approval carries a name and a time. The method of 1957 was right about what a schedule is. The discipline of 2030 is right about who it is for.