Sit in enough mobilisation meetings and you will hear all three called "the BIM plan", usually by someone handed the folder from the last job and told to sort it out. ISO 19650-2 gives them three separate jobs: how information will be produced, when the master set of containers is due, and what each task team has actually committed to. Let those three say different things and the common data environment will not rescue you; it will file the disagreement tidily and let you find it in month nine.

The confusion is understandable: the acronyms look alike, they arrive in the same email, and on many projects one overworked person writes all three in the same week.

What the BEP is for

The BIM execution plan is the appointed side's method — its answer to the exchange information requirements it has just been handed. It does not list every container. It sets out how containers will be named, federated, reviewed, issued and archived, which CDE and which states will be used, who holds which information-management function, which software and classification everyone shares, and how security, clash and suitability will be handled.

ISO 19650-2 splits it in two, and that split matters. Before appointment, the prospective lead appointed party writes a pre-appointment BEP: a tender method, with the proposed delivery strategy and enough resource detail for the ask to be priced honestly. After appointment, the same party confirms the BEP. The confirmed document is the one the job is meant to run on. Carry the tender PDF through to handover and you spend two years executing a bid.

So the BEP is a procedure rather than a programme. If you cannot put a finger on the CDE workflow, the review gates and the named functions inside it, what you are holding is a brochure.

What a TIDP is for

A task information delivery plan is one task team's slice of the delivery. Architecture writes one. Structures writes one. Each services package writes one. A specialist contractor who is a task team writes one, and the number of jobs where that gets skipped is remarkable. The TIDP lists the containers that team will produce, the level of information need for each, the milestone or date, and a named producer — a person, not "the design team".

Think of it as a promise the team can be held to. It is not a miniature BEP: it does not redesign the CDE and it does not invent a second naming convention. It fills the method with actual work.

"Architectural model, monthly" is not a plan, it is a note to self. Name the container, the purpose it serves, the state it has to reach and the week it has to reach it, and you have given a package manager something to chase.

What the MIDP is for

The master information delivery plan is the project's programme of information. The lead appointed party's information manager compiles it out of the TIDPs. Every container the EIR asked for, and every container the BEP said would exist, should appear once, with a responsible task team and a date somebody can watch.

This is the document a project manager lays alongside the construction programme to see whether information is arriving early enough to be of any use. Not a second method statement, and not a Gantt chart of meetings. If a coordination model is due in week 18 and the first pour depending on it is week 16, the MIDP is what should have shown the collision while there was still time to move one of them.

When the master plan is not the sum of the task plans, one of three things has happened: a team's promise is missing, two teams have promised the same container, or somebody typed a date that no TIDP supports. All three are cheaper to find in week two than in month six.

How the three nest together

The stack is an ask, a method, and a programme assembled out of team slices.

Above all three sit the appointing party's exchange information requirements, which say what must be delivered and to what level of information need. That is the client's document, not the supply chain's, and confusing it with a BEP is a common mix-up.

Under that ask:

  1. The BEP is how the appointed side will produce, manage and issue information — including how TIDPs will be written and how the MIDP will be kept current.
  2. Each TIDP is a task team's list of containers, dates and named producers, written inside that method.
  3. The MIDP is those TIDPs rolled up, maintained as one programme, and used to run delivery.

Read downwards when you are setting a job up: EIR, then BEP, then TIDPs, then MIDP. Read upwards when something is late — the missing container belongs to a team, so start at the TIDP; the team's date has to match the master, so check the MIDP; and the method for moving that container through its states is already written in the BEP. Flatten all three into one Word file called "the BIM plan" and you lose the only useful property of the arrangement: knowing who owns which promise.

They also have to agree with each other. A BEP cannot promise weekly federation when the MIDP carries no federation milestone and the services TIDP has no coordinated model. The CDE cannot run a fourth naming rule the BEP never agreed to. Once they drift apart, people stop opening any of them and the job gets run off a coordinator's spreadsheet — which works right up until the coordinator changes employer.

Who writes what

