The change nobody assessed: why management of change breaks businesses that think they are stable

Every operational failure we have named on this site, the single point of failure, the legacy system, the growth that has outrun its controls, the deferred investment, the prior failure that was never fully rectified, has a sixth failure mode hiding underneath it. Something changed. A process was patched, a system was replaced, a step was worked around, a supplier was swapped, a shortcut was taken under deadline pressure. Nobody assessed what new risk the change introduced before it went live. That is management of change, and its absence is the reason fixed problems come back.

Why change is different from the other five risks

The other failure modes are conditions. A single point of failure sits there, static, until the day it triggers. Management of change is different because it is not a condition, it is an event, and it happens constantly. Every week someone in your business changes something: a spreadsheet formula, a vendor, a step in a process, a permission on a system, a shortcut around a control that was slowing a project down. Most of those changes are harmless. Some of them are not, and the business has no way of telling the two apart before the change goes live, because nobody is required to ask.

In heavy industry this is not an abstraction. Management of change is one of the core elements of formal process safety management, precisely because investigators kept finding the same root cause behind major incidents: not a single catastrophic failure, but an unassessed change to equipment, a procedure or a role that removed a safeguard nobody realised was load-bearing. Mid-market contractors and project-delivery firms run the same exposure at a smaller scale, without the formal discipline that heavy industry only adopted after a long run of major incidents made it mandatory.

What it looks like in a business your size

A job-cost workbook gets a new column added by whoever needed it that week, and the total row silently stops reconciling with the ledger. A scheduling tool gets swapped for a cheaper one mid-project because the old vendor's price went up, and nobody checks whether the new tool handles retentions the same way. A safety procedure gets shortened because a supervisor found it slowed the crew down, and the step that got cut was the one covering the exact scenario that later caused a near miss. A subcontractor scope changes verbally on site, and the change never reaches the commercial team pricing the variation. None of these are dramatic. All of them are unmanaged change, and every one of them is a decision that was made by someone who did not know, or was not required to ask, what it put at risk.

Why it undoes the fixes you have already paid for

This is the failure mode that makes the other five expensive twice. You remove a single point of failure with a properly built system, and eighteen months later someone changes a step in how the business uses it, without validation, because the person who built the original control has moved on and nobody else knew to ask. The fix does not fail because it was wrong. It fails because nothing was watching for the change that quietly broke it. A resolved risk with no management-of-change discipline behind it is not resolved. It is deferred again, on a shorter fuse, because everyone believes it is handled.

What a documented management-of-change process actually requires

It does not need to be bureaucratic. It needs four things that most mid-market businesses do not currently have in writing: a trigger, so it is clear which changes require assessment and which do not; an assessment step, so someone actually asks what new risk the change introduces before it goes live, not after; an approval, so a named person with the authority to say no has actually looked at it; and a record, so the next person who touches the system knows what changed, why, and who signed off. That is the whole discipline. The difficulty is never designing it. It is making it survive contact with a deadline, which is exactly when most businesses skip it.

Where it sits in the Blueprint

This is why our Operational Risk Audit now asks explicitly whether changes to your critical systems and processes are being assessed and approved before they happen, and why dual sign-off before production is built into every Risk Elimination Build we deliver. It is also why the Sustain phase exists at all. A fix nobody is watching is a new single point of failure, and the single most common way a good fix quietly becomes a bad one is a change that nobody assessed.

If you cannot point to a documented process that catches a change to a critical system before it goes live, you do not have five failure modes. You have six, and the sixth one is capable of reopening the other five after you have already paid to close them.