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.

Not just consultancy

I was musing to my wife the other day - trying to explain how I conceptualise my skills - what makes what I do special, and a bit different from other people who might have the same role. I explained that what I like to do is to chat with people, find out about the problems they are having, and then try to work out ways that they can solve the problems. Sometimes the solution might involve technology, sometimes training, sometimes changing processes, sometimes changing the way that they think about the problem.
She said to me, "That's just consultancy!"
Instinctively I shrink from describing what I do as consultancy, and, over the past few days I've been trying to figure out why.

Three problems I have with consultants

Consultants tell you what you want to hear 

 

I think that a lot of businesses bring in consultants to justify what the MD or CEO wants to do anyway. They come in, listen to the Boss, write it all down, add some charts, take the money and away we go.

Your problem is always solved by what the consultant has to sell

The second problem I have with consultants is that a lot of them come in to sell you their own solutions off the shelf. Whatever your problem is, the things that they just happen to sell are the solution. So the process improvement consultants will sell you CMM, or EFQM, or Scrum, the software vendors will sell you a new CRM or an ERP system (if you're really rich and unlucky) and the system integrators will sell you lots of different systems which will cost a fortune to glue together.

Consultants charge too much, with no guarantees

The third problem is that they're so expensive. A one-man band will cost you £350-£500 a day, a consultant from a small to medium-sized consultancy will cost £600-800 and if you go to the big beasts then you can expect to pay anything up to £1500 a day. And whats worst about this is the risk is all yours: once they have delivered the report, or the new project management templates, or the shiny new website they are out of the door and it's up to you to turn all that spend into something that actually benefits your business.

Another way

I'd like to propose another way. My way has two parts to it: a new way of working and a new way of getting paid.

A new way of working

It's very simple really: This is how it works:

1. I work with you to figure out what your real problems are;
2. I work with you to figure out what is the simplest and cheapest thing that can be done to solve that real problem;
3. I work with you until the problem is solved or until you don't need me any more.

 A new way of getting paid

Instead of doing half the solution, taking the money and leaving you to do the rest, the consultant should have an up front conversation about how much you expect to gain from solving the problem. Then we can talk about how much and when the consultant should be paid.

How much

There's very little point in paying £5k for a new website if it doesn't bring in any new business. As an aside, this conversation (known in Prince2 speak as the Business Case) is a key part of step one of my 3 step plan, above. Maybe you would want to pay £5,000 if you were going to get £50,000 of business from it. I don't know, but it's a conversation we should have

When

I am of the firm opinion that any decent consultant should have enough faith in his own expertise to be willing to be paid by results instead of getting paid whether or not he (or she) makes a difference. Of course there are limits - I wouldn't expect a consultant to shoulder the risk of implementing a new data centre (and I hope neither would you) but it should be part of the conversation.

Do you think this would work for you? If so contact me and we can have a chat.