Project Controls in EPC: Why Your Dashboard Is Always Wrong — and What to Do About It
There is a specific moment on every large EPC project when the project controls report and reality diverge visibly enough that someone in the room stops believing the numbers. It usually happens around month six or seven. The S-curve says 42 percent complete. The site manager says the foundations are barely done. The engineering team says they are still issuing IFR drawings. The procurement team says three critical packages have not been awarded yet.
The dashboard is not lying. It is correctly reporting the data it was given. The problem is that the data it was given came from four different sources, in four different formats, updated on four different schedules, by four different people who each interpreted “percent complete” differently. By the time it reaches the dashboard, it is a weighted average of opinions, not a measurement of progress.
EPCdoc’s Project Controls module was built to fix the data problem, not just the dashboard problem. Because a better-looking dashboard fed by the same bad data produces the same wrong answers faster.
What Project Controls Is Actually For
Project controls exists to answer three questions at any point in a project’s life:
Where are we? — Current progress against plan, across engineering, procurement, and construction simultaneously.
Where are we going? — Forecast at completion for cost and schedule, based on current performance, not original estimates.
Why are we there? — The variance analysis that separates contractor-caused delay from client-caused delay, scope growth from productivity loss, and recoverable slippage from structural overrun.
Most project controls tools answer the first question adequately, the second approximately, and the third almost never — because answering “why” requires the data to be causally structured, not just numerically aggregated. EPCdoc is built to answer all three.
The Three Disciplines of Project Controls — Connected
EPC projects have three distinct work streams — Engineering, Procurement, and Construction — each with its own progress measurement logic, its own cost drivers, and its own risk profile. Most project controls tools treat these as separate modules that produce separate reports, which a senior project controls engineer then manually reconciles into a single project-level view. EPCdoc treats them as a single integrated system from the start.
Engineering Progress — Earned Value, Not Opinion
Engineering progress in EPCdoc is calculated from the deliverable register using stage-weighted earned value. When a drawing reaches IFR, EPCdoc earns 30 percent of its budgeted manhours. When it reaches IFC, it earns 100 percent. No engineer types a percentage. No project controls engineer negotiates it.
This matters for the overall project S-curve because engineering progress drives procurement readiness (you cannot award a package without an approved material requisition) and construction readiness (you cannot build without IFC drawings). When engineering progress is measured objectively, its downstream effects on procurement and construction can be forecast with confidence rather than optimism.
Procurement — Package Status, Commitment, and Cash Flow
Procurement progress in EPCdoc is tracked at the package level: from material requisition approval through RFQ issue, bid evaluation, purchase order award, vendor document submission, manufacturing progress, inspection, and delivery. Each stage has a planned date and a forecast date, and the gap between them cascades forward into the construction schedule automatically.
The commercial side of procurement — committed cost versus budget, actual expenditure versus cash flow plan, variation orders against the original PO value — is tracked in the same system. This means the cost-to-complete calculation is always working from actual committed costs, not from the original budget line items that may have been superseded three revisions ago.
Construction — Physical Progress Against Earned Value
Construction progress in EPCdoc is measured against work packages with their own earned value curves — not a single project-level percentage, but a discipline-by-discipline, area-by-area view of what physical work has been completed against what was planned. Civil earthworks earns differently from structural steel erection, which earns differently from piping installation, which earns differently from electrical terminations. EPCdoc applies the right earning logic to each work type rather than collapsing everything into a single progress figure.
The result is a construction S-curve that is a genuine measurement of installed work, not a subjective estimate dressed up as a curve.
The Cost Control Engine
Budget Structure — WBS Down to Activity Level
EPCdoc organises project cost against a Work Breakdown Structure that mirrors the project’s physical and contractual scope. Engineering costs are tracked at the discipline level. Procurement costs are tracked at the package level. Construction costs are tracked at the work-package and area level. Each WBS element carries its original budget, its current approved budget (reflecting approved change orders), its committed cost, and its actual expenditure.
The gap between current approved budget and committed cost is the contingency remaining. The gap between committed cost and actual expenditure is the cash flow position. Both are visible at the WBS element level, rolled up to the project level, and breakable back down to individual transactions — without the project controls engineer having to manually reconcile three spreadsheets.
Cost-to-Complete — Calculated, Not Guessed
The Estimate at Completion (EAC) in EPCdoc is calculated, not entered. For engineering, it uses the productivity index (earned hours divided by actual hours) applied to remaining budget hours. For procurement, it uses committed costs plus an estimate of uncommitted scope based on current market intelligence and quantity movements. For construction, it uses the productivity rate from completed work packages applied to remaining quantities.
The result is an EAC that moves with actual performance, not one that stays static at “on budget” until someone decides to revise it at month-end. When engineering productivity drops in week three, the EAC moves in week three — not in the month-end report when it is too late to recover.
Variation Orders and Change Management
Every cost movement in EPCdoc is traceable to a cause. Approved scope changes flow from Engineering Change Notices or Scope Change Notices through to Variation Orders, each carrying the manhour estimate, the schedule impact, and the commercial value. When a VO is approved, EPCdoc automatically updates the current approved budget, creates the relevant schedule activity in the CPM engine, and adjusts the EAC baseline — all without manual re-entry into separate cost and schedule systems.
Unapproved scope — work that has been instructed but not yet formally approved — is tracked separately as a pending VO, flagged in the cost report as a contingent liability rather than buried in the actual cost figures. The client can see exactly what is approved, what is under negotiation, and what is being done at the contractor’s risk.
Schedule Control — CPM That Actually Updates
The Critical Path Method, Properly Implemented
EPCdoc’s CPM engine maintains a live network of project activities with predecessor relationships, durations, and resource links. The critical path — the sequence of activities that determines the project completion date — is recalculated every time a schedule activity is updated. When a procurement package slips its award date by three weeks, EPCdoc immediately shows which downstream engineering, fabrication, and construction activities are affected, and by how much.
This is what critical path is supposed to do. In most projects, it does not, because the schedule is updated monthly in a separate planning tool by a planner who has to manually gather progress from the field, engineering, and procurement teams and integrate it by hand. By the time the updated schedule is published, the data is three weeks old and the critical path has already moved.
EPCdoc’s schedule is connected to the same live data that drives the engineering, procurement, and construction progress views — which means the critical path moves when real events happen, not when the monthly report is assembled.
Float Tracking and Early Warning
EPCdoc tracks float at the activity level and flags activities that are approaching zero float — before they become critical. A piping spool that had 15 days of float three weeks ago and now has four days of float is a warning. A structural steel package that has been on the critical path for six weeks with no recovery plan is a red flag. EPCdoc surfaces both, continuously, without waiting for someone to run a report.
The look-ahead view shows the activities due in the next two to four weeks, filtered to show only those with float below a configurable threshold. This is the Project Controls Engineer’s daily management tool — not the monthly report, which is always a post-mortem, but the week-by-week view that allows intervention before delays become commitments.
Baseline vs. Current Schedule
EPCdoc maintains the original baseline schedule separately from the current working schedule. Every deviation from baseline is recorded with a date and a reason — client instruction, force majeure, contractor productivity, scope change — creating a contemporaneous delay record that supports the project’s contractual position. When a delay claim is eventually prepared, the schedule movement history is already in EPCdoc, organised by cause, with dates and approvals attached.
Reporting That Tells the Truth
The Monthly Project Controls Report — Generated, Not Assembled
The project controls report in EPCdoc is generated from live data, not assembled from contributions sent by email. The engineering progress figures come from the EPM deliverable register. The procurement status comes from the package tracker. The cost figures come from the committed cost register. The schedule figures come from the CPM engine. The project controls engineer reviews and approves the report; they do not spend three days building it.
The report is produced in two variants: an external version for the client showing progress, forecast, and approved changes; and an internal version for senior management showing the full cost and schedule performance including unapproved scope, contingency consumption, and productivity variances that would not be shared externally.
Earned Value Indices — SPI and CPI, Automatically
EPCdoc calculates Schedule Performance Index (SPI) and Cost Performance Index (CPI) at the project level, the discipline level, and the work-package level — automatically, as a byproduct of the earned value and actual cost data already in the system. These indices are not computed once a month for the report; they are live figures available to the project team at any time.
When SPI drops below 0.85 on a critical discipline, EPCdoc flags it. When CPI drops below 0.90 on a major cost element, EPCdoc flags it. The project controls engineer does not need to hunt for the problem — EPCdoc identifies it and surfaces it directly.
Who Uses Project Controls, and How
Project Manager uses the project-level dashboard for client progress meetings and senior management reporting — a single view of engineering, procurement, and construction progress with cost and schedule performance indices.
Project Controls Engineer uses the WBS cost tracker, EAC calculation, and variance analysis for the monthly cost report, and the CPM look-ahead for weekly schedule management.
Planning Engineer uses the CPM network, float tracker, and baseline comparison for schedule maintenance and delay analysis.
Commercial Manager uses the variation order register, pending VO log, and cash flow forecast for contract administration and client billing.
Engineering Manager uses the discipline-level engineering EAC and the IFC progress curve for their own team’s performance management.
Construction Manager uses the work-package progress tracker and the construction S-curve for site progress meetings and subcontractor management.
The Difference That Makes Project Controls Worth Having
Project controls is only useful if the data feeding it is trustworthy. And data is only trustworthy if it comes from the system where the work actually gets done — not from a separate data-entry exercise that someone does at month-end to feed a reporting tool.
EPCdoc’s project controls is not a reporting layer on top of your existing tools. It is the system where engineering deliverables are managed, where procurement packages are tracked, where change notices are approved, where timesheets are logged, and where the CPM schedule lives. The project controls reports are a byproduct of that system doing its job — not a separate effort to assemble data that the system should have been producing all along.
When project controls works this way, the dashboard is right. Not because someone worked hard to make it right, but because the system cannot produce a wrong number — the data has nowhere else to come from.
