Ask ten project people what "control" means, and you'll get ten different answers, most involving spreadsheets and a bit of dread. The Teal Book, the UK government's code of practice for project delivery, puts it more usefully: control is any action taken to increase the likelihood that objectives are achieved.
Look at what that leaves out. Nothing about status reports, RAG ratings, or steering packs. Those are outputs. Control is the action you take. Everything else just exists to make that action better.
Underneath it is a loop of five steps. Plan, do the work, track progress, assess, take action. Then round again. It looks too simple to matter, and that's the trap. In over 15 years of extensive experience delivering challenging and complex projects in highly regulated industries, I've watched teams get it wrong the same two ways.
First, they run the loop backwards. Control isn't about writing up what already broke. It's about acting to keep the work on course, catching problems and opportunities before they turn into facts. If your controls team spends most of its time explaining last month, it isn't controlling the project. It's narrating it.
Second, they run it at one speed. The loop works at every level, and it should turn at a different pace at each. A portfolio might review monthly while a work package meets daily. Riskier work needs a tighter loop. That's a decision to make on purpose, not a meeting someone set up once and never questioned.
Then there's the word I think is the most underused in our profession: tolerance. Tolerance is the deviation above and below the plan that a manager can absorb before they have to escalate. Get it right and two things happen. Managers act with confidence inside their range, and the board only sees what actually needs it. Get it wrong, or skip it, and you land in one of two places I've seen too often. Either everything escalates, and the board drowns, or nothing does, and the problems grow quietly until it's too late to fix them.
None of this works without a baseline. It's the dull foundation everything sits on. Until you've agreed what the plan is, "late", "early," and "over budget" don't mean anything. You can't measure a variance from nothing. If you can't say what "on plan" looks like, you're not controlling the work. You're watching it and hoping.
So the control cycle isn't bureaucracy, and it isn't a slide for the governance pack. It's the difference between steering the project and riding in the back of it.
Next time: how to work out what actually deserves your attention, because trying to control everything is the fastest way to control nothing.
This is the kind of thing the IET Project Controls Technical Network exists to share, bringing engineers and practitioners together to sharpen how we all work. As Chair, I'm after people who want to help build that community. If that's you, fill in this form (Volunteer with the IET - Register your interest (Page 1 of 2)) or message me directly.