Simon Battersby

A couple of weeks ago I ended up talking for a few minutes about project management and what it isn’t, and thought I’d post it here as well.

There’s a strange sort of mystique about project management and what it involves. Clearly project management is about getting your documentation right – plans, risk registers, PIDs, issue logs , change requests, progress reports. No.  Most of the really good project managers I’ve had the privilege to work with have used these things. But all of the project managers I would judge as less successful have used these as well. There is an unfortunate tendency to mistake intense activity completing all these things for actually getting something done.

I can illustrate this with a personal example. Way back before I was a project manager I was on the receiving end of a project, as it were, when I used to manage a call centre. Every Friday I – and five colleagues doing the same job elsewhere – had to complete a document reporting progress and risks and issues. I used to complete the form religiously. Far more religiously than my colleagues, it turned out, since I was publicly congratulated for doing such a good job. All well and good. The problem was that I was making a right hash of actually completing the project…..

In recent years one of the least successful programmes I’ve worked on used the most documentation and adhered most rigidly to project management standards. It passed two heavyweight QMS audits without any major problems. And yet, ultimately, this particular programme failed. Another instance that sticks in my mind, on a different programme, was the use of very detailed documents to specify the interface between two different systems. Everything you could possibly need to know about this interface was contained in a single document. Great, eh? No. Our supplier had a highly intelligent lead programmer working for them who really operated on a higher intellectual plane than the rest of us. He was heavily involved in all the discussion about these interfaces, but even he couldn’t understand the resulting document – it was too complicated. And if he didn’t understand it, what hope did the rest of us have?

At the other end of the documentation spectrum I’ve also seen a project deliver an application to 6,000 people pretty successfully, which never had a risk register or an issue register. (Actually, it did have one right at the end of the project because it got audited, and one was “found”, ahem, but that doesn’t really count.)

So don’t be fooled into thinking that project management is just about filling in documents. The difference between good and bad projects isn’t documentation and all the hideous apparatus of the project management textbooks. It’s the people working on the project.

We all know this anyway, because good people in any sort of work make things variously easier, quicker, cheaper, and even, perhaps, more fun. It’s no different on projects. Good project managers find it helpful to use risk registers etc to help them organise a project. The key word here is help though.

Risk registers and project plans are not an acceptable substitute for sensible project management.

Consultant-speak buzzwords have been around for a while, of course, but the one that really gets up my nose is “underpinned”. Often used when announcing some new development or innovation, it is somehow (deemed) far more impressive to say that it’s underpinned by this, that or the other. I thought that was what you did to a building that’s in danger of falling down. What on earth’s wrong with “supported”?

Equally bad, the use of “architected” instead of “designed”. Particularly prevalent in software ITTs.

It’s not big, and it’s not certainly not clever…

Feel free to offer your own personal favourites.

I’m reading this book about Scott’s expeditions to the Antarctic at the moment.

A bit of background information about the Royal Navy particularly interested me. It talks about communication between naval vessels in action. In Nelson’s time in the early 1800s it was very difficult, with the result that each captain had to rely on his own judgement and initiative. By the mid to late 1800s, however, improvements in naval signalling meant that captains relied far more heavily on orders from superior officers, with the result that initiative and individual thought was largely stifled, and the quality of naval leadership suffered badly as a result.

It struck me that there are parallels with today’s “always in touch” culture via mobile phones, emails, Blackberrys and the like, all of which discourage people from using their initiative and making a decision, because there’s always someone else to refer the decision upwards.

Maybe one day a week should be declared “trust your own judgement” day…

Not all problems can be solved by throwing more resources at them.

A few years ago I worked on a programme with three or four workstreams, with maybe 70 or so people in all. For various reasons, the requirements were relatively fluid, and because the programme was quite large, there was a danger of some design decisions being made without taking the full picture into account.

The master stroke (and I can’t claim responsibility), was to set up a small team, with one person responsible across the programme for requirements, one person responsible for technical design, and one person responsible for build. This team achieved a vast amount in only a few weeks in aligning the requirements, assuring the design, and generally tidying up a lot of loose ends. Like all small teams, everyone in the team knew what everyone else was doing and what they were responsible for.

Once again, a few people in tune with each other was the critical difference.