Back to InsightsThought Leadership · PCE USA 2026 · Session T10

Prediction AI in Project Controls: Why We Start With Structure, Not the Model

What xPM has learned about project context, governed evidence, forecasting, and human decision authority

Dr. Omer BisenFounder, xPM

At Project Controls Expo USA 2026, I will present a session called “Prediction AI in Project Controls.”

The title puts Prediction AI at the center of the conversation. Our experience, however, has led us to start somewhere else.

We start with the Project Controls environment the prediction will depend on.

Across more than 25 years of work involving project management, Project Controls, ERP, analytics, forecasting, and construction decision support, the technology has changed considerably. The underlying management problem has changed much less.

A project can have more data, more dashboards, more connected applications, and now more AI-generated output, while management still struggles to answer a basic question:

What does the available evidence actually support, and what can we still do about it?

That is why our working sequence is:

Structure

first

Integration

second

Intelligence

third

Prediction AI is the last step in project controls, not the first.

Connected Is Not the Same as Integrated

Most complex projects operate across several systems. Schedule may live in one environment, cost and commitments in another, documents and RFIs in a PMIS, design information in BIM platforms, and risk, procurement, change, and executive reporting somewhere else.

We are not putting everything into one software. We are creating one governed project identity.

The more practical objective has been to preserve a consistent project meaning as information moves between them.

APIs move data. Integration preserves meaning.

If the same scope item, activity, quantity, location, work package, responsibility, or cost carries a different identity from one system to another, moving more data does not necessarily resolve the management problem.

This is why our approach begins with the Project Controls Plan, the Master Coding System, and integrated controls.

The Project Controls Plan establishes how the project will be governed, measured, forecast, reported, and controlled.

The Master Coding System provides a common project identity that can be mapped or inherited across the relevant control structures.

Integrated controls then connect the baseline, actual condition, and forecast across cost, schedule, risk, contracts, and change.

We developed this way of thinking before the current AI cycle. AI has made the issue more important because it can process far more information, far faster. But increased processing capacity does not remove the need for a sound control basis underneath it.

Diagram showing source and operational systems on the left flowing into a central Master Coding System, then out to control and management uses on the right, illustrating that integration is common meaning across systems, not merely data movement between them. — Integration is common meaning across systems, not merely data movement between them

AI does not make fragmented data trustworthy

Available Information Is Not Automatically Decision Evidence

Integration alone is still not enough.

One of the more important distinctions in our current work is between information that is available and evidence that is appropriate to use for a particular decision.

A drawing may be accessible but superseded.

An estimate may be technically detailed but not the approved basis.

A specification may still exist in the document environment even though an addendum has changed the requirement.

A project record can therefore be technically readable and still be inappropriate evidence for the question being asked.

This is why we treat source authority, version, context, and decision relevance as part of the analytical problem rather than as administrative metadata.

A technically correct analysis based on the wrong project context can still lead management in the wrong direction.

AI does not solve this automatically.

Before asking a model to explain, forecast, or recommend, we first need to understand what evidence it is allowed to rely on and why.

That principle has increasingly shaped the way we design our own intelligence workflows.

III

Three Different Jobs. One Project-Controls Foundation.

We also learned that treating “AI” as one capability creates unnecessary confusion.

For Project Controls, we find it more useful to separate three different jobs.

Generative AI helps us understand evidence. It can extract, organize, compare, summarize, and explain large bodies of project information. Its value is often speed and accessibility. But a well-written summary does not by itself establish whether the underlying evidence is contractually, commercially, or professionally sufficient.

Agentic AI helps us advance governed workflows. It can retrieve information, route tasks, monitor conditions, and escalate within defined permissions. This can reduce workflow latency. But moving a process forward is different from holding the authority attached to the final management action.

Prediction AI helps us look forward. Where the evidence and model quality justify it, forecasting can express possible future exposure through ranges, quantiles, probabilities, scenarios, or other suitable methods.

The distinction matters because the consequences are different.

A generated explanation may help someone review the evidence faster.

An agent may help the organization respond faster.

A forecast may change how management evaluates the future.

None of those actions automatically transfers management authority to the system.

A forecast can inform a decision. It is not the decision.

As consequence increases, we believe the need for visible human review, approval, and accountability should increase with it.

Quadrant chart of intelligence depth versus control cycle speed showing Prediction AI, Generative AI, and Agentic AI moving from a governed project-controls baseline toward earlier, better-supported management action. — Where AI changes project controls, moving from a governed baseline toward earlier, better-supported management action

The Question Comes Before the Method

Another lesson from our work is that analytical sophistication is not useful if it is applied to the wrong question.

We organize management reasoning around five questions:

What should be?

What happened?

What is happening now?

What could happen?

What should we do?

They may sound simple. They are not interchangeable.

“What should be?” asks us to establish the intended condition, requirement, baseline, or objective.

“What happened?” is historical and explanatory.

“What is happening now?” is a current-state assessment.

“What could happen?” moves into uncertainty, scenarios, and forecasting.

“What should we do?” compares realistic alternatives and leads toward an authorized management decision.

