Structural Modeling Best Practices: Common Mistakes That Compound Through a Project
November 7, 2026
No Comments
Most ISO 19650 discussions on UAE projects focus heavily on the Common Data Environment and the BIM Execution Plan, and genuinely useful as those conversations are, they often skip past a document that sits underneath both and quietly determines whether a project’s information actually arrives when it’s needed: the Information Delivery Plan. Get this right, and task teams know exactly what to produce and when. Get it wrong, or skip it entirely, and you end up with the familiar late-project scramble where nobody can say definitively who was supposed to deliver what by which milestone.
An Information Delivery Plan answers one specific, practical question for a project: who is delivering which specific piece of information, in what format, and by what date. It sits inside the broader ISO 19650 ecosystem alongside the Exchange Information Requirements (EIR, defining what’s needed) and the BIM Execution Plan (BEP, defining how the project will meet those requirements) — the IDP is the scheduling and responsibility layer that makes the EIR’s requirements and the BEP’s processes concrete and trackable against actual dates and actual named task teams.
Without a genuine, maintained IDP, an EIR and BEP can both be technically excellent documents and a project can still fail at information delivery in practice, simply because nobody translated “what’s required” and “how we’ll work” into “who delivers what, by when” at a level of detail task teams can actually plan their own work around.
CEN/TR 17654, the detailed European technical guidance supporting the ISO 19650 series, structures information delivery planning across three distinct levels, and understanding this structure is the practical foundation for building a usable IDP on a UAE project.
| Level | What It Covers | Owned By |
|---|---|---|
| Detailed Responsibility Matrix | Fine-grained breakdown of who is responsible for which specific information deliverable | Project-wide, feeding into TIDPs |
| Task Information Delivery Plan (TIDP) | One task team’s specific deliverables, formats, and dates | Each individual task team |
| Master Information Delivery Plan (MIDP) | The aggregated schedule combining every task team’s TIDP into one project-wide delivery timeline | Project/delivery team lead, built from all TIDPs |
The practical relationship between these three levels matters: the responsibility matrix establishes who owns what at a granular level, each task team then builds its own TIDP reflecting its specific commitments, and the MIDP aggregates every TIDP into the single reference document the whole project team uses to see the complete information delivery picture at once. A project missing the MIDP level specifically — where each discipline has a TIDP but nobody has actually combined them into one aggregated view — loses the whole-project visibility that’s often the most valuable part of doing this properly in the first place.
Before any individual task team writes their own TIDP, establish project-wide clarity on which team is responsible for which category of information deliverable. This doesn’t need to be exhaustive on day one, but it needs enough structure that no major deliverable category is left ambiguously owned by “whoever gets to it,” which is a genuinely common early-project failure mode on fast-moving UAE schemes under schedule pressure.
Each discipline — architectural, structural, MEP, and any specialist task teams — builds its own Task Information Delivery Plan, listing specifically what it will deliver, in what format, and by what date, consistent with the responsibility matrix from Step 1. This should be built by people who actually understand that task team’s real production capacity, not imposed top-down by a BIM Manager estimating on their behalf — a TIDP a task team didn’t genuinely commit to is far more likely to slip later.
Once task teams have built their individual TIDPs, someone — typically the Information Manager or lead BIM Coordinator — aggregates them into a single Master Information Delivery Plan, giving the whole project team one reference document showing every deliverable, from every team, against the full project timeline. This is also the point where scheduling conflicts and dependency gaps between task teams’ individual plans tend to surface — a structural deliverable that depends on an architectural model milestone that, once aggregated, turns out to land a week later than the structural team assumed, for instance.
Government and institutional BEP templates reviewed for this guide — including Queensland’s Transport and Main Roads department template and Cambridge’s BIM Toolkit delivery team BEP template — consistently structure their information-delivery-related content around a few recurring supporting elements beyond the core TIDP/MIDP schedule itself: a responsibility matrix (covered above), a software schedule specifying what tools each task team will use to produce their deliverables, and a federation strategy describing how individual discipline models combine into the coordinated federated model. Cambridge’s specific template also includes an information delivery risk register and a mobilisation plan as explicit supporting sections — both genuinely useful additions for flagging delivery risks early rather than discovering them only once a deadline is missed.
The most common real-world gap in information delivery planning isn’t that the documents don’t exist — plenty of UAE projects can produce a TIDP and MIDP at BEP sign-off and then never meaningfully update either again. The actual value of this structure comes from treating the MIDP as a living, regularly reviewed schedule, checked against genuine progress, rather than a compliance artifact produced once to satisfy a contractual requirement and then filed away.
When a BIM Manager or Information Manager drafts task teams’ delivery commitments on their behalf, without real input from the people who’ll actually have to meet those dates, the resulting TIDP often reflects optimistic assumptions rather than realistic production capacity — and the gap surfaces later as missed milestones, at a point where it’s harder to recover from than if it had been caught during planning.
Individual task teams each having a TIDP, with nobody ever combining them into a genuine project-wide MIDP, means the project never actually gets the cross-discipline visibility that’s the main practical benefit of this whole structure — dependency conflicts between teams’ individual plans go unnoticed until they cause a real coordination problem.
Projects evolve — scope changes, schedules compress or extend, task teams’ actual capacity turns out to differ from initial estimates. An IDP that was accurate at BEP sign-off but never revisited stops reflecting reality fairly quickly on any live UAE project, and a stale IDP that nobody trusts anymore is barely more useful than having no IDP at all.
If TIDPs get built without clear grounding in an agreed, project-wide responsibility matrix first, overlapping or conflicting ownership claims between task teams tend to surface later, often during an actual information exchange, rather than being caught earlier during planning when they’re considerably cheaper to resolve.
The Information Delivery Plan isn’t a standalone compliance document sitting apart from the rest of your ISO 19650 documentation — it’s the practical scheduling backbone that makes the rest of the BEP’s commitments trackable and enforceable. A BEP that defines excellent CDE discipline and clear roles, without a genuinely maintained TIDP/MIDP structure underneath it, still leaves the project without a clear, trackable answer to “is the information we need actually going to arrive on time,” which is ultimately the question all of this exists to answer.
Consider a mid-rise mixed-use project in Dubai with architectural, structural, MEP, and facade task teams all contributing to a federated BIM model. At responsibility-matrix stage, the project team agrees that structural is responsible for primary structure and foundation information, MEP for all services routing and plant room coordination, facade for the building envelope system, and architectural for overall spatial coordination and internal layouts — a necessarily simplified example, but enough to establish non-overlapping ownership at a category level.
Each task team then builds its own TIDP. The facade team, for instance, commits to delivering a coordinated envelope model by a specific milestone tied to when structural steel information needs to be locked in, since facade fixing details depend directly on structural tolerances. When the Information Manager aggregates all four TIDPs into the MIDP, a dependency conflict surfaces immediately: the facade team’s committed delivery date assumes structural will have published its steel model two weeks earlier than structural’s own TIDP actually commits to. Caught at MIDP-aggregation stage, this is a straightforward scheduling conversation between two task leads. Caught only once the facade team is actually blocked waiting on a structural model that hasn’t arrived, it’s a live, expensive project delay instead.
This is the concrete, practical value an aggregated MIDP provides that four separate, never-combined TIDPs don’t: visibility into exactly these cross-discipline dependency conflicts, early enough that they’re a planning conversation rather than a site problem.
In practice, the responsibility matrix and MIDP aggregation role tend to fall to whoever holds the Information Manager function on a project — sometimes a dedicated role, often a hat worn by a senior BIM Coordinator or BIM Manager on small to mid-sized UAE teams. What matters more than the specific job title is that one identifiable person or small team owns keeping the MIDP current and chasing task teams for genuine, realistic TIDP commitments, rather than the responsibility being diffuse enough that nobody feels directly accountable when the document goes stale. Projects that assign this ownership clearly and explicitly at BEP sign-off tend to maintain a genuinely useful IDP much further into the project than ones where it’s an implied, unassigned responsibility.
While an Information Delivery Plan can be built and maintained in a well-structured spreadsheet — and plenty of UAE projects do exactly that, particularly on smaller schemes — larger, more complex multi-disciplinary projects increasingly track TIDP/MIDP status directly inside their Common Data Environment platform, such as Autodesk Construction Cloud, where deliverable status can connect directly to the actual container status (WIP, Shared, Published) of the information itself, rather than living as a separate tracking document disconnected from where the real work happens. This integration reduces one of the more common failure modes covered above — an IDP that goes stale because updating it is a separate, easily-forgotten administrative task rather than something that naturally reflects the project’s actual, live information status.
Whichever tool a UAE project uses, the underlying discipline matters more than the specific platform: someone needs to own keeping the MIDP’s status genuinely current, and the project team needs to actually trust and reference it as the real source of truth for delivery status, rather than treating it as a document produced once for compliance and then functionally ignored for the rest of the project.
Structuring a genuinely usable TIDP and MIDP — one task teams actually commit to and one that gets maintained rather than filed away after sign-off — is a practical skill that goes well beyond knowing the acronyms. Orbit’s BIM Standards / ISO 19650 Compliance course in Dubai works through building this structure hands-on, inside the same kind of multi-disciplinary information management workflow real UAE projects actually run, rather than treating information delivery planning as a theoretical exercise disconnected from how task teams genuinely work.
A Task Information Delivery Plan (TIDP) belongs to one individual task team and lists that team’s specific deliverables, formats, and dates. A Master Information Delivery Plan (MIDP) aggregates every task team’s TIDP into a single project-wide delivery schedule, giving the whole team visibility across all disciplines at once.
The task team itself should build its own TIDP, since they understand their genuine production capacity. A TIDP imposed top-down by a BIM Manager without real task-team input tends to reflect optimistic assumptions that surface as missed milestones later.
No — the BEP defines how a project will meet its information requirements generally (roles, CDE structure, processes), while the IDP (via TIDPs and the MIDP) is the specific scheduling and responsibility layer tracking who delivers what, in what format, by which date.
It should be treated as a living document reviewed regularly against genuine project progress, not produced once at BEP sign-off and left static — a stale MIDP that no longer reflects real task-team capacity or schedule changes loses most of its practical value.
It’s a project-wide breakdown establishing which task team is responsible for which category of information deliverable, built before individual TIDPs so that each task team’s plan is grounded in agreed, non-overlapping ownership rather than assumptions that might conflict with another team’s understanding of the same scope.
Without a genuine TIDP/MIDP structure, a project loses clear visibility into who is delivering what by when across disciplines, which commonly surfaces later as missed milestones, unclear accountability when information doesn’t arrive on time, and coordination conflicts between task teams’ informal, unaligned assumptions about their own delivery dates.
Government and institutional BEP templates consistently include them as supporting elements alongside the core TIDP/MIDP structure, since knowing what software each task team will use and how their models will be federated directly affects whether the planned information deliverables can actually combine into a coordinated, usable project model on schedule.