This video explains how to create a detailed responsibility matrix for ISO 19650 BIM project delivery. The written guide below covers why clear accountability prevents finger-pointing and delays, how to structure the matrix around use cases and object-based requirements, why ownership transitions between teams must be defined, and how timeline views with dependencies make the matrix practical and actionable across the full project lifecycle.
Why a clear responsibility matrix eliminates confusion and blame
The responsibility matrix is one of the most important tools for avoiding the classic scenario where nobody knows who owns what, teams point fingers at each other, and critical deliverables fall through the gaps. When roles are not clearly defined, people assume somebody else is responsible for key tasks, deadlines are missed, and the project ends up in a blame game that causes unnecessary delays and frustration between teams. A well-structured detailed responsibility matrix solves this by defining specific information management duties, assigning clear accountability for every deliverable, and ensuring seamless collaboration across all project teams so that ISO 19650 requirements are met.
The matrix does more than simply list who is responsible for what. It helps teams understand that different use cases require different approaches. Each information exchange milestone may require different modelling methods, different information requirements, and even different tools, because the stakeholders involved and the decisions being supported are different at each stage. For example, the requirements for quantity takeoff are fundamentally different from those for coordination, field layout, or facility management. These data drops must be clearly recognised as distinct use cases, and the responsibility matrix must reflect who is responsible for delivering the right information at each one.
In BIM projects, requirements are typically object-oriented, focusing on different building components and element groups. These elements should be structured into a classification hierarchy so that component requirements can be established per use case, covering geometrical needs, responsibilities for information delivery, specification and documentation requirements, required information with predefined values, and expectations for level of information need. It is also essential to define ownership transitions. When a concrete slab initially designed by the architect transfers to the structural designer, clear ownership definition at each project stage prevents duplicate elements that could compromise model-based quantification and coordination efforts. Without this clarity, the same element can end up being modelled by two different teams, leading to clashes, double-counted quantities, and wasted effort.
The responsibility matrix must align with the project’s BIM Execution Plan and Master Information Delivery Plan (MIDP). If the BEP specifies who is responsible for model coordination at each stage, that should directly inform the matrix. This integration creates a cohesive plan ensuring consistency across all project workflows. The matrix should also include task-specific deadlines, the tools required for each deliverable, and escalation processes for unresolved issues, making it not just a record of responsibilities but a functional guide that drives project execution efficiently.
How to build a detailed responsibility matrix
- Identify core responsibilities and create a high-level matrix – Start by defining the major responsibility areas for each team — architectural, structural, MEP, project management — and assign the start and end points of each team’s responsibilities across the project phases.
- Define information exchange milestones as distinct use cases – Recognise that each milestone may require different modelling approaches, information requirements, and tools. Structure the matrix to reflect the specific responsibilities at each data drop, from concept through to construction and operations.
- Structure requirements by element and classification – Organise deliverables around building components and element groups using a classification hierarchy. For each use case, specify the geometrical requirements, information delivery responsibilities, documentation needs, and information delivery specifications.
- Define ownership transitions between teams – For elements that transfer from one discipline to another during the project, clearly document when and how ownership changes. This prevents duplicate modelling, conflicting data, and coordination failures at handover points.
- Integrate with the BEP and MIDP – Ensure the responsibility matrix aligns with the information management strategy in the BEP and the delivery schedule in the MIDP, creating a consistent accountability framework across all project documents.
- Add deadlines, tools, and escalation paths – Make the matrix actionable by including task-specific deadlines, the tools required for each deliverable, and clear escalation processes for when issues arise or responsibilities are disputed.
- Visualise in timeline and dependency views – Use the timeline view to define milestones, set dependencies between tasks across disciplines, and view the waterfall of responsibilities in a compact view that shows how all teams’ deliverables interconnect.
- Assign detailed information requirements to elements – Attach specific information requirements directly to each element in the database, ensuring that teams know not just that they are responsible for a deliverable, but exactly what information is needed for each item.
What you’ll learn
- Why responsibility matrices matter – How undefined roles lead to blame, duplicated effort, and missed deliverables, and how a clear matrix creates the accountability framework that every project needs.
- Use cases and milestones as distinct events – Why each information exchange milestone requires different approaches, and how structuring the matrix around use cases ensures the right information is delivered for the right purpose at each stage.
- Object-based requirements and classification – How organising responsibilities around building elements and classification hierarchies makes requirements precise, measurable, and directly connected to what teams actually model and deliver.
- Ownership transitions – Why clearly defining when responsibility for an element transfers from one team to another prevents duplicate modelling, conflicting data, and coordination failures that compromise quantification and quality.
- Integration with BEP and MIDP – How the responsibility matrix connects to the broader project planning framework, ensuring consistency between the information strategy, delivery schedule, and accountability assignments.
- Timeline and dependency visualisation – How viewing responsibilities as a timeline with dependencies helps teams understand the sequencing of work across disciplines and identify where their deliverables intersect with other teams.
Common questions
How is the responsibility matrix different from the MIDP?
The MIDP focuses on what will be delivered and when, coordinating all deliverables into a single schedule with deadlines and dependencies. The responsibility matrix focuses on who is responsible for each deliverable and what specific information they must produce. The MIDP is the delivery schedule; the responsibility matrix is the accountability record. Together, they answer the complete question of what, when, and who.
Why do ownership transitions need to be defined explicitly?
When elements like structural slabs, MEP risers, or facade panels transition from one discipline to another during the project, both teams may assume the other is responsible for maintaining the element in the model. Without explicit ownership definition, this leads to duplicate elements, conflicting geometry, inaccurate quantities, and coordination clashes. Defining the exact point at which ownership transfers — and what information must be handed over at that point — prevents these problems entirely.
How detailed should the responsibility matrix be?
The matrix should be detailed enough to eliminate ambiguity about who owns each deliverable and what they must produce, but not so granular that it becomes unmanageable. A practical approach is to define responsibilities at the element group level using a classification-based structure, then attach specific information requirements to each element. This provides clarity without creating an overwhelming volume of individual assignments.
Can the responsibility matrix be updated during the project?
Yes. The responsibility matrix should be treated as a living document that is updated as the project evolves. New deliverables may be added, team structures may change, and responsibilities may shift between disciplines as the design develops. Regular reviews aligned with project milestones ensure the matrix remains accurate and actionable. Using the quick assign and status tools makes it straightforward to update assignments and track changes over time.
Explore further
- Creating the detailed responsibility matrix – The full expert course lesson covering how to build and manage the matrix in detail.
- Creating a responsibility matrix with IDS and RACI – How to combine classification-based responsibility assignments with information delivery specifications for a more structured approach.
- EIR, PIR, and BEP documents with Plannerly – How the responsibility matrix connects to the broader set of information requirement and delivery documents.
- ISO 19650 concepts and workflows – The full help centre collection covering how each component of ISO 19650 works together in practice.