Common Data Environments: when SharePoint is enough and when it isn't

A CDE is the single, controlled source of truth for project information. Drawings, models, specifications, RFIs, variations, RAMS, snags, handover documents. Every party on the project sees the same current version, with a clear status (Work In Progress, Shared, Published, Archived) and a clear audit trail.

The standard that defines this in the UK is ISO 19650, which carries forward from BS 1192. The standard doesn't mandate a particular tool. It mandates a set of behaviours, naming conventions, statuses and approval flows. Any tool that can support those behaviours can, in principle, be a CDE.

Smaller contractors, tighter project teams, and contracts that don't mandate a specific CDE can get a long way with a properly designed SharePoint estate. Metadata-driven libraries, versioning that's actually used, status fields that match ISO 19650, retention labels, and an information manager who owns the structure.

The key word is 'designed'. SharePoint at default settings is not a CDE. SharePoint with a deliberate information architecture, naming convention, metadata model and trained users absolutely can be. Several mid-sized contractors run dozens of projects this way and pass audits comfortably.

Large multi-disciplinary projects, BIM Level 2 obligations, and tier-one demands generally push you to a dedicated CDE. Procore, Aconex, Asite and Viewpoint For Projects have specific workflows for transmittals, RFIs, federation of BIM models, and the kind of cross-party review and approval that gets unwieldy in SharePoint above a certain scale.

If the project is using Revit and Navisworks heavily, with multiple external designers federating models, a dedicated CDE will save weeks of pain. If the tier-one mandates Aconex, you don't have a choice, and trying to mirror everything into SharePoint as well is a recipe for two diverging records.

Many contractors end up with both: a dedicated CDE for tier-one projects and SharePoint for everything else. That's fine in principle, but it creates a different problem: where does anything live, and who decides?

The pragmatic fix is to be explicit. Define which project types go on which platform, write it down, and make sure new project managers know before they start setting up folders. Don't leave it to taste.

Even if you eventually move to a dedicated CDE, the SharePoint hygiene work doesn't go to waste. Information architecture, metadata, naming conventions and access control discipline travel with you. The platform changes; the habits don't.

Conversely, bolting a dedicated CDE onto an organisation that hasn't done that hygiene work usually fails. The new tool inherits the old habits, the project teams resent it, and the CDE becomes 'where we put the documents the tier-one asks for', with the real work continuing on email and OneDrive.

Most contractors don't have a dedicated information manager. The role gets shared between a senior engineer, a project manager and an administrator, none of whom have it as their main job. The result is predictable: the CDE drifts, the metadata gets sloppy, and the audit trail develops gaps.

Larger contractors increasingly hire dedicated information managers per project. Smaller contractors can't justify that and end up either using a managed CDE service (where the platform vendor or a partner provides the role) or building the discipline into the project manager's responsibilities explicitly.

Whichever platform you end up on, the marker of a good CDE practice is the same. Anyone can find the current version of any document in under a minute. Nobody is unsure which version is the latest. The audit trail holds up under a JCT dispute. Tier-ones don't complain.

That's the standard. The tool is a question of scale, contract type and budget. The discipline isn't.

Whichever platform you land on, the difference between a CDE that works and one that doesn't is usually training. Not a one-off induction. Ongoing, role-specific training: how a quantity surveyor uses it, how a site engineer uses it, how the design team uses it.

A short refresher when someone joins, a quarterly drop-in for questions, and a clear escalation when someone is stuck does more for the audit trail than any product feature. The investment is modest and pays back every time a tier-one runs a document audit.