Article 6 of 12 · Digitalizing the PMO Mandate
Entities delivering capital projects in the Kingdom are spending money that belongs to the public, to the sovereign fund, or to shareholders whose interests are aligned with national development objectives. The standard of financial governance expected is correspondingly high, and it is rising.
This article deals with the chain that runs from an approved budget to a paid invoice, and with why that chain so often breaks in ways that are not discovered until the end.
Financial control on a capital project rests on four quantities. Every serious cost management discipline is a way of keeping them consistent.
Budget is what has been approved for expenditure. Commitment is what has been contractually promised to third parties. Actual is what has been certified as earned and is payable or paid. Forecast at completion is what the project will ultimately cost given everything currently known.
The relationships between them are the substance of cost control. Commitment must not exceed budget without an approved variation to budget. Actual must not exceed commitment without an approved change to the commitment. Forecast at completion must reflect known trends, approved changes, pending changes and risk exposure, not simply the current commitment.
In an environment where these four quantities live in different systems maintained by different functions, they diverge continuously and are reconciled periodically, usually with difficulty and always with a lag. Most cost overruns that "appear suddenly" were visible in the divergence months earlier and nobody was positioned to see it.
The most common and most damaging failure in capital project cost control is the pending commitment gap.
At any moment on an active construction project there is work that has been instructed but not yet valued, variations agreed in principle but not yet approved, claims submitted but not yet assessed, and provisional sums not yet expended. None of this appears in the commitment figure, because it has not been formally committed. All of it will become commitment.
Entities that report only approved commitment against budget are therefore reporting a systematically optimistic position — not through any impropriety, but because the reporting structure excludes a real and often large exposure.
A properly configured PMIS holds pending items as a distinct category with its own value and status, and includes them in the forecast. The result is a cost report that shows the entity what it is likely to owe, not merely what it has already agreed to owe. The difference between these two figures on a large project is frequently the entire contingency.

Payment certification is the point at which the entity converts a contractor's assertion of progress into an obligation to pay. It is the highest-value repeated transaction on any construction project and deserves more scrutiny than it usually receives.
The integrity of certification depends on the link between the payment application and the evidence that the work was done and was acceptable. In a manual environment that link exists in the professional judgement of the engineer, supported by site records that live somewhere else.
In an integrated system the link is explicit. The progress claimed against a line item connects to the measured quantity, which connects to the inspection record that approved it, which connects to the photographs taken at the time and the location on site. The certifier is not exercising judgement in the absence of evidence. The evidence is attached to the thing being certified.
This matters for three separate reasons. It reduces the risk of over-certification, which is a real financial exposure. It gives the entity a defensible position if the certification is later challenged. And it substantially accelerates the certification cycle, because the reviewer stops spending time assembling supporting information.
Beyond the headline figures there is a category of commercial administration that is unglamorous, entirely mechanical, and responsible for a surprising quantity of value leakage on capital programmes.
Retention that is released when it should be held. Advance payments recovered at the wrong rate or not fully recovered before final account. Liquidated damages not applied. Performance bonds allowed to expire while the obligation remains live. Insurance certificates not renewed. Provisional sums expended without instruction. Contra charges never levied.
Each of these is small individually and each is entirely avoidable. Collectively, across a portfolio of dozens of contracts, they represent material sums.
They leak because they depend on someone remembering a date or a rate written in a contract signed years earlier by someone who has since moved on. Systems do not forget. Retention rules, recovery schedules, bond and insurance expiry dates and milestone-linked obligations configured against the contract record generate the correct treatment automatically and alert before an expiry rather than after it.
This is not the most intellectually interesting benefit of a PMIS. In pure financial terms it is frequently among the largest.
Capital programmes are funded through budget cycles, and the accuracy of an entity's cash flow forecast determines whether it can secure and retain its allocations.
Forecasting cash requirements manually is difficult because it requires combining the schedule, the contract payment terms, the certification cycle, the retention profile and the current progress position — five sources of information that usually live in five places.
When they live in one, the forecast becomes derivable rather than estimated. The system knows the schedule, the contract terms and the current position, and can project the cash requirement by period across the portfolio, updating as reality changes.
Entities that achieve this find their relationship with their funding authority changes character. Requests are supported by traceable derivation rather than assertion. Variances against previous forecasts can be explained by reference to specific events. Credibility accumulates, and credibility is what determines allocations in a competitive funding environment.
A question that arises in every implementation is the relationship between the PMIS and the entity's financial system — an ERP, a government financial platform, or both.
The answer that works is a division by function rather than by data. The PMIS is where project cost is managed: where the budget is structured against the work breakdown, where commitments are raised against contracts, where progress is measured and certified, where changes are assessed and approved, where the forecast is built. The financial system is where money is accounted for and disbursed: the general ledger, the payment run, the statutory accounts.
The interface between them carries approved transactions in one direction and payment status in the other. It should be narrow and well-defined. Attempts to manage project cost in a general ledger fail because the ledger has no concept of a work breakdown structure, a variation, a pending commitment or a forecast at completion. Attempts to run financial accounting in a PMIS fail for equivalent reasons.
Where the two are properly interfaced, the entity has project-level control and enterprise-level accounting without duplicated data entry and without reconciliation disputes between the PMO and finance — a dispute that consumes a remarkable amount of senior time in organisations that have not solved it.
For anyone assessing an entity's financial control over a capital programme, one question separates the organisations that have it from those that do not.
What is the forecast final cost of this project, and what changed since last month?
The first half of that question is usually answerable. The second half is the test. An entity that can decompose the movement in its forecast into specific approved changes, specific pending changes, specific trend adjustments and Next in the series: the schedule as a governance instrument rather than a contractor deliverable.
Next step
Tell us which processes matter most to you, and we will show them running in PMWEB.