Tracing an EPC Project KPI Back to the BOQ, Progress Measurement and Cost Transaction

In an EPC project review, a number gets questioned — percent complete looks high, cost variance looks wrong, the forecast moved. The right response is to pull the thread: this KPI comes from these BOQ lines, measured at these quantities on site, against these cost transactions. If you can show that thread, the number is defensible. If you cannot, it is an assertion, and the review becomes an argument.

Traceability is the quiet foundation of trustworthy project controls. The headline KPIs — earned value, cost performance, percent complete — are all derived numbers, and a derived number is only as good as the ability to decompose it back to the source facts it was built from. Without that decomposition, cost control is a set of totals nobody can interrogate.

Most EPC reporting cannot pull the thread, and that is the real problem it has — not that the numbers are necessarily wrong, but that they cannot be shown to be right.

The reason is structural. The project KPI is typically calculated in a spreadsheet that pulls disconnected extracts: a BOQ export from the commercial system, progress from a site log or a separate measurement spreadsheet, and costs from the ERP, each on its own key, stitched together by hand. The KPI that comes out is a calculation over extracts that were never connected, so there is no path from the number back to the source records.

When the number is questioned, the thread does not exist. You cannot click from earned value to the BOQ lines and measurements that produced it, because the calculation flattened them into a total and discarded the links. The best anyone can do is rebuild the spreadsheet and hope it reconciles — which is exactly the credibility problem a project controls function exists to avoid.

This is not a discipline failure by the QS or the planner; it is a data-structure failure. The commercial process knows the links — a measurement belongs to a BOQ line, a cost is incurred against a line — but the reporting throws them away by consolidating through spreadsheets. Keeping the links is the fix.

Traceability requires an end-to-end chain held in a governed data model rather than reconstructed in a spreadsheet. The BOQ is the baseline — every line a unit of scope, quantity and rate. Progress measurement — the measurement book, the site records of what has actually been executed — links to BOQ lines, so completion is recorded against the scope it belongs to. And cost transactions from the ERP link to the same BOQ lines, so spend is attributed to scope.

With all three connected to the BOQ as the common spine, every fact has a place and a link: this measurement belongs to this line; this cost was incurred against this line; this line has this baseline quantity and rate. The chain is intact, which means any derived number sits on top of connected source facts rather than flattened extracts.

On a Microsoft estate this is a Fabric and OneLake model where BOQ, measurement and cost tables are related on the BOQ line key, so the relationships are preserved and queryable. It mirrors the commercial process the QS already runs — a measurement against a line, a cost against a line — but keeps the links the spreadsheet discarded.

Once the chain exists, the KPIs are calculated from connected data and therefore decompose back to it. Earned value is the baseline value of work measured as complete against each BOQ line; percent complete rolls up measured quantities against baseline quantities; cost variance compares cost transactions attributed to lines against the earned value of those lines. Each KPI is a roll-up of linked source facts, so it can be broken back down to them.

That decomposition is the whole payoff. When percent complete is questioned, you show the BOQ lines, their measured quantities and their baseline — the completion explained line by line. When cost variance is questioned, you show the costs attributed to the lines against the value earned on them. The number stops being an assertion and becomes a view with its sources one click away.

This is the same discipline that a change feed over the cost and BOQ tables supports over time — here the focus is the structural traceability at a point in time: can this KPI, right now, be decomposed to the BOQ, the measurement and the cost behind it? With the chain in place, yes; without it, no.

An EPC project KPI is trustworthy when it can be traced to its sources, and that requires an end-to-end chain — BOQ as the baseline spine, progress measurement linked to BOQ lines, cost transactions linked to the same lines — held in a governed data model rather than reconstructed from disconnected spreadsheet extracts. Then earned value, percent complete and cost variance are calculated from connected data and decompose back to the BOQ line, the site measurement and the cost transaction behind them.

The test is the review: when a project number is questioned, can you pull the thread back to the BOQ, the measurement and the cost on the spot? If yes, the number is defensible and the review is about decisions. If the honest answer is "we would have to rebuild the spreadsheet", the reporting has no traceability and every questioned number is a dispute waiting to happen. We build this on Microsoft Fabric and Power BI, modelling BOQ, measurement and cost on a common key so the chain is intact — turning project KPIs from assertions into numbers you can show.