Misalignment between the document register, the document management system, the ISO list, the 3D model and the schedule is the largest recurring source of AWP effort on the projects we have worked. A weekly reconciliation routine, with one accountable owner for every dataset, removes most of that effort and turns data quality into a number that trends.
Most projects know this and still skip it. The comparison gets done by hand, by one person, in a workbook, and the result is argued about in a meeting that was supposed to be about something else.
The Monday Rebuild
On a project without the routine, the week starts the same way. Someone on the information management team exports the master document register from the engineering contractor, exports the document list from the document management system, pulls the ISO list, takes the latest model extract and opens last week's workbook. The lookups get rebuilt. By Wednesday there is a list of mismatches. By Thursday the discipline leads have disputed half of them, and the Friday meeting opens with the question of whose number is right.
That meeting was scheduled to decide which EWPs release next week. The reconciliation dispute takes the first twenty minutes, the decision gets taken on numbers nobody fully trusts, and the workbook is rebuilt again the following Monday with slightly different exports.
The cost is rarely visible as a line item. It shows up as an information manager who spends a day a week on lookups, and as an EWP that releases with a document the construction contractor does not hold at the right revision.
Four Discrepancies Account for Most of the Effort
The mismatches fall into a small number of categories, and each one has a typical cause and a person who feels it first.
| Discrepancy | What it looks like | Who feels it first | Typical cause |
|---|---|---|---|
| In the document management system, absent from the register | A drawing has been issued and transmitted, and the master document register has no row for it | The AWP manager, whose EWP denominator is wrong | A placeholder was never requested, or the register is synchronized on a slower cycle than the EDMS |
| In the register, absent from the document management system | The register lists a document as issued and the EDMS has no record or an older revision | Document control, during the weekly revision check | The register was updated by hand ahead of the transmittal, or a renamed document broke the link |
| Issued per the ISO list, absent from the model | An isometric is IFC on the list and the line or spool does not exist in the model extract | Workface planning, when the IWP cannot be built from the model | The model was conditioned from an older design version, or the ISO carries a line number the model does not |
| Revision mismatch between contractor system, EDMS and site | Three systems hold three revisions of one document | The construction contractor, who installs from the wrong one | A post-IFC change was issued without a change notice, or the distribution matrix missed a recipient |
Two leading indicators sit alongside these. The first is placeholder completeness, which is whether every planned document for an EWP exists in the register at least 8 weeks before the planned release date. The second is document allocation, which is whether every document is assigned to an EWP, a VEWP or an FEWP or marked not applicable. When either slips, the four discrepancies above follow within weeks.
Why Spreadsheet Comparisons Fail at Project Scale
A spreadsheet comparison works on a small project and fails on a large one for reasons that have little to do with the person doing it.
The volume is the first reason. A project of any size carries tens of thousands of controlled documents, weekly revisions, and five or six sources of truth that each export in a different structure. A workbook that holds all of that is slow and fragile, and it is owned by one person.
Timing is the second. Each export is a snapshot taken at a different moment, so the comparison is of states that were never simultaneously true. A document issued on Tuesday afternoon appears in one export and not another, and the mismatch is real for a day and gone by Friday. The team learns to discount the list, which means it also discounts the mismatches that matter.
The third reason is that a workbook has no history. It answers whether two lists agree today. It cannot say whether the register has been getting better or worse for six weeks, which is the question leadership actually asks.
The fourth is ownership. When the comparison lives in a personal workbook, the method leaves when the person rotates off the project. The successor starts over, and the project pays for the same lesson twice.
The Routine
The routine that replaces the workbook has five parts, and none of them is complicated.
The cadence is weekly, on a fixed day, with the comparison run before the AWP weekly meeting so that the meeting reviews results. Document counts, register against EDMS discrepancies, register against ISO list discrepancies, allocation gaps and forecast dates against planned release dates are checked every week. The data warehouse itself is reviewed and cleaned monthly.
Every dataset has one accountable owner. The engineering contractor's information manager owns the quality of the engineering data and the implementation of the checks. The master document register, the tag register, the model extract and the fabricator status report each have a named owner. When a check fails, there is one name against it.
Every rule produces a trend line. A rule is measured every week, and the result is kept, so the register's health is a line over the life of the project. The line is what gets reported to leadership, since a single week's figure is easy to dispute and a six-week trend is not.
Defects are fixed at source. A tag that is spelled two ways is corrected in the system that created it, and the warehouse and the report take the correction from there. The warehouse holds a validated copy of the source, and the source stays authoritative.
The owner's information manager provides oversight. The contractor runs the checks and fixes the failures. The owner audits that the framework is working, reviews the trends, and escalates repeat findings through the project's non-compliance process. Responsibility for quality rests with the organization that produces the data. Responsibility for the standard rests with the owner.
What a Validation Dashboard Publishes
Once the rules are written down, the dashboard follows. On a well-run project it publishes a small set of figures, which are the number of registers under measurement, the number of rules in force, the registers with problems and the number of open problems.
Under those figures, each register shows its own health. Every rule that applies to it sits in exactly one of four states, passing, warning, failing or not applicable, with the number behind the verdict and the direction it is heading. A rule that is passing is shown, which matters more than it sounds. A register with no visible rules reads as unchecked. A register with twelve passing rules and one failing reads as measured, and the one failure gets attention.
Measurement happens on a schedule, with a timestamp. The page says when the register was last evaluated, so nobody is reading a number computed while they waited and nobody is reading last month's. A refresh re-reads the stored result. The measurement itself runs on load and on a timer.
Rules are written once. A column's meaning and the checks that apply to it are defined in one place and shared between data validation and the rest of the system, so a check added for the tag register does not have to be re-authored for the report that reads the tag register.
Validation Gates EWP Release
The routine earns its keep at the EWP release gate. The CII AWP Data Requirements Implementation Guideline exists because the data an EWP carries is as much a part of the package as the drawings, and a well-written project procedure says the same thing in contractual terms. Compliance with the Data Requirements and the 3D model attributes is demonstrated before each EWP goes IFC, and a package can be rejected on data grounds alone.
In practice that means the EWP checklist carries data items alongside document items. It asks whether the Primary and Secondary MTOs are complete and delivered as data, whether the 3D model attributes match the register, whether the model, the MTO and the engineering lists agree, whether every tag was reserved at least 10 weeks before the planned IFC date, and whether every placeholder was registered 8 weeks before release. An EWP with a signed checklist goes to review. An EWP without one waits.
What the Data Requirements document has to contain for this to work is its own subject. So is model conditioning, which is where the model side of the comparison is made reliable.
Who Owns the Registers and the Checks
The engineering contractor's information manager owns the checks and the resolution of what they find. The owner's information manager owns the standard they are measured against and audits their effectiveness. Each dataset has one accountable owner, named in the procedure.
What this produces over a project is a set of registers that agree with each other, a validation framework that has been running weekly since FEED, and a trend for every rule from the first week to turnover. All of it belongs to the owner, and all of it is reusable on the next project. The framework is described in more detail under information management, and the extracts and warehouse behind it under data integration.
openAWP measures every register against the rules that apply to it, on load and on a timer, and shows passing, warning, failing and not applicable counts with a trend per rule. The registers, the rules and the trends sit on the client's infrastructure and stay with the client when the engagement ends. How we set that up as a service is described under information management services.