Project Management

Project management documentation Last updated:17 June 2024

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.

Involve the users Last updated:18 August 2016

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.

The technology in question was a complex piece of machinery which automated the process of splitting up multiple carbon copies of orders for distribution to different sections (shows how long ago it was…). This had previously been done by hand. The order packs came in batches of 48 at a time, and needed to be threaded through this machine before the process could be run. This was rather fiddly.

Now, once it was installed, we had lots of senior visitors who came from the top floor to see this wonderful machine and marvel at how much time was saved. Except, it didn’t really save that much time, if any, because the total time taken was pretty much the same as before for a set of 48 packs, and actually rather longer if there was less than 48 – this happened quite often because urgent orders had to be printed off as soon as they were entered.

The clerical people that actually did the job knew all this, but nobody had asked them… I managed to put my foot in it by saying this to one of the more senior people and was told “You’re not paid to think”. Ouch!

This is especially critical in a contact centre/CRM environment where usability is so critical to the success of an application. On one occasion I commented about the lack of involvement from users in design, and was told it was OK as the Director of Customer Service was involved. But they’re not going to use the system on a call with a customer, are they?

Make sure the real grass roots/coal face/sharp end users are involved in design. They will be the harshest critics of anything that isn’t quite right – and what seems like an acceptable compromise in a design workshop may be the end of the world in a busy contact centre.

Blackberrys, naval signalling and thinking for yourself Last updated:9 September 2015

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…

Relations with suppliers Last updated:5 October 2011

Some little time ago I came across a job ad looking for a project manager (and I quote) “to bludgeon the supplier into submission”. I’m not quite sure whether the agency thought that this was a good way to attract high class candidates, or what. The sad thing is I suspect it wasn’t a joke.

Subsequent reflection on this got me thinking about really productive working relationships I have had with different suppliers. One common characteristic of these successful relationships has been the old fashioned virtue of trust. However, I’ve never trusted the supplier. I have trusted the people who work for the supplier. I’ve trusted them to bring their specific expertise to the project and I’ve trusted them when they’ve told me that things are impossible, and I’ve trusted their judgement when we’ve discussed problems. I flatter myself that, again in the most productive relationships, the trust has been mutual. The supplier project manager has trusted me to manage things at my end, believed me when I said some elements are essential however difficult they might be, and so on. These have been relationships of equals, not assailant and victim. There has been a remarkably small amount of bludgeoning.

So how did I get to this position of trust? I had been conscious for quite a while, having worked with suppliers on many different projects, that the situations which I felt to be most useful were face to face meetings with people. No big suprise there. But actually I realised it was a bit more specific than that – in many cases the most productive discussions were actually the informal ones. The circumstances varied from sitting next to a developer and chatting about an issue, talking with a supplier project manager over lunch during a more formal meeting, even chatting to potential suppliers during a coffee break during a tender presentation. My experience of projects is that it’s usually a few people who are in tune with each other who are critical to the success of a project. And it’s the informal contact that builds this set of people who are in sync, and who trust each other, just as much as the formal contact. None of this is to say you don’t need formal meetings – of course you do. But don’t neglect the opportunity to build the relationship through the informal contact.

I am not normally one for reading learned articles on project methodologies – but there’s one I came across called “Characterizing people as non-linear, first-order components in software development” written by US methodology guru Alistair Cockburn in 1999. Normally the title of this alone would have been enough to put me off, but in fact the more I read, the more I found myself in tune with its substance. Cockburn notes that a commonly quoted factor in successful projects is that “a few good people stepped in at key moments and did whatever was needed to get the job done”. Additionally, he concludes that the most effective way to communicate is to have two people standing at a whiteboard, and that the further you get away from this situation the less effective the communication. He doesn’t make this specific distinction, but this implies to me an informal meeting rather than a formal presentation.

The relationship with your supplier becomes more important when problems occur – and things always go wrong during projects. Coming back to the start of this article, bludgeoning the supplier into submission isn’t very likely to help. I’ve never seen a project fixed by people shouting – and I’ve seen a fair amount of shouting. I’ve seen projects fixed by sitting down and talking about them. I’ve seen projects not fixed by either approach. I’ve certainly seen shouting make suppliers less co-operative. In my experience, sitting down and talking calmly about the problem is usually the best approach, and certainly the one adopted by all the most impressive project managers I’ve worked with. The better your relationship with the supplier, the easier this sort of meeting is likely to be, another benefit of getting to know the people you’re dealing with better.

Looking at this from the point of view of less successful relationships I have had, they support the same conclusion. In a few cases I have not had what I’d call positive relations with suppliers. These have pretty much coincided with situations where I haven’t been able to establish good relations at a person to person level – either because of geographical separation, or in some cases, cultural differences.

In conclusion, remembering that the people you are dealing with are just that, people, and taking every opportunity to build relationships with those people, is a significant success factor in projects. The fringe benefit, of course, is that it might actually make the project more enjoyable as well as more productive. And that’s got be a good thing.

Laws of CRM and telephony projects Last updated:30 September 2011

Simon’s first law – Comms rooms

One or more of the following will apply

  • There will be no room in the comms room for the new server. Resolving this will necessitate anything up to and including an extension to the building.
  • There will be insufficient power supplies
  • There will be no spare ethernet ports

Note that these rules apply regardless of how recently a comms room has been built.

Simon’s second law – Address formats

No matter how unlikely it seems at the outset, there will be an intense discussion about addresses at some point, normally involving postcodes. This may well extend beyond intense, into heated.

Simon’s third law – head scratching

At some point more than three people will be observered clustered around the same screen with slightly vexed expressions on their faces.

Simon’s fourth law – telephony testing

You will, at some point, have your desk phone to one ear, and your mobile to the other ear, talking to yourself. It’s inevitable. Don’t fight it.

Simon’s theorem on development gurus

In normal circumstances, on any given development project, there’s someone who can fix anything. It may take you a while to work out who he/she is, and even longer to get his time. Slightly more than half of these people are called Dave.

Corollary to the theorem

If no such person exists, you’re in trouble.