The Construction Operating System: One Model for Cost, Cash, Programme and Commercial

Ask a project director where the margin went on a job that came in thin, and the answer is almost never "the concrete". It is a variation that was instructed verbally and never priced. A retention that nobody chased at practical completion. A supplier claim that landed after the cost report was already signed. A programme slip that quietly burned six weeks of preliminaries before anyone put a number on it.

None of those are site failures. They are reconciliation failures — losses that live in the gap between the systems that run the project. The field team is in one tool, the quantity surveyor is in a spreadsheet, the planner is in another, and finance is in the ledger. Each is right about its own slice. No two of them agree by month-end.

That is not a reporting problem. It is a data foundation problem wearing a hard hat.

Walk the typical mid-market EPC contractor and you find the same estate every time. Procore or Aconex for the field — RFIs, submittals, daily reports, snags. A quantity surveyor running valuations, applications and variations in Excel. Oracle Primavera P6 or Microsoft Project for the programme. SAP, Dynamics 365, QuickBooks or Sage carrying the actual money. SharePoint holding the certificates, the correspondence and the version of the truth nobody trusts.

Every one of those systems is doing its job. The problem is that the questions a project director actually needs answered live across all of them at once. What is my forecast margin on this job, today, after the variations I have not yet recovered? Which supplier claim is about to breach the cost report? Is the schedule slip on Marina Tower a resourcing problem or a procurement one? You cannot answer any of those from a single screen — so they get answered at month-end, by hand, in a workbook that takes three days to build and is stale the day it is finished.

By the time the cost report reconciles, the window to do anything about it has closed. The number is accurate. It is also a post-mortem.

The answer is not another point tool. It is the layer that sits above the ones you already run and reconciles them — a single governed model where cost, cash, programme, commercial, procurement and quality are read against each other, on the same definitions, refreshed continuously rather than rebuilt monthly.

We build it on the Microsoft stack: Microsoft Fabric and OneLake hold the unified model, Power BI carries the analytics in Direct Lake, and Power Platform handles the capture and the workflow at the edges. The sources stay where they are — Procore, Primavera, the ERP, the QS workbook — and mirror in on a governed schedule. Nothing is ripped out.

Here is a screen-by-screen walkthrough of that layer — eight views, illustrative figures, built on the structure I would put on a contractor's own project, cost and programme data. It runs a demonstration portfolio of five live UAE projects, with the numbers coming from Procore, QuickBooks, MS Project and SharePoint.

The Portfolio Overview is the screen a director opens first: portfolio value, cost to date, forecast margin, net cash, retentions held and variations pending — across every active job, on one page, drillable to the project driving each number. Behind it sit the pages that do the work.

Cost & Margin reads budget against committed and forecast cost per project, so erosion shows up before the cost report, not after. Cashflow projects certified receipts against outflow — the position most contractors only learn from a spreadsheet a month too late. Commercial puts applications, retentions and variations into one ledger: what is applied, what is certified, what is held to practical completion, and the variation exposure not yet recovered. Programme reads planned against actual progress with the labour forecast behind it. Procurement tracks suppliers, purchase orders and material call-offs against the schedule, flagging long-lead items before they hold up the site. And Site & QA finally joins the field data — daily reports, NCRs, inspections — to the commercial picture, instead of leaving it stranded in a folder.

The point is not the individual dashboards. It is that they read from one model, so the variation the QS logs on Tuesday is in the director's margin number on Wednesday — not in next month's reconciliation.

This only works if the field data actually gets captured. If your site teams are not logging daily reports and NCRs, no model conjures that data — it needs a light Power Apps capture layer and the discipline to use it. We build the capture; the habit is your team's.

The quantity surveyor's judgement stays. WIP valuation and variation assessment are commercial calls, not calculations — the operating system removes the manual aggregation and the version conflicts, but it does not replace the QS. Anyone selling you an EPC platform that "automates the commercial function" has not run a project.

And it will not fix a contract that was mispriced at tender. The system makes the erosion visible early enough to manage it — a mode shift, a claim filed on time, a supplier conversation held in week two rather than at final account. It does not manufacture margin that the bid never had.

You stop finding out about the miss at month-end. The forecast margin becomes something you manage in-week, from one number the whole team trusts, instead of a figure three functions dispute in the cost review. The variation gets priced because the system flagged it, the retention gets chased because it aged into a bucket in front of someone, and the schedule slip gets a resourcing decision while there is still schedule left to recover.

That is the difference between a reporting pack and an operating system. One tells you what happened. The other lets you act while it is still happening.