Glossary

The words operators should know.

Clear definitions for the language of keeping work under control — from The Control Library.

Select any term to read its full definition.

Accountability vs Responsibility: Responsibility is for doing the work; accountability is for the outcome. Several people can be responsible for the tasks, but one person is accountable for whether the result actually lands. Responsibility can be shared and handed around; accountability cannot be divided without disappearing — which is why every important outcome needs a single accountable owner.
After-Action Review (AAR): An after-action review is a short, structured debrief that asks four questions: what was supposed to happen, what actually happened, why was there a difference, and what will we change? Originally a US Army practice, it turns experience into improvement — and works best when it's blameless but accountable.
Bus Factor: The bus factor is the number of people who would have to be lost — "hit by a bus" — before a project stalls because critical knowledge or access went with them. A bus factor of one means a single person is a single point of failure. Raising it is a core goal of good ownership and delegation.
Control Point: A control point is the unit of being in control: a piece of work that has a clear owner, a dated next step, a decision or escalation date, and a fallback. When uncertainty is converted into a control point, work can still go wrong — but it can no longer drift quietly.
Crew Resource Management (CRM): Crew resource management is a set of team practices, born in aviation after a string of 1970s crashes, that uses every crew member's knowledge to prevent error. Its central idea is flattening the authority gradient: making it safe and expected for a junior person to challenge a senior one when they see something wrong.
Critical Path: The critical path is the longest sequence of dependent tasks that determines the shortest possible time to finish a project. A delay to any task on the critical path delays the whole project; tasks off it have slack. Knowing yours tells you where a slip actually costs you time.
Decision Rights: Decision rights define who gets to make which decisions, and at what level, without needing sign-off from above. Setting them clearly is how a team stops routing every choice through one person: cheap, reversible decisions are pushed down with guardrails, while the rare, hard-to-reverse ones are deliberately kept for a more senior call.
Definition of Done: A definition of done is an agreed, shared checklist of the criteria a piece of work must meet before it counts as finished — not just "code written" but tested, reviewed, documented and shippable. It removes the ambiguity that lets half-finished work get called "done".
Drift (Operational Drift): Drift is what happens when work slides sideways from where it should be while everyone stays busy — dates slipping, decisions waiting, dependencies going quiet, scope creeping. It is gradual and individually small, which is why it goes unnoticed until it surfaces as a surprise.
Fishbone Diagram (Ishikawa): A fishbone diagram — also called an Ishikawa or cause-and-effect diagram — is a visual tool that sorts the possible causes of a problem into categories, so a team can see every contributing factor at once instead of fixing the first thing they notice. Created by Kaoru Ishikawa, it is a staple of root-cause analysis.
Just Culture: A just culture is an organisational approach to error that holds people accountable for reckless choices while treating honest mistakes as a signal to fix the system, not the person. Popularised by Sidney Dekker and David Marx, it replaces "who messed up?" with "what let this happen?" — so people report problems instead of hiding them.
Ladder of Accountability: The ladder of accountability is a model that ranks how people respond to a problem, from the lowest rung of ignorance, blame and excuses up to the highest rungs of owning reality, finding solutions and acting on them. Popularised by The Oz Principle (Partners In Leadership), it shows accountability as a posture you choose, rung by rung.
Lessons Learned: Lessons learned are the documented insights a team captures during or after a project — what worked, what didn't, and what should change — so the next piece of work benefits from the last. A core project-management practice, recognised by PMI and PRINCE2, it only pays back when a lesson becomes an actual change.
Manage by Exception: Manage by exception is a control principle, formalised in PRINCE2, where a manager agrees tolerances — the limits within which work can run without sign-off — and is only alerted when a forecast breaches them. It lets senior people delegate the routine and reserve their attention for the genuine exceptions.
MoSCoW Prioritisation: MoSCoW prioritisation sorts requirements into four groups — Must have, Should have, Could have, and Won't have this time — so a team agrees what is truly essential before work starts. Its real value is the explicit "Won't have" list and a capped "Must have" set, which protect the deadline when time runs short.
Pre-Mortem: A pre-mortem is a planning exercise where, before work begins, the team imagines it has already failed and works backwards to explain why. By making it safe to voice doubts up front, it surfaces risks that optimism would otherwise hide — the opposite of a post-mortem held after the damage is done.
Process Mapping: Process mapping is the practice of drawing a process as a step-by-step diagram — showing each task, decision, handoff and information flow from trigger to outcome. It makes invisible work visible, exposes where things stall, and creates a shared picture a team can agree on before they try to improve or automate anything.
Pyramid Principle: The Pyramid Principle is a structuring method for written and spoken communication, devised by Barbara Minto at McKinsey, that puts the answer or recommendation first, then groups the supporting arguments beneath it. You lead with the conclusion, then justify it — so a busy reader gets the point before the detail.
RACI Matrix: A RACI matrix is a simple grid that maps who is Responsible, Accountable, Consulted and Informed for each task or decision in a piece of work. It removes the most common cause of drift — unclear ownership — by forcing a single accountable name per row, so everyone knows who does the work and who answers for the outcome.
RAG Status: A RAG status reports the health of a project or task with a traffic-light colour: Red, Amber or Green. It is a fast way to communicate at a glance, but on its own it is a summary of someone's judgement, not evidence of control — a green light only means as much as the owner, dated next step and fallback sitting behind it.
RAID Log: A RAID log is a simple project-management tool that tracks four things in one place: Risks (what might go wrong), Assumptions (what you're taking as true), Issues (what has already gone wrong), and Dependencies (what you're relying on others for). It keeps the sources of drift visible and owned.
Root Cause Analysis (RCA): Root cause analysis (RCA) is a structured way to find the underlying cause of a problem — not just its symptoms — so a fix stops it coming back. It uses tools like the 5 Whys, fishbone diagrams and Pareto analysis to move from "what happened" to "why", and ends in a change with a named owner and a date.
Routing vs Leading: Routing vs leading is the distinction between processing your team's work one item at a time — answering questions, making small decisions, unblocking people — and acting on the system that produces that work: its standards, decision rights, and handoffs. Routing feels productive; only leading compounds.
Scope Creep: Scope creep is the gradual expansion of a project's work beyond what was agreed, without a matching change to the time, budget or commercial terms. It rarely arrives as one big request — it accumulates from small, reasonable-sounding extras — which is why the delivery shape can change completely while the contract stays still.
Single Source of Truth: A single source of truth (SSOT) is one authoritative, agreed place where a given piece of information lives, so everyone reads and updates the same version instead of keeping rival copies. It removes the "which spreadsheet is right?" problem, kills duplicate data, and means a decision is based on one set of facts rather than several conflicting ones.
Stakeholder Engagement: Stakeholder engagement is the ongoing practice of identifying the people affected by a project, understanding their interests and influence, and actively working with them throughout its life. It is a continuous two-way relationship — not a one-off mapping exercise — aimed at keeping support high and surprises low.
Stakeholder Management: Stakeholder management is the deliberate work of identifying everyone with a stake in a piece of work, understanding what each needs, and keeping them aligned as it proceeds. It matters because projects move at the speed of stakeholder alignment, not the speed of the plan — and "they were in the meeting" is not the same as "they are aligned".
Swim Lane Diagram: A swim lane diagram is a process map split into parallel "lanes" — one per person, role, team or system — so each step sits in the lane of whoever owns it. It shows not just what happens but who does it and where work crosses from one lane to another, making handoffs and ownership gaps impossible to miss.
The 5 Whys: The 5 Whys is a root-cause technique: you ask "why?" about five times in a row, tracing a problem back from its visible symptom to the underlying cause, so you fix what actually broke instead of the surface effect. Developed at Toyota, it suits single-cause problems and pairs well with a fishbone diagram.
The Coaching Test: The coaching test is a single question for telling coaching apart from rescuing: after being coached, does the person perform better when you are not in the room? If yes, it was coaching. If the problem got solved but the person is no more capable, it was useful — but not coaching.
Touching the Task vs Carrying the Outcome: Touching the task vs carrying the outcome is a distinction from The Control Standard. Touching a task is doing the obviously-yours bit and handing it on; carrying an outcome means keeping your attention on what the work was meant to produce until it is secure. The one-line test: would this still count as done if the result never landed?