2 minute read time.

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.

These are insights drawn from how the UK government's code of practice for project delivery, the Teal Book, 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.

Parents
  • Hi Ahmed.  A good read and introduction to one of the paths that the Project Controls TN might take.  I like the 'taster' and really look forward to the planned upcoming series that you propose.  The focus really aligns to my own thinking as I continue to look at trending of large data sources in both the qualitative and quantitative dimensions.  I am currently looking at the data repositories within NUVIA and how AI enabled algorithms can be used to forecast failure.  I actually started a research and development workstream in this area earlier this year.  This aligns very well with my past PhD research in support of aero-engines and other high value engineering products.  Here, on-product sensors monitors the dimensions of the Physics of failure which can predict MRO strategies.  

    Prior to working in Nuclear, I worked in automotive and also with F1.  Whilst spectators see a sporting event, in engineering it is actually a massive test bed.  My past work included the design and manufacture of F1 car geometry.  Through the use of sensors, aero-dynamic performance was relayed to the Pits during the race and then transmitted directly to Race Team HQ.  The project was to develop the car body for the next race in the season.  At HQ, the use of the race telemetry and digital twins enabled aerodynamic geometry testing, and before the race completes, the new geometry has been tested and approved.  We would start production of the new body 'shape' before the race was finished.  Why do I put this forward as an example?  Quite simply, it shows the power of data within a project and the short iteration times that can be achieved. System architecture and aligned algorithms are key to the future of project management going forward.

Comment
  • Hi Ahmed.  A good read and introduction to one of the paths that the Project Controls TN might take.  I like the 'taster' and really look forward to the planned upcoming series that you propose.  The focus really aligns to my own thinking as I continue to look at trending of large data sources in both the qualitative and quantitative dimensions.  I am currently looking at the data repositories within NUVIA and how AI enabled algorithms can be used to forecast failure.  I actually started a research and development workstream in this area earlier this year.  This aligns very well with my past PhD research in support of aero-engines and other high value engineering products.  Here, on-product sensors monitors the dimensions of the Physics of failure which can predict MRO strategies.  

    Prior to working in Nuclear, I worked in automotive and also with F1.  Whilst spectators see a sporting event, in engineering it is actually a massive test bed.  My past work included the design and manufacture of F1 car geometry.  Through the use of sensors, aero-dynamic performance was relayed to the Pits during the race and then transmitted directly to Race Team HQ.  The project was to develop the car body for the next race in the season.  At HQ, the use of the race telemetry and digital twins enabled aerodynamic geometry testing, and before the race completes, the new geometry has been tested and approved.  We would start production of the new body 'shape' before the race was finished.  Why do I put this forward as an example?  Quite simply, it shows the power of data within a project and the short iteration times that can be achieved. System architecture and aligned algorithms are key to the future of project management going forward.

Children
  • Hi Louis, thanks a lot for your engagement and valuable comments. Learning from experience and utilising the historical data to understand trends and support decision-making is a really smart move that not many companies implement, despite talking a lot about it. The exercise you are leading at NUVIA sounds very interesting, and I would personally be excited to know how this changed the way projects are being managed and decisions are being taken. 
    Also, the example you gave from your experience working on F1 aligns perfectly with the message of this post. You/your F1 team monitored what mattered, immediately implemented changes, and took actions to improve (control).