Engineering Progress Management: Why Tracking Hours Is Not the Same as Tracking Progress

Ask any Engineering Manager on an active EPC project how the engineering is going, and they will give you one of two answers. Either a percentage — “we’re at 68 percent” — or a hedge — “the numbers look okay but I’m not confident in them.” Both answers have the same root cause: the engineering progress figure is being tracked the wrong way.

Most engineering teams track progress by asking engineers to estimate their own completion percentage, or by counting how many documents have reached IFC against the total planned. Both methods produce a number. Neither produces a defensible basis for billing a client, forecasting where the discipline will land against budget, or identifying which deliverables are actually at risk before they become late.

EPCdoc’s Engineering Progress Management module was built to replace this guesswork with a system that connects deliverable status to manhours, manhours to earned value, and earned value to the commercial reality of the project.

The Problem With Percentage-Complete

Percentage-complete as reported by an engineer is a sentiment, not a measurement. An engineer who says a drawing is “80 percent done” is telling you how they feel about it. They are not telling you how many of its budgeted hours have been spent, how many remain, or whether the remaining 20 percent is a minor annotation pass or a complete rework triggered by a late vendor datasheet.

The construction industry solved this decades ago with earned value management — measuring progress not by opinion but by which physical milestones have been completed and what budget those milestones carried. Engineering has the same solution available, but most EPC engineering teams do not apply it because their tools do not support it. They have timesheets, and they have a document register, but the two systems do not talk to each other, and neither of them knows what a deliverable is budgeted to cost.

EPCdoc connects all three.

---

How EPCdoc EPM Actually Works

Deliverable Register — The Foundation

Every piece of engineering output is a deliverable in EPCdoc: a P&ID, a structural calculation, a piping isometric, a vendor datasheet review, a material take-off. Each deliverable is registered with its discipline, its type, its budgeted manhours, and its planned issue dates.

The deliverable register is not a separate spreadsheet that someone maintains alongside the project — it is the source of truth that every other EPM calculation reads from. When a deliverable moves from DRAFT to IFR to IFC, those status changes are the inputs that drive progress measurement, not a separately-entered percentage field.

Stage-Weighted Earned Value

EPCdoc calculates earned progress using stage weights — predefined weightages assigned to each milestone in a deliverable’s lifecycle. A typical three-stage scheme might assign 30 percent earned at IFR, 70 percent at IFA, and 100 percent at IFC. When a deliverable reaches IFR, EPCdoc automatically calculates earned hours as 30 percent of its budgeted manhours — without anyone typing a number.

This is the key structural difference from percentage-complete reporting. The earned value is derived from an objective event (a document reaching a formal issue stage) against a pre-agreed budget (the manhour norm for that deliverable type), not from an engineer’s self-assessment. The result is a progress figure that is auditable, repeatable, and commercially defensible.

Manhour Budget vs. Actual vs. Earned — All Three, Together

EPCdoc tracks three distinct manhour figures per deliverable and per discipline:

Budget hours — what was planned, set at the start of the project based on manhour norms for each deliverable type. This is the baseline. It does not change when work runs over; it is the reference against which performance is measured.

Actual hours — what has been spent, drawn from timesheet entries logged against each deliverable. This is the cost side.

Earned hours — what has been earned based on stage completion. This is the progress side.

The relationship between these three numbers tells the engineering story that percentage-complete cannot. If actual hours exceed earned hours, productivity is below plan — the team is spending more than the work has earned. If earned hours are tracking ahead of actual, productivity is above plan. If budget hours are being consumed faster than earned hours are accumulating, the discipline is heading for a cost overrun before the schedule one becomes visible.

Discipline-Level Progress Dashboard

The EPM dashboard rolls these numbers up by discipline, giving the Engineering Manager a real-time view of where each discipline stands against its budget and schedule. The S-curve shows planned versus actual versus earned progress over time — not as a manually-maintained chart, but as a live calculation from the deliverable register and timesheet data that feeds it automatically.

Disciplines that are running behind on earned value against budget consumption are flagged before the overrun is locked in. Disciplines that are behind on IFC count but tracking well on earned hours are a different management problem than disciplines that are behind on both. The dashboard separates these cases rather than collapsing them into a single traffic-light status.

Deliverable-Level Risk Visibility