A root-cause method should not be selected simply because it is familiar when the real question is forward exposure. Likewise, a forecasting model should not be used to give the appearance of precision when the decision actually depends on commercial judgment, contractual interpretation, or strategic alternatives.

This is also why we maintain a broader method library across Strategy, Decision, Communication, Analysis, and Forecasting.

610+

entries across five libraries and 61 method families

Explore the xPM Method Library

The number itself is not the value.

In fact, using more techniques is often the wrong objective.

The value is being able to select the few approaches that fit the management question, the evidence available, the uncertainty involved, and the consequence of the decision.

Strategy helps frame the problem.

Analysis tests what the evidence supports.

Forecasting examines what may happen next.

Decision methods help compare alternatives and tradeoffs.

Communication methods help make the conclusion understandable enough to challenge and act upon.

The question comes before the method.

Two Ways a Decision Problem Reaches Management

Not every management question begins in the boardroom.

Sometimes the decision starts deliberately. Management knows a major award, funding, procurement, recovery, change, or delivery decision is approaching and asks for analysis.

At other times, the issue begins as a signal.

An unusual RFI pattern. A design revision. A procurement condition. Repeated schedule movement. Cost behavior that is inconsistent with physical progress.

This distinction led us to think about two complementary capabilities.

Early Signal Intelligence asks: What deserves attention?

Its purpose is not to declare that every signal is a problem. It is to connect emerging conditions to potential consequence so management can determine whether deeper analysis is justified.

Strategic Decision Support asks: What should we do?

Once a material issue reaches the decision level, the problem changes. Management needs to understand the condition, examine the relevant evidence, consider uncertainty, compare realistic alternatives, and decide while meaningful options still exist.

The two capabilities meet at the same point:

a management decision with a visible evidence trail and a named decision-maker.

Flow diagram: Detect, Escalate, Decide Before Consequence, connecting early signals through Generative, Agentic, and Prediction AI to potential consequences, with the message to intervene before the consequence becomes the KPI. — From leading signals to management action: intervene before the consequence becomes the KPI

Earlier Is Valuable Only While Management Still Has Options

This is where Prediction AI becomes especially relevant.

The objective is not simply to predict a future number earlier.

The management value comes from understanding possible exposure while something can still be changed.

At the beginning of a response window, management may still have several alternatives.

As commitments accumulate, procurement advances, work is installed, contractual positions harden, or schedule flexibility disappears, that option set narrows.

A better forecast delivered after the response window closes may improve understanding of what happened.

It may no longer improve the outcome.

That is why one of the questions we keep returning to is:

What can management still change?

For us, the useful role of intelligence is not simply to tell management that a problem exists. It is to improve the quality of the evidence and foresight available while realistic choices remain.

VII

Forecasting Needs Governance Too

Prediction deserves the same control discipline as the data underneath it.

When a predictive output may influence a material decision, we want the decision-maker to understand more than the headline number.

What assumptions shaped it?
What historical evidence was available?
How did the approach perform when tested against known outcomes where testing was possible?
How well calibrated is the uncertainty?
What evidence was unavailable or excluded?
What could materially change the conclusion?

And where the model has not actually computed an answer, we believe the correct output is to say so.

An unsupported number should not be printed simply because an empty space looks unfinished.

Visible uncertainty is more useful than false precision.

This does not make forecasting weaker.

It makes its role clearer.

VIII

We Apply the Same Discipline to Our Own AI Claims

A governance-first approach also requires discipline in how we describe our own technology.

Where our work stands today

So here is where our own work stands today, rather than an invitation to assume.

Detection and drafting on live project documents runs today under human review; nothing issues without a human act. The decision-run controls — citation validation, a two-key approval lock, and a frozen, append-only record — are built and exercised in dry runs. Retrieval, routing and standing-watch layers are specified and not yet live. Owner pilots begin at the review gates the method itself defines, not before.

We do not think an architectural concept should automatically be presented as production maturity, and that applies to us first.

The same principle applies to case studies.

The session will use a replayed Owner award decision and publicly documented external cases to show how the reasoning works. These cases are examples of application, not universal validation.

Where the evidence supports a conclusion, we should say so.

Where the evidence is incomplete, the output should remain conditional.

Where professional or commercial judgment is still required, the record should show that clearly.

And where a management decision is required, a human retains the authority to make it.

This is not a limitation we are trying to engineer away.

It is part of the control architecture.

Structure First. AI Last.

Our interest in AI did not begin with today’s generative tools.

We have worked for years at the intersection of integrated Project Controls, ERP, business intelligence, forecasting, and decision support. Earlier research included neural networks, fuzzy logic, and ANFIS applied to construction cost uncertainty.

The tools are far more capable today.

That changes how much evidence we can process, how quickly we can detect relationships, and how broadly we can test alternative explanations and future conditions.

It does not change the sequence we have found most useful.

01First establish the control basis.
02Then preserve project meaning across systems.
03Then determine what evidence is appropriate to the question.
04Then apply the intelligence needed.
05Then show the uncertainty and alternatives clearly.

And finally:

A named human decides.

That is the framework we will discuss at Project Controls Expo USA 2026, Session T10, on October 7 at Nationals Park in Washington, D.C.

The objective is not more AI output.

It is better-supported management decisions while there is still time to act.