On most capital projects the AWP record, which is the registers, the AWP Matrix and the readiness history, sits in the contractor's system for the length of the contract. When the contract ends the record leaves with it, and the next project builds it again from a blank sheet.
We have sat on the owner's side of that handover more than once. The following is what we think an owner should do about it, and why the fix starts with where the standard lives.
Two Principles Most Owners Hold, and Are Right to Hold
Most owners we have worked with run their capital projects on two principles. The first is that a staffing partner staffs the project. A long-term partner at the right cost, embedded on every project, builds the same skills from one job to the next, and the owner's own organization stays lean. The second is that contractors bring their own software where the software is suitable. The owner specifies what has to be delivered and leaves the tooling to the people doing the work.
Both principles are sound. We would keep them. The owner that abandons either one usually ends up paying for a bench it does not need or for software its contractors will not use.
The Consequence Nobody Chose
Put the two principles together and a third thing follows that nobody decided. The AWP record sits with whoever runs the AWP software, and on most projects that is the engineering or construction contractor, for the length of the contract.
The best case today is a strong contractor on a well-run job. Even then, the owner works inside someone else's system, with the access the contractor grants and the export format the contractor's license allows. The owner's AWP lead reviews the EWP release plan in a report the contractor built. All of that is reasonable during execution. The problem arrives at the end.
When the contract closes, the registers, the matrix, the readiness history and the lessons go with it. The owner keeps the plant and the handover documents. The record of how the plant was packaged, sequenced and released stays in a system the owner no longer has a login to.
What the Record Is
The record is a small number of controlled lists and the relationships between them. On the projects we have run, these are the pieces that take the longest to build and are the first to be lost at closeout.
| Component | What it holds | Who needs it on the next project |
|---|---|---|
| AWP Matrix | Every CWA, discipline and sub-discipline mapped to its CWP, EWP, VEWP, FEWP, PWP, FPWP and MWP, issued weekly with its change log | Project controls, document control, engineering, procurement and workface planning, so every system aligns to one list |
| Naming convention and hierarchy | The TYPE, CWA, DISC, SUBDISC and SEQ structure every package name follows, frozen before the first ISO is issued | Everyone who has to make the schedule, the document system, the model and the material system talk |
| Tag Register | One source of truth for every tag, with parent and child relationships and its EWP, CWP and PWP | Engineering, procurement, materials, completions and the people who build the next tag register |
| Data Requirements and 3D model attributes | What each discipline delivers as data, at what granularity, and which attributes every model object carries | The next contractor, who inherits a standard and does not have to write one |
| Definition of complete | What complete means for each package type, EWP through SWP, fixed in the procedure | Whoever has to settle the first progress argument on the next job |
| Readiness history | Which packages released when, which were IFC with accepted HOLDs, which constraints escaped and why | The owner's AWP lead, who otherwise relearns the same lessons |
None of this is a dashboard. A dashboard only reads the record, and it is the record that has to survive closeout.
Why AWP Has Been Hard to Scale
Owners have been trying to make AWP repeatable for well over a decade, and the method itself is well documented in CII IR 272-2, the Construction Industry Institute's implementation resource for Advanced Work Packaging. The difficulty has been in carrying it from one project to the next.
It has lived in people. A strong project manager builds the program, gets promoted, and the next project starts over. It has lived in contractor systems, so the registers and the matrix leave when the contract ends. Each project has therefore rebuilt its own version of the same thing, and the lessons learned register from the last job becomes a document people read in the first week and do not open again.
The pattern holds even when the owner writes a good procedure. A procedure says what the record should contain. It does not hold the record.
What Changes When the Owner Holds the Standard
The change we would propose keeps both principles and moves one thing. The owner's AWP system lives in the owner's tenant, run day to day by the staffing partner, and it holds the standard.
The standard is loaded once. The naming convention, the hierarchy, the Data Requirements, the 3D model attributes, the definition of complete and the integrity checks sit in the owner's system before any contractor system exists for the project. Contractors keep their own software where it is suitable. They deliver documents and data to the owner's requirements, as they do today, and the owner holds one validated record of every project, whichever contractor builds it.
Each project then starts where the last one finished. The configuration of the first project becomes the template for the second. A new region or a new portfolio starts from that template, and the staffing partner that ran the first deployment leads the next one with the same team. When the project manager is promoted, the record stays.
This also changes what the owner can see. Every project is measured the same way, so leadership compares package readiness and data quality across the portfolio, and the AWP weekly meeting runs from the owner's own figures. The owner's role is still oversight and stewardship, as described in how owners run AWP across several EPC contractors. The difference is that the oversight runs on a record the owner holds.
Two Checks Before the Data Is Trusted
An owner-held record is only worth holding if the data in it is right. We would propose two checks, in two places, with every issue fixed at source by whoever owns the data.
The first check is data integrity, and it runs in the contractor's engineering and procurement data warehouse. The Data Requirements become rules. The document register is reconciled against the document management system, the ISO list against the 3D model, tags against purchase orders and MTOs, and forecast dates against the EWP release plan. Discrepancies go back to the discipline that produced them. That routine, and why most projects skip it, is the subject of weekly data reconciliation.
The second check is AWP integrity, and it runs in the owner's system against the owner's standard. The standard says that every CWP has one EWP and one PWP, that every document is allocated to a package or marked not applicable, that every tag sits in a package, and that the Level 3 schedule carries work packages as activities while the IWPs stay at Level 4. The package hierarchy and the schedule logic are measured against the standard every time the data moves, and a package that fails is not released.
The contractor is accountable for the quality of what it delivers. The owner is accountable for the standard it is measured against.
What the Owner Keeps
At the end of a project run this way, the owner keeps the standard, the configuration, the validated record of every package from FEED to turnover, and the system it all runs in. In our practice that system is openAWP, deployed in the owner's tenant, and the owner keeps the software and the right to modify it when the engagement ends. How that is set up and run is described under owner-side AWP services.
The contractors still bring their own software and the staffing partner still staffs the project. The record stays with the owner, and the next project starts from it.