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.
Before anyone draws, a delivery team has to agree who will produce each piece of information, and by when. I am Dr Sepehr Abrishami. In architectural practice I managed a design team. I keep Reimagining AEC separate from the MSc in building information modelling, or BIM, that I lead at the University of Portsmouth, and this episode is about information delivery planning.
Take a task team, the group of people who carry out one specific task, about to write its delivery plan with a party wall interface detail on its list. It has two ways to write that line, and each costs it something. It can predict the drawings now, give each one an identifier from the project's naming rules, and promise them by number. If the detail later needs more drawings before anyone on site can build from it, every extra sheet sends the team back through change control, the agreed procedure for altering a plan once it is fixed, to add, withdraw or reassign identifiers. Or it can name the information alone, all party wall interface detail, and leave the number of drawings open. Then nothing in the plan changes when one drawing becomes several, but the plan is only as useful as the team's description of what it will deliver. The team has to choose before the design is far enough on to show which cost will be larger.
Both options come from Part F of the UK BIM Framework, the UK guidance on information delivery planning, published in September 2020, and the choice between them sits inside a larger problem. So the question for this episode is how a delivery team settles three things for one piece of information, a door schedule: which task team will produce it, by what date, and how the team's leader would know in time that it was going to be late. Doors are the guidance's own example, and I will follow them from start to finish.
Three parties appear throughout. The appointing party is the client, which receives the information. The lead appointed party, the team's leader in that question, is the organisation the client appoints to lead a delivery team, such as a main contractor or a lead designer. The appointed parties are the organisations it appoints in turn, and the lead appointed party together with its appointed parties makes up the delivery team. The rules they work to come from ISO 19650, the international series of standards for managing information over the life of a built asset using BIM.
By the end, information delivery planning should have a clear place for you within the wider delivery of information, and the two responsibility matrices should no longer blur into the assignment matrix that is often confused with them. A task information delivery plan that meets ISO 19650-2 should be something you can set out yourself, together with what the lead appointed party does with those plans and why they bind. The episode moves in four steps: where planning sits, the responsibility matrices, the task team's own plan, and the master plan that turns all of it into an obligation. Part F is my main source. In May 2025 the UK BIM Framework became the IMI Framework, named after the Information Management Initiative and maintained by nima, formerly the UK BIM Alliance, with the British Standards Institution, and Part F is now among its archived documents. Its method still follows the 2018 editions of ISO 19650-1 and ISO 19650-2 that remain in force.
Start with where planning sits. ISO 19650-1, the part of the series that sets out concepts and principles, describes the delivery of information as four steps in a loop. First, the information requirements state what is wanted. Second, information delivery planning sets out how and when it will be delivered. Third comes the delivery itself, and fourth the approval. When the information is not acceptable, feedback sends the work back to an earlier step. Planning is the second step, and Part F insists that it cannot begin until the requirements are clear, so that every variable can be considered. The episode on information requirements covers that first step. Citing clause ten point one of ISO 19650-1 and clause five point four of ISO 19650-2, the guidance makes planning the responsibility of each lead appointed party and each appointed party, and it calls the delivery plans the most detailed level of planning in the series.
That second step uses four tools, and they run from the broad to the particular. The federation strategy describes how and why the information model is divided into parts. The information container breakdown structure turns that division into manageable units, so that several appointed parties can work at the same time without overwriting each other's information. An information container, defined more fully later, is any named, retrievable set of information, a file being the familiar kind. The responsibility matrices then add who produces what, and when. Last, the delivery plans name each container a team will deliver. Part F left its own section on the first two tools as an empty placeholder in its first edition, so the detail on them comes from the concepts guidance, Guidance Part 1 of the UK BIM Framework, in its second edition of 2019. It says the lead appointed party sets the breakdown structure with its delivery team, while the appointing party may set the federation strategy where it has requirements that run across the whole project. For our doors, the breakdown structure places them under building fabric, next to the windows.
None of this is new, as Part F reminds practitioners. Design teams have long kept a design responsibility matrix, setting down what design information is needed, when and from whom. Sir Michael Latham's 1994 report, Constructing the Team, recommended that the use of coordinated project information should be a contractual requirement. Part F notes that the recommendation entered a Joint Contracts Tribunal form of contract in 1998 as the information release schedule, which named each piece of information, its author and its release dates. What ISO 19650-2 adds is standardisation. It gives the matrix a neutral name, because it covers all information at all stages and not only design, and it fixes when planning starts, who takes part and the minimum content of each plan. Part F's advice is to build on the tools a team already knows, which eases acceptance and reduces disruption. Planning, then, follows the requirements and narrows step by step from the whole model to the single container.
The second step is the responsibility matrices, and there are two of them. ISO 19650-1 defines the responsibility matrix in clause three point one point one and explains it in clause ten point three. As a minimum it has two axes, the information management functions along one and the tasks or deliverables along the other. Any form will do if it satisfies ISO 19650-2, although a table is usual. Clauses five point three point two and five point four point two of ISO 19650-2 give the job of defining it to the lead appointed party, in two stages. The high-level matrix comes first, before appointment, as part of the pre-appointment BIM execution plan, or BEP, the document in which a prospective delivery team sets out how it will manage information. It is then refined into the detailed matrix while the appointment is confirmed. ISO 19650-2 does not list the detailed matrix as an appointment resource, because the high-level matrix and the delivery plans already carry the contractual requirements. The detailed matrix is a working tool that feeds the plans.
Take the high-level matrix first. While preparing its tender response, the prospective lead appointed party filters out the deliverables it expects to provide against the client's exchange information requirements, or EIR, the client's statement of the information it needs from that appointment. This clarifies its scope and avoids overlap with other delivery teams. A main contractor with a contractor's design portion, for example, must make clear where its scope starts and ends. Part F's example of a high-level matrix is deliberately coarse. Its rows come straight from the agreed breakdown structure, first mechanical, electrical and plumbing information, known as MEP, then structural information. Its columns name two task teams, one for MEP and one for steelwork, and these sit on the axis for information management functions. The MEP team takes mechanical and electrical information, and the steelwork team takes structural. The matrix says mechanical information, and leaves air conditioning or gas distribution information for later. It may also allocate management tasks, such as who deploys the common data environment, or CDE, the shared environment in which the project's information is collected, managed and shared, and who manages information for the Construction (Design and Management) Regulations 2015, known as CDM. At this level the doors are only part of building fabric.
The detailed matrix is where Part F says considerable thought must go into allocating tasks and responsibilities. Clause five point four point two asks it to settle three things for each deliverable: what information is to be produced, when it is to be exchanged and with whom, which captures the dependencies between teams, and who, meaning which task team, is responsible for producing it. Part F's door example answers all three. The lead appointed party wants door information, it wants it at stage two, and it gives the work to task team one. How much dependency detail the detailed matrix holds varies with the appointment, but it should stay proportionate and should never duplicate the master plan that comes later. Once drafted, it goes to the task teams to review and to inform their own plans.
Part F accepts that a traditional design responsibility matrix can satisfy clause five point four point two, but argues that it leaves current tools unused, and it offers two improvements, both built on the doors. The first is semantic, meaning that each deliverable takes its name from an agreed industry grouping. Under the Industry Foundation Classes, or IFC, the open data schema published by buildingSMART International and adopted as ISO 16739-1 in 2024, metal doors become the door entity, IfcDoor. A Uniclass 2015 product code would serve the same purpose, although Uniclass codes and titles change between releases, so the current version is the one to check. Shared names link the matrix, the master plan and the models. The second improvement assigns responsibility property by property. In the door example, the fire rating comes from task team one at stage three, and the manufacturer from task team two at stage four. That matters when structured data, rather than documents in portable document format, or PDF, is a key output. Part F attaches a caution to both. Every extra level costs the lead appointed party effort to compile and the task teams effort to review, so the matrix should stay as simple and proportionate as the project allows.
Because these tools sit so close together, Part F names three confusions that cause trouble. The first is a clash of names, since ISO 19650 uses responsibility matrices for two different jobs. The information management assignment matrix, set out in Annex A of ISO 19650-2 as Table A point one, allocates the management activities that the clauses of the standard require. The high-level and detailed matrices allocate delivery team tasks and information deliverables. Part F warns that Table A point one should never stand in for either of them, and the assignment matrix has its own episode, the one on the information management assignment matrix. The second confusion is between the detailed matrix and the master plan, and Part F uses drainage to separate them. Suppose the detailed matrix gives above-ground drainage to a drainage contractor and below-ground drainage to a civil engineer. The drainage contractor now knows its scope, and its plan lists drainage layout plans for the above-ground work only. The master plan then records exactly which drawings, schedules and models each of the two will produce. The third confusion concerns order. The breakdown structure comes first. Annex A of ISO 19650-1 gives example breakdowns that supply the what, and the matrices add the who and the when. So the matrices answer the first part of the question, which team.
The third step asks by when, and that belongs to the task team. Part F traces the whole chain for the doors, starting with the breakdown structure, the agreed grouping of building fabric into windows and doors. That informs the detailed matrix, which asks for door information, at stage two, from task team one. The matrix directly informs the task team, and the task team directly responds. Its response is its task information delivery plan, or TIDP. Alongside the matrix, clause five point four point three has the lead appointed party set out its own exchange information requirements for each appointed party, and the task team plans against both. Task team one turns door information into three information containers, a door location plan drawing, a door schedule and a door specification. It states a date within stage two for each, and confirms that each falls within its scope. Finally, the lead appointed party compiles every TIDP into the master information delivery plan, or MIDP, for the whole delivery team. The matrix sets the what, the when and the who, and the task team decides how.
Clause five point four point four of ISO 19650-2 requires every task team to produce a TIDP for its own information, taking account of the requirements assigned to it, its responsibilities and its timescales. The plan schedules an agreed list of information containers and records six things for each, which fall into two groups. Three say what the container is and who makes it: its name and title, its level of information need, and its author. Three fix it in time: its dependencies on other information, its production duration and its delivery milestones, the agreed points at which information is due. Part F illustrates them with an invented structural engineering task team planning two piling layout plans. Each depends on architectural site information, each is a drawing at a scale of one to one hundred in PDF format with the pile types noted, and each has its delivery milestones. The standard does not mandate a template, and Part F treats the TIDP as a resource rather than a document, so a schedule, a spreadsheet or a programme tool will do. It also recommends agreeing the TIDP with the lead appointed party, for example in a meeting, rather than drafting it alone.
Naming each container causes the most difficulty, because the term information container is often taken to mean a file. Clause three point three point twelve of ISO 19650-1 defines it as a named persistent set of information retrievable from within a file, system or application storage hierarchy. A container can therefore be a folder, a file, or a distinct part of a file, such as a chapter, a layer or a symbol. That definition gives a task team two ways to write its plan. A plan focused on files lists every drawing and predicts each unique identifier from the naming convention in the UK National Annex to ISO 19650-2. This is the first option from the opening. Files are hard to predict at the outset, the plan ends up describing presentation rather than information, and every extra drawing for the party wall detail means another round of change control. Part F expects that to repeat dozens, if not hundreds, of times, and it counts the change control and the upkeep of identifiers together as a significant administrative burden. A plan focused on information, the second option, leaves the number of drawings open, so one file can become six, or six become one, without any change to the plan. Part F calls this approach looser, but says it still acts as a clear guide, provided each container has a clear name and description. It judges that both approaches have advantages and disadvantages, and that both deserve consideration. Either way, the lead appointed party has the same job, which is to make sure it receives the right information at the right time. For the doors, task team one can commit to a door schedule without promising how many sheets it will run to.
The other records need care too. Level of information need defines the scope of each container, so that everyone knows what it will and will not include at each delivery milestone. For the door schedule, task team one might state that fire ratings are included. The method for defining level of information need now sits in ISO 7817-1, published in 2024, which replaced the European standard BS EN 17412-1. It sets the need by considering the purpose, the delivery milestone, the actors involved and the objects within a breakdown structure, and it describes the content as geometrical information, alphanumerical information and documentation. Part F's own fields for form, scale and format predate it. Production durations matter most where there are dependencies or review periods. In Part F's programme for the piling team, the team records when it will receive the architect's site plan and allows five days for review before sharing its first piling layout. The author can be a whole organisation or, where a team holds two distinct disciplines, the named discipline leads. Milestones come both from the EIR and from the task team itself. A milestone can be tied to a status in the common data environment, for example S3, shared for comment, or A4, published at stage four. So the TIDP answers the second part of the question. The door schedule now has an author, a defined content, a duration that allows for what it waits on, and a date.
The fourth step belongs to the lead appointed party, and it answers the last part of the question, how anyone would know in time that the door schedule was going to be late. Clause five point four point five of ISO 19650-2 tells the lead appointed party to aggregate its appointed parties' TIDPs into the delivery team's MIDP. In doing so it weighs the responsibilities in the detailed matrix, the dependencies between task teams, and the review periods that both the client and the lead appointed party itself will need. Three actions then follow. The first is to baseline the deliverables and dates, so that progress can be measured against them, and to share that baseline so that the whole delivery team agrees it. The second is feedback. Projects rarely stand still, so whenever the scope changes, the TIDPs are reviewed together and the MIDP updated to match. The third is risk. Any risk to a delivery milestone goes into the risk register that the lead appointed party must set up under clause five point three point six, and the client is told of it. Part F's examples include an unrealistic deadline, and a milestone that cannot be met without reference information from the client.
Part F then recommends one step that the standard does not state, which is to check the MIDP against the EIR and record anything unresolved as a risk. No template is mandated here either, and where a client has a template of its own, it becomes a shared resource. The door schedule now sits in the MIDP with the client's review period built in, measured against a baseline and linked to a risk register.
One last move turns these plans into obligations, and each tool ends with a different contractual status. The high-level matrix travels into the appointment as part of the BEP. The detailed matrix, as I said earlier, stays a working tool. Clause five point four point six requires the MIDP to be included in the lead appointed party's appointment, and clause five point four point seven requires the relevant TIDPs to be included in each appointed party's appointment. Part F states the consequence plainly. Both create a contractual obligation to deliver the required information, and any update after appointment follows the agreed change control procedure. For the doors, task team one is now bound to deliver its door schedule to the lead appointed party, and through the MIDP the lead appointed party is bound to the client. Whatever a TIDP lists, the appointment holds, which is why the choice between files and information carries weight.
Drawing this together, the question was which task team delivers the door schedule, by what date, and how its late arrival would be seen in time. The responsibility matrices name the team, first as broad scope at tender and then in detail. The TIDP fixes the date, together with everything the container must hold and wait on. The MIDP, baselined and tied to the risk register, lets the lead appointed party see a late delivery coming and tell the client, and because both plans sit inside the appointments, any change runs through change control.
Three habits follow for anyone who writes or receives these plans. Choose deliberately how a plan lists its containers, knowing that predicted files multiply change control and that a looser plan needs descriptions precise enough to carry the commitment. Keep each matrix to its own task, with the assignment matrix for the standard's management activities, the responsibility matrices for deliverables, and neither of them a copy of the master plan. Treat the risk register as part of the plan, so that a milestone in doubt is reported when the doubt first appears.
For reading, take Part F alongside clauses five point four point two to five point four point five of ISO 19650-2. Revised drafts of ISO 19650 Parts 1 and 2 went out for UK public comment between March and May 2026, as nima reported that March, so check the clause numbers when new editions appear. The episodes on information requirements, on tendering and appointments and on the common data environment each take one of the links in this chain further.
I am Dr Sepehr Abrishami, once the manager of a design team, and each date in a delivery plan binds the teams downstream as well as its author. On Reimagining AEC I ask you to test that on the next plan you write or receive, at work or in research.