EPCdoc tracks forecast dates and slip days at the individual deliverable level. When a deliverable’s forecast date moves beyond its planned date, EPCdoc records the slip — how many days, how many times the forecast has been revised, and whether a recovery plan has been submitted. This creates an audit trail of schedule movement that is separately trackable from the progress measurement itself.

Deliverables that are blocked — waiting on a vendor datasheet, held pending inter-discipline input, or paused on client instruction — are flagged with a distinct status rather than simply showing as “behind.” The difference matters for management: a blocked deliverable needs escalation, not chase-up.

Timesheet Integration

EPCdoc’s timesheet module feeds directly into the EPM calculation. Engineers log hours against specific deliverables, not against work packages or project codes. This means actual hours are always traceable to the specific document they were spent on — not aggregated into a discipline bucket that tells you the total cost but not where it went.

For the Engineering Manager, this means the “actual hours” figure in the EPM dashboard is not an estimate or an allocation — it is a direct sum of individually-attributed timesheet entries.

Milestones and Look-Ahead

Beyond the deliverable register, EPCdoc tracks engineering milestones — IFR freeze dates, model completion targets, IFC package submission dates — as discrete events with planned and forecast dates. The look-ahead view shows which milestones are due in the coming two to four weeks, which are at risk based on current deliverable progress, and which have already slipped. This is the operational planning tool the Engineering Planning Manager uses week to week, separate from the strategic S-curve view the Engineering Manager uses in progress meetings.

---

Engineering Progress as a Billing Instrument

In lump-sum and remeasured EPC contracts, engineering progress is not just an internal management metric — it is the basis for progress invoicing. The engineering contractor invoices the client for the percentage of engineering complete, and the client expects that figure to be defensible: backed by a named list of deliverables, their current status, and the manhour value they carry.

EPCdoc generates the engineering revenue-earned-to-date report as a direct output of the EPM system — not as a manually prepared document that someone assembles from several spreadsheets before each billing cycle, but as a live calculation from the deliverable register. Earned hours multiplied by the contract rate per discipline produces the invoiceable engineering value to date, with the deliverable-level detail to support it if the client’s PMC asks for backup.

This turns the EPM module from a project management tool into a commercial instrument — something that directly supports the engineering contractor’s cash flow, not just their internal reporting.

---

Change Notices and Budget Rebaselining

Engineering progress on a real EPC project does not happen against a fixed budget. Scope changes, client-initiated design changes, vendor substitutions, and site-driven revisions all add deliverables, add hours to existing deliverables, and extend schedules. If these changes are absorbed without being formally recorded and rebaselined, the budget figure in the EPM dashboard becomes meaningless — it is no longer the approved budget, it is the original estimate minus everything that happened since.

EPCdoc connects the Engineering Change Notice (ECN) and Scope Change Notice (SCN) workflow directly to the EPM deliverable register. When a change notice is approved, EPCdoc automatically rebaselines the affected deliverables’ budgeted hours and creates or extends the relevant schedule activity in the CPM engine. The baseline budget is preserved separately from the current approved budget — so the EPM dashboard always shows the correct approved budget, not the original one, while still allowing the engineering manager to see the cumulative impact of approved changes against the original contract scope.

---

Who Uses EPM, and How

Engineering Manager uses the discipline-level dashboard and S-curve for weekly progress meetings with the client and for internal resource decisions. The earned value figures and EAC are the primary inputs for any conversation about whether the engineering budget is under control.

Engineering Planning Manager uses the deliverable register, look-ahead, and milestone tracker for day-to-day schedule management — chasing outstanding IFR submissions, flagging blocked deliverables for escalation, and managing the forecast dates that feed the S-curve.

Discipline Lead uses their discipline’s deliverable register to manage their own team’s workload — seeing which deliverables are due, which are at risk, and how their discipline’s earned progress compares to actuals spent.

Document Controller uses the deliverable register as the master list of expected engineering outputs — the source from which the document register is built, and the record against which transmittals are issued.

Project Controls / Cost Engineer uses the earned value figures and manhour EAC for the project-level cost report — specifically to separate engineering cost performance from procurement and construction performance, and to identify engineering-driven cost variance before it surfaces at the project level.

---

The Engineering Progress Problem, Solved

EPCdoc’s Engineering Progress Management module does not make engineering easier. It makes engineering performance visible — objectively, consistently, and in a form that is useful for management, billing, and commercial defence.

The team still does the engineering. EPCdoc measures it the right way.

---

EPCdoc is built by Twor — engineers who ran EPC projects before building software to manage them.