Singapore BIM Execution Plan That Clears CORENET X and NBIMS Checks

September 2, 2026

A BIM Execution Plan (BEP) is the project’s information constitution: a project-specific document that defines who delivers what model content, when they deliver it, and how that information gets exchanged and accepted. It is not optional paperwork. If you are starting one, pull an NBIMS-aligned template or follow the checklist below, and draft the project-stage version before design coordination begins, not after.

TL;DR:

A well-structured BEP must align with the owner’s BIM goals and the Exchange Information Requirements to avoid liabilities and disputes.

The project BEP should be developed collaboratively after contract award, signed off by all discipline leads, and incorporated by reference into the contract for enforceability.

The BEP must specify exact coordination workflows, clash detection procedures, file management rules, and responsible parties, with regular updates reflecting project changes.

Inadequate governance, such as static or incomplete BEPs, causes misalignment, delays, and ineffective coordination, especially if the responsibility matrix is not verified against actual model deliveries.

Utilizing established templates and attaching detailed matrices, responsibilities, and statutory submission protocols ensures the BEP functions as an enforceable compliance and coordination tool.

What Is a BIM Execution Plan and Why Does It Matter?
Who Owns the BEP, and What Happens at Each Stage?
What Sections Should Every Project BEP Include?
How Should the BEP Structure Model Coordination and Clash Detection?
What CDE, Naming, and Software Rules Belong in the BEP?
How Do You Actually Draft the BEP Step by Step?
What Mistakes Turn a BEP Into a Shelf Document?
Where Can You Find BEP Templates and What Should You Attach?
What Practitioners See When BEPs Actually Work
How Aman Supports BEP Drafting and Submission-Ready BIM
Sources

What Is a BIM Execution Plan and Why Does It Matter?

A BEP sets the enforceable rules for how a project team produces, exchanges, and verifies digital models. Think of it less as guidance and more as a governing document. It names who owns which model elements, at what level of development, on what schedule, and it spells out the consequences when a discipline fails to deliver.

The NBIMS BEP Standard and the BIMForum BxP guidance both treat the BEP as the anchor document for BIM implementation strategy on a project. Both frameworks converge on the same logic: identify the BIM uses the owner actually needs, design the process to deliver them, define the exchanges between parties, and specify the infrastructure (software, hardware, network access) that makes the process work. A BEP that skips any of those four legs tends to collapse under real project pressure, usually around week six of coordination when the first major clash report lands and nobody agrees on who owns the fix.

Scale the document to the project. A single-building fit-out with two BIM uses (clash detection and quantity extraction) might need six pages. A mixed-use development with facade coordination, MEP fabrication modeling, and 4D sequencing across a dozen subcontractors needs forty. The mistake most teams make is copying a heavyweight template onto a small job, which produces a document nobody reads, or writing a lightweight one for a complex job, which produces a document that says nothing when a dispute arises.

Procore’s research on BEP adoption makes the case plainly: a well-documented BEP reduces rework because it aligns responsibilities and specifies verification steps before modeling starts, not after clashes pile up. That alignment is the entire point. Everything else in the document exists to support it.

The BEP also has to answer to something upstream: the Exchange Information Requirements (EIR), if the owner issued one, or the owner’s stated BIM goals if they did not formalize an EIR. A BEP written in isolation from what the owner actually asked for is a liability, not an asset, because it gives every party a document to point to that doesn’t match the contract.

Who Owns the BEP, and What Happens at Each Stage?

Ownership shifts as the project moves from tender to execution, and confusing the stages is one of the most common ways teams delay coordination by weeks.

The NBIMS BEP Standard describes three distinct stages, each with a different author and a different purpose:

RFP BEP. The owner or its consultant drafts this before bids go out. It states what BIM uses the owner requires, what deliverables it expects, and what minimum competency it will accept from proposers. This is the owner’s chance to set enforceable expectations before price negotiations start, and it should be attached to the invitation to bid, not emailed separately.

Proposal BEP. Each proposing team responds with its own version, showing how it intends to meet the RFP BEP’s requirements: staffing, software, proposed workflow, and any deviations it wants approved before award. A proposer that submits a boilerplate BEP with no project-specific detail is signaling that BIM execution wasn’t a real part of its bid strategy.

Project BEP. Once a team is awarded the work, the Proposal BEP gets negotiated and expanded into the binding Project BEP, developed collaboratively by the general contractor, design team, and key subcontractors. This is the working document for the life of the project.

