Construction Competency Matrix: Building One That Holds Up

It usually starts with a pre-qualification questionnaire or a client's competence clause: "Please provide your competency matrix for the operatives and supervisors proposed for this package." Someone exports the training spreadsheet, tidies the column headers and sends it. A few weeks later the client's consultant comes back with a sharper question: which of these people are competent to install this system, on this building, and how did you decide?

What's Actually Being Asked

Part 2A of the Building Regulations 2010, in force in England since 1 October 2023 (subject to transitional arrangements), requires anyone carrying out design or building work to have the skills, knowledge, experience and behaviours necessary to do it, and requires organisations to have the appropriate policies, procedures, systems and resources to carry out the work in compliance with the relevant requirements. Anyone appointing a designer or contractor must take all reasonable steps to satisfy themselves that the people they appoint are competent, and people still in training must be adequately supervised. On higher-risk building work, the steps taken to check competence on appointment have to be recorded in writing.

The regulations do not prescribe a matrix or any particular format, although on higher-risk building work the competence checks must be recorded in writing. Either way, a client or principal contractor taking "all reasonable steps" will ask how you define competence for the work you do, and how you check people against that definition. BS 8670, BSI's core criteria for building safety competence frameworks, points the same way: competence should be defined against the role and the work, and assessed against that definition, rather than inferred from a list of courses. A competency matrix is simply the written form of that definition. The question behind the request is whether yours is one.

The Evidence That Answers It

A matrix that holds up is really two documents that a typical training spreadsheet merges into one. The first is the framework: what competence each role needs for each operation. The second is the register: where each person stands against that framework, and on what evidence. The framework should carry:

• Operations, not courses, down the side: the activities that matter on your work, split by system where the system changes the risk. "Install cavity barriers, system X" is a row; "fire awareness training" is evidence for a row.
• Roles across the top: operative, supervisor, assessor, designer, package manager, with the operations each role is expected to carry out, supervise or sign off.
• The four elements in every cell: the skills, knowledge, experience and behaviours required for that operation in that role, written as things that can be checked, such as a named qualification, manufacturer's system training, a number of supervised installs, or an observed assessment.
• Levels: a small, fixed scale, for example in training and supervised, competent to work unsupervised, competent to supervise, competent to assess. Every person sits at one level per operation, never "partly".
• The evidence each level needs: what an assessor must see before moving someone up a level, so two assessors reach the same decision on the same facts.
• Review triggers: a review date, plus the events that force an earlier review: a new system, a changed method statement, a quality failure, a long gap since the person last did the work.
• A version and an owner: who approved the framework, when, and what changed from the last version.

The register then records, per person and per operation: the level, the date it was granted, the assessor, the evidence relied on, the framework version it was assessed against, and the date it lapses or falls due for review. That is the record a client's consultant can test, and the one that answers the sharper question.

Why the Spreadsheet Version Fails

The usual spreadsheet has names down the side and courses across the top, with expiry dates in the cells. It is a list of certificates, not a definition of competence. It cannot say which operations a course qualifies someone for, so the decision that a person can install a given system lives in a supervisor's head. It has no assessor column, so nobody can say who made that decision or on what evidence. Renewals are typed over old dates, so the history is lost. Copies drift: one version in the office, another attached to last month's tender, a third in a site manager's email, and the certificates themselves scattered across a shared folder and people's phones. Asked "how did you decide?", the spreadsheet has no answer, because no decision was ever recorded in it.

Keeping It Provable

The framework changes slowly and deliberately; the register changes every week. Treat them that way. Version the framework, and when it changes, assess people against the new version rather than silently editing the old one. In the register, make every change a new dated entry: a level granted, a level withdrawn, a certificate renewed. Nothing is overwritten, so the matrix can show where a person stood on any past date as well as today.

Then connect the register to the work. When people are allocated to operations at a location on the building, the allocation should check their level for that operation before the shift, and the inspection sign-offs and photographs for that location should carry the names of people who were within scope when they did the work. A matrix that only lives in the office answers the pre-qualification question. A matrix that is checked at the point of allocation, and kept against the building, also answers the questions that come years later.

The Monday Checklist

1. List the ten operations on your current work where a competence failure would matter most to building safety or quality. Those are your first rows.
2. For each, write what an operative, a supervisor and an assessor must have, as checkable evidence, across skills, knowledge, experience and behaviours.
3. Agree a level scale of no more than four steps, and define the evidence needed to move up each step.
4. Name your assessors, and record each one's own level for the operations they assess.
5. Split your existing spreadsheet: certificates become evidence in the register, not columns in the framework.
6. Give the framework a version number and an owner, and stop editing dates in place: renewals and changes become new entries.
7. Test it: pick one operative on one live package and show, from records alone, their level for each operation they did last week and who granted it.

Where BrieXO Fits

In BrieXO, competence records sit in the FIELD bundle, which is live today. Its competence app, XO Comp, holds role frameworks and person scopes, with evidence reviews, training plans, CPD and verification links. XO Comp produces eligibility signals for site readiness, and XO Time includes eligibility checks alongside labour time capture; both sit in the same bundle as the daily site records and QA/ITP checks. It does not decide whether someone is competent: that judgement stays with your assessors, against your own framework. It supports your competence duties; it doesn't discharge them. The detail is on the XO Comp page.

Related reading:SKEB in practice: skills, knowledge, experience, behaviours, competence on the day: proving who was competent, and Building Safety Act dutyholders and who signs what.

George Sfica is a senior design manager at a specialist façade contractor, with 23 years in manufacturing and construction, eleven of them in façades and external envelopes, spanning fabrication, installation and design management, an MSc in Façade Engineering and an IFE Level 2 Certificate in Passive Fire Protection. He is the founder of BrieXO.