What Is Project Controls?

Project controls is the discipline that tells a capital project where it actually stands: what the work will cost, when it will finish, and how far reality has drifted from the plan. In practice it covers five functions: planning and scheduling, progress measurement, cost management, change control, and forecasting and reporting. Done well, it is the project's instrument panel, the thing a project manager trusts before committing money. Done poorly, it is a monthly report that describes last month. This article walks through each function the way a practitioner meets it on an industrial project, and looks at how advanced work packaging has changed what good looks like.

The five functions, briefly

• Planning and scheduling. Turning scope into a logic-linked, resource-loaded schedule, typically built and maintained in Primavera P6, and then defending its baseline.
• Progress measurement. Deciding what counts as earned progress and collecting it objectively, so that percent complete means the same thing in every status meeting.
• Cost management. Budgets, commitments, actuals, and the earned value that connects money spent to work physically in place.
• Change control. Making sure scope, schedule, and budget only move through a governed process that leaves a record.
• Forecasting and reporting. Converting all of the above into an honest forecast and putting it in front of people who can act on it.

None of this is new. What has changed on industrial projects is the unit of control. Traditional project controls measures activities and disciplines. On a project run under advanced work packaging, the unit of control is the work package: the EWP, the PWP, the CWP, and at the workface the IWP. That shift touches every one of the five functions, so the rest of this article treats them through that lens.

The schedule is the integration engine

The Level 3 schedule is where engineering, procurement, fabrication, and construction meet the path of construction. On a package-driven project, a few rules make it work:

• Work packages are activities. Each EWP, PWP, and CWP appears as a real activity with a duration, logic ties, and resources. Packages are never represented as finish milestones, and each EWP is a single activity whose Activity ID is the EWP number itself.
• Activities stay short. Level 3 activities run no longer than about eight weeks, which matches CWP sizing. Detailed construction planning happens at Level 4, by IWP, in one-to-two-week activities, and it lives in the workface planning software, never in the Level 3 schedule.
• Four dates per EWP. Baseline planned release, current planned release, actual start, and actual finish (the date the package is released through document control). Everything else, review cycles and transmittals included, lives in its own tracker.

A useful audit for any schedule that claims to be AWP-compliant is four tests. EWP release dates link to CWP planned start dates. Material availability is integrated into construction planning. Constraint-based readiness gates are used. And performance is measured by work package, not by activity percent complete. If your P6 file fails any of these, you have a schedule that mentions packages, not a package-driven schedule. As a minimum, activities carry coding for CWA, discipline, package type, and contractor, so one file can be sliced for every audience. There is more on P6 practice in our Primavera hub.

Progress measurement: rules of credit you cannot argue with

The strongest progress systems share one property: the credit rule is objective. On the AWP programs we work to, engineering progress per EWP is simply documents issued IFC divided by total documents in the package. A document is either issued for construction in the document management system or it is not. There is no partial credit, and the denominator is the full document list, placeholders included, so scope not yet produced still counts against you. Procurement packages use weighted rules of credit across their lifecycle, for example engineering 20 percent, procurement 25, fabrication 40, inspection 5, delivery to site 10, reported weekly.

Why so strict? Because subjective percent complete gets gamed, rarely maliciously, mostly optimistically. Every scheduler has watched a deliverable sit at 92 percent complete for three months. Binary, package-level credit cannot do that: a document is IFC or it is not, a PWP has 100 percent site receipt or it does not. That discipline is what turns a progress report into a forecast someone can commit money against.

A WBS that schedulers cannot "improve"

The work breakdown structure on a package-driven project is deliverable-oriented: its elements are work packages, and its levels are phase (engineering, procurement, construction), discipline, and construction work area. It is deliberately rigid: schedulers may not add or remove levels. That rule reads as bureaucratic until you watch what happens without it. Extra levels disrupt the flow of packages and break IWP production, crew allocation, and material allocation downstream. Reporting flexibility comes from activity coding, not from reshaping the hierarchy.

A second structural rule is worth stealing even outside AWP: every package activity is fully resource loaded and cost loaded before the baseline is approved. A baseline approved with unloaded activities is a date list, not a control instrument.

Cost lives on the same structure

Cost control earns its keep when the cost breakdown maps onto the same packages the schedule and progress systems use. Commitments roll up by PWP, installed cost by CWP, and earned value falls out of the rules of credit above. When cost sits on a different structure, someone spends the first week of every reporting cycle reconciling two coding systems by hand, and the forecast inherits every mapping error they miss.

Change control: one register, then the systems

On a project with hundreds of packages spread across several systems (P6, the master document register, the document management system, the AWP software, procurement tools), the change-control question is: which system holds the truth? The answer that works is none of them. A single controlled register, the AWP Matrix on our projects, defines which packages exist and how they relate, and every downstream system aligns to it only after each weekly controlled issue. No package is created, deleted, split, merged, or re-allocated outside that register. Once the updated register is issued, project controls updates P6, document control re-assigns documents, engineering updates model attributes and MTOs, and procurement updates its packages, in that order.

The integrated project controls team (owner, engineering contractor, construction contractor) closes the loop with a monthly reconciliation: register against Level 3 schedule against the document register against the AWP software. A package that exists in one system but not the others is a defect to be resolved, not a curiosity.

Forecasting and reporting

Two rhythms matter. Weekly: the engineering schedule and the release plan are issued every week, with notification of significant package date changes, and a stewardship tracker covers every package due in the next eight weeks with quantities, input dates, planned and forecast IFC dates, color-coded status, and delay reasons. Monthly: cost, earned value, and trend reporting for management, plus the reconciliation described above.

The delivery layer for most of this, in our practice, is Power BI: skylines for each package type (EWP, VEWP, FEWP, PWP, CWP), lookahead views, and status dashboards fed from a governed central data repository. The test of a reporting stack is traceability: if a number on the page cannot be traced to the system it came from, it is opinion, not controls. There is more on the reporting side in our construction reporting hub.

Where AWPBI fits

Project controls is one of our service lines: schedule builds and health checks, package-based progress measurement, and reporting stacks, delivered by a team whose field record covers WFP, AWP, and IM on capital projects from $20M to $10B. The project controls service page has the commercial detail. On the product side, openAWP carries the package and constraint data this article keeps referring to, Custom Dashboards is our bespoke Power BI project-status dashboard offering, and Skyline and Burndown are free Power BI visuals, built for the industry and free by design.