Simon Battersby

Sometimes the best thing to do with a project task is to start it…

Sounds a daft thing to say, but there’s sometimes a danger of over-planning and over-analysing a task, instead of actually getting on and doing it.

I can think of two personal examples. A few years ago I was managing a complex set of interfaces between two systems. One of our suppliers was reluctant to sit down and talk about it because they wanted more preparation. However, we gained more from a rough and ready two hour meeting with everyone round the table than we would have done from a couple of weeks planning. The supplier was generous enough to agree this as well.

My other example concerns a web tool which had been discussed for a long time at high level, to the extent that everyone thought it was a difficult task. Again in a couple of hours, by talking about some detail and the sort of data we wanted to display, we were able to take a big step towards understanding what we were trying to do, and realise it wasn’t quite as hard as we thought.

Sometimes you just need to start talking about something – it’s pretty certain that talking discussing some detail will focus thoughts and help get a clearer idea of what it is you’re trying to do.

Here’s a great quote on the subject:

Aside: This quote is generally, but incorrectly attributed to Goethe, but in fact was introduced as part of a “very free translation” from Faust by John Anster in 1835. Now you know…

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.