And that got me thinking : Project Controls ... really ?

In this blog, Jon questions whether Project Controls really does what it says on the tin.

I was speaking at the Program Management International Summit in Dublin last week and there was a very good session on Project Controls. It emphasised the importance of setting the systems up properly to avoid excessive work, both for those managing the overall project controls framework and those having to input data. And if set up properly, the data is then useful. However, it did crystallise a nagging issue I have with the title ‘Project Controls’

My issues around ‘Project Controls’.

My beef is not with what Project Controls is, but with the term ‘Controls’ implies. Here’s why :

1. Philosophically, do you ever truly ‘control’ something ? In the real world, there are multiple causes and multiple effects many of which are beyond anybody’s or any parties contemplation, let alone absolute control. In large complex projects where significant effort is put into setting up project controls, this is even more true. So thinking you can ‘control’ this complexity is illusory, even delusional, yet this is what is implied.

2. Does the part of the organisation or project that runs ‘project controls’ actually control the project ? No, it :

• gathers data and information, typically about what has happened (note the past tense and if you don’t believe me, read the excellent guide to ‘Planning, Scheduling, Monitoring & Control’ by the APM’s Planning, Monitoring & Control SIG : the section on ‘control’ is all about what has happened);
• collates and analyses it to identify areas which are ahead or behind where they should be, whether that is in time, cost &/or value delivered; and
• pinpoints areas for management attention, possible providing some insight into the problem based on the data.

However, it is management and those at the coalface that then do the actions which hopefully bring it back into tolerance i.e. exert influence, not control. Or to an analogy, you do not 'control' your car by looking backwards and at the dashboard. You control it by using the break, accelerator, steering wheel and gears.

What a well set-up project controls framework does is allow you to reactively influence the consequences of this complexity, but you are definitely not controlling the causes.

3. The controls – or my precisely the tolerances – are often set too rigidly given the risk and uncertainty in a given project. So going outside these tolerances implies a loss of control and someone needs to be held to account for that e.g. blamed ! What this commonly seems to promote is a manipulation of the information to avoid reporting that there is a problem; and, when this fails to work, a passing of the buck for who is responsible for delay or cost increase. All the time this is happening, the problem is not being managed let alone ‘controlled’.

 

If not Project Controls, then what ?

So what should the sub-profession of project controls being called ? Or, to ask it in another way, what benefit are you putting in place on your project, programme or portfolio when you put in place the capability to gather data and information; and collate and analyse it to give re-assurance in the areas that you are on-track and pinpoints areas for attention if not ?

It’s definitely more than administration; it should be more than just reporting; if the system is working well and the culture is right, you might even be (re-actively) significantly influencing, but is it controlling ... really ?