CDE: the most common mistakes firms make when starting out

The CDE — common data environment — is probably the most cited and the least well implemented building block of ISO 19650. Many firms think they have one as soon as they use a shared cloud such as Drive, SharePoint or BIM 360. In reality, having a shared storage space and having a CDE in the sense of the standard are two different things: the first organises files, the second organises the lifecycle of information, with rules that apply the same way across every project. Here are the mistakes that come up most often on the ground.

Mistake #1 — mistaking a shared folder for a real CDE

A shared folder organises files; a CDE organises a lifecycle of information.

A shared cloud folder, however well organised, is not a CDE as long as it enforces no rule on the state of the files it contains. The difference shows up in a very concrete case: in a simple shared folder, an “up to date” file and a file “still being modified” sit in the same place, with the same visibility for everyone. An external party who opens the wrong file — an unapproved version rather than the published one — can base a whole work package on incorrect data, with no warning at all. That is exactly what a CDE's structure is meant to prevent.

Mistake #2 — workflow statuses that exist on paper, not in practice

Most firms who have heard of the standard know the four expected statuses: Work in Progress, Shared, Published, Archived. The problem is almost never ignorance of these statuses — it is their actual application. A “Published” folder that in fact contains files never formally approved by their author empties the system of its meaning: other disciplines trust that status to base their own work on it, and that trust is exactly what collapses first once the status stops meaning anything.

• Files in “Work in Progress” consulted and used by other disciplines as if they were approved
• A “Shared” status used as a simple drop box, with no review before moving to the next status
• A “Published” status that is never moved to “Archived” when the next version is published — several “published” versions coexist, and nobody knows which one is authoritative
• Statuses applied differently from one project to another depending on the project manager, for lack of a written, shared rule

Mistake #3 — no naming convention

A CDE with no consistent naming convention remains a storage space that looks well organised but becomes unreadable in practice as soon as the number of files goes past a few dozen. ISO 19650 recommends a segmented file-name structure — project, originator, volume or system, level, document type, number, revision — precisely so a file can be identified without opening it, and so automatic sorting or filtering remains possible even with hundreds of documents. Without this convention, each party names files their own way, often perfectly clear to themselves and opaque to everyone else. The cost does not show up right away; it appears six months later, when you have to find the latest version of a drawing among forty similarly named, undated files.

Mistake #4 — undifferentiated access rights

Many CDEs set up quickly give everyone the same level of access — architects, engineering consultants, contractors, the client — to avoid the complexity of managing different permissions. That shortcut is costly on two fronts. The first is information security: a subcontractor who leaves the project partway through sometimes keeps full access to data unrelated to their package. The second is clarity: when everyone can modify anything anywhere, workflow statuses lose part of their point, since nothing really stops a “Published” file from being modified by mistake by someone who should not be touching it.

Mistake #5 — a CDE with no one responsible for its rules

The last mistake is the most structural: setting up a technically correct CDE without naming who is responsible for keeping its rules alive day to day — approving status changes, checking the naming convention, adjusting access rights as the project moves forward. Without this role clearly assigned (often the information manager or the BIM Manager, depending on firm size), a CDE well designed at project kick-off gradually degrades, as each party drifts back to individual habits for lack of any check.

Where to start to fix it

Fixing a poorly started CDE does not require rebuilding everything at once. The firms that improve fastest almost always start with the same four steps, in this order, rather than trying to tackle everything at the same time.

• Formalise a short naming convention (even a minimal one) and apply it on the next project that starts, without waiting to fix ongoing projects
• Actually enforce the four workflow statuses on at least one pilot project, with a review before each move to the next status
• Differentiate access rights at least between internal and external parties, before refining it project by project
• Name a person responsible for the CDE, even part-time, whose role is explicitly recognised by the rest of the team

These four steps require neither extra software nor a big budget: what they mainly require is consistency. This is in fact why the CDE is often the fastest theme to improve in a maturity diagnostic — unlike training or BIM culture, which take time, a well-structured CDE can change within a few weeks if the right rules are set and upheld.