BIM information requirements: a client briefing guide
Admin · 22 October 2026
Illustrative image. Photo by Marina Zvada on Unsplash. Unsplash License.
A client can ask for a detailed digital model and still receive information that does not answer the questions the organisation needs to resolve. More geometry or more data is not automatically more useful. Information requirements should begin with the decisions and activities the client intends to support, then explain what must be provided, when it is needed and how it will be assessed.
For project sponsors and asset owners, the briefing task is to connect organisational needs with a workable delivery arrangement. The appointed information management specialists can help translate those needs into the appropriate technical and contractual documents. The client’s contribution is essential because only the organisation can explain which decisions matter and what information its teams can realistically use.
Start with a specific use
Identify the activities the information should support. These may concern project decisions, coordination or operation of the completed asset. Avoid beginning with a software format or a broad statement that the project must use BIM. A format describes part of the exchange; it does not establish the purpose or content. Ask the receiving team what it needs to do and what evidence would help.
Break broad aspirations into questions. If the client wants better maintenance information, identify which assets or tasks are relevant, who will use the records and how they will access them. If the information supports a design decision, state the decision and its timing. This creates a basis for selecting useful requirements rather than requesting every available field in the hope that something proves valuable.
Identify the receiving people and systems
Bring the people who will receive and maintain the information into the briefing process. Their workflow may differ from the project team’s assumptions. A facilities system may need particular identifiers or an agreed structure, while a project reviewer may need a clear report alongside digital files. The requirements should reflect actual receiving arrangements and identify decisions still needed about them.
Confirm what the organisation can support after handover. Requesting complex information without a plan for ownership and updates can create an expensive archive that soon loses relevance. Identify who maintains the record, what resources are available and how changes will be controlled. Where the future system is not selected, record the uncertainty and seek specialist advice on a proportionate interim exchange approach.
Define content and acceptance together
For each requirement, explain the information needed and the evidence that will demonstrate an acceptable response. The appropriate specialists should establish the detailed structure and checks. The client should understand the relationship between the requested content and its intended use. A list of properties without that connection can impose effort while leaving the receiving team unclear about what it can rely on.
The UK BIM Framework’s Guidance Part D on developing information requirements, Edition 2 published in February 2021, provides background on defining requirements precisely. The project should confirm the current applicable standards and appointment documents through its specialists. A generic reference to a framework alone is not a complete information brief.
Set delivery dates around decisions
Information should arrive early enough to be reviewed and used. Link delivery dates to the decisions or operational milestones they support, allowing for the agreed checks and responses. A file issued on the day a client must approve a major commitment may be too late for a meaningful review. Explain the dependency so that contributors understand why the date matters.
Distinguish staged information needs. Early options work may require a different level of detail from procurement or final asset handover. Ask what is proportionate at each point rather than demanding final completeness throughout. This helps the team plan effort and makes it easier to identify when an information gap genuinely prevents the next decision.
Clarify responsibilities across appointments
Identify who will produce, coordinate, check and accept the relevant information under the project’s arrangements. The same organisation may not perform every role. Ensure the allocation is consistent with appointments and package scopes, with appropriate commercial review. A requirements document cannot safely be used to assume responsibility that the actual agreement leaves unclear.
Consider information assembled from several contributors. Someone needs to define the integration process and resolve inconsistent identifiers or structures. A final handover requirement can fail if every supplier provides a complete-looking record in a different form. Plan the consolidation and checking work, including the inputs and authority needed by the person responsible for it.
Test an exchange before scaling it
Use a representative sample to test the proposed information exchange where appropriate. Define what the test must establish, such as whether required fields can be read or whether the receiving team can perform the intended task. Include real users of the destination workflow. A successful file transfer does not necessarily show that the content is complete or usable.
A hypothetical asset owner may request equipment records for import into a maintenance system. Testing a small, representative set can reveal naming or data issues while contributors still have time to adjust. The test should not be presented as acceptance of every future record. Its purpose is to validate the process and improve the requirements before the full information volume arrives.
Control changes to the requirement
Business needs can evolve, but new information requests have consequences for effort, timing and existing work. Record the reason for a change and obtain the relevant assessment before approval through the project’s procedures. Distinguish correction of an unclear requirement from an additional request. The actual documents and appointments should inform that discussion rather than the label used in a meeting.
Communicate approved changes to all affected contributors and update the controlled requirements. Identify whether information already supplied needs revision. Avoid allowing different teams to work from separate email requests that gradually diverge. The client needs a single understandable position on what it expects and which version of the requirement applies.
Review delivery through usable evidence
Track information readiness against the planned uses, rather than report only the number of files received. Identify missing content, failed checks and unresolved questions with owners and dates. The relevant reviewers should distinguish technical content assessment from administrative receipt. A dashboard marked complete because a file exists can conceal a serious gap in the receiving team’s ability to use it.
Where an information requirement cannot be met as planned, explain the consequence and available response. The client may need further work, a revised arrangement or an explicit decision about the limitation. Do not quietly remove a requirement from the register to improve completion figures. Preserve the decision and its effect on the intended use.
Close with ownership and continuity
At handover, confirm access, formats and responsibility for the accepted information. Retain the checks and limitations alongside the delivered records. The organisation should understand what has been verified and what remains conditional. Information that is technically delivered but inaccessible to its intended users does not meet the practical purpose of the brief.
After the first period of use, ask whether the requirements produced information that helped the client’s actual work. Record unnecessary requests as well as omissions. That feedback improves the next brief and helps the organisation request information with a clear purpose, a realistic delivery route and an accountable owner throughout its useful life.
Keep the original use case visible when discussing additions to the information request. Ask which decision the extra content will support and who will maintain it. This helps the client distinguish a useful improvement from a request made simply because the software can hold another field or produce another export.
