BIM Execution Plan: [Project name]
The delivery team's plan for producing, checking and handing over
project information on a building or infrastructure project: who does
the information management, how the exchange information requirements
will be met, the common data environment (CDE), naming and metadata,
level of information need, and the delivery plans that schedule every
information container. Structure aligned with the information
management process of ISO 19650-2:2018 (clause 5), the concepts of
ISO 19650-1:2018, and the security and health and safety parts
ISO 19650-5:2020 and ISO 19650-6:2025. Replace every [bracketed]
value and every row marked Example. Facts checked October 2026.
Document control
| Field | Value |
|---|
| Document ID | [FHL-QCN-ZZ-ZZ-RP-X-00001] |
| Project | [Project name and code] |
| BEP stage | [Pre-appointment (ISO 19650-2 5.3.2) / Confirmed at appointment (5.4.1)] |
| Responds to | [Appointing party's EIR, ID and version], [Lead appointed party's EIR to task teams (5.4.3), ID and version] |
| Version | [P01] |
| Status | [S3 suitable for review and comment / A1 accepted] |
| Owner | [Lead appointed party information manager, @name] |
| Approvers / reviewers | [Appointing party information manager @name], [Lead appointed party project director @name] |
| Last updated | YYYY-MM-DD |
| Classification | [Commercial in confidence; security-minded approach per section 11] |
| ISO 19650 editions applied | [ISO 19650-1:2018, ISO 19650-2:2018, plus national annex if any, ISO 19650-5:2020, ISO 19650-6:2025] |
Approvals
| Role | Name | Decision | Date |
|---|
| Lead appointed party, information manager | [@name] | [Author] | YYYY-MM-DD |
| Lead appointed party, project director | [@name] | [Approved for submission] | YYYY-MM-DD |
| Appointing party, information manager | [@name] | [Accepted into appointment] | YYYY-MM-DD |
Revision history
| Version | Date | Author | Change summary |
|---|
| P01 | YYYY-MM-DD | [@name] | Pre-appointment BEP for tender |
| C01 | YYYY-MM-DD | [@name] | Example: Confirmed at appointment; responsibility matrix detailed, TIDPs and MIDP linked |
| C02 | YYYY-MM-DD | [@name] | Example: Health and safety information requirements added for the handover stage |
Contents
1. Project information
| Item | Value |
|---|
| Asset and scope | Example: New three-storey library, 2,400 m2 gross internal area, steel frame, external works |
| Procurement route | Example: Two-stage design and build |
| Appointing party | Example: Fernhollow Town Trust |
| Lead appointed party | Example: Quillmere Construction |
| Project stages used | [Your plan of work stages, for example strategic definition to handover] |
| Key information delivery milestones | [Linked from the appointing party's milestones, ISO 19650-2 5.1.3] |
| Handover target | YYYY-MM-DD |
2. Information management function and roles
| Role | Organisation | Named person | Time committed | Responsibilities |
|---|
| Information manager (delivery team) | Example: Quillmere Construction | [@name] | [0.6 FTE] | Owns this BEP, the MIDP, CDE workflow and information model audits |
| Task information manager, architecture | Example: Marrowpike Architects | [@name] | [0.2 FTE] | Owns the architecture TIDP and model quality checks |
| Task information manager, structure | Example: Okeburn Structures | [@name] | [0.2 FTE] | Owns the structure TIDP |
| Task information manager, MEP | Example: Tessaline Building Services | [@name] | [0.3 FTE] | Owns the MEP TIDP and coordination of services |
| Interface manager | Example: Quillmere Construction | [@name] | [0.2 FTE] | Runs clash detection and coordination meetings |
| Appointing party information manager | Example: Fernhollow Town Trust's agent | [@name] | [As needed] | Reviews and accepts the information model |
3. Information requirements and response
3.1 Hierarchy of requirements
ISO 19650-1 describes how requirements cascade: organisational
information requirements (OIR) and asset information requirements (AIR)
from the asset owner, project information requirements (PIR) for the
project, and exchange information requirements (EIR) for each
appointment. The delivery team answers the EIR in this plan.
3.2 EIR response matrix
| EIR ID | Requirement (summary) | Response: what is produced | Format | Responsible task team | Milestone | Acceptance check |
|---|
| EIR-01 (Example) | Federated design model for each stage gate | Federated model plus clash report | IFC 4 and native | Architecture (lead), all | End of each design stage | Clash report with no unresolved critical clashes |
| EIR-02 (Example) | Space data for the library management system | Room schedule with area, use, occupancy | Spreadsheet export from the model | Architecture | Stage 4 | Areas within 1% of the measured drawing |
| EIR-03 (Example) | Asset data for maintainable equipment | Asset register with attributes listed in the AIR | Spreadsheet in the agreed asset data template | MEP | Handover | Every maintainable asset in the register has its required attributes |
| EIR-04 (Example) | Health and safety information for the file | Residual risk register, as-built drawings, access and maintenance information | PDF and model attributes | All, coordinated by the principal designer | Handover | Section 12 checks passed |
| [EIR-nn] | [Requirement] | [Response] | [Format] | [Team] | [Milestone] | [Criteria] |
4. Information delivery strategy
- Approach to the EIR: [How each requirement is produced, by whom and
when, with reference to the response matrix in section 3.2.]
- Collaboration goals: Example: single federated model reviewed every
two weeks; design coordination before each stage gate; contractor input
to buildability from stage 3.
- Organisation and commercial relationships: Example: Quillmere
Construction holds the appointment with the appointing party; design
task teams are appointed by Quillmere under novated or direct
appointments, each with its own TIDP.
- Task team split: Example: architecture and landscape (one task
team), structure, MEP, and the contractor's own construction sequencing
team.
5. Federation strategy and volumes
| Volume code | Description | Owning task team |
|---|
| ZZ | All volumes | All |
| 01 (Example) | Library building | Architecture |
| 02 (Example) | External works and landscape | Architecture |
| ST (Example) | Structure, whole building | Structure |
| ME (Example) | Mechanical and electrical systems | MEP |
- One discipline per model container; no team edits another team's
container.
- Shared coordinates and project base point set in the project
information standard and checked at each upload.
- Federated model assembled by the interface manager every [two weeks].
6. Responsibility matrix
| Information element | Deliverable | Architecture | Structure | MEP | Contractor | Appointing party |
|---|
| Example: Building fabric | Model and drawings | R | C | C | I | A |
| Example: Structural frame | Model, drawings, calculations | C | R | I | C | A |
| Example: Building services | Model, schematics, asset data | C | I | R | C | A |
| Example: Construction sequence | 4D programme model | I | C | C | R | I |
| Example: Cost model | Cost plans | I | I | I | R | A |
| [Element] | [Deliverable] | [R/A/C/I] | | | | |
R responsible, A accepts, C consulted, I informed.
7. Level of information need
| Purpose | Milestone | Object or system | Geometry (detail, dimension, location, appearance) | Alphanumerical data | Documentation |
|---|
| Example: Planning approval | Stage 3 end | External envelope | Indicative form and openings | Material type | Elevations, materials schedule |
| Example: Coordination | Stage 4 | Ductwork above 300 mm | Actual size, position within 25 mm | System, size | Coordination drawings |
| Example: Facilities management | Handover | Air handling units | Bounding box and access zone | Manufacturer, model, serial number, warranty, maintenance interval | O&M manual section, test certificate |
| [Purpose] | [Milestone] | [Object] | [Geometry] | [Data] | [Documents] |
8. Common data environment and workflow
| Item | Value |
|---|
| CDE solution | [Product and hosting, set by the appointing party under 5.1.7 or proposed by the delivery team] |
| Hosted by | Example: Appointing party, with delivery team access |
| Access control | Role-based; task teams write only to their own work-in-progress areas |
| Backup and retention | [Frequency, retention period, owner] |
| Transition | Check | Who |
|---|
| Work in progress to shared | Quality assurance check: naming, metadata, model health, content against the TIDP (ISO 19650-2 5.6.3, 5.6.4) | Task team |
| Shared to published | Review and authorise the information model (5.7.1, 5.7.2) | Lead appointed party |
| Published, accepted | Review and accept against the EIR acceptance criteria (5.7.3, 5.7.4) | Appointing party |
| Published to archived | Archive at close-out (5.8.1) | Information manager |
9. Naming, metadata and classification
9.1 Container naming
Example using the field order of the UK National Annex:
Project, Originator, Volume or system, Level or location, Type, Role, Number.
| Field | Example code | Meaning |
|---|
| Project | FHL | Fernhollow Library and Learning Centre |
| Originator | MPA | Marrowpike Architects |
| Volume or system | 01 | Library building |
| Level or location | 02 | Second floor |
| Type | DR | Drawing |
| Role | A | Architect |
| Number | 00201 | Sequential number |
Resulting name: FHL-MPA-01-02-DR-A-00201.
9.2 Status and revision metadata
ISO 19650-1 asks for a status code and a revision code on every
container. Example status codes used in UK guidance (check the national
annex edition your project applies):
| Status | Meaning (summary) | CDE state |
|---|
| S0 | Initial status, work in progress | Work in progress |
| S1 | Suitable for coordination | Shared |
| S2 | Suitable for information | Shared |
| S3 | Suitable for review and comment | Shared |
| S4 | Suitable for stage approval | Shared |
| A1, A2 | Authorised and accepted | Published |
| B1, B2 | Partial sign-off with comments | Published |
| CR | As constructed record | Published |
Revisions: P01, P02 for preliminary; C01, C02 for contractual, with
sub-revisions such as P01.1 while in work in progress. [Confirm against
the project information standard.]
9.3 Classification
[Name the classification system, for example Uniclass, OmniClass or a
national system, and the tables applied to elements, systems, products
and spaces.]
10. Production methods, quality assurance and coordination
| Topic | Method |
|---|
| Model set-up | Example: Shared coordinates from the survey; template files issued by the information manager |
| Units and tolerances | Millimetres; modelling tolerance [5 mm] |
| Model health checks | Example: Weekly automated check of naming, warnings, unused views, file size |
| Clash detection | Example: Every two weeks; rules and tolerances in the coordination procedure |
| Issue tracking | BIM Collaboration Format (BCF) issues linked to the request for information log (construction/rfi-log) |
| Drawing production | Drawings generated from models; no 2D overdrawing of model geometry |
| Open formats | IFC 4 for exchange [confirm schema and model view], PDF for drawings, spreadsheet for data |
10.1 Coordination meeting cycle
| Meeting | Frequency | Inputs | Outputs |
|---|
| Design coordination | Every [two] weeks | Federated model, clash report | BCF issues assigned with due dates |
| Information model review | Before each milestone | TIDP status, quality reports | Go or no-go to publish |
11. Security-minded information management
| Item | Value |
|---|
| Security triage outcome | [Sensitive / not sensitive, decided by the appointing party] |
| Security management plan reference | [ID, if one exists] |
| Information not to be shared | Example: Security system layouts and locations of cash handling areas |
| Controls | Example: Restricted CDE folder, named access, no export to personal devices, watermarking on published drawings |
| Incident reporting | [How a security breach involving project information is reported] |
12. Health and safety information
| Information | Produced by | When | Where held | Feeds |
|---|
| Design residual risks | Each designer | Each design stage | Risk attributes in the model and the risk register | Pre-construction information, construction phase plan (construction/construction-phase-plan) |
| Construction risks and RAMS | Contractors | Before each activity | CDE, RAMS folder (construction/rams) | Site management |
| Health and safety file content | Principal designer with all teams | Through construction, final at handover | CDE, handover folder | Health and safety file in construction/punch-list-handover |
13. Delivery plans and milestones
| TIDP or MIDP | Owner | Location | Last baselined |
|---|
| MIDP | Information manager | [CDE link] | YYYY-MM-DD |
| TIDP architecture | Task information manager, architecture | [CDE link] | YYYY-MM-DD |
| TIDP structure | Task information manager, structure | [CDE link] | YYYY-MM-DD |
| TIDP MEP | Task information manager, MEP | [CDE link] | YYYY-MM-DD |
| Container | Description | Task team | Level of information need ref. | Due milestone | Due date | Status |
|---|
| FHL-MPA-01-ZZ-M3-A-00001 | Architecture model | Architecture | LOIN-04-ARCH | Stage 4 coordination | YYYY-MM-DD | S1 |
| FHL-OKS-ST-ZZ-M3-S-00001 | Structural model | Structure | LOIN-04-STR | Stage 4 coordination | YYYY-MM-DD | S1 |
| FHL-TBS-ME-ZZ-M3-M-00001 | Mechanical model | MEP | LOIN-04-MEP | Stage 4 coordination | YYYY-MM-DD | S0 |
| FHL-QCN-ZZ-ZZ-SH-X-00010 | Asset register for handover | Contractor | LOIN-HO-ASSET | Handover | YYYY-MM-DD | Not started |
14. Software, hardware and IT infrastructure
| Use | Software and version | Used by | Exchange format |
|---|
| Authoring, architecture | [Product, version] | Architecture | Native and IFC |
| Authoring, structure | [Product, version] | Structure | Native and IFC |
| Authoring, MEP | [Product, version] | MEP | Native and IFC |
| Federation and clash | [Product, version] | Interface manager | IFC, BCF |
| CDE | [Product] | All | Not applicable |
| Hardware minimum | [Specification] | All | Not applicable |
15. Mobilisation, capability and risk
15.1 Capability and capacity
| Task team | Assessed capability | Capacity (people) | Gaps and actions |
|---|
| Example: Architecture | IFC export tested, BCF in use | 4 modellers | None |
| Example: MEP | No previous use of the asset data template | 3 modellers | Training session before stage 4 |
| [Team] | [Capability] | [n] | [Action] |
15.2 Mobilisation plan
- Issue templates, shared coordinates and the project information
standard to all task teams.
- Grant CDE access and test the workflow with a sample container through
every state (ISO 19650-2 5.5.3).
- Run a trial federation and clash test before the first coordination
meeting.
- Confirm the TIDPs and baseline the MIDP.
15.3 Information delivery risks
| ID | Risk (cause, event, effect) | Likelihood | Impact | Response | Owner |
|---|
| IR-01 (Example) | Because the MEP team is new to the asset data template, handover data may be incomplete, delaying acceptance | Medium | High | Training, early sample submission at stage 4 | MEP task information manager |
| IR-02 (Example) | Because the CDE is hosted by the appointing party, access delays may hold up sharing | Low | Medium | Access requests at mobilisation, named backup administrator | Information manager |
| [IR-nn] | [Risk] | [L] | [I] | [Response] | [@owner] |
Project-wide risks belong in the RAID log (project/raid-log).
16. Glossary and references
16.1 Glossary
| Term | Meaning in this plan |
|---|
| Appointing party | The client receiving information from the lead appointed party |
| Lead appointed party | The party appointed directly by the appointing party that coordinates a delivery team |
| Task team | A group of people doing one specific part of the information production |
| EIR | Exchange information requirements: what the appointing party needs from an appointment, with format, timing and acceptance criteria |
| CDE | Common data environment: the agreed source of information for the project, with a managed workflow between states |
| Information container | A named, persistent set of information, such as a model file, drawing or schedule |
| Level of information need | The quality, quantity and granularity of information required for a defined purpose |
| TIDP, MIDP | Task information delivery plan; master information delivery plan compiled from all TIDPs |
| Federation | Combining separate discipline models into one coordinated view without merging the source files |
16.2 References
ISO 19650 is a paid standard. This template cites part, edition and
clause numbers only, in original wording.
- ISO 19650-1:2018, Concepts and principles,
ISO.
- ISO 19650-2:2018, Delivery phase of the assets,
ISO. Clause 5 activities
5.1 to 5.8 are used for the section structure.
- ISO 19650-5:2020, Security-minded approach to information management,
ISO.
- ISO 19650-6:2025, Health and safety information,
ISO.
- ISO 7817-1:2024, Level of information need, concepts and principles,
ISO.
- Official text: ISO and national standards bodies (for example BSI for
BS EN ISO 19650 with the UK National Annex), purchase or licensed
access: ISO catalogue search,
BSI Knowledge.
- UK BIM Framework, free guidance on applying ISO 19650, including
Guidance Part 2 (Edition 3, January 2020) on the BEP contents and status
codes, ukbimframework.org.
- Related templates:
construction/construction-phase-plan,
construction/rfi-log, construction/punch-list-handover,
project/project-management-plan, project/raid-log,
compliance/iso-55001-samp.
Standard and licence note
Structure aligned with ISO 19650-2:2018 clause 5 (information
management process during the delivery phase), with concepts from
ISO 19650-1:2018, ISO 19650-5:2020, ISO 19650-6:2025 and ISO 7817-1:2024,
as checked in October 2026. The text is original and reproduces no
wording, tables or definitions from these standards. Official text:
ISO and national standards bodies, purchase or licensed access at the
links in section 16.2. A revision of Parts 1 to 3 was in draft in 2026;
check the current editions and the version named in your appointment.
Template licence: MIT.