Buying a common data environment does not give you a common data environment.
The licence is paid. The platform is live. Everyone has a login, the folder structure looks reasonable, and somewhere in your office right now, someone is emailing a drawing to a colleague because it is faster than explaining where to find it.
That last part is the tell.
I spent ten years doing this before I started teaching it.
I worked as a BIM coordinator and Manager on various AEC projects from hospitals to metro lines. I hold the Information Management Practitioner certification, which mostly taught me how wide the gap is between what ISO 19650 says and what companies actually do.
Then I did something more useful than any of that.
I sat down with 20 BIM managers, information managers and digital leads and asked one narrow question: why doesn’t your CDE work? They gave me 240+ separate problems. When I sorted them, 116 had nothing to do with software features. They were about who decides, who approves, who is allowed, and what happens when nobody checks.
This article is about those 116.
Six questions that tell you what you actually have
Here is a test you can run in the next ten minutes.
Pick a live project. Pick one drawing that matters. I mean something that has been issued to a client or a contractor.
Now try to answer these six questions using only the platform, with no phone calls and no asking the person who made it:
- Which version of this is approved for construction?
- Who approved it, and when?
- What changed between this revision and the last one?
- Who can see this folder, and who can upload into it?
- Where is the record that this was formally sent to the client?
- If I am a new starter, how would I know any of this without asking?
- If you can answer all six in under a minute, stop reading. You have a working system and you do not need me.
Most people in can’t answer three.
And I don’t want to criticse anyone here. It is just a a description of what happens when a Common Data Enviroment platform gets deployed without a decision layer underneath it.
This isn't a training problem
The most common response to the test above is “we need more training.”
It is almost never true.
Think about how the platform arrived in your company. Autodesk sold you licences, because that is what Autodesk sells. A reseller ran a configuration and training package, often a few hours, sometimes half a day. Someone set up a folder structure, some permission logic. Then everyone went back to their deadlines.
Nobody in that chain was ever paid to answer the hard question.
The hard question isn’t “where do I click to upload.”
It is “who in this company has the authority to declare a piece of information reliable, and what has to happen before they do.”
No reseller can answer that for you. It is a decision about how your business works, and it has to be made by people inside your business.
So it never gets made.
And because it never gets made, the platform fills up with files that are technically in the right place and functionally meaningless. So basically you have a repository. You do not have a common data environment.
The difference between those two things is the whole subject of this article.
What the standard actually asks for
ISO 19650 is often described as the reason companies buy a CDE.
That is backwards.
The standard makes a distinction that most implementations quietly ignore: it separates the workflow from the solution.
The workflow is the managed process by which information gets produced, checked, shared, approved and archived. The solution is the technology that hosts it. The standard asks for the first one. The second one is just the container it runs in.
Read that again, because it explains almost every failed rollout you have seen.
Nobody fails at buying software. Companies fail because they buy the CDE (container) and never build the process that is supposed to live inside it. Then, when the CDE doesn’t deliver, they blame the container.
So what does a real CDE need? Five things, and none of them are features:
- Controlled states. Information moves through defined stages: work in progress, shared, published, archived – and moving between them is an event, not a drag-and-drop.
- Access based on role. Who can see, edit, upload and approve is decided by what someone does, not by who asked loudest.
- Metadata discipline. Every file carries the information needed to understand what it is, what it is for, and whether you are allowed to rely on it.
- Review and authorisation gates. Something has to happen, inside the system, before information becomes reliable.
- An audit trail. You can prove who did what, when, without asking anyone.
Notice that all five are decisions.
You can implement every one of them badly in excellent software, and I have watched companies do exactly that.
8 signs you are running an expensive network drive, not CDE
These came out of the interviews. See how many you recognise.
1. You have WIP, Shared and Published folders, but no rules about who moves things between them. The folder names are borrowed from the standard. The behaviour underneath is not. This is the single most common form of surface compliance in the industry.
2. Project Admin rights have been handed out widely. Usually with the reasoning “so people can actually work.” The result is permission drift, accidental deletions, and nobody able to say who changed what.
3. Publishing means copying a file to another folder. Which means the same document now exists in three places, and within a month nobody is sure which one is real.
4. Approvals happen in email. The upload is in the platform. The decision that makes it meaningful is in someone’s inbox. Your audit trail has a hole in the exact place where it matters.
5. Every project is set up differently. Eight of my twenty interviewees said this about their own company. Same firm, same tools, five different folder structures, because there is no template and everyone copies the last project they worked on.
6. Naming rules exist in a document nobody opens. Or worse, they were enforced in the middle of a live project and blocked people from uploading, so someone quietly turned them off.
7. “Latest version” is treated as “approved version.” The platform versions files automatically when you upload something with the same name. That tells you a file is newer. It tells you nothing about whether you are allowed to build from it.
8. Nobody has ever audited who has access to what. Access was set once, at project setup, by someone who has since moved to another project.
Three or more of these and you are not running a CDE.
You are running shared storage with a governance costume on.
It isn't that your people are undisciplined
This is the part most implementation plans get wrong.
When I asked what actually blocks change, the same answer came back from most intervies that I made.
People have a working way of doing things, and their first reaction to new rules is refusal. Not sabotage. Not laziness.
Just the entirely rational preference for the way that gets today’s deadline met. Under deadline pressure, the familiar way always wins.
Which means an argument like “this is better for the organisation” does nothing.
Nobody has ever changed how they work on a Thursday afternoon because it was better for the organisation. The benefit has to be visible from the point of view of one person doing one task: this saves me a step, this stops me getting blamed, this means I stop being asked where the file is.
If your CDE implementation process can’t pass that test, it will hold for about three weeks.
Then it will quietly stop being followed, and the person who introduced it will get a reputation for making work harder. I have watched capable BIM managers burn a year of credibility this way. The rules were correct. The rollout ignored how humans behave.
Where you actually are: three levels
Most companies place themselves higher than they are, so be honest here.
Level 1: Storage. The platform is used for uploading and finding files. Permissions are ad hoc. Naming rules are aspirational. Approval of documentation happen outside the system. So the the structure exists, the behaviour doesn’t.
Level 2: Partial control. Project templates exist. Naming standards are enforced in the folders that matter. Reviews and formal issues run inside the platform. There is a defined owner. What is missing is consistency across projects, and any way to measure whether it is working.
Level 3: A managed system. New projects start correctly by default. Authority to publish is explicit and limited. Permissions are audited on a schedule. And critically, you can show a director, in numbers, what changed.
Almost everyone reading this is at Level 1 and believes they are at Level 2.
The gap between 1 and 2 has nothing to do with technology and software. It is roughly a dozen decisions about infomrmation managmenet that nobody has been given the time or the mandate to make.
The test to run this week
Do not start with a strategy document.
Take 20 documents that have been issued from a live project in the last three months. For each one, check four things:
- Does it have a status code that means something specific?
- Does it have a revision code that distinguishes preliminary version from contractual version?
- Is there evidence, inside the platform, that someone authorised it?
- Is there a record of who it was formally sent to, and when?
Count how many pass all four.
In the conversations I’ve had, the number is usually somewhere between two and five out of twenty. This is an impression from interviews, so treat it as a rough expectation, not a benchmark.
Then take that number to your director. One sentence: out of twenty documents we have issued to clients this quarter, X have a complete, provable chain of approval.
That sentence does more than any maturity assessment I have ever produced.
What's coming next
This article was the diagnosis.
The next articles goes deeper on the question that costs the most money: which version is current, and who approved it. I’ll map the ISO 19650 concepts: information containers, suitability, status and revision – onto the specific controls inside Autodesk Forma (formerly Autodesk Construction Cloud) that actually enforce them.
Naming standards, status and revision codes, the Holding Area decision, packages instead of copies, and why reviews and transmittals are the two features most companies own and never switch on.
Before you go: the number your director will ask for
Here is a question worth answering before someone else asks it.
How many of the licences you are paying for were actually used last month? Not assigned, used. In most companies nobody has ever checked, and the answer tends to be uncomfortable.
I am putting together a 90-day implementation programme called the CDE ROI Accelerator for design offices that already own the platform and know it is not delivering. First cohort runs most probably in February 2027, and it is limited to 10 companies.
If the six questions at the top of this article made you uncomfortable, join the waitlist here: https://cderoiaccelerator.com/
Thanks for reading
If so, I am pretty sure you will like my CDE ROI Accelerator Newsletter.
Every Tuesday, I’ll send you practical insights that help reduce waste, errors, and delays caused by messy project information.
