A request for an ISO 19650 project does not tell a designer or contractor which information to produce. Clients need to link business decisions to deliverables, responsibilities, and acceptance tests, while bidders can still price the work
A client asks for BIM, a detailed model and a complete digital handover. Each bidder can agree with those ambitions while assuming a different amount of work. One prices coordinated design information; another allows for structured asset records; a third assumes the contractor will populate missing fields later. The apparent agreement conceals a procurement gap.
That gap becomes expensive when information is needed for an immediate decision. A cost adviser cannot compare options because quantities have different boundaries. A maintenance team receives equipment names without accessible service documentation. Producing the missing information remains possible, but responsibility, programme and payment may now have to be renegotiated.
The starting point is therefore the client’s decision. Which option can be funded? Which design can be accepted? Which assets will require planned maintenance? Describing those decisions gives information production a purpose before the project commits to a software platform or a visually elaborate model.
A standard provides a framework, not a project brief
ISO 19650-1 sets out concepts and principles for information management using building information modelling. Its scope concerns managing information across a built asset’s life cycle. By its title alone, it does not define the information a particular hospital, office refurbishment, or drainage project requires.
The IMI Framework’s frequently asked questions make the procurement consequence explicit: information management and modelling requirements should be specified for individual appointments rather than relying on a general reference to the framework. The guidance also distinguishes an information management function from an assumption that every project requires a new job title.
For a client, this means naming who will make and maintain the requirements, who can approve changes, and who will assess the delivered information. Outsourcing those activities can be sensible. Leaving them unallocated simply moves the uncertainty into the tender and, eventually, into delivery. A standard becomes useful when those responsibilities are made workable.
Translate a decision into an answerable request
Consider an illustrative requirement to compare two ventilation strategies before design approval. A model alone is not the answer. The decision may need spatial allowances, energy assumptions, access requirements and a cost comparison, each at an appropriate level of confidence. The requirement should explain the purpose, the needed information and the point at which the comparison must be available.
Timing matters because information develops. Requiring a manufacturer’s serial number before equipment has been selected would create an impossible early deliverable. Accepting a generic equipment description at final handover may leave the operator unable to identify the installed item. The field is meaningful only when linked to its stage and intended use.
The same approach limits unnecessary production. If a client needs to identify and locate maintainable assets, that does not mean every fixing requires a separately managed object. More detail increases authoring, checking and maintenance work. The worthwhile level is the information sufficient for the identified purpose, with any uncertainty visible to the person relying on it.
Make the tender capable of being priced
The UK BIM Framework’s guidance on tendering and appointments discusses the information standard and the information production methods and procedures that support the appointment process. Practically, bidders need a defined basis for their delivery proposals. General ambition is difficult to compare on price.
A useful tender package identifies the required exchanges, formats, milestones and review arrangements. It should explain whether existing records are reliable enough to use, which surveys remain necessary, and what information the client will supply. Otherwise, a bidder has to price uncertainty, make assumptions, or leave a gap that may surface as a variation.
Assessment should examine how the proposed team will deliver the requirement. A sample exchange, explanation of checking arrangements and evidence of available capacity can reveal more than a polished presentation. A firm may have excellent software and experienced individuals, but insufficient time allocated to the commission. Capability and capacity answer different procurement questions.
Connect responsibility across the supply chain
Many required records originate beyond the organisation holding the main appointment. Product information may come from a manufacturer, installation evidence from a specialist and commissioning results from another team. The client-facing deliverable depends on requesting those contributions at the right time and in a form that can be combined.
A responsibility schedule should distinguish producing information, coordinating it, checking it and accepting it for a purpose. Treating all four as a single obligation can leave a coordinator apparently responsible for facts only the installer can verify. Similarly, passing supplier information through without an agreed check can leave the client with inconsistent or incomplete records.
The handoffs deserve as much attention as the final submission. A specialist arriving late in procurement may inherit naming rules or data demands that its ordinary product records cannot meet. Early engagement allows the project to identify a workable conversion process and its cost. It can also expose a requirement that should be simplified before every downstream business has to accommodate it.
Acceptance needs evidence beyond file delivery
An uploaded file proves that something was submitted. It does not prove that the content answers the requirement. A client could receive every scheduled file and still be unable to compare options, trace an asset, or establish which design was authorised for use. Acceptance needs to address the information’s function, not just its existence.
A test can be modest and concrete. Can the intended user locate a specified asset, retrieve its required properties and connect it to the appropriate document? Can a reviewer identify the revision and suitability of a drawing without guessing from its filename? Can a cost adviser reproduce the basis of a quantity rather than trust an unexplained number?
Automated validation can check some properties, allowed values and completeness. It cannot determine every engineering judgement. A populated fire-performance field, for example, shows a value exists; it does not establish that the specified product is suitable for the application or installed correctly. The acceptance process must preserve that distinction.
Information obligations also change
A project may change its operating strategy, procurement route or technical solution after appointment. Its information requirements may need to change with it. The commercial record should show what changed, why it is needed, who is affected and whether additional time or payment is involved. Otherwise, a reasonable client request can become an unpriced accumulation of work.
Removing requirements casually carries a related risk. Dropping a survey or a data field can reduce the immediate fee while creating uncertainty for another decision. Reviewing the purpose behind the original requirement makes the trade-off visible. The right answer may be to remove it, defer it or obtain the evidence through a less costly method.
The Construction Playbook sets out government expectations for assessing, procuring and delivering public works, including early engagement and a focus on outcomes. Its stated application is to central government departments and their arm’s-length bodies on a comply-or-explain basis; it should not be described as a universal statutory BIM requirement for every UK project.
Procure the ability to use the result
The client also needs resources on its side of the exchange. Someone must attend reviews, resolve conflicting demands and assess submissions within the promised time. An excellent delivery team cannot compensate indefinitely for a client that has not decided which department owns the requirement or who is authorised to accept the result.
For repeat clients, a standard template can preserve lessons and reduce tendering effort, but each requirement still needs a project-specific purpose. The strongest template clarifies decisions and responsibilities. It helps suppliers price a defined service and gives the client a reliable basis to confirm the required information has been delivered.
