Model Progression & Delivery Matrices in Plannerly Scope

Plannerly's Scope module lets you build model progression tables, TIDPs, MIDPs, responsibility matrices and IPSs in one place, structured by stage and classification, aligned with ISO 19650 and ISO 7817 level of information need, with exports to PDF contracts, Excel and buildingSMART IDS.

TL;DR

If you need a model progression table, a task or master information delivery plan, a responsibility matrix, EIR or the new information production schedule (IPS) coming with the 2026 ISO 19650 updates, they all live in the same place. Build them inside the Plannerly Scope module, aligned to the level of information need concept from ISO 7817.

Watch: a short walkthrough of building structured information requirements in the Scope module - from stage columns and classification rows to information containers, responsibilities and exports.

Why Scope is where this lives

I get this question a lot. People ask where to build their model progression table, their TIDP, their MIDP, or their responsibility matrix. The honest answer is they are all the same kind of artefact - a structured set of requirements organised by stage and by something you are delivering. So they all belong in one place.

That place is the Scope module. It is built around the level of information need idea from ISO 7817, so the structure already lines up with how the standard wants you to think about geometry, information and documentation per stage.

Building the matrix structure

Across the top you have your project stages or milestones. Down the side, you choose the structure that fits your team. In the example I show, we use a simple discipline folder structure, but you are not locked into that.

Plannerly supports the classifications you would actually use on a real project - Uniclass, Uniformat, OmniClass, or whatever your appointing party requires. The cells where stages meet rows are where your information containers sit. That is the matrix.

What information containers actually carry

An information container is more than a tick in a box. It is where you capture every requirement attached to that thing at that stage - geometric needs if it is a modelling requirement, information requirements with the actual parameters you expect, and the values you want back.

Values can be anything you need them to be - numeric, text, separated lists, Boolean, and so on. That is what makes the output usable as a contract, not just a wishlist. You can also communicate responsibility here - who is delivering what at which stage, and where responsibility shifts between teams.

ⓘ
Good to know
You can change what each cell shows in the grid view. If you are working through modelling requirements, set the grid to display information requirements. If you are looking at it from a delivery angle, switch the visualisation to suit. The data does not move - the view changes.

Inside an information container

Click into any information container and you get the deeper layer. That includes a description, checklists, attached documents, a threaded conversation against the requirement itself, and the history of everything that has happened to it.

This is the part that surprises people. You are not just writing a static matrix - you are creating a place where the requirement, the conversation about the requirement, and the proof that the requirement was met all live together.

Non-model activities and document placeholders

Not every line in your MIDP or TIDP is a model. A lot of it is documents - reports, calculations, sign-offs, drawings. Scope handles those too.

Define a non-model activity as a row, request the document at the right stage, and you get a document placeholder. Later, when the document is produced, your team uploads it against that placeholder. The output becomes accessible from multiple places in the platform, not just the matrix you built it in.

Naming it: TIDP, MIDP, MPDT, EIR, IPS

The naming has shifted over the years and it is going to shift again. Today people call it a TIDP (task information delivery plan), MIDP (master information delivery plan), MPDT (model progression delivery table), or EIR (exchange information requirements) depending on country, framework and context.

With the 2026 ISO 19650 updates, the term you will likely hear more of is information production schedule (IPS). Whatever the label, the artefact is the same - a structured set of requirements organised by stage and by what you are delivering. Build it once in Scope and you are covered for all of them.

Exporting your requirements

Once your matrix is built, you can take it out in the format your project actually needs. Export to PDF contracts for sign-off, export the scope data to Excel for downstream tools, or export to IDS - the Information Delivery Specification standard from buildingSMART - to drive automated validation.

One source of truth, multiple outputs. That is the part that saves the most time on real projects.

Related resources