Project Management, G4S and the Olympics

There's been a lot of speculation around concerning the failure of G4S to recruit and train enough security staff in time for the London 2012 Olympics.

Buckles buckles, and poor Tommy Atkins picks up the pieces

According to G4S' CEO, Nick Buckles, they will end up losing between 30 and 50 million on this contract. G4S are going to pay for the extra soldiers who will be forced to give up their recovery time to fill the gap. While I would bet much on Buckles still being in a job in a month's time, surely the most serious outcome is that some of the troops in Afghanistan will be required to stay out there for longer to cover for troops that have been drafted in for the games.
Some commentators have expressed surprise that Buckles was only made aware that they weren't going to make it 9 days before the story broke. I'm afraid that, with over 20 years experience of delivering complex projects (and this was not a particularly complex project), I was not surprised at all.

2000 to 10000 in 9 months, a slow-motion train wreck

Now I haven't worked for G4S, but I can make a pretty educated guess as to what happened: G4S were originally contracted to supply 2000 security staff. This was upped to 10000 staff following a review in November 2011, leaving them with less than 9 months to find an extra 8000 staff. Just to be clear, this represents a 400% increase. Now I'm willing to bet that the Project Manager in charge, and the recruitment team knew that this couldn't be done as soon as they were told about the change. The project manager may have even told people higher up the food chain that it couldn't be done. They would then have come back to him/her and said that it had to be done. They may have even offered extra money and people to do it. The PM probably took on some extra staff to try and avert the impending train wreck.

 

Classic mistakes

[As an aside, in software development circles, this is known as a classic mistake, adding people to a late project. There's a whole book on it, The mythical man month, which I recommend to anyone who's interested in why software projects go wrong. ]
What I'm guessing happened now, is that the PM and the team struggled on, knowing that they were not going to make it, but equally knowing that no-one in senior management would be interested in hearing the bad news until it was obvious to everyone. There's a name for this in software development circles too: The Death March Project.
I think (though I don't know) that the Olympics security debacle was a symptom of a corporate culture at G4S that is all too common in UK business: The people at the top think that they can get things done by demanding it, they don't like to hear bad news, and moreover, dismiss those who say that a thing can't be done as whingers, even while they are relying those same people to do the thing that can't be done.

"Star Trek is not like real life" shock

If there's one thing that I've learned in 25 years, it's that if you're relying on a person to do a thing, and they tell you it will take three months, and you tell them that it has to be done in two, it will take three months - if you're lucky. Real life isn't like Star Trek.
Another thing that is common to these sorts of organisations is a Mickawberish belief that something will turn up, and if you are lucky, you will get away with it. Again, 25 years of experience tells me that you are never, ever lucky. In fact, if something only takes the amount of time and effort you thought it would, and not more, then you can count yourself as lucky.
I have two prescriptions: one for the CEO, and another for the Project Manager:

 

A better way for the chief

For the CEO - This, like many aspects of leadership, is simple. Simple but not easy. What Buckles' successor has to do is to change the culture of the organisation so that open communication of bad news is encouraged and acted upon. And in case you think I'm being hopelessly idealistic - I have actually done this, for a team of 30 people, and it does actually work. The way you start is, the next time that someone brings you bad news, just take the time to actually listen to their concerns, engage with them in a way that shows that you understand and negotiate some changes that will make a difference. Then you keep doing that every day. Within 6 months, you will really see the change.
Imagine if someone had come to Buckles in November 2011 and told him that there was no way that they could go from 2000 to 10000 in 9 months and instead of just telling them to make it happen, listened to their concerns and responded to them. They might have figured out that the best that they could do was 5000. They could have gone back to LOCOG with that figure, LOCOG would still have had to get the troops in but they would have had 9 months to plan it and it would certainly have kept G4S out of the headlines.

 

A better way for the Project Manager

Too many PMs, when faced with a project, and a management like this, just give up. They stop planning and they stop reporting. This is the wrong thing to do. When the project goes wrong it is then the PM's fault, fair and square. What you should do is keep the plan up to date and keep reporting openly and honestly. Here at Stonivale we have a simple way of reporting progress, using red, amber and green statuses that are clearly defined and consistently applied:

• GREEN - All tasks are on time and the project is on time
• AMBER - One or more tasks is forecast to finish late but the project is still forecast to finish on time
• RED - One or more tasks is late and the project is forecast to finish late.

We insist on weekly reporting, not monthly as is common (and was the case for the G4S project). Senior managers tend to sit up and take notice if they are getting a report week after week that is telling them their project is late.

Does any of the above look familiar? Need help with sorting your projects and programmes out? Contact Stonivale for a chat. We might be able to help.