A standard needs a project application
AEC Magazine’s historical article on BIM standards discusses defining deliverables and shared information practices. The useful contemporary question is how a team converts its own requirements into a workable package brief. This article offers an original hypothetical matrix for a precast coordination package. It does not interpret a contract or claim that one matrix satisfies a particular standard. Project requirements and engineering responsibilities still govern the work.
Name the receiving use
Write the intended use beside each deliverable: coordination, quantity review, design communication or another agreed purpose. Avoid describing a package only as a model at a certain stage. The receiver needs to know what decisions the information can support. If fabrication information is outside the author’s scope, state that boundary clearly. A detailed-looking connection object should not imply that fabrication design has been completed or accepted.
Define the information at object level
For a hypothetical precast panel, the coordination package might require an identifier, location, nominal geometry and agreed interface zones. Other information may remain provisional or belong to a specialist’s later deliverable. List required properties and define their units and permitted states. Link each requirement to a reason. A parameter added without a receiving use creates maintenance work and can distract from a smaller set of critical, reliable information.
Read diagram notes
- Receiving use
- The decision the package supports
- Information producer
- Named role and required fields
- Acceptance evidence
- Check, reviewer and record
Assign authoring and acceptance roles separately
Record who provides each piece of information and who accepts it for the stated use. Include interfaces with the structural designer, specialist contractor and coordinating team as applicable. The BIM manager can manage the information process without becoming the designer of every component. Where responsibilities are not agreed, identify the open question before modelling proceeds. Ambiguity becomes more expensive when it is embedded in many objects and assumed to be settled.
Describe the evidence of completion
For each deliverable, specify the checks and evidence the receiver will examine. Examples include a reconciled object schedule, agreed coordinate check and a list of unresolved interface questions. Distinguish required evidence from a general claim that the model has been checked. A sample acceptance row should name the check, expected outcome, responsible reviewer and where the result will be stored. Keep the evidence proportionate to the package’s purpose.
Manage change at the package boundary
Identify what happens when the scope, receiving use or required information changes. Record the affected deliverables and the decision authorising the change. Do not silently expand the model’s intended use after issue. A package suitable for coordination may require additional work before another team can rely on it for a different task. Revisit the matrix at agreed milestones and preserve the version associated with each issued package.
Use the matrix in everyday reviews
Keep the matrix short enough to discuss in a coordination meeting. Test it against a small sample package and remove ambiguous wording. The final result should help an author know what to produce, a reviewer know what to check and a receiver know what can be relied upon. That clarity is a practical foundation for consistent structural BIM delivery.