ISO 19650 · Common data environment

A CDE is a workflow, not a folder.

Almost every project has somewhere to put files. Far fewer can say what has to be true before a file moves from one place to the next, who decides, and what the file is called when it gets there. That difference is the whole of what ISO 19650 means by a common data environment.

Part of the ISO 19650 toolkit.

Four states, and what it takes to leave each one

ISO 19650-1 describes the CDE as a managed process, not a piece of software. Every information container sits in exactly one of these states, carries a status code and a revision, and moves only when somebody holding a named role says it can.

01

Work in progress

The task team’s own space. Information is generated here and is visible to the team producing it and to nobody else. Nothing leaves without a quality-assurance check against the project’s information standard — naming, format, metadata — and a review by whoever is accountable for that team’s output (5.6.3, 5.6.4).

02

Shared

Visible to the whole delivery team, for coordination rather than for construction. This is where federation happens, and where the other task teams find out what you have been assuming about them. A container here is checked but not authorized: rely on it to coordinate a design, not to make a decision the appointing party will pay for.

03

Published

Authorized by the lead appointed party, then accepted by the appointing party (5.7.2, 5.7.4). Published information is the version the project acts on, so the gate is the entire point — somebody reviewed it against the exchange information requirements and put their name to it. A CDE that lets a container arrive here without that has three states and a label.

04

Archive

Every superseded revision, kept with its audit trail rather than deleted, and the state most projects skip. It is the one that matters at close-out (5.8.1): the record of who authorized what and when is what makes the asset information model defensible years later, when the question is no longer what was built but why.

The client establishes it. The delivery team has to live in it.

Under ISO 19650-2 the CDE is a clause 5.1 activity — 5.1.7, establish the project’s common data environment — which puts it with the appointing party, before the invitation to tender goes out. What each side then owes the other is the part most projects leave implicit until it gets expensive.

Appointing party

What the EIR has to specify

The CDE is yours to establish, and the EIR is where the supply chain finds out what it will be. A requirement that names a product and stops is a requirement nobody can price. The EIR Health Check scores a whole section on this one.

Clause 5.1.7 · issued with the tender

  • The platform, or the criteria for approving one — and whether the supply chain is expected to bring its own
  • The four states by name, with the status and revision codes a container carries in each
  • Who authorizes a move between states, by role rather than by person
  • The naming convention in full, with a worked example rather than a pointer to an annex
  • Access and permissions, including whatever a security-minded approach makes you decide about who can see what
  • What happens at close-out: what is archived, in which format, and who holds it afterwards
Score your EIR against this

Both documents name a common data environment. Neither states the naming convention, the status codes, or who approves a transition — so the platform arrives, and the governance never does.

What people actually ask

Is SharePoint a CDE?

It can be, and so can a purpose-built platform — neither is one out of the box. What makes a CDE is the workflow: the four states, a naming convention applied to every container, status and revision codes, an approval gate with a named role behind it, and an audit trail that survives somebody leaving the project. Any tool configured to do that qualifies. Any tool used as a shared drive does not.

One CDE, or one per organisation?

One project CDE, established by the appointing party. Task teams commonly keep their own work-in-progress space inside their own systems and ISO 19650 allows for it — work in progress is by definition not shared. What cannot be split is the shared, published and archive part: two published states is two versions of the truth, which is the failure the standard exists to prevent.

Who pays for it?

The appointing party establishes it, which usually means procuring it. What matters more commercially is that the EIR says so before the tender goes out. A delivery team pricing a bid without knowing whether it is bringing a platform or paying for seats on somebody else’s is pricing a different job from the one it is bidding for.

We are mid-project and none of this was set up. Now what?

Start with the state a container is in, not with the platform. Write down what is genuinely published — authorized, accepted, being built from — and separate it from what is merely shared. That one distinction closes most of the gap and needs nothing migrated. The platform question comes after it, and is usually smaller than it looks from here.

Where does this sit against the rest of ISO 19650?

Upstream of almost everything. The CDE is established in clause 5.1, before the EIR is written; it is tested at mobilization in 5.5; every exchange in 5.6 and 5.7 is a transition between its states; and 5.8 archives what is left. The ISO 19650 hub draws the whole of clause 5 as an interactive figure, if you want to see where a given activity falls.

Score the document you actually have

Both diagnostics run in your browser and end in a report you can hand to somebody else. If the CDE section is where yours scores worst, that is a half-hour conversation rather than a project.

info@noeinsolutions.com