The PMO Mandate Is Now a Data Mandate

Every government, semi-government and PIF-affiliated entity in Saudi Arabia that delivers capital construction projects is now required to establish a Project Management Office. This is no longer a matter of organisational preference. It is a condition of how public and quasi-public capital is permitted to be spent.

The requirement exists for a reason that is easy to state and difficult to satisfy. Capital projects in the Kingdom are being delivered at a scale and concurrency that has no historical precedent anywhere. Giga-projects, municipal infrastructure, healthcare and education facilities, transport corridors, stadiums, housing developments and industrial estates are being procured simultaneously, often by entities that were themselves established in the last five years. The institutional memory that older organisations rely on does not yet exist. The PMO is the mechanism intended to supply that memory by design rather than by accumulation.

Mashroat, the National Project Management Office, has provided the content of that design. The NPMO framework sets out the processes an entity is expected to run across the full project life cycle — from the identification and justification of a need, through planning, procurement, design, construction, commissioning and handover, into operation. It describes who is accountable for each decision, what evidence supports it, and what has to be reported upward.

That framework is the answer to the question of what a PMO should do. It does not, by itself, answer the harder question, which is how an entity actually executes hundreds of processes across dozens of projects, hundreds of contractors and consultants, and thousands of people who have never met each other.

Here is what happens in practice when a PMO is established without a Project Management Information System underneath it.

The processes are written. They are approved, printed, circulated and put on a shared drive. Then delivery begins, and the processes meet reality. A payment certificate is raised in a spreadsheet. A variation is agreed in a meeting and confirmed by email. A design change is issued as a PDF and superseded three weeks later by another PDF that some parties receive and some do not. A risk is identified on site and mentioned verbally to a project manager who is transferred to another project two months later.

The PMO, meanwhile, is asked for the monthly report. So it sends out a template. Twenty-two project managers fill it in, each with a slightly different interpretation of what "percentage complete" means. The PMO consolidates, reconciles the obvious contradictions, formats the deck, and presents it to the executive committee four to six weeks after the period it describes.

That PMO has not failed. It is doing exactly what it can do with the tools it has been given. But it is not governing anything. It is describing, late and approximately, events it had no ability to influence.

The distinction matters enormously to anyone with a stake in the outcome of these projects. A PMO that governs prevents overruns. A PMO that reports explains them.

What "digitalization" actually means here

Digitalization is a word that has been degraded by overuse, so let me be precise about what it means in this context. It does not mean scanning documents. It does not mean moving spreadsheets to the cloud. It does not mean buying a reporting tool that reads other people's data.

It means that the process defined in the NPMO framework is executed inside a system. The budget request is raised as a record. It routes to the approver defined in the delegation of authority. The approver acts, and the system captures When that chain exists, the monthly report is not produced. It is queried. The distinction between those two verbs is the entire argument of this series.

A Project Management Information System such as PMWEB is the layer that makes this possible. It holds the forms, the workflows, the delegation of authority, the cost ledger, the schedule integration, the document register, the correspondence, the risk register, the inspections and the records — in one structure, with one set of project and cost breakdowns, accessible to every party to the project at the level of visibility their role permits.

Three obligations that a PMIS makes achievable

Accountability. Every entity spending public or sovereign-linked capital must be able to demonstrate that each commitment was authorised by a person with the authority to authorise it, on the basis of evidence that existed at the time. In a document-and-email environment, this is reconstructed after the fact by people searching mailboxes. In a PMIS, it is a permanent property of the record.

Transparency. Stakeholders — ministries, boards, investment committees, auditors, regulators, and the communities whose lives are affected by these projects — are entitled to a view of status that is not curated by the party being assessed. A PMIS provides that by giving each stakeholder controlled access to the same underlying data rather than to a document written about it.

Real-time reporting. The value of information about a capital project decays rapidly. A cost overrun identified in the month it originates can often be absorbed. The same overrun identified two quarters later has usually been compounded by decisions taken in ignorance of it. Reporting latency is not an administrative inconvenience. It is a direct financial exposure.

If you are reading this as a board member, a ministry official, a regulator, an investment committee member, a lender, a contractor or a consultant, the argument above is not an IT argument. It is an argument about whether the organisation you are dealing with can answer questions.

Ask an entity how much of its approved capital budget is committed today. Ask what the forecast final cost of a specific project is and what evidence supports the forecast. Ask which contractor submissions have been sitting with the engineer beyond the contractual review period. Ask how many variations have been instructed but not yet valued.

An entity running a properly implemented PMIS answers these in minutes, on screen, with the underlying records one click away. An entity without one answers in weeks, with numbers assembled by hand, carrying an error rate nobody can quantify.

That gap is the subject of this series.

What this series will cover

Over the next eleven articles I will work through the argument in detail: how the NPMO process architecture maps onto a digital system; how accountability, transparency and real-time control are actually enforced; how cost, schedule, documents, risk, quality and safety are governed; why the growing demand for artificial intelligence use cases makes a PMIS a precondition rather than a complement; and how PMWEB data combined with GIS and construction site cameras produces a genuine control tower for an entity's entire capital portfolio.

The conclusion I will argue for is stated plainly at the outset. For an entity in the Kingdom delivering capital projects under an NPMO-aligned mandate, a Project Management Information System is not a productivity tool that improves an existing capability. It is the capability. Without it, the PMO is an intention.

Next in the series: mapping the NPMO process architecture into a working digital system.