Despite Uniclass 2015 being applied to UK and Irish projects for some time now, it is often overlooked just how useful it can be. Many teams still see it as an added burden or something to reference only when asked, but in practice it has real value when used consistently across information management workflows.
The Case for Standardisation
One of the biggest challenges in information management is that everyone wants to follow a standard, but they often want it to be their own preferred system. Architects might push for the file structures they’ve always used, engineers may prefer internal codes, and contractors often come with their own numbering. The result? A patchwork of systems that undermines collaboration.
Uniclass isn’t perfect. No classification system is. But it’s the common language we’ve got — and it should be used to standardise projects to one agreed system. By doing so, we can eliminate confusion and ensure that the same codes carry through from responsibility allocation all the way to information handover.
Understanding the PM Codes (Project Management – PM)
Uniclass 2015 is split into multiple tables (entities, systems, products, activities, and so on). For information deliverables and day‑to‑day project governance, the PM (Project management) table is the anchor. It’s deliberately structured to follow the lifecycle of a project, from client briefing through to operation and asset management. Here’s how the top‑level PM groups are organised and how I use them in IM workflows:
- PM_10 – Project information: Early‑stage material such as client requirements and high‑level project information. (Includes groupings like PM_10_10 Project, PM_10_20 Client requirements, PM_10_80 Space management requirements, PM_10_90 Transport management requirements.)
- PM_30 – Site, ground and environmental information: Baseline surveys and existing information, e.g., site surveys, ground investigation, environmental/wildlife reports, hazardous substances, building/fabric and services condition surveys.
- PM_35 – Project performance requirements: The project’s performance brief, covering quality/operational properties, structural, fire, sustainability, safety, acoustics, and energy performance requirements.
- PM_40 – Design and approvals information: Core design outputs and approvals artefacts — design strategies, calculations, design information, design models, design drawings (PM_40_40), specifications, approvals information, schedules, and project information management information (PM_40_60) that touches directly on CDE practice.
- PM_50 – Financial and commercial information: Commercials, viability, and procurement/tendering information.
- PM_55 – Contract information: Contract compliance information and contract documents.
- PM_60 – Construction management information (also known as General requirements / Project management & coordination): Site information, project requirements, construction models, programme/progress, meetings & records, cost management, contract support information, construction risk management, and quality standards.
- PM_70 – Testing, commissioning and completion information: Compliance/certification, testing, commissioning, completion, record information, and project assurance.
- PM_80 – Asset management information: Strategy & planning, maintenance, comms & engagement, impact assessments, life‑cycle cost, training, personnel, emergency strategy, and asset risk management.
Other Uniclass tables (e.g., Ss Systems, Pr Products, Ac Activities, RK Risk, FI Form of information) are highly relevant but outside the focus here. I’ll cover those in a follow‑up post so this piece can stay centred on the PM table and document‑centric deliverables.
Linking Information Management Workflows
Where Uniclass becomes powerful is when you use it as the thread between your key information management processes:
- Responsibility Matrix
For example, I can list PM_40_40 : Design Drawings and assign responsible parties. That simple code immediately clarifies who is accountable for producing design drawings. - Task Information Delivery Plans (TIDPs)
I then ask teams to ensure that their TIDPs use the same PM_40_40 code for design drawings. This creates alignment between planned deliverables and responsibilities. - Common Data Environment (CDE)
Finally, I check that the information has actually been issued to the CDE under the same code. This closes the loop: what was required, what was planned, and what was delivered all match.
Why PM Codes Are Often Overlooked
Many teams focus on Ss (systems) and Pr (products) when delivering asset data, especially for COBie. While those are important, the PM table provides the scaffolding for project management deliverables. Without it, there’s often confusion about what exactly is required and when. By embedding PM codes into the responsibility matrix and aligning them with TIDPs, teams can ensure that nothing slips through the cracks.
Beyond the Codes
Using Uniclass isn’t just about memorising long strings of numbers. It’s about creating a consistent reference system that flows through multiple tools and documents:
- Linking codes to MIDPs for progress reporting.
- Mapping to COBie fields to keep asset data consistent.
- Supporting audit trails by showing that the same requirement has been tracked across the project lifecycle.
Even if the codes feel abstract, the consistency they provide allows information managers to connect the dots between different deliverables and processes.
Conclusion
Uniclass 2015 may not be flawless, but it’s far more useful than many give it credit for. By treating it as the common thread across responsibility matrices, TIDPs, and CDEs, we can standardise projects, reduce misunderstandings, and deliver information that is easier to validate and hand over. Rather than dismissing it as just another requirement, it’s time we saw Uniclass for what it really is: a practical tool that helps us bring order to the complexity of BIM Information Management.
This article has focused on the PM codes because they tie directly to project deliverables. Other Uniclass tables — covering systems, products, activities, and more — deserve their own deep dive, and I’ll explore those in future posts.
Coulter BIM Information Management 
Leave a comment