A practical timeline involves issuing the draft Project BEP soon after contract award, allowing a reasonable review period among all named parties, then requiring signatures from each discipline lead before the first coordination meeting. Skipping the signature step is the single most common reason a BEP becomes unenforceable later. If nobody signed it, nobody is bound by it, and a dispute over missing model content turns into a he-said-she-said argument instead of a contract reference.

Attach the BEP as a numbered appendix to the ITB or the prime contract, and reference it explicitly in the contract’s scope-of-work clause. A BEP that lives only as a shared PDF, with no contractual teeth, functions as a suggestion. One that’s incorporated by reference into the contract functions as an obligation, which is the entire difference when a subcontractor delivers an LOD 200 model where the contract called for LOD 350.

What Sections Should Every Project BEP Include?

A complete BEP has six functional blocks. Skip a block and you leave a gap that surfaces later, usually during a payment dispute or a statutory submission rejection.

Project summary, objectives, and BIM uses. State the project name, delivery method, and the specific BIM uses the team commits to: clash detection, quantity takeoff, 4D sequencing, facade coordination, as-built handover, whatever applies. List only what you will actually execute. A BEP that claims twelve BIM uses but only staffs for three is a document that will be used against the team, not for it.

Contacts, roles, and a responsibility matrix. Name the BIM manager, the model coordinators for each discipline, and the discipline leads responsible for content accuracy. A responsibility matrix (a simple table works fine) should map each model element category to the party accountable for it:

Model deliverables, LOD/LOI, and exchange schedule. For every model element category, specify the Level of Development, the Level of Information (data attached, not just geometry), and the date each exchange is due. Tie these dates to the overall project schedule, not to an abstract BIM timeline that nobody else on the project follows.

Information management infrastructure. This is the CDE structure, accepted file types, naming conventions, and required software versions, covered in detail below. The BEP should name the specific Common Data Environment platform in use and who administers access.

Quality control and acceptance criteria. Define the clash detection rules, the tolerance thresholds for hard clashes versus soft clashes, and the verification steps a model must pass before it’s accepted into the federated dataset. Reference a clash matrix (more on this below) rather than leaving acceptance criteria to individual judgment.

Contractual and compliance clauses, plus attachments. State how the BEP interacts with the prime contract, what happens when a party fails to deliver per the schedule, and list every attachment: the responsibility matrix, the clash matrix, the naming convention spreadsheet, and any statutory submission checklist. The NBIMS BEP content standard treats these modular sections as the baseline for a repeatable, auditable BEP, and building your document around that same modularity makes it far easier to update mid-project without rewriting the whole thing.

How Should the BEP Structure Model Coordination and Clash Detection?

The BEP should not just mention clash detection. It should specify exactly how the process runs, who runs it, and what counts as resolution, because a vague clash clause is where coordination workflows quietly fall apart.

Federate the models on a fixed schedule. Set a weekly or biweekly federation date so every discipline knows when their model must be current. Federating on an ad hoc basis produces stale clash reports that nobody trusts.
Define the clash matrix and tolerances before the first run. A clash matrix specifies which model categories get tested against which others (structure versus MEP, facade versus structure) and what clearance tolerance counts as a real clash versus noise. Solibri’s clash detection matrix approach shows how an exportable matrix, built once in a spreadsheet, saves teams from rebuilding rule sets on every project.
Classify clashes by type. Hard clashes are physical collisions between solid elements. Soft clashes are clearance violations, like a duct sitting too close to a maintenance access zone. 4D clashes are workspace or sequencing conflicts, where two trades need the same physical space at the same time. The BEP should require all three types to be checked, not just hard clashes, since soft and 4D clashes cause more field delays than most teams expect.
Run the tests and filter false positives before circulating reports. A filtered report, reviewed by the BIM coordinator before the coordination meeting, prevents what practitioners sometimes call clash fatigue: a team that stops paying attention to clash reports because half the flagged items are duplicates or non-issues rather than real conflicts.
Log every issue with a full field set. Each clash needs an ID, an assigned owner, a severity rating, a due date, and a closure verification step. Without an issue log with an audit trail, disputes over who caused a delay have no paper trail to settle them.
Re-run and verify before closing. A clash is not resolved until the updated model is re-tested and the fix confirmed, not just marked closed by the party that claims to have fixed it.

