If you've ever reviewed a BIM Execution Plan submitted with a tender and come away with a vague sense that it looked professionally formatted but didn't actually tell you how the project would run day to day, that instinct is worth trusting - because a BEP written to satisfy a tender requirement and a BEP that genuinely meets ISO 19650's intent are, in a meaningful share of Indian submissions, two very different documents wearing the same title.
This gap matters because the BEP is meant to function as the operational rulebook for how a project's information actually gets created, managed and exchanged between every party involved. A generic, tender-focused version leaves exactly the questions unanswered that tend to surface as disputes a few months into execution, once real coordination work has started and the document's vagueness stops being a formatting issue and starts being an operational one.
Where the Gap Between Requirement and Practice Actually Shows Up
| ISO 19650 BEP requirement | What's typically actually submitted |
|---|---|
| Defined information delivery milestones tied to project stages | Often present but generic, not tailored to the specific project's actual design programme |
| Named roles and responsibilities (Information Manager, Task Team roles) | Frequently thin - roles listed by title without clear individual accountability |
| Federation strategy and model ownership per discipline | Often missing or vague, leading to ambiguity resolved informally once the project starts |
| Volume strategy, coordinate system and naming conventions | Usually present, since these are the most commonly templated elements |
| Risk register specific to information management (data loss, software compatibility, resourcing) | Rarely included in Indian tender submissions, even though ISO 19650 expects it |
Why the templated sections survive and the tailored ones don't
A generic BEP template gets reused across tenders considerably faster than a genuinely project-specific one gets written from scratch, which is exactly why the sections requiring real tailoring - milestone definitions matched to the actual design programme, named accountability rather than generic role titles - are precisely the ones most commonly left thin or copied wholesale from a previous, differently structured project. Clients evaluating tenders rarely have the internal BIM expertise to distinguish a genuinely tailored BEP from a well-formatted generic one at first read, which reduces the competitive pressure on bidding firms to actually close this gap, since the reward for doing the harder work of proper tailoring isn't always visible at tender stage.
The pre-appointment versus post-appointment confusion
ISO 19650 draws an explicit distinction between a pre-appointment BEP - submitted at tender stage to demonstrate a bidder's capability and proposed approach - and a post-appointment BEP, which is meant to be the detailed, agreed working document once a firm is actually awarded the project. Indian practice sometimes conflates these two, treating the tender-stage document as the final word rather than developing it further once the project is genuinely underway. The practical consequence is a project that never actually gets a working BEP in the ISO 19650 sense - only the marketing version that won the tender, which was never built to be operationally followed in the first place.
A Scenario Where This Gap Becomes a Real Problem
Picture a mid-size consultancy that wins a hospital project specifically on the strength of a well-written, ISO 19650-referencing BEP submitted at tender stage. Once the project starts, the same document is filed away as "complete" rather than developed into the detailed, post-appointment working version ISO 19650 actually envisions. Three months into design development, a disagreement surfaces between the structural and MEP teams about who owns responsibility for coordinating a particularly dense mechanical riser zone - a disagreement that a properly developed federation strategy, naming specific model ownership boundaries, would have pre-empted entirely. Instead, the ambiguity gets resolved informally and somewhat contentiously in the moment, exactly the kind of friction the BEP was supposed to prevent, and exactly the kind of gap that traces directly back to treating the tender-stage document as sufficient rather than building it out into a genuine working plan.
What Closing This Gap Actually Requires
Closing the gap between a tender-compliant BEP and a genuinely operational one doesn't require an especially sophisticated process - it requires treating the document as one the team will actually use daily, not a compliance artefact. That means naming specific individuals against specific decision rights rather than listing job titles generically, developing a federation strategy that explicitly assigns model ownership zones before modelling starts rather than leaving that to be worked out informally, and including an honest information management risk register that acknowledges the practical risks - software version mismatches, key team member turnover, resourcing gaps during peak coordination periods - that ISO 19650 expects to see addressed and that Indian tender submissions most consistently omit.