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.
In the very first paid job I did, as a fresh-faced 18 year old, I was on the receiving end of some new technology. It was an interesting experience. 
Find myself in an interesting situation at the moment – enforced usage of IE6 at work. Good reasons for this of course, one application used in this organisation will only work with IE6. Quite a common situation. 
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”? 
I’m reading