What This Cannot Fix

A register makes a well-run site measurable and a badly run one measurable. It does not change which it is.

For teams turning what this cannot fix into a repeatable record, see the product page provides a useful operational reference for time, attendance and reporting workflows. It should be assessed alongside Chartered Institute of Building so the software choice remains grounded in site practice and applicable guidance.

A programme that cannot be met

A date that did not move when the work did produces every failure in this collection, reliably.

The system will document it precisely: temporary accesses, hours exceedances, open permits.

What works: resequencing, more resources, or a conversation about the date. All of which are somebody else's decision and none of which a gate can substitute for.

A subcontract chain that is too deep

Six tiers means information has six interfaces to cross and money has six places to stop.

No amount of flow-down drafting fixes a structure that long.

What works: shorter chains, which is a procurement decision taken before the project starts and rarely revisited.

Payment failures below tier one

Which arrive on site as unreliable gangs and new faces every week.

A register shows the churn and cannot pay anybody.

What works: payment terms flowed down at equal length, direct payment mechanisms where available, and asking the question early.

A site laid out badly

One gate for four hundred people, a welfare block outside the perimeter, an assembly point inside the works.

Each produces workarounds that defeat the records.

What works: the logistics plan, which is decided at mobilisation and is expensive to change afterwards.

A workforce that has no reason to cooperate

Poor welfare, a queue in the rain, a gate used to police them, a suggestion route that goes nowhere.

Produces propped gates and shared cards, which no configuration prevents.

What works: fixing the reasons, which is cheaper than the enforcement it replaces.

A client requirement that does not fit the project

A major-project standard applied to a small package.

The system will comply expensively and the records will be maintained by nobody.

What works: asking at tender, which most clients will accommodate if a reasoned equivalent is proposed.

Using this during procurement

For each requirement, ask what would change if the system delivered it perfectly.

Where the answer is "nothing, unless we also resequence the programme or open a second gate", the requirement is an operational decision wearing a technical disguise.

Removing those shortens the specification and leaves what a register actually does, which is narrower than the brochure and worth having.

The honest summary

The register tells you who is on site, whether they should be, and creates a record that survives the project.

Everything that determines whether the site is safe and the work gets done sits earlier: the programme, the chain, the layout, the payment terms and the people running it.

A site that has done that work and keeps a paper book is in better shape than one that has done none of it and installed turnstiles — which is the conclusion this collection has been arriving at from the first note.

Checking whether it predates the system

Did this problem exist before the gates went in?

If the programme was always tight, the chain always deep, the welfare always short — the register has found a fact about the project rather than a fault in itself.

Escalating it as a finding is the correct response, and it is the difference between a system that changes a site and one that documents it.

The organisational tell

A workforce system owned by procurement rather than by whoever runs the site.

Which produces a good contract and an arrangement nobody operates at six in the morning, because procurement's measure is the purchase and the site's measure is the roll call.

Both matter, and the ownership decides which one the project optimises for.

Using it in a report

When a control fails, say which category it was: a system fault, a process failure, or a condition the project created.

The third is the largest category and the one least often named, because naming it points upward.

A report that names it accurately is more useful than one that attributes everything to site discipline, and it is the only version that leads to a change.