DocumentAuthorConfirms or accepts
EIR (above the stack)Appointing party, usually through the information managerProspective lead appointed parties at tender
Pre-appointment BEPProspective lead appointed partyAppointing party at appointment
Confirmed BEPLead appointed party, with appointed parties contributing their methodAppointing partythen used by every task team
TIDPEach task team — typically the task team manager with the discipline information leadLead appointed party's information manager
MIDPLead appointed party's information manager, compiled from TIDPsAppointing party's information managerthen used as the live programme

Authorship here is a function, not a software licence. A BIM coordinator can draft. A document controller can keep the register the MIDP points at, usually better than anyone else would. Neither of them removes the lead appointed party's duty to confirm the method and compile the master plan, or a task team's duty to own its own slice.

If you cannot name a living person against each row of that table on this project, the documents will be written by whoever still has last job's template on their desktop.

What copied documents look like

The characteristic failure is rarely a missing acronym. Far more often it is a PDF from the previous contract, find-and-replaced, uploaded to the CDE at mobilisation and never opened again.

The copied BEP still names another project's CDE, last year's software versions and a security matrix drafted for a different client. Roles are job titles that do not exist on this organogram, or people who left in week three. Suitability codes are listed and then ignored, because nobody configured the live workflow to match the text. The confirmed BEP was never confirmed, so the tender method is still the method.

The copied TIDP is one line per discipline. Container identifiers are missing, so nothing can be ticked off. Two packages each assume the other is producing the coordinated services model. A specialist who is plainly a task team has no TIDP at all, so their information turns up as email attachments and is treated as a surprise.

The copied MIDP is a kick-off Gantt exported to PDF. The dates never matched the construction programme. A coordination workshop moved and the master plan did not follow it. By month four the only programme anyone trusts is a tracker on a package manager's laptop, and the official MIDP is archaeology.

The three fail together because nobody is required to reconcile them. Information then runs "on time" against a fantasy calendar, late against the pour, and untraceable against the EIR. The CDE shows uploads; it cannot show you a promise nobody ever owned.

Copied documents also fail in a quieter way. They pass bids and gateway reviews perfectly well: someone points at the filenames, the box is ticked, and the information still does not exist.

A test you can run on Monday

You do not need a consultant. Ask for the current files rather than the mobilisation pack, and accept only a dated record as an answer.

  1. Which BEP is live — pre-appointment or confirmed — and when was it last revised? If the answer is the tender PDF, the method was never appointed.
  2. Open the CDE section of that BEP. Does the live workflow match it: states, suitability, naming, who may publish? If the operators have had to invent a parallel rule, the BEP is decoration.
  3. Does every task team, specialists included, have a TIDP naming containers, producers and dates? "The design team" is not a producer.
  4. Does the MIDP equal the sum of those TIDPs — no gaps, no double-counting, no master date that no team has promised?
  5. Put the MIDP beside the construction programme. For the next two critical activities, is the information they will rely on already due, with a named container, before the activity starts?
  6. When a date moved last week, which document changed first? If the answer is a chat message, the plans are not in use.

Six answers pointing at current containers and named functions mean the stack is working. Six answers pointing at a template folder mean you have stationery.

None of this is a certificate

ISO 19650, CDM, the Building Safety Act, NEC, FIDIC, JCT, COBie and the Gulf mandates all have owners, and each assumes an information-delivery problem underneath. None of them turns a copied execution plan into compliance, and a folder of acronyms has never yet stopped a coordination model landing two weeks after the pour that needed it.

At appointment, the appointing party should refuse a confirmed BEP that still names last job's CDE, last year's software or people who are not on this organogram, and should not accept a kick-off Gantt exported to PDF as an MIDP. Require every task team — specialists included — to table a TIDP that names containers, producers and dates, and make the lead appointed party's information manager compile those into a live MIDP that moves when the construction programme moves. That costs a writing week at mobilisation and a named person to keep the three reconciled afterwards; a copied folder is cheaper on day one and is how you buy a fantasy calendar. If those living names are not on the table before the first coordination workshop, you do not have a method yet.

Read next: Writing exchange information requirements that actually get answered, Migrating a live project to a new CDE without losing the audit trail, Everyone says they have a CDE. Most have a shared drive with permissions..