inSIGHTS BIM Execution Plans: Towards a One‑Page Communication Backbone
How trimming the fat and focusing on precision, coordination, and real‑world workflows turns a static PDF into a living playbook. By Matt Sweeney, Kristopher Dane, Margaret Sullivan-Miller, and the Structural Engineering Institute Committee on Digital Design
A
sk a room full of structural engineers about the BIM Execution Plan (BEP) for their most recent project and you’ll spot the same grin: “Yeah … I think it’s on the server.” We all inherit PDFs that dictate line weights and sheet numbers, yet day‑to‑day coordination still happens in chat threads and late‑night “Where’s the latest model?” emails. The result is wheel‑spinning, confusion, and too often, rework. A BEP should be less a rule book and more a communication backbone—the shared resource where decisions land, questions sur‑ face, and responsibilities stay crystal clear. When it works, information flows smoothly from engineer to architect to contractor; when it doesn’t, we chase our tails hunting versions, debating model precision and con‑ tents, and reopening settled questions. In a breakout discussion at the 2025 SEI Structures Congress called “BEP Musical Chairs,” engineers from across the country representing firms of various sizes and specialties traded war stories. Within min‑ utes the attendees realized they were not short on BEP templates; they were short on BEP templates that spark productive dialog and stick around as useful tools for the remainder of the project. The fix for this issue isn’t fancy tech—it’s slimming the plan so that it’s opened and used as an organizing tool for making key decisions and prioritizing effec‑ tive communication.
Seven Pain Points Every Engineer Recognizes The discussion at the Structures Congress recognized seven main pain points: 40 STRUCTURE magazine
1. Template Overload: Most firms have a BEP template, but it dives into font sizes and colors before it explains how engineers and architects will synchronize models. The docu‑ ments were originally built by technologists to explain the computer programs/applications when BIM was new to the industry. As the design process evolved to more readily utilize BIM, the BEP template must also evolve to more readily focus on the human issues and big‑picture questions like who sends what, when, and through which channel or else we get buried under layer standards or matrices that nobody ever looks at. 2. Contractual Blind Spot: Rarely are BEPs tied directly into the contract, which makes adherence difficult. The people draft‑ ing or debating the plan often aren’t aware of the BIM language in the owner-architect or architect-engineer agreements. This dis‑ connect means teams end up committing to
workflows that may not align with contractual obligations, often setting up conflicts down the road. Clear communication, simplifica‑ tion, and compelling reasons to follow the plan become essential when enforcement isn’t guaranteed. 3. Undefined Model Consumers: As engineers, we sometimes argue LOD (Level of Development) 350 vs 400 before asking who is going to use the model and for what purpose. Sometimes, the wrong people end up having these conversations (people who may not be fully cognizant of the details of a specific project, and as such what’s needed from the model). Before we can determine the specific level of development of a column, we need to know who will do what with that column. Estimators? Fabricators? Code reviewers? Without that conversation, we unnecessarily over‑detail and at the same time miss communicating critical parameters. We also have model conversations when we could and should be having scope and value conversa‑ tions. The right people need to have the right conversations at the right time in order to fully and effectively determine scope, value, and implementation. 4. Version & Change Whiplash: New uploads can arrive with cryptic file names, and design tweaks can slip through silently. Sometimes it feels like every download becomes a detective hunt, and seemingly small issues snowball into RFIs. New(ish) platforms may be configured so there isn’t a need to have a conversation about a model “release,” and instead the model is treated as a continuously updated object (which sometimes just doesn’t work). Engineers shouldn’t be having a conversa‑ In this Risk/Reward Matrix for BIM Execution, the bottom right section is the goal, but oftentimes engineers can end up in the upper left quadrant. tion about configuring an online