Major Incident | A process people actually followed

The Mission

Every organisation has a Major Incident process. Fewer have one that people actually follow when everything is on fire. This one existed on paper, but in practice it was a mix of tribal knowledge, improvisation and whoever shouted loudest on the bridge call. The process needed updating, but the real brief was bigger than a document refresh. A process nobody adopts is just a well-formatted PDF. The job was to rebuild it, then make it stick.

The Work

We started by rewriting the process with the people who would live it. Not in a workshop-for-the-sake-of-it way, but genuinely pressure-testing every step against how incidents actually unfold at 2am. Roles were clarified, escalation paths simplified, comms responsibilities made explicit, because during a major incident the communication is half the battle.

Then came the part most process rollouts skip: the socialising. We took the new process on the road. Sessions with every team it touched, framed around what changes for you, not here is the new document. And to prove it worked rather than just claiming it did, we ran a full day in the life. A simulated major incident, start to finish, run under the new process with the real teams in their real roles. People got to feel the process working before they ever needed it in anger. The wobbles it surfaced got fixed. The confidence it built stayed.

The Result

When the next real major incident hit, nobody reached for the old habits. The bridge call had structure. Everyone knew their role because they had already rehearsed it. Stakeholders got timely, consistent updates instead of radio silence and rumour. The day in the life had done exactly what it was designed to do: turned a new process from something people had read into something people had done. That is the difference between publishing a process and embedding one.