Book a demo
Login
Advanced Work Packaging has become the standard methodology for executing large capital projects in oil and gas, energy, and chemicals. The productivity gains it delivers are well documented: projects that implement AWP properly see measurable reductions in rework, improved schedule performance, and lower construction man-hours per unit of installed scope. The methodology works. The problem is that AWP is entirely dependent on the quality of the engineering data it consumes — and most AWP implementations treat data quality as someone else's problem.
This article is about the gap between what AWP tools deliver and what capital projects actually need. It is also about why every organization running AWP should think carefully about what sits underneath the work packaging layer. For a full explanation of the AWP methodology, the work package hierarchy, and the standards that govern it, see our Advanced Work Packaging (AWP) glossary entry.
Advanced Work Packaging software — platforms like O3 Solutions' ONBuild product — is designed to plan, sequence, and manage the execution of construction work packages. They provide visibility into the path of construction, help identify and resolve constraints before IWPs are released to the field, and give project controls teams the data they need to manage schedule and resource allocation at the work package level.
These are real capabilities that deliver real value. AWP tools are execution management tools. They answer the questions: Which work packages are ready to execute? Which IWPs are constraint-free? What is blocking the ones that are not? What is the planned sequence of construction through each work area? How is field execution performing against the planned path of construction?
What they are not designed to do — and what no AWP tool does — is govern the underlying engineering data that work packages depend on. That distinction is the core of this article.
For an Installation Work Package (IWP) to be constraint-free and ready for release to the field, specific conditions must be met. The engineering design within the IWP scope must be complete and at the right revision. All materials in the IWP must be available at the workface. The drawings and vendor documents the craft workers need must be in the correct revision and physically accessible. The equipment items in the IWP scope must be properly tagged and their technical attributes must be complete enough for inspection and acceptance.
Every one of these constraints has a data dimension. Engineering completeness is a data question: has the tag register been updated to reflect the current design, and is the engineering document index at the right status? Material availability is a data question: are purchase orders linked to the correct tags, and has vendor documentation been received and verified against the correct equipment records? Drawing access is a data question: are documents linked to the right tags in the engineering document management system, at the right revision, and have they passed vendor document review? Equipment acceptance is a data question: are the CFIHOS-required technical attributes populated, validated, and traceable to approved source documents?
AWP tools can track whether these constraints are resolved. They cannot resolve them. They cannot govern the engineering data that determines whether a constraint is genuinely cleared or just marked complete by someone who wanted the IWP to progress.
The most common source of IWP constraints in field execution is not construction readiness in the traditional sense. It is data incompleteness. Engineering documents are at the wrong revision. Vendor data has not been received, or has been received but not processed against the correct tag numbers. Equipment attributes required for mechanical completion are missing or have not been validated against the approved datasheet. Materials are on site but cannot be confirmed against the purchase order because the procurement data has not been linked to the tags in the IWP scope.
These failures are not AWP failures. They are data management failures upstream of AWP. But they manifest as AWP constraints, delayed IWP release, and field work stoppages that erode the productivity gains the methodology was supposed to deliver.
The data gap is particularly acute in projects with complex supplier and sub-supplier chains. A large capital project in the energy sector might have 200 to 500 suppliers submitting engineering data — datasheets, equipment lists, inspection records, preservation procedures, installation manuals — each in their own format, against their own part numbers rather than project tag numbers. Without a governed process for receiving, validating, and linking that supplier data to the project tag register, the IWP constraint check cannot actually verify whether engineering data is complete for a given scope. The constraint is marked open because nobody can confirm it is actually closed.
CFIHOS — the Capital Facilities Information Handover Specification — defines the structured data model for equipment attributes that owner-operators in oil and gas, energy, and chemicals require at facility handover. It specifies which attributes must be populated for each equipment class, how those attributes must be structured, and what the source of each attribute value must be.
CFIHOS matters for AWP because it defines completeness. When a project defines its data requirements using the CFIHOS data model, there is a clear, unambiguous answer to the question of whether engineering data is complete for a given tag: either the required attributes are populated with validated values traceable to approved source documents, or they are not. This makes it possible to actually measure IWP data readiness rather than relying on subjective assessments or checkbox processes.
AWP tools cannot implement CFIHOS. They do not have the data model, the validation logic, or the supplier submission workflow required to collect, validate, and structure equipment attribute data against a CFIHOS template. That is not what they are designed to do. But without CFIHOS-structured data in the underlying engineering data environment, the data completeness checks that AWP depends on for IWP release are unreliable.
AWP work packages are organized around tags. IWPs contain the tags in scope for a specific field installation activity. CWPs aggregate IWPs by discipline or construction work area. The sequence of construction through the path of construction is, at its foundation, a sequence of tag-level completions.
For this to work, the tag register that drives AWP execution must be authoritative, complete, and synchronized with the current engineering state. Tags that appear in an IWP scope must exist in the tag register at the correct revision. Tags that were deleted from scope must not appear in active IWPs. Tags that were added in a late engineering change must be incorporated into the work packaging structure before the affected IWPs are released.
When the tag register is managed informally — in engineering tools that are not synchronized with the AWP platform — the IWP scope integrity is permanently at risk. Work packages contain tags that no longer exist in the current design, or are missing tags that were added. Field execution proceeds against an IWP scope that does not match the current engineering state. The rework and re-inspection that follows is precisely the cost that AWP was implemented to eliminate. For a practical guide to master tag register governance from FEED through CMMS handover, see our article on the master tag register as the foundation of asset identity in capital projects.
AWP tools and engineering data management platforms are not competitors. They address different layers of the same problem. AWP tools handle execution planning and constraint management. Engineering data platforms handle the data governance that makes constraint management meaningful.
Organizations that implement both see materially different outcomes from their AWP programmes than organizations that implement AWP tools alone. When IWP constraint checks are backed by a governed, CFIHOS-structured engineering data environment, the constraint resolution process works because data completeness can actually be verified rather than assumed. When the tag register governing AWP is synchronized with a live, validated master tag register, IWP scope integrity is maintained through engineering changes. When vendor data submissions are processed and linked to tags through a governed workflow, the vendor data constraint type — consistently one of the largest sources of IWP delays in field execution — becomes manageable.
Sharecat provides the engineering data governance layer that AWP tools depend on but cannot themselves deliver. This is not a marginal improvement — it is the difference between AWP constraint management that works and AWP constraint management that appears to work until the IWP hits the field.
The Sharecat tag register is the single, governed master of tag identity for the project. It enforces the tagging convention, prevents duplicates, maintains the full change history for every tag, and is the source of record for which tags are in scope, at what revision, and in what status. When AWP work packages are built from the Sharecat tag register, IWP scope integrity is assured: the tags in each work package reflect the current engineering state, not a snapshot from an earlier phase. Engineering changes that affect scope are captured in Sharecat's change management workflow and propagate to the affected work packages — not discovered at field release when the drawings no longer match the installed configuration.
Supplier data submissions in Sharecat are validated against CFIHOS templates and linked to project tags at point of receipt. Vendors cannot submit documentation against internal part numbers and expect it to pass review; submissions must be structured against the project's CFIHOS data requirements and tagged against the project's tag register. This transforms vendor data from the largest category of AWP constraint into a measurable, trackable completeness metric: for each tag, at each point in the project, it is possible to know exactly which required data is present and which is missing — not as a manually maintained spreadsheet, but as a governed, queryable status in the platform.
Document management in Sharecat links every document — drawings, datasheets, inspection certificates, vendor manuals — to the tags they cover. When an AWP platform checks document availability as an IWP constraint, it can draw from a data environment where document-to-tag linkage is maintained and validated, not one where documents are stored in a file system and tag references exist only in document metadata maintained by document controllers.
The result is an AWP programme where constraint management works as designed: constraints are identified from real data, resolved through governed processes, and verified against a data environment that accurately reflects the current engineering state. The IWPs released to the field are genuinely constraint-free. The productivity gains AWP promises are achievable because the data layer that makes them possible is actually in place.
For organizations running AWP tools, Sharecat is not an alternative to those tools. It is the foundation they require. AWP software manages what happens once the data is right. Sharecat makes the data right.
No. AWP platforms are designed for work package planning, sequencing, and execution management. They can track whether engineering data constraints are open or closed, but they cannot collect, validate, and structure equipment attribute data against a CFIHOS data model. That capability requires a dedicated engineering data management platform with supplier submission workflows, validation rules, and a governed tag register. AWP tools and engineering data platforms are complementary layers, not alternatives.
Vendor and supplier data incompleteness is consistently one of the largest sources of IWP constraint delays in practice. When vendor data has not been received, or has been received but not processed and linked to project tag numbers, the data completeness check for IWP release cannot confirm that engineering data is actually available for the work scope. The IWP remains constrained while teams manually track down document status in email threads and shared drives.
CFIHOS provides an unambiguous definition of what complete engineering data means for each equipment class. When a project defines its data requirements using CFIHOS, the constraint check for IWP release has a clear, measurable standard: either the required attributes are populated with validated, traceable values, or they are not. Without that standard, data completeness is a subjective judgment. With it, IWP data readiness is a measurable status that can be tracked and managed through the project schedule.
No. Sharecat provides the engineering data governance layer — the governed tag register, CFIHOS-structured attribute management, supplier data submission workflows, and document-to-tag linkage — that AWP tools need to function reliably. AWP tools continue to manage work package planning, path of construction sequencing, constraint tracking, and field execution management. The two systems work together: Sharecat ensures the data that AWP depends on is complete, governed, and accurate; AWP tools use that data to manage field execution effectively.
ISO
27001
Certified
