Not by everyone, and not in full. But someone noticed. The trend that kept slipping. The number that never quite reconciled. The supplier update that felt a little too smooth. The signal was in the room. What wasn't there was a system for turning that signal into action while action still mattered.
That's the gap. Not a failure to know, but a failure to act. And it's where project controls either earns its place or quietly fails to. Plenty of control functions live on the wrong side of it: measuring everything, catching problems late, producing immaculate reports on disasters they never stopped.
So here are three ideas worth sitting with.
Control is not monitoring. Monitoring is watching. Control is action taken to make objectives more likely to be met. Say that back to your own function and ask: how much of what we do ends in a decision, and how much just records the past? For a lot of teams, the honest answer is that they've built an archaeology department and hung a "controls" sign over the door.
Watch everything, and you watch nothing. When a project matters, the instinct is to track it all, all the time. But attention is finite. Spread it evenly and you have none left for the things that will actually sink you. Real control means choosing, on purpose, what gets scrutiny and what doesn't, then defending that choice. The critical path, the handovers, the costly or genuinely uncertain work: these earn your focus. The task that's ticking along nicely does not, however good it feels to tick it off. Knowing what to leave alone is a skill, not a lapse.
No baseline, no control. It sounds almost too obvious to say: until you've fixed what the plan is, "late," "early" and "over budget" mean nothing. You can't vary from nothing. Look closely at troubled projects, and you'll often find them controlling against a plan that was never really baselined, or one amended so many times it now describes a project that no longer exists. That isn't control. It's guessing, with charts.
None of this is mine. It's drawn from how government's code of practice for project delivery frames the discipline, a way of thinking I keep coming back to because it cuts straight through the noise of how controls usually get done. Over the next few posts, I'll take it one idea at a time and pull out what actually changes how you run a project, not what looks tidy in a governance pack.
Next time: the control cycle, the five-step loop beneath all of this, and why "tolerance" is the most underused word in our profession.
Closing that gap between insight and action is what the IET Project Controls Technical Network is built for. We're growing a global community of practice focused on learning, practical value and better decisions, and as Chair I'm looking for volunteers to help shape it. If you'd like a hand in where it goes next, fill in this form (Volunteer with the IET - Register your interest (Page 1 of 2)) or message me directly.
