Subscribe
Share
Share
Embed
Reimagining AEC is Dr Sepehr Abrishami's independent podcast on how the built environment handles information. Each episode takes one subject from digital construction, from the ISO 19650 series and the common data environment to the golden thread, soft landings and the arrival of artificial intelligence in design and surveying practice, and tells it as a single argument built on the published standards, guidance and evidence. Sepehr is a researcher and former architect who leads the Centre for AI in Construction and teaches building information modelling at master's level. The episodes are written for postgraduate students and practitioners who want the reasoning behind the rules, not a summary of them.
A clause in a client's appointment can sound precise and still ask for nothing anyone can check. I am Dr Sepehr Abrishami, and from 2003 to 2009 I practised as an architect. On Reimagining AEC I take the question every client faces before a single drawing exists, which is what exactly it should ask for when it wants the information on its project managed well. The answer comes from the ISO 19650 series of international standards and the UK guidance written to explain them.
Start with the kind of sentence the UK guidance warns against. The project shall be delivered using building information modelling, or BIM, in accordance with ISO 19650. The wording is mine, but the verdict on it comes from the UK concepts guidance, published in 2019 by the UK BIM Alliance, the Centre for Digital Built Britain and the British Standards Institution, BSI. The guidance says that a client who asks only for this will not meet the requirements of the standard and will not get its benefits. There is no legal definition of BIM according to the ISO 19650 series. A consultant who signs up to that sentence has agreed to something nobody can measure, and a client who wrote it has asked for something it cannot check.
So the client has a decision to make, and the obvious answer, asking for more BIM, is the wrong one. By the end of this episode you will be able to tell that client what to write instead. That means setting out what it should require at every step, from its first statement of information needs, through the people and the process that deliver against them, to a single document that carries a name and a description anyone can read.
We will take this in five parts: why information management matters and where the standard came from, who the parties are and which requirements they set, how information is planned, delivered and approved, how it is produced and organised once many teams are at work, and how contracts, security and the UK National Annex make it binding and give it a name. To keep all of this concrete, I will follow one document from start to finish. It is a structural steel specification on a multi-storey building, taken from the worked example in the UK guidance. The project is called N E W P, and the structural engineer who writes the specification is called ABC. Where I extend that example beyond what the guidance says, I will tell you that the detail is mine.
Begin with the case for information management, because clients and supply chains invest in it only when they believe the return is real. The UK path started with a hypothesis put forward by the BIM Working Group in its 2011 strategy paper. In its words, government as a client can derive significant improvements in cost, value and carbon performance through the use of open sharable asset information. The government accepted that hypothesis and published it as the BIM mandate in the 2011 Government Construction Strategy. Notice the three measures it names, cost, value and carbon, and notice that the benefit comes from asset information that the owner can share and use, and not from three-dimensional geometry on its own. Since 2011, central government departments across the four home nations and a number of private clients have tested that premise. The guidance reports that these early adopter projects showed the value of information that is purpose-driven, structured, verified and validated, and exchanged in a collaborative and secure environment. Keep the phrase open sharable asset information in mind. It comes back at the end of this episode, when our steel specification receives a name and a description that anyone can find and trust.
The standards followed the policy. BS 1192, published in 2007, defined the collaborative production of information and the first version of the common data environment. The 2011 strategy framed adoption in levels of BIM maturity, often drawn as the Bew Richards maturity wedge, and Publicly Available Specification 1192-2, known as PAS 1192-2, followed in 2013 as the specification for the delivery phase. Treat the wedge and the whole 1192 suite as history. ISO 19650 Parts 1 and 2 were published in 2018 and took effect in the UK in January 2019, replacing BS 1192 and PAS 1192-2. Parts 3, 4, 5 and 6 followed between 2020 and 2025, and the UK National Annex to Part 2 was revised in 2021. The UK BIM Framework, launched in 2019 to gather the guidance, has since been renamed the IMI Framework, after the Information Management Initiative, and nima, formerly the UK BIM Alliance, oversees it with the support of BSI. Revised drafts of Parts 1 and 2 went out for public comment in spring 2026, as nima reported that March. A new edition is coming, but the 2018 editions remain the ones in force.
The guidance describes four features of a successful outcome, and they rest on two principles. The first principle is that the client defines what it needs. It states the information it requires, together with the standards, methods, deadlines and protocols that govern how that information is produced and reviewed, and it asks for enough and no more. Too much information is wasted effort by the supply chain. Too little means the owner takes decisions without the facts. Hold on to that idea of just enough, because it returns later under a formal name, the level of information need. The second principle is that information must move and be used when it matters. Transfer has to be efficient above all at the joint between project delivery and asset operation, where information has so often been lost, and the payoff is informed and timely decisions, with less waste, less rework and lower risk. None of this appears because someone writes BIM into a contract. Each feature depends on every party, the client included, doing its part.
The last piece of context is where information management sits among the other management systems an organisation already runs. ISO 19650-1 draws this as a set of nested frames, and you can hold it in mind as four layers, read from the outside in. The outermost layer is organisational management, with quality management under ISO 9001 as the standard's example. Inside that sit asset management and project management, with ISO 55000 and ISO 21500 as examples. Inside those sits information management under ISO 19650, which tells you that it serves the other two and does not replace them. At the centre is the life cycle of the asset, and it runs as a loop with three movements. At the start of delivery, relevant information passes from the asset information model, or AIM, which the owner keeps during operation, into the project information model, or PIM. During delivery, the PIM grows as the design intent model develops into the virtual construction model. At the end of delivery, relevant information passes back from the PIM into the AIM. One clarification the guidance makes is worth keeping. Certification to ISO 9001, or to any other management system standard, is not a prerequisite for ISO 19650, although the discipline of quality management helps. With the context set, we can meet the people.
The second part is about who does what. ISO 19650 avoids familiar contract words such as employer and contractor, and defines parties by what they do with information. The appointing party leads the project or the management of the asset, and is usually the client. The lead appointed party is accountable for coordinating information exchange, both among its own task teams and between its delivery team and the appointing party. An appointed party is anyone who generates information, whether a consultant, a contractor, a subcontractor or a supplier. The teams nest inside one another in the same way. The project team is everyone involved, whatever the contract arrangement. A delivery team is one lead appointed party with its task teams, for example a contractor with its subcontractors. A task team does one specific job, such as the architecture or the curtain walling design. A project can have several lead appointed parties, each with its own delivery team, and an inexperienced appointing party may seek help from a prospective lead appointed party or from an independent third party. In our example, ABC, the structural engineer, is an appointed party. As my own illustration, I will place it in a design delivery team.
Those parties set and meet a hierarchy of information requirements, and ISO 19650-1 lays it out as two rows, one for the organisation and its assets and one for the project. Each row reads in the same order: whose need it is, what the appointment must deliver to meet it, and which information model results. Start with the organisation. Organisational information requirements, the OIR, capture what the organisation needs for its own objectives. They feed the asset information requirements, the AIR, which set out what is needed to operate and maintain the asset, and the AIR specify the asset information model, the AIM. Now the project. The OIR also feed the project information requirements, the PIR, which set out what is needed to deliver the project. The PIR feed the exchange information requirements, the EIR, which are set for each appointment and say what that appointment delivers and when. The AIR contribute to the EIR as well, so that asset needs reach the people producing information during delivery. The EIR specify the project information model, the PIM, and at the end of delivery the PIM contributes to the AIM. Those links give three paths. A project with no asset management interest runs from PIR to EIR to PIM. Asset management with no project runs from OIR to AIR to AIM. The combined case uses both. For our steel specification, the EIR is the document in which the client says what the specification must contain and when it is due. With the requirements set, we turn to delivery.
The third part is the process. Beneath every appointment runs a simple loop, which ISO 19650-1 gives in four steps with plain labels. State what you want, which means the appointing party sets the information requirements. Plan how and when to deliver it, which means the delivery teams plan who produces what, by when. Deliver it, which means the teams produce the information and share it for coordination. Approve it, which means the information is reviewed against the requirements. If it passes, it is accepted. If it fails, a feedback loop sends it back, and where it goes depends on where the fault lies. It may go back to delivery, or to planning, or even to the requirements themselves. That last route matters. A rejected deliverable can mean that the requirement was unclear, which is why the guidance puts so much weight on getting requirements right at the start. In our example, the client states its need, ABC plans and produces the specification, and approval checks it against what was asked.
The guidance then turns that loop into a sequence across a single appointment. It begins with the appointing party's statement of need, which defines the information requirements, the benefits the client expects, and how information will be structured and exchanged. Each prospective lead appointed party responds at tender with a pre-appointment BIM execution plan, or BEP, which shows its capability and capacity. At appointment and mobilisation, the parties agree roles and the information delivery plan, which takes the form of the BEP, the master information delivery plan, or MIDP, and the task information delivery plans, or TIDPs. The parties then fix the level of information need, the approval procedures and the supporting systems. Finally, at the end of every stage, the team gives assurance that the requirements are met, and at completion the asset information passes into operation. On UK building projects, those stage ends can be aligned with the Royal Institute of British Architects Plan of Work 2020. The standard is also scalable. Where ISO 19650-2 says shall consider, the items it lists apply only so far as they are relevant, and good practice is to record that each one was considered. The eight activities through which ISO 19650-2 formalises this sequence have their own treatment in the episode on parties, teams and processes in the delivery phase.
That leaves responsibility. ISO 19650 settles who is responsible for what with two matrices, and the easiest way to keep them apart is by the question each one asks. The first asks who carries out each information management activity, such as establishing the project's information standard or its common data environment. ISO 19650-2 gives an indicative template for it in Annex A. The appointing party, or someone acting for it, uses it first, and each lead appointed party then organises its own information management function. The second matrix asks who delivers each piece of information, and at which exchange. It starts at a high level in the tender and becomes a detailed responsibility matrix at appointment, as the lead appointed party confirms what each appointed party will deliver. The standard gives no template for this one. In our example, the detailed matrix is where the steel specification is assigned to ABC and tied to an exchange. Alongside both, ISO 19650-1 expects an information risk assessment within the project's overall risk management, addressed while the pre-appointment BEP is prepared. The UK version of the activities matrix is the subject of the episode on the information management assignment matrix. With roles and responsibilities settled, the process has an owner at every step.
The fourth part moves from planning to production, where information is created by many hands at once. The guidance observes that construction information builds on the work of others and should not be created in isolation. So information is shared regularly within each stage, and other teams use it as a reference for coordination, both spatially and in terms of performance. Three layers of review protect each exchange, and they follow the information upward. The task team checks and reviews its own information before sharing it. The lead appointed party reviews the combined information across its delivery team, for example for spatial coordination, and authorises it. The appointing party then reviews the delivered model and accepts it, or rejects it for amendment. That final acceptance compares what was delivered with what was asked for, which narrows the performance gap and supports a soft landing at handover, the subject of the episode on Government Soft Landings. In our example, and this is my illustration, ABC checks its specification first, the lead appointed party checks it against the architecture and the frame, and only then does the client see it.
All of this sharing happens in the common data environment, or CDE, so it pays to be precise about what one is. ISO 19650-1 separates the CDE workflow, which is the process, from the CDE solution, which is the technology. The guidance calls it a common misconception that a CDE is only software, and always a single product. A range of technologies may be needed, and the workflow matters most. Information moves through four states. It starts in work in progress, where a task team develops it within its own area. Once it passes its checks, it moves to shared, where other teams can use it for coordination. Once it has been authorised and accepted, it is published for its intended use. Throughout, the archive keeps a record of what was shared and published, and when. Our steel specification passes through these states, carrying a status code from the UK National Annex in each, and we will read one of those codes shortly. The episode on the common data environment takes the workflow further.
The unit the CDE manages is the information container. In everyday terms a container is often a file, such as a drawing, a model, a programme or a cost plan, although it can also be a set of information held within a system. An information model is a collection of containers, however they were created. Model is meant in the abstract sense, so a schedule belongs to the model as much as the geometry does, and information models exist at asset, project and delivery team level. A project produces a great many containers, and two planning tools organise them. The information container breakdown structure divides the work into manageable units, so that several appointed parties can create information at the same time without overwriting each other. The lead appointed party sets it with its delivery team. The federation strategy is the higher-level explanation of how and why the model is divided and recombined, for purposes such as security, spatial coordination or transmission. The appointing party sets it where it has project-wide needs, and otherwise the lead appointed party does. Both apply to every type of container, and both may evolve as the project develops.
Each container also has a defined level of information need, and this is where the idea of just enough returns. Every piece of information serves a purpose, to perform a task or to support a decision. The level of information need defines how rich each deliverable must be for that purpose at each exchange. Too little increases risk, and too much is waste. ISO 19650-1 introduced the concept, and the method for defining it now sits in ISO 7817-1 of 2024, which replaced the European standard BS EN 17412-1. The 2019 guidance pointed to earlier definitions of level of detail and level of information. Treat those, like the older UK term level of definition, as history. Under the current framework you describe each need across three kinds of information: geometry, meaning shape, size and location, alphanumerical information, meaning properties and values, and documentation, such as certificates. Each is asked for only where the purpose calls for it. The appointing party sets the method in its information standard and applies it in each set of exchange information requirements, the EIR. The level is identified for each container, and the task information delivery plan, the TIDP, records its delivery. For our steel specification, and this detail is mine, documentation and alphanumerical information dominate, and geometry may not be needed at all.
With so many containers in play, people need a consistent way to find them, and classification provides it. The guidance uses the Dewey Decimal Classification as an analogy. Libraries label books by subject so that readers can search and sort them, and digital classification does the same through metadata, so that software can search, filter and sort. ISO 19650-1 recommends classification in line with ISO 12006-2, the international framework, and in the UK that framework is applied through Uniclass, published by NBS. Uniclass can be mapped to other coded lists, such as the New Rules of Measurement from the Royal Institution of Chartered Surveyors, or the SFG20 maintenance schedules. The guidance notes that ISO 19650-2 requires each container to be classified through a metadata attribute, so that the CDE can index and retrieve it. Metadata needs agreement too. A project should decide in advance where each item of metadata sits, whether on an element, on the container or in a linked database, what each attribute is called, and how its value is formatted. Production now has its rules. What remains is to make them binding and to put a name on our specification.
The fifth part covers the ground rules that hold everything together, and the guidance flags four of them. The first two concern the contract itself. Information management works only when it is written into appointments, so the vocabulary has to be mapped. Employer becomes appointing party, and employer's information requirements become exchange information requirements. A glossary or mapping table keeps the contract clear. The appointing party must also establish an information protocol and include it in every appointment, and lead appointed parties carry it into every sub-appointment. In 2019 a template was still being drafted. Today the UK BIM Framework, now the IMI Framework, publishes one for ISO 19650-2, developed with the Construction Industry Council, and the episode on information protocols covers it in full. The other two concern protecting the information. For security, the guidance relied on PAS 1192-5 until an ISO part appeared, and that part is now ISO 19650-5 of 2020, which asks for proportionate measures to protect people, assets and information. For access, the guidance cites Trant Engineering against Mott MacDonald, a 2017 case. The consultant hosting the CDE blocked its client's access to the design data during a payment dispute, and the court granted an injunction that restored access. The lesson for any appointment is to agree who hosts, owns and can access the information, during the project and after it.
This is also where the client from the opening gets its answer. Recall that the ISO 19650 series gives BIM no legal definition, which is why the guidance calls a bare requirement for it insufficient for a tender or an appointment. The appointing party must state instead the duties, rights and deliverables it expects, and everything we have covered so far is the content of that statement.
The last step is the name. The UK National Annex adds national detail to ISO 19650-2, and the guidance lists four areas it clarifies: the project's information requirements, its information standard, its information production methods and procedures, and its common data environment. The annex's most visible rule is the unique ID, which keeps the convention first set out in BS 1192. Here is the unique ID of our steel specification, field by field. N E W P is the project, and the annex says the project code should differ from any organisation's internal job number. A B C is the originator, the engineer that produced it. X X says the container belongs to no particular system, and Z Z says it covers all levels. S P marks it as a specification, S as structural, and zero zero zero one as the first in its sequence. Put together, it reads N E W P, A B C, X X, Z Z, S P, S, zero zero zero one. The guidance suggests reading it back to front: the first structural specification, for all levels, from ABC, on N E W P. A note on currency. The 2021 edition of the annex renamed several fields, so volume or system became functional breakdown, level or location became spatial breakdown, type became form, and role became discipline. Notice also what the ID does not say. It does not say steel frame. That job falls to classification metadata.
The unique ID identifies the container, and metadata describes its condition. The National Annex requires the CDE to record a status, a revision and a classification against every container, and the guidance adds that the CDE should prompt for them whenever a container is added or revised. For our specification, the status is S two, which means suitable for information, one of the shared status codes. The revision is P zero one, the first preliminary revision. The classification is P M thirty-five twenty eighty, the Uniclass code the guidance gives for structural design performance requirements. Together, the ID and the metadata keep written descriptions to a minimum. That helps consistency across large numbers of containers, and it supports a security-minded approach, because the name alone reveals little. The guidance also gives a warning. Suppose ABC files the same document in its own office as Steel frame eight zero zero one, inside a folder called Specifications. Nothing then links that file to the container in the CDE. The remedy is to use the same unique ID and metadata in back-office systems. This is the point at which open sharable asset information, the phrase from the 2011 hypothesis, becomes practical. The annex also lists open exchange formats, such as Industry Foundation Classes, or IFC, and the portable document format, PDF.
That brings us to the close. The question was what a client should ask for when it wants the information on its project managed well. The answer is that it should never ask for BIM on its own. It should set out its organisational, asset, project and exchange information requirements, and appoint parties who know their roles and who plan, produce, review and approve information through a defined cycle. It should require a common data environment as a workflow of states, and ask for just enough information, defined by the level of information need, then classified, named and described with metadata. And it should cite the current standards, ISO 19650-1 and ISO 19650-2 of 2018, the 2021 UK National Annex and ISO 7817-1 of 2024, with the 1192 suite kept as history. Our steel specification has gone the whole way, from a line in an EIR to a named and coded container.
Three things are worth taking into your own work. Requirements come before process, and process comes before software, so any review of a project's information management should start with its OIR, AIR, PIR and EIR. A CDE is judged by its workflow and its states, and a software product on its own proves nothing. And a container you cannot find or trust is of no use, so the unique ID and the metadata matter as much as the content. For reading, start with ISO 19650-1, then ISO 19650-2 with its 2021 UK National Annex, and then the 2019 concepts guidance. The episodes on information requirements, on the common data environment and on information protocols each take one part of this framework further.
The hope behind this episode of Reimagining AEC is mine, Dr Sepehr Abrishami's, and it is that the next appointment you read, in practice or in research, reads to you as a client's statement of need, clause by clause.