The BEP should reference workflows, not just software names, since tools change over version cycles but the process (federate, define rules, test, filter, assign, verify) stays constant. Where a specific platform matters, name it: Solibri clash detection is a common choice for rule-based matrix testing, and the BEP should state which platform the team standardizes on so nobody wastes a week exporting between incompatible formats.

Pro Tip: Set your coordination meeting cadence to match your clash-run cadence, not the other way around. If you run clash tests weekly but meet biweekly, half your flagged issues go stale before anyone discusses them, and stale issues are exactly what produce clash fatigue.

Practical coordination workflows built around a filtered issue log tend to close disputes faster because every party can see exactly when an issue was raised, who owned it, and when it was verified closed.

What CDE, Naming, and Software Rules Belong in the BEP?

The BEP has to lock down the mechanics of file exchange, because vague rules here are what cause a model to bounce at a statutory submission gateway weeks before a deadline.

CDE folder structure and permissions. Specify the work-in-progress, shared, published, and archive states inside the Common Data Environment, and name who has write access to each. A CDE without a defined permission model turns into a dumping ground where nobody can trust which file is current.

File naming convention. Give a real example, not just a rule description. A workable pattern looks like:

PROJ-DISC-LEVEL-TYPE-NUMBER for example, MRT7-STR-L03-MOD-001 for the structural model, Level 3, Model 001, on a project coded MRT7.

State the version control policy alongside it: sequential revision letters, mandatory changelogs on every published revision, and a rule against overwriting a published file without a version bump.

Software versions and exchange formats. Name the specific software versions the team standardizes on for the project duration, and require IFC exports alongside native files for every published model, so no party is locked out of coordination because they’re on a different license tier. Mixing software versions mid-project without a documented upgrade path is one of the fastest ways to break a federated model silently.

CDE states: work-in-progress, shared, published, archive, with named access owners for each.
Naming convention: fixed format, documented with a real example, enforced at file upload.
Version control: sequential revisions, mandatory changelog, no silent overwrites.
Exchange format: native file plus IFC on every publish, format specified per discipline.
Software version lock: named versions, with an agreed upgrade window if a new release forces a change.

For statutory submissions, the BEP should note the required submission format explicitly rather than assuming everyone already knows it. CORENET X guidance on BEP content recommends documenting the submission workflow directly inside the BEP, including which model outputs feed the regulatory gateway and in what format, since a model prepared correctly for coordination is not automatically prepared correctly for submission and compliance review.

How Do You Actually Draft the BEP Step by Step?

Drafting a BEP in the wrong order wastes time, because teams routinely start with the executive summary before they know what deliverables they’re summarizing. Work in this sequence instead:

Collect the inputs first. Pull the owner’s Exchange Information Requirements if one exists, confirm the project’s actual BIM goals with the client, and honestly assess your team’s software and staffing competency. A BEP that promises capability the team doesn’t have is worse than no BEP at all.
Draft the model deliverables and exchange schedule before the narrative sections. Once you know what’s being delivered and when, the executive summary, roles, and objectives sections write themselves. Teams that draft the executive summary first usually end up rewriting it after the deliverables section forces a reality check.
Build the responsibility matrix and clash matrix as standalone attachments. Keep them as spreadsheets referenced by the main document rather than embedded as static tables, so they can be updated without reissuing the whole BEP.
Circulate a negotiation draft to every named party. Give each discipline lead a fixed window, fourteen days is a reasonable standard, to flag conflicts between what the BEP demands and what their contract scope actually covers.
Lock the signature version and version-number the BEP itself. Treat BEP revisions the same way you treat model revisions: sequential numbering, a changelog, and a defined trigger (scope change, new subcontractor, delivery method shift) for when a revision is required.
Host the live version in the CDE, not in email threads. The signed BEP and its attachments belong in the published folder of the CDE, version-locked, with old versions archived rather than deleted.

Templates from BIMForum and NBIMS map cleanly onto this sequence. Start from one of them rather than a blank page. The four-step BIMForum procedure, identify uses, design process, define exchanges, build infrastructure, is a genuinely reliable skeleton to adapt rather than reinvent.

What Mistakes Turn a BEP Into a Shelf Document?

Three failures show up repeatedly on real projects, and all three are avoidable with basic governance discipline.

