Ask three people on a capital project what information management is and you will get three different answers: document control, the tag register, the reporting warehouse. All three are pieces of it. Information management (IM) is the discipline of managing documents, document attributes, equipment data, 3D models, and the relationships between them, so that work packages, materials, tests, and turnover records all travel on data the project can trust. On a packaged project, IM is not a support function. It is the discipline that makes every other procedure executable.
Why a packaged project runs on data
If your project runs advanced work packaging, every process in it consumes structured data. An EWP is not just a stack of drawings; it is documents plus metadata, tags, MTO lines, and model objects that procurement, fabrication, and workface planning all query. A constraint check on an IWP compares material receipts against a bill of materials. A turnover dossier assembles itself from document-to-tag-to-system relationships. When two systems disagree about a tag or a revision, the disagreement does not stay in the office: it surfaces at the workface as missing material, or at completions as a punch item.
That is why the founding principle of a good IM specification is progressive exchange: documents, data, and databases generated by contractors, subcontractors, and suppliers are structured, validated, and exchanged in parallel with the actual progress of the work, never as an end-of-job cleanup. End-of-job data campaigns always meet the same conditions: the engineers who created the data have rolled off the project, the design context is gone, and every defect costs archaeology against contract deadlines.
The four components of an IM framework
A complete IM framework has four parts:
- The narrative specification: the process itself, covering identification, classification, submission, review, approval, verification, handover, acceptance, and closeout.
- The Reference Data Library (RDL): the controlled vocabulary of the project. An equipment class library defines classification, attributes, and units of measure for equipment data, commonly built on the CFIHOS industry standard, with the most granular available class always selected. A document class library defines document types, attributes, review categories, and handover requirements. Project reference data carries the plant breakdown structure and the controlled code lists: areas, units, systems, originator companies, work packages.
- Deliverable templates, so every register and datasheet arrives in a shape the receiving system can load.
- Related standards for CAD, numbering, and databases.
The test of a mature framework is where compliance gets enforced. In a construction-driven program, compliance with the data requirements and 3D model attributes is verified before each EWP releases for IFC, and a package can be rejected on data alone. Data quality is a release gate.
Follow one pump's flowrate: it is born in a datasheet, lives in the equipment class attribute set, flows through the model, the MTO, and the purchase order, and dies in the maintenance system twenty years later. The RDL is what keeps that fact recognizable at every hop. Without it, every system speaks its own dialect and every handover becomes a translation project.
Identity is issued, never invented
Every object and every document on the project carries a controlled identity, and that identity is issued through a system of record, never made up at the point of need. The lead times in a good specification look bureaucratic until you trace one backward. Tags are typically requested around ten weeks before the planned EWP IFC release and available around eight weeks before it, because the tag has to be in the model before the MTO extracts, in the MTO before the purchase order line exists, on the purchase order before the packing list can match, and on the packing list before receiving can find the material. Late tags are late steel, four systems later.
Formatting discipline matters just as much. An instrument tag written three different ways (with a space, without one, with a different separator) is three different tags to every downstream system, and every hop multiplies the variants: MTO, purchase order, packing list, completions database. Fixing identity at the source, while the population is small, is the cheap version. Weekly reconciliation of a known defect carries it forever.
Documents get the same treatment through placeholders: a registered entry for a planned deliverable, created well before the file itself exists, carrying at minimum the document number, title, discipline, and package allocation. Placeholder completeness is the earliest leading indicator in the whole program. If placeholders are complete eight weeks before release, the denominator of every progress number is real and package scope is knowable. Late placeholders mean every percentage upstream of the field is fiction.
The document lifecycle: reviews, response codes, revisions
Formal review is where document control meets the schedule. Deliverables are classified into review categories: the most critical add an independent verification agent, routine deliverables get a standard company review on a fixed clock, and some are information only. Two rules do the most damage when misunderstood.
First, silence is consent only where the specification explicitly grants it, usually on the routine category alone. Proceeding on an unanswered deliverable that requires explicit approval means the work has been running on an unapproved basis from day one.
Second, response codes decide what may proceed. Minor comments let work continue while the comments are incorporated. Major comments stop downstream work until the document returns clean.
A foundation drawing that comes back with major comments stops the pour, even with the crew mobilized in that area. The recovery play is speed on the review cycle, not risk transfer to the field: a technically commented drawing poured anyway becomes installed concrete plus a demolition decision.
Revision identifiers follow a grammar: letters while a document is a draft, numbered revisions once published, redline suffixes for field markups on the IFC base, a separate numbering series for as-builts, and a formal void status cross-referenced both ways with the superseding document. Hold that grammar and the register stays readable for the decades the plant will operate. Batch documents into compiled books instead, and the operating facility inherits documents whose current state exists only inside a PDF.
Change is a data event
An EWP issued for construction is the approved baseline for fabrication, procurement, workface planning, and project controls, which makes every change to it a data event as much as a drawing event. Two disciplines keep change honest. The first is early warning: the moment a discipline lead knows a change will revise an IFC document, a notification goes out to construction, fabrication, procurement, and project controls, before the revised documents are released. Nobody downstream should learn about a change from the transmittal.
The second is completeness. A revision is not complete because revised documents were issued. It completes only when the metadata, allocations, tag registers, MTOs, 3D models, schedule, and reporting systems are all verified as reconciled against the issued revision. Anything less leaves two versions of the truth in circulation.
Supplier information is project information
Supplier data is managed to the same standards of governance, tagging, and traceability as contractor-generated information, and the requirements travel contractually: into requisitions, RFQs, purchase orders, and supplier document requirement lists. Deliverables are timed by purpose, from bid go-bys through general arrangements ahead of model reviews to certified finals around shipment.
The rule that bites is at the shipping dock: no identification, no shipment. Packing lists arrive structured, with parent-child traceability down to child components, or the shipping release is withheld. A skid that arrives as a scanned crate list cannot be received against the BOM, allocated to its package, or trusted at completions. Receiving can count crates; it cannot reconstruct relationships it never received.
Two systems of record, one declared split
A mature project declares the split explicitly: the document management system is the system of record for documents and revisions, and a structured data warehouse is the system of record for project data. Any discrepancy between them is a data-quality defect with an owner and a deadline, not a fact of life.
Inside the warehouse, data moves through layers: raw extracts land first, validated data with quality checks applied and relationships established sits in the middle, and optimized reporting datasets feed the dashboards. The middle layer is the one that matters, because it holds the validated relationships between tag, document, package, and material that reporting and handover both depend on. A validation layer that blocks a dashboard launch is working as designed. Point dashboards at raw extracts and they publish every unresolved defect as fact.
Handover is progressive
Everything above converges on handover. Governed by an information handover plan, delivery happens progressively in searchable electronic formats, with startup-critical documentation accessible before facility startup. If IM ran progressively from FEED, handover is a verification exercise. If it did not, handover becomes a data reconstruction project running against contract deadlines, staffed by people who were not there when the decisions were made.
Where AWPBI fits
Standing up this framework is what our information management consulting team does: the specification, the RDL, the governance rhythm, and the warehouse. On the software side, openAWP is built for projects that take data ownership seriously: user-defined forms, fields, and package hierarchy so the data model matches your specification, deployed single-tenant on your own infrastructure, with a full API for your warehouse to consume. For the reporting layer, Custom Dashboards builds the Power BI views that sit on top of validated project data.
If work packaging is new to you, start with what advanced work packaging is, then come back: IM is the discipline that makes it executable.