Now you operate the foundation.

Part 1 set the foundation, the cascade, the CDE, LOIN, naming, and the cast of parties. It told you what gets produced and by whom. Part 2 is the other half: how you run a project against it. The appointment, the mobilisation, the production cycle and the stage gates that turn a set of requirements into a delivered, audited information model.

ISO 19650-2 organises all of that into eight activities, four to set the appointment up, four that loop at every stage. About seventeen minutes of reading. If you haven't read Part 1, start there; this part assumes its vocabulary.

How does a project actually move information from requirement to record?

Through a cycle. ISO 19650-2 sets out the delivery phase as eight activities. The first four build the appointment, the client states the need, invites tenders, reads the responses, and signs. The last four are the engine that runs afterward, mobilise, produce, deliver, and eventually close out. Activities five through seven repeat at every project stage, which is what makes it a cycle rather than a line.

The appointment build-up answers who, on what terms, to what spec. The production loop answers and now do it, stage after stage, with every exchange checked.

1, Assessment & need

The appointing party starts. It confirms its requirements, the OIR, AIR and PIR from Part 1's cascade, and turns them into the EIR, the formal specification it will issue to the market.

ISO 19650-2 fixes three things the EIR must carry: the information requirements, the information delivery standards, and the information production methods and procedures. The client also makes the foundational choices here, the CDE platform and the information-management function, because nothing about delivery works if these slip past tender.

2, Invitation to tender

The EIR goes out in the tender pack, with the reference information a bidder needs to respond properly and the criteria the bids will be scored on.

This is the moment the requirements cascade meets the market. A vague EIR here produces vague bids, and a vague project. The clarity of what you ask for sets the ceiling on what you'll receive.

3, Tender response

Each prospective lead appointed party answers with a pre-appointment BEP, the pBEP. It shows how they intend to deliver: named team and capacity, the technology stack, the coordination strategy, a draft MIDP extract, and a mobilisation plan.

The pBEP is the single most reliable predictor of how the team will actually perform, which is why the appointing party scores it, heavily, before anyone signs.

4, Appointment

The winning pBEP is developed into the confirmed BEP, the contractual delivery plan that actually gets executed. The appointment is signed. The information standard, the methods and procedures, the responsibilities and the requirements all become binding.

This is the hinge of the whole standard. Everything before it is preparation; everything after it is execution against what was just fixed.

5, Mobilisation

Before a single deliverable is produced, the lead appointed party mobilises, the four-to-six week window between contract award and productive work. It confirms the BEP, configures the CDE, assembles the MIDP from the task teams' plans, and onboards every team. Skip it and the project spends months recovering from improvised setups.

6, Collaborative production

The task teams produce. Each container is authored in WIP, checked at Gate 1, then moved to Shared for coordination, the CDE flow Part 1 defined. Production follows each team's TIDP: its own slice of what's due, by when, at what level of information need.

7, Information model delivery

At each stage gate the lead appointed party reviews and authorises the information against the EIR and the federated model, Gate 2, then delivers it to the appointing party as a formal information exchange, tracked against the MIDP. Then the loop turns: the next stage begins. (The quality mechanics of that exchange, the Five Cs, the Decision A/B review, are ISO 19650-4's job; that's Part 4.)

8, Project close-out

At the final stage the cycle exits. The accepted information model is archived, lessons learned are captured, and the PIM transitions into the AIM, the operational record the building runs on. That handover, and everything after it, is Part 3's territory.

Deep diveThe eight activities at a glance, and who leads each

Activities 5–7 repeat at every project stage. The appointing party can appoint several lead appointed parties; each runs the same tender → response → appoint pattern with its own appointed parties below it. The cascade of requirements in Part 1 is mirrored by a cascade of appointments here.

The BEP, produced twice

Part 1 noted the BEP is produced twice. Here's why the distinction matters operationally. The pre-appointment BEP is written to win, it shows the appointing party how the team would deliver if chosen. The confirmed BEP is written to deliver, it's the contractual plan the team is held to, and it supersedes the pBEP. Same document family, two very different jobs, two very different stakes.

Pre-appointment BEP, the bid

Submitted with the tender response, under ISO 19650-2 Clause 5.3. It demonstrates capability and approach: how the team will meet the EIR, who's on it and whether they have the capacity, the proposed standards and software, a coordination strategy, a draft MIDP extract, and a mobilisation plan. It is a commitment a bidder makes to win, which is exactly why it must be deliverable, not aspirational.

Confirmed BEP, the contract

Developed from the winning pBEP after appointment (Clause 5.4), within roughly fifteen to twenty working days, before production starts. It hardens everything: the confirmed responsibilities matrix and RACI, the agreed information standard and methods, the TIDPs aggregated into the MIDP, the CDE configuration, the LOIN per stage, the QA procedure, and the handover strategy. This is the document the delivery phase is actually run from.