A static BEP that never updates. Teams write the BEP once at award and never touch it again, even as scope changes, subcontractors turn over, or software gets upgraded. A BEP that doesn’t match current project reality has no enforcement value, because everyone quietly agrees it’s out of date and stops referencing it.

Missing EIR alignment. If the BEP’s BIM uses and deliverables don’t map back to what the owner actually asked for in the EIR (or in the absence of one, in stated project goals), you’ve built an internally consistent document that fails the moment the owner reviews it against the contract.

Over-prescribing tools instead of outcomes. A BEP that mandates a specific software version down to the point release, without a defined upgrade path, breaks the moment a vendor forces an update. Specify the outcome (IFC4 export capability, clash-matrix compatibility) and name the current tool as the team’s chosen means of achieving it.

Good governance ties directly to the contract: require sign-off at each major revision, schedule quarterly audits against actual model deliveries, and define what triggers a mandatory BEP update (new subcontractor onboarding, scope change order, delivery method shift). Tie non-conformance, a model delivered below the agreed LOD, or a missed exchange date, to a specific contract remedy rather than leaving it as an unenforceable expectation.

Pro Tip: Build the “change trigger” list into the BEP itself as a short table: event, required BEP action, responsible party. That table alone turns a vague governance promise into a checklist your team will actually follow when something changes mid-project.

Where Can You Find BEP Templates and What Should You Attach?

Start from an established standard rather than drafting from scratch. The NBIMS BEP standard prescribes both required and optional content fields, and its companion content specification document breaks each field down into modular sections you can lift directly. The BIMForum BxP guidance offers a more field-tested version with practical examples from real project teams. Penn State’s Bim is a widely used academic template that many practitioners adapt for smaller commercial projects. For statutory alignment, CORENET X’s BEP guide walks through how to document submission workflows so the model feeds the regulatory gateway without last-minute format surprises.

Attach these documents to every BEP, whichever base template you start from:

The model element responsibility matrix, as an editable spreadsheet.
The clash detection matrix, with tolerances and category pairings defined.
The file naming convention spreadsheet, with real examples for every discipline.
A statutory submission checklist, where the project involves a regulatory gateway.
The CDE permission map, showing access levels by role.

Scale the template down for a design-bid-build renovation with two disciplines, and scale it up for a design-build tower with a dozen subcontractors. The structure stays the same; only the depth of each section changes.

What Practitioners See When BEPs Actually Work

The gap between a BEP that reads well and a BEP that functions usually shows up in one place: whether the responsibility matrix gets checked against actual deliveries, or just filed away after signature. Aman’s digital engineering team integrates BEP drafting directly with the statutory submission workflow, because a model that satisfies coordination requirements but fails a compliance gateway check has solved the wrong problem.

A typical action at contract award looks like this: within the first coordination meeting, the BIM coordinator walks each discipline lead through their specific LOD commitments line by line, rather than assuming everyone read the full document. That single step catches more scope mismatches than any amount of upfront drafting, because it forces a verbal confirmation against a written commitment before modeling starts, not after the first missed deadline.

The lesson from repeated project cycles is consistent: a BEP earns its authority through enforcement, not through thoroughness. A forty-page document nobody checks against real deliveries is weaker than a ten-page document a team actually audits monthly.

— Aman

How Aman Supports BEP Drafting and Submission-Ready BIM

Drafting a compliant BEP is one task. Making sure the models it governs actually clear coordination and pass statutory review is another, and that second part is where most in-house teams lose time. Aman works both sides: helping project teams draft or tighten an existing BEP against NBIMS and BIMForum standards, and delivering the BIM modeling services that produce submission-ready models against Singapore’s regulatory gateways.

For teams that already have a BEP drafted but aren’t confident it will hold up under coordination pressure or a CORENET X submission review, Aman offers a practical starting point: a document review against the responsibility matrix, clash matrix, and CDE structure you’re currently using, plus a gap check against the LOD and information exchange schedule in your contract. For teams building 4D sequencing into their BIM uses, Aman’s 4D planning guidance extends the same coordination discipline into schedule integration. If your current workflow relies on scattered email threads instead of a structured CDE, BRCKS’s guide to construction workflow management is a useful companion read on tightening document control before you formalize the BEP.

Reach out through Aman’s main site to request a BEP review or start a new one from the project’s RFP stage onward.

Sources

BIMForum BxP guidance