Advanced work packaging does not replace Primavera P6. It changes what the Level 3 schedule is made of. In an AWP-compliant schedule, the activities are the work packages themselves: CWPs, EWPs, and PWPs, each a real activity with a duration, logic ties, and resources. Activity IDs carry package numbers, activity codes carry the CWA, discipline, package type, and contractor, and EWP release dates link directly to the planned start dates of the CWPs they feed. Installation work packages (IWPs) stay out of P6 entirely. That is the short answer. The rest of this article is what it looks like in practice, and how to tell whether a P6 schedule is actually AWP-compliant or just AWP-labeled.
The sequence comes before the schedule
If AWP itself is new to you, start with what advanced work packaging is and come back. The short version: plan backward from startup, and break scope into packages sized for how the work will be built.
The scheduling consequence is an iron rule: do not create a detailed activity schedule until the CWP-EWP-PWP sequencing exists in the Level 3 schedule.
That sequencing is the Path of Construction: the optimal building sequence, based on constructability criteria and commissioning and start-up priorities, expressed as a logical, dated sequence of CWPs in the Level 3 schedule. It is negotiated in Interactive Planning sessions with operations, engineering, procurement, construction, and commissioning at the table, and it is graphical, developed first in 2D and then against the 3D model. Each CWP in the agreed sequence then determines the scope, boundaries, and need dates of its EWP and PWP. Once the sequence is agreed, both scheduling teams, engineering and constructor, implement the packages as unique activity IDs with logic in Primavera.
Notice the order. On a traditional project, schedulers build the activity network from the WBS and the estimate, and packages get mapped onto it later, if at all. Under AWP, the package logic exists first and the detailed schedule is built from it. If your project is doing it the other way around, no amount of activity coding will fix it afterward.
What lives at Level 3
Alignment between engineering, procurement, fabrication, and construction is planned at Level 3, with activities of typically no more than eight weeks, a duration that matches CWP sizing. The rules per package type:
- Every construction activity at Level 3 corresponds to a CWP, and the constructor maintains the forecast CWP durations.
- Each EWP is a single activity whose Activity ID is the EWP number. EWP durations derive from drawing counts and planned production rates, with discipline leads mapping their typical engineering cycle times before the Path of Construction is developed.
- Preliminary engineering activities (readiness reviews, kick-off meetings, constructability and stress analyses, model reviews) are scheduled as predecessors to their EWPs. An activity that supports several EWPs links to every one of them.
- A VEWP activity starts when the first PO associated with it is issued and finishes when the final vendor drawing in the package is planned IFC. A PWP finishes at 100% site receipt, measured against its ROS date.
Work packages are activities with durations, logic, and resources, never finish milestones. A milestone cannot be resource loaded, progressed, or forecast, and those are exactly the three things you need a package to do in P6.
For each EWP, the Level 3 schedule records four dates: baseline planned release, current planned release, actual start, and actual finish, where actual finish is the DMS release date. Review and transmittal dates belong in the Review Tracker, not in the schedule.
What stays out: IWPs
No Level 4 IWPs appear in the Level 3 schedule, under any condition. IWPs are one-to-two-week crew packages, hammocked within their CWPs at Level 4 and managed in the workface planning system, not in P6.
It is always tempting to pull IWPs into P6 so that "everything is in one place." Resist it. IWP scope moves constantly: constraint dates shift, crews get reassigned, packages get split and rebuilt in the field. That churn belongs in the workface planning system, where planners manage it daily. The Level 3 schedule is the integration engine between engineering, procurement, fabrication, and construction, and it only works if it is not being rebuilt every time a crew plan changes. If you want the fuller picture of how the field side works, see how workface planning fits into AWP.
Activity coding, and why the hierarchy is frozen
The minimum P6 activity coding for an AWP project is four codes: CWA, discipline, package type, and contractor. The codes reflect the package nomenclature, which means the naming convention has to be frozen before the schedule is built. That convention is the shared language across every system on the project: P6, the document management system, the MDR, the 3D model, and the AWP software all reference the same package IDs.
The package hierarchy itself is fixed. Schedulers will not add or remove levels, because doing so disrupts IWP production, crew allocation, and material allocation downstream. If someone needs a new reporting cut, the answer is activity coding, not an extra WBS level.
The four tests of an AWP-compliant schedule
A schedule can contain package-shaped activities and still not be an AWP schedule. Four tests separate the real thing from the label:
- EWP release dates link to CWP planned start dates.
- Material availability is integrated into construction planning.
- Constraint-based readiness gates are used.
- Performance is measured by work package, not activity percent complete.
Test one is the package logic itself: if you can delay an EWP in P6 and no CWP start date moves, the linkage does not exist. Tests two and three are about what the schedule assumes versus what it verifies: a CWP start date that ignores material receipt and open constraints is a date, not a plan. Test four changes the monthly progress conversation, which is where most schedules quietly revert to tradition: activities coded to packages, but progress still earned as activity percent complete.
Keeping P6 aligned: the AWP Matrix
Packages change. CWPs get split after a crane plan changes, EWPs get merged, scope moves between areas. The cardinal rule is that no work package may be created, deleted, split, merged, or re-allocated outside the AWP Matrix, the single controlled list of all work packages and the relationships between them. Downstream systems, and Primavera P6 is explicitly one of them, may be aligned to a change only after the updated Matrix has been issued.
Think of the Matrix as the project's foreign-key table. P6, the DMS, the MDR, the model, and the AWP software each hold fragments of package data; the Matrix defines which combinations are legal. Update P6 first and you have created an orphan record that every weekly reconciliation will flag until someone hunts it down.
The cadence around this is deliberately tight: the engineering schedule and the EWP Release Plan are issued weekly, with a weekly notification of significant package date changes. Discrepancies between the engineering MDR and P6, or between the engineering and constructor schedules, are resolved through the Matrix review process, not by either scheduler quietly editing their own file. Neither schedule outranks the other; both align to the Matrix.
Progress that cannot be gamed
Package-based measurement changes the arithmetic of progress. EWP progress is documents issued IFC divided by the total documents in the EWP, with the denominator being the full MDR document set including placeholders. Credit per document is binary: it is IFC in the DMS or it is not.
That binary, package-level credit is what makes the reporting trustworthy. Package status is displayed as skylines: Power BI visuals showing package status against schedule dates, linked to the Level 3 schedule so that misalignment between the MDR and the schedule is instantly visible. Equivalent skylines exist for EWPs, VEWPs, FEWPs, PWPs, and CWPs. How that reporting layer gets built is its own topic; the Power BI hub covers it.
Where AWPBI fits
Everything above is method, and it holds whatever software you run. On the tooling side, openAWP integrates with Primavera P6, so the package structure and dates in your AWP platform and your Level 3 schedule come from one connected pipeline. Skyline is our free Power BI visual for exactly the view described above: package status against schedule dates. And if the problem is upstream of tooling, building the package-based schedule and coding structure in the first place, that is the kind of work our project controls consulting covers.
To see a P6 schedule feeding an AWP platform live, book a demo or explore openAWP directly.