Article 10 of 12 · Digitalizing the PMO Mandate
Every entity in the Kingdom delivering capital projects is now being asked what it is doing about artificial intelligence. The question comes from boards, from ministries, from investment committees and from national digital transformation objectives. It is a reasonable question and it deserves a better answer than most entities are currently able to give.
The honest answer, for the majority, is that they cannot yet do anything meaningful with AI, because the data on which it would operate does not exist in a usable form.
This article is about why that is the case, and about what has to be true before an AI programme in capital project delivery produces anything other than a pilot that impresses in a demonstration and is never deployed.
Set aside the technology for a moment and consider what would have to be true for an artificial intelligence system to answer a question like which of our projects are most likely to overrun, and why.
It would need the cost position of every project, structured consistently, with history. It would need the schedule position, with baselines and updates retained over time. It would need the change history, with values, causes and approval dates. It would need the approval performance data — how long decisions took, and where they queued. It would need the quality and safety record. It would need the risk position and how it evolved. And it would need all of this expressed in a common structure so that a pattern observed in one project is recognisable in another.
Now consider where that data sits in an entity without a PMIS. Cost in spreadsheets with project-specific structures. Schedules in individual files with inconsistent WBS coding. Changes in a mixture of registers and correspondence. Approval timings nowhere, because nobody recorded when things arrived and left. Quality records on paper. Risk in documents. Nothing linked to anything.
No model can be built on that. Not because the algorithms are inadequate, but because the input does not exist. The most common and most expensive mistake in enterprise AI is treating data preparation as a phase of the AI project. On a capital programme it is not a phase. It is years of operational discipline that either happened or did not.

Capital project data divides into two categories, and useful AI applications require both.
is the transactional record: budget lines, commitment values, certified amounts, activity dates, progress quantities, risk scores, inspection results, approval timestamps. It is numeric or categorical, it fits in fields, and it is what makes quantitative prediction and anomaly detection possible.
is the documentary record: correspondence, minutes, contracts, specifications, reports, method statements, technical submissions, photographs. It is language and images, and it is where the explanation of what happened lives. Large language models are unusually good at working with exactly this material — retrieving relevant passages, summarising positions, identifying obligations, comparing documents against requirements.
The value emerges when the two are connected. A model that knows a project's cost variance is useful. A model that knows the cost variance and can retrieve the correspondence, instructions and change records that explain it is transformative, because it can answer why rather than only what.
That connection is not something an AI layer creates. It is a property of how the data was captured. A PMIS captures both categories in the same structure, with the same project, contract, WBS and asset references, and with the relationships between records preserved. This is why the PMIS is the foundation of the AI capability rather than a component of it.
There are two requirements that determine whether an AI output is usable in a governance context, and both are frequently discovered late.
Provenance. An answer without a source is an opinion. When an AI system tells an executive that a project's forecast is unreliable, the immediate and correct response is "on what basis." A system built over a governed data repository can cite the records it drew on, and the reader can open them. A system built over an unstructured document dump cannot, and it will not survive its first challenge in a board meeting.
Permissions. An AI assistant that answers questions must respect the same access rules as the underlying data. A contractor asking a question of the system must not receive an answer synthesised from another contractor's commercial information. This is not solvable by instructing the model. It is solvable by ensuring the retrieval layer operates under the same role-based permissions as the source system — which requires the source system to have them.
Both requirements point in the same direction. AI in capital project delivery is safe and useful when it operates over a governed system of record, and unsafe or useless when it operates over a data lake assembled from exports.
It is worth being direct about the realistic near-term applications, because the gap between what is marketed and what is deployed is wide.
Applications that work well today over a governed PMIS include: natural-language querying of project and portfolio data, so that a senior stakeholder can ask a question directly rather than requesting a report; retrieval and summarisation across the documentary record, which compresses tasks like identifying every instruction relating to a disputed area of work from days to minutes; automated extraction of obligations and dates from contracts into a tracked register; assisted review of submissions against specification requirements; anomaly detection across transactions, flagging patterns that would not be visible in aggregate reporting; and predictive indicators built on historical patterns across a portfolio, provided the portfolio has enough history to learn from.
Applications that are not yet reliable include anything that removes professional judgement from a consequential decision. AI can identify that a variation is unusual for its category. It cannot decide whether it is justified. The distinction matters, and entities that blur it in their internal messaging create expectations that will not be met.
The practical conclusion for an entity is a sequencing argument.
An entity that implements a PMIS today and operates it with discipline is, within twelve to eighteen months, in possession of a structured, governed, permissioned, complete and growing record of its capital delivery. At that point, AI applications become straightforward to introduce, because the difficult part is already done.
An entity that pursues AI first, over the data it currently holds, will spend its budget on data remediation, produce a proof of concept over a cleaned subset, and be unable to move to production because the underlying capture process has not changed and the data degrades again immediately.
This is not an argument for delaying AI. It is an argument about what the AI programme's first phase actually is. For a capital delivery entity, the first phase of the AI programme is the PMIS implementation. Everything after that is comparatively easy.
For a board or a ministry assessing an entity's readiness to deploy AI in capital delivery, the diagnostic is not what tools it has evaluated.
Where does your project data live, in what structure, and how much history do you have in it?
If the answer describes a single governed system with two or more years of consistently structured transactional and documentary history, the entity is ready and the AI conversation is worth having in detail.
If the answer describes an intention to consolidate data from multiple sources into a lake for the purpose, the entity is at the beginning of a longer road than it currently believes, and the honest recommendation is to build the record first.
Next in the series: the control tower — PMWEB data combined with GIS and construction site cameras.
Next step
Tell us which processes matter most to you, and we will show them running in PMWEB.