Deep diveWhat's in a BEP, the QA framework inside it, and the two ways it goes wrong

The sections the confirmed BEP carries

Project information · team and responsibilities (org chart, named roles, RACI, sub-consultant scope) · information standards (software versions, IFC version, coordinate system, units, Uniclass 2015) · CDE configuration (platform, folders, naming, status codes, approval workflow, access matrix) · the LOIN specification · the MIDP summary and milestones · quality assurance · coordination procedures (clash workflow, federation, design-freeze dates) · security and data (an ISO 19650-5 plan where the project warrants it) · handover strategy (FM data, COBie, as-built, O&M).

The consultant and contractor variants differ mainly in who leads and in stage emphasis, the consultant carries design-stage production and multi-discipline coordination across the RIBA stages; the contractor carries construction-stage delivery: design models received at LOD 300, developed to LOD 350 for coordination and LOD 400 for shop drawings and fabrication, then verified to LOD 500 as-built, with 4D sequencing and subcontractor task-team governance on top. The structure is the same.

The QA framework the BEP commits to

A serious BEP defines its own internal quality gates, so no container reaches a shared or published state unchecked. JES's standard is a four-level framework: L1 modeller self-check (naming, model health, internal clash) → L2 discipline/trade review (rules-based model checking, metadata) → L3 coordination review (federated clash detection, BCF report) → L4 milestone gate audit (formal EIR/BEP compliance scorecard, written sign-off before any milestone deliverable goes to the client). Anything that can't be resolved before publication is logged as a Non-Conformance Report and tracked in the CDE.

Two failure modes

A pBEP that overpromises. The bid commits to LOIN levels or delivery cadences the team can't hit. By Stage 3 it's missing milestones, and because the over-commitment was signed, the contractual exposure was baked in at appointment, not discovered later.

A boilerplate BEP nobody runs from. The team copy-pastes last project's BEP, leaves the BIM Manager column reading "to be confirmed," files it, and runs the project from habit. A boilerplate BEP versus a serious one is the clearest leading indicator of project quality there is.

The first thirty days decide the project

This is the part of delivery most often skipped and most expensive to skip. Mobilisation is where the foundations are physically built: the CDE configured, the MIDP assembled, the standards issued, the teams trained. Get it right and the project runs on reliable process from day one. Rush it, "commence immediately on signature", and the first real exchange is the first time anyone tries the workflow, under deadline.

ISO 19650-2 Clause 5.4 requires the appointed party to confirm the BEP, develop the MIDP, and establish the CDE in this window. The standard treats it as four weeks of disciplined setup, run as a programme with hard checkpoints.

Weeks 1–2, confirm the BEP

Review the contract and EIR in detail. Run a gap analysis between what the pBEP promised and what the contract requires. Formally appoint the named BIM Manager. Draft and finalise the confirmed BEP, and submit it for client review by the end of week two.

Weeks 2–3, configure and test the CDE

Set the CDE up to the agreed structure: the four ISO 19650 state areas, the access-control matrix, and, the single most important step, naming validation that rejects non-compliant uploads automatically. Without it, teams revert to their own conventions within weeks. Then test it: run a pilot upload workflow before anyone relies on it.

Weeks 2–4, assemble the MIDP

Build the MIDP bottom-up from the task teams' TIDPs (next section). Map the regulatory submission milestones first, permits, fire and life safety, utilities, sustainability, then work the design deliverables back to feed each one with adequate review time.

Weeks 3–4, onboard the teams, then go live

Onboarding is not emailing login credentials. Each user is trained on the project's standards and CDE, then must pass a test upload–review–download cycle before getting production access. Week four closes with the formal BIM kickoff meeting; the CDE goes live; production begins.

Deep diveThe kickoff, the risk register, and the compressed-mobilisation trap

The BIM kickoff meeting

The formal launch of the information-management process, held at the end of mobilisation. It walks the whole team through the approved BEP, demonstrates the live CDE, reviews the MIDP and its first data drop, confirms the RACI, and reviews the mobilisation risk register with owners assigned. After this meeting, everyone knows the rules of the game and where their work goes.

The mobilisation risk register

ISO 19650-2 requires the appointed party to identify risks to the information-management process and propose mitigations, kept as a live Likelihood × Impact register, reviewed monthly. The recurring high-impact risks and their fixes:

Risk	Mitigation
CDE not ready at go-live	Start CDE procurement at pre-appointment; temporary labelled folder for week 1–2 only
BEP not approved by client	Submit week 1; dedicated review meeting week 2; cap at two revision cycles
Team not trained	Mandatory training week 3; no production access without confirmed completion
Naming convention not enforced	Server-side validation enabled before go-live; non-compliant uploads rejected
MIDP misaligned with programme	Co-develop with the programme manager; map regulatory milestones first

The compressed-mobilisation trap

Mobilisation theatre is the named failure: lots of kickoff meetings, little measurable setup, and day thirty arrives with the CDE unconfigured, the naming convention still in draft, and the MIDP unbuilt. Treat the mobilisation checklist as a hard gate at day 7, 14 and 30, an unfilled box is a schedule slip, not housekeeping. Where the client genuinely cannot wait, run parallel mobilisation: low-risk early tasks in a clearly-labelled temporary folder while the CDE is configured alongside, all of it migrated into the live CDE before the first formal milestone, and the approach documented in the BEP so early outputs are understood as preliminary.

How the delivery plan is assembled

The MIDP isn't authored top-down. It's assembled bottom-up. Each task team writes the plan for the work it owns; the lead appointed party consolidates those into one master register. The structure mirrors the parties: production happens in the task teams, so the plan is built from their commitments and rolled up, not dictated from above.

TIDP, each team's slice

The Task Information Delivery Plan is one task team's list of the information containers it will produce: each container named to the convention, its responsible author, its level of information need, its due date, the status it'll carry at delivery, and its dependencies. Each team submits its TIDP to the lead appointed party within about fourteen days of appointment.

MIDP, the master register

The lead appointed party aggregates all the TIDPs into the Master Information Delivery Plan: every container, every team, every date, every format, every dependency, across the whole appointment. Each row carries the container ID, title, originator, discipline, type, status code, revision, LOIN reference, planned and actual issue dates, target status, exchange milestone, and dependencies. It is the master schedule of information delivery, maintained continuously and tracked against actuals at every exchange.

Deep diveBuild order, and the failure that kills it

How the plan comes together

1. Map the EIR, extract what's required, per stage.
2. Draft the TIDPs, each task team plans its own containers, owners, LOIN, dates, dependencies.
3. Consolidate, the lead appointed party merges the TIDPs into the MIDP.
4. Align, reconcile against the project programme, regulatory milestones mapped first.
5. Approve, client sign-off, then track against actuals at each exchange.

The static MIDP

The single most common delivery failure: the MIDP is built in week four against a programme that's obsolete by week twelve, then never touched again. By month four nobody trusts it, the weekly delivery review reverts to email and WhatsApp, and the project loses the one register that told it what was due. Rebuild the MIDP at every information-exchange milestone, not just at the start. A MIDP is only as useful as it is current.

The production cycle, gate by gate

Part 1 defined the CDE's four states and two gates. Part 2 is where they do their work. Every container a project produces runs the same path, produced privately, checked, shared, authorised, published, eventually archived. The gates map onto the parties: the producing team checks its own output, the lead appointed party authorises the exchange.

Gate 1, WIP to Shared

The producing team's BIM Coordinator runs it. The checks: naming convention, model health (no warnings, purged content, correct origin and coordinates), and LOIN against the spec. Pass, and the container moves to Shared, visible to other teams for coordination, but not yet for procurement or construction. Fail, and it returns for rework.

Gate 2, Shared to Published

The lead appointed party runs it, on behalf of the appointing party. The checks: EIR compliance, coordination against the federated model, and formal sign-off. Pass, and the container is Published with the appropriate suitability code, authorised, contractual-grade, the current version of record. This is also the point of the information exchange at a stage gate.

Deep diveStatus codes, and where the exchange-quality rules live

The suitability codes (locked canon, same as Part 1)

A container's state says where it lives; its status code says what it's approved for. The code travels with the container and changes at every transition.

Code	Status	Approved for
S0	Work in progress	Author / originating team only
S1	Suitable for coordination	Design coordination
S2	Suitable for information	Information only, no action
S3	Suitable for review & comment	Formal review, response required
S4	Suitable for stage approval	Stage / gate approval
S5	Suitable for costing	QS / cost estimation
S6	Suitable for manufacture	Fabrication / procurement
S7	Suitable for construction	Site construction use
A1–An	Approved / accepted	Full team + client; supersedes earlier
CR	As-constructed record	Final record, archived for FM

At a stage exchange a container typically runs S4 (submitted for stage approval) → A1 (approved). The published/approved codes are defined in the EIR and vary by framework, some projects use A1–A5 plus B1/B2 instead of S7/CR. Pick one scheme per project and enforce it in the CDE. The approver's decision is itself coded, A approved · B approved with comments · C rejected, revise & resubmit · D rejected, do not resubmit, and the one rule underneath it all is separation of duties: an author never approves their own container.

Where the exchange-quality rules live

Part 2 gets the information to the gate and runs the project around it. The mechanics of the gate review, the Five Cs an exchange is tested against, the Decision A / Decision B records that make each transition accountable, the model review report, and the format and COBie checks, are governed by ISO 19650-4. That's Part 4. Read it for how an exchange is actually quality-assured; read this part for how the project that produces the exchange is run.

Further reading

• ISO 19650 series, BSI, Part 2 covers the delivery phase in full.
• UK BIM Framework, BEP, MIDP and appointment templates.