Structural Modeling Best Practices: Common Mistakes That Compound Through a Project
November 7, 2026
No Comments
Most BIM teams in the UAE already know the acronym CDE. Far fewer have a Common Data Environment that actually works the way ISO 19650 intends. The standard itself gets plenty of coverage elsewhere — what rarely gets discussed honestly is where real projects quietly get the CDE wrong, usually in the first few weeks of setup, and then live with the consequences for the rest of the job.
This isn’t another “what is ISO 19650” primer. If you need that groundwork, it’s well covered elsewhere. This is a practical look at the specific CDE setup mistakes that show up repeatedly on Dubai and wider UAE construction and infrastructure projects, and what actually fixes them.
This is the mistake that causes most of the others. A project team sets up four folders — WIP, Shared, Published, Archive — inside Autodesk Construction Cloud, Autodesk Vault-style storage, or even just a structured network drive, and quietly assumes the job is done. It isn’t. A folder called “WIP” is not a Work in Progress state unless the process that governs what moves out of it is actually enforced. Create the folder structure, and you’ve built the stage set; you haven’t cast a single actor.
The states ISO 19650 defines are about status, not location. Information earns its way from WIP to Shared through a defined check, and from Shared to Published through a defined approval — not by someone deciding a file “looks done” and dragging it to a different folder. On UAE projects running tight handover deadlines, this distinction gets lost fast, because dragging a file takes ten seconds and running an actual quality check does not.
If there’s one transition that gets quietly skipped more than any other on real projects, it’s this one. A discipline team is behind schedule, a coordination meeting is tomorrow morning, and someone pushes an unchecked model straight into Shared so the rest of the team has “something to look at.” It feels harmless in the moment. It isn’t — because everyone downstream now treats that model as checked information, when it hasn’t actually been checked by anyone.
The fix isn’t a policy memo nobody reads. It’s making the check a structural step the platform itself enforces — a defined reviewer who has to actively approve a status change, not a permission that lets anyone move a file between folders freely. If your current CDE setup lets any team member promote their own file from WIP to Shared with no second person involved, that’s not a minor gap. That’s the control ISO 19650’s CDE states exist to provide, and it’s missing.
Once a container is Published — issued for construction, tender, or client sign-off — it should not be edited in place. If a change is needed, the correct move is to create a new revision and publish that, leaving the original Published container as an accurate historical record of what was actually issued at that point in time.
Editing a Published file directly breaks the audit trail that the whole CDE structure exists to protect. If a contractor built something based on a drawing that was silently edited after issue, and there’s no record of what the drawing actually said on the day it was issued, that’s a liability problem as much as a BIM process problem — and it’s entirely avoidable with disciplined revision control instead of in-place edits.
A clean CDE setup uses two distinct revision series, not one: a preliminary series during design development (commonly P01, P02, P03…) and a separate contractual series once a container is first published for construction (commonly C01, C02…). Running a single continuous numbering series across both phases sounds simpler on day one, but it muddies exactly the distinction a contractor, client, or auditor most needs to see at a glance — whether a given container was ever actually issued as a construction document, or whether it was still in design development when it carries that revision number.
| Revision Stage | Typical Series | What It Signals |
|---|---|---|
| Design development | P01, P02, P03… | Still in progress, not yet issued for construction use |
| First construction issue | C01 | Formally published, suitable for the stated construction use |
| Subsequent construction revisions | C02, C03… | Each supersedes the prior construction-issued version |
ISO 19650’s UK-originated annex requires every information container to carry a unique ID built from an agreed, documented naming convention — project code, originator, volume/system, level, type, role, and number, typically concatenated in a fixed order. The mistake isn’t usually the absence of a naming convention document; most UAE projects have one somewhere in the BIM Execution Plan. The mistake is that nobody enforces it in practice, so three months into a project, half the team is quietly using their own shorthand because the “official” convention was never actually checked against real files being uploaded.
A naming convention that exists only on paper does nothing. The practical fix is making the platform itself validate file names against the agreed pattern where possible, and assigning someone — realistically, your Information Manager or a senior BIM Coordinator — to actually spot-check uploads against the convention in the first few weeks of a project, when bad habits are still easy to correct rather than already baked into hundreds of files.
This runs in the opposite direction from Mistake 5, and it’s just as real: some teams become so focused on getting naming conventions and folder structures exactly right that they treat CDE setup as finished once those two things are sorted, forgetting that ISO 19650 covers considerably more ground — roles and responsibilities, the Information Delivery Plan, security-minded information management, and the operational handover requirements that matter enormously to the client long after the file-naming discussion is forgotten.
A CDE with pristine, perfectly consistent file names and genuinely nobody clearly accountable for approving status changes is not meaningfully more compliant than a messier CDE with proper ownership and checking discipline. If you’re setting priorities under time pressure, ownership and process discipline matter more than naming perfection — though obviously you want both.
A smaller, more mechanical mistake, but one that causes real daily friction: not structuring folders so platforms display them in the intended WIP-to-Archive order (a numbered prefix like 01-WIP, 02-Shared, 03-Published, 04-Archive solves this cleanly), and not segregating access correctly by state. WIP should realistically only be visible to the originating task team; Shared should be visible project-wide for coordination; Published should be accessible to anyone with a genuine need for that specific authorized information, including parties outside the immediate task teams.
Get this wrong, and you either lock people out of information they legitimately need, or — the more common and more damaging failure — leave WIP information visible project-wide, which quietly erodes the entire point of having a WIP state in the first place. If anyone can see unchecked work at any time, the WIP/Shared distinction stops meaning anything in practice, even if it’s still technically configured correctly on paper.
Autodesk itself has published guidance specifically on configuring Autodesk Construction Cloud (formerly BIM 360 Docs) as a genuinely ISO 19650-compliant CDE, and the existence of that guidance is itself a signal worth noting: a platform capable of CDE compliance is not automatically configured for it out of the box. Buying the software is not the same as doing the setup work — assigning folder permissions, configuring approval workflows, documenting the naming convention inside the platform’s actual settings, and training the team on the process rather than just the interface.
This is the mistake behind most of the others on this list, in a sense: the belief that purchasing a capable tool solves a process problem. It doesn’t. It gives you the capability to solve it, which is a meaningfully different thing, and the gap between the two is exactly where most UAE project CDE setups fall short in practice.
On a project where this has genuinely been done right, a few things are visibly true. A named Information Manager (even if that’s one of several hats a senior BIM Coordinator wears on a smaller team) can tell you, for any container, exactly what state it’s in and who approved that status. Nobody can move their own file from WIP into Shared without a defined second person signing off. Published containers are never edited in place — only superseded. File names follow the documented convention consistently enough that a newcomer to the project can navigate it without a verbal explanation from someone who’s been there since kickoff. And when someone in authority asks “is this the current, approved version,” the answer is immediate and unambiguous, not a round of Slack messages and guesswork.
None of the mistakes above tend to happen in isolation on an actual live project. A team that treats folders as states (Mistake 1) is also the team most likely to skip the WIP-to-Shared check under pressure (Mistake 2), because neither problem was ever really about folders — both come from the same root cause: nobody owning the discipline of the process, only the appearance of it. On a typical Dubai multi-disciplinary project with structural, MEP, architectural, and facade teams all publishing into the same CDE, this compounding effect shows up fastest at coordination meetings, where someone presents a clash resolved against a model that, on closer inspection, was never actually promoted through a genuine Shared-state check — meaning the “resolved” clash was never really verified against checked information at all.
The practical consequence is wasted coordination time, which is expensive in a different way than a direct cost overrun, but still real: engineers and BIM coordinators spend meeting after meeting re-litigating issues that a disciplined CDE would have caught and flagged automatically, weeks earlier, before it reached a live coordination session at all.
A CDE can be configured perfectly by a skilled Information Manager and still fail in practice if the wider project team — architects, structural engineers, MEP designers, even client-side reviewers — don’t actually understand why the discipline matters, treating it as an administrative hurdle imposed by the BIM team rather than a shared project control that protects their own work too. This is a training and communication problem as much as a technical setup problem, and it’s routinely underinvested in relative to how much time goes into the initial folder and permissions configuration.
The UAE projects that genuinely run a clean CDE tend to be the ones where this gets addressed explicitly at project kickoff — a short, concrete walkthrough of exactly what happens when a file moves from WIP to Shared, who checks it, and why skipping that step creates real downstream risk, rather than assuming the BIM Execution Plan document alone will communicate this to a busy design team under their own deadline pressure.
CDE setup mistakes are far cheaper to fix in week one than in month six, once bad habits and inconsistent files are already spread across hundreds of containers. If you’re a BIM Coordinator or Manager setting up a new UAE project’s CDE, the realistic priority order is: get the states and the approval process enforced first (not just the folders), get the naming convention validated against real early uploads second, and treat the platform’s configuration options as tools for enforcing both of those, not as a substitute for someone actually owning the process.
Orbit’s BIM Standards / ISO 19650 Compliance course in Dubai works through exactly this kind of CDE setup hands-on, inside real Autodesk Construction Cloud and Navisworks-based project workflows, rather than teaching the standard’s clause numbers as theory. If you already have solid BIM modeling experience and want the information-management discipline that actually separates a well-run project’s CDE from a folder structure with the right labels on it, that’s the specific gap this training closes.
ISO 19650 defines the Information Manager as a distinct role from BIM Manager or Coordinator, but on many UAE project teams, particularly smaller ones, one person wears both hats. What matters is that someone is clearly, formally accountable for CDE discipline — not that the title on their business card matches the standard’s exact wording.
No. The platform can support a compliant CDE, and Autodesk has published specific guidance on configuring it that way, but the setup work — permissions, approval workflows, naming convention enforcement — has to be done deliberately. Buying the software gives you the capability, not the compliance itself.
Deadline pressure causing the WIP-to-Shared check to get skipped. It’s the transition most likely to get bypassed when a team is behind schedule and needs something visible to the wider project team quickly, and it’s exactly the step that protects everyone downstream from treating unchecked work as reviewed.
No — even a small fix should go through a new revision and a fresh publish, not a direct edit of the already-issued container. Editing in place destroys the audit trail of what was actually issued on a given date, which matters if a dispute or liability question ever arises later in the project.
Some widely used suitability codes originated from UK industry practice rather than being spelled out verbatim in the core ISO 19650 text, which only defines the WIP/Shared/Published/Archived states directly. If your project’s Employer’s Information Requirements or BIM Execution Plan specifies a particular coding scheme, follow that document rather than assuming a code set you’ve seen elsewhere is automatically the correct one for your project.
It depends heavily on how far along the project is and how many containers already exist with inconsistent naming or unclear status history. Fixing the process going forward — enforcing the WIP-to-Shared check, correcting folder permissions — can happen within days. Retroactively cleaning up hundreds of already-inconsistent legacy files is considerably slower and is exactly why catching these mistakes in the first few weeks of a project, rather than months in, matters so much.
The scale of the formal setup can reasonably be lighter on a small project, but the core discipline — someone owning approval status, no editing Published files directly, a documented naming convention that’s actually enforced — holds value at any project size. The mistakes on this list cause real confusion and rework even on small teams; they just take longer to compound into a visible problem.