openAWP as the AWP System Underneath
Registers with fields the project defines, the package hierarchy from CWA to tag, releases, constraints, 3D and 4D, deployed single tenant and kept by the owner.
We would propose an AWP system that stays with the owner, run by the owner's staffing partner, with AWPBI underneath as the practice and technology partner.
Registers with fields the project defines, the package hierarchy from CWA to tag, releases, constraints, 3D and 4D, deployed single tenant and kept by the owner.
Registers, the naming convention, the AWP Matrix, data requirements, 3D model attributes and integrity checklists, loaded once so every contractor is measured the same way.
Weekly reconciliation across the document register, the EDMS, the ISO list, the model and the schedule, with one accountable owner per dataset and a trend per rule.
Mobilize
We would deploy openAWP in the owner's tenant, set up the registers, the naming convention and the AWP Matrix, and load the standard. The staffing partner names its AWP manager and information manager.
Foundations
During pre-FEED and FEED we would keep the registers live against the AWP Matrix, record the path of construction with CWA and CWP boundaries, map every EWP to its CWP, and publish the first reports with the date their data was measured.
Connect and Run
The contractor's warehouse connects wave by wave with validation and alerts, EWP release runs on live data with the skyline and the lookahead, and the staffing partner runs intake, the AWP integrity check and reporting day to day with AWPBI coaching on the job.
Next Project
The configuration packages as the template, with what the first project taught in place as rules, reports and automations. The staffing partner leads the next deployment with the same team, and the portfolio view goes above every project if the owner chooses.
Most owners run projects on two principles that are each sound. A staffing partner staffs the project, and the contractor uses its own software where the software is suitable. The consequence is that the AWP record, 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 it leaves, and the next project builds it again. Advanced work packaging has been hard to scale for that reason, and the AWP record should outlive the contract sets out what an owner keeps instead.
A way to start is to put the owner's AWP system in the owner's tenant. There, openAWP holds the standard, the AWP Matrix, the registers and one validated record of every project, whichever contractor builds it. Two checks run before any number is trusted. Data integrity is measured in the contractor's warehouse against the owner's data requirements, and AWP integrity is measured in openAWP against the owner's package hierarchy and schedule logic, with every issue sent back to its owner and fixed at source, as described in weekly data reconciliation. The owner's staffing partner stays the visible operator on every project, for the long term. AWPBI works underneath as the technology and practice partner, and our measure of success is that the partner never has to build tooling to do its job well.
The end state we would propose is one portfolio view above every project, so each project starts where the last one finished. The configuration of the first project packages as the template for the second, in any region or portfolio, and leadership compares readiness and data quality across projects on one measure. The owner decides the tenant, the subscriptions and the Power BI capacity, names its own information manager and AWP lead as owners of the standard, and chooses whether the configuration becomes the template and whether the portfolio view goes above every project. Each step is small enough to judge on its own, and the next one is the owner's call.
Thirty minutes with a practitioner on your portfolio, on real software.
