MSP and Project Management

It’s been nose-to-the-grindstone this last week working towards an insane deadline to write up the findings (and think up some suggestions going forward) from a large card-sort being done while I was in Milan the week before. Planning and analysing the results of a 30-user card sort is actually rather fun. It’s rare you get the chance to do one – I only regret not having the time to facilitate more than a couple of sessions. And of course it’s more than just a pity it ended up crashing into such a short deadline, but such is life. At least, I say it’s just life. But I have a sneaking suspicion it’s something else as well.

Firstly, a disclaimer: I am not a project manager, although I have been responsible for managing projects in the past, I’ve been lucky enough only to have been in charge of small-scale ones of comparatively short durations. I respect anyone who can manage large projects over time – possibly the most difficult job in web development that there is right now.

This healthy respect for the ability to manage projects was driven home to me the hard way several year ago. I was put on a project that I single-handedly screwed up beyond redemption simply through lack of knowledge. I didn’t know the basics, and boy did we all suffer. The project got delivered, but so far over time and budget that the site only survived for a few months, and the sheer hatred that flew about in the process was scorching. I offered to resign – the client offered to kill me.

The experience naturally made me resolve never to let it happen again, so I started find out how. Much of what I learnt got me interested in the new media development process in general, but along the way I found Microsoft Project. I’d spoken to a few people about MSP in the past, and they said it was usually too complex to bother with. But I persisted, went on a course, experimented, and found out that MSP is without a doubt the most useful, yet criminally mis-used, software of all time.

MSP has one very strange quality. Or at least, it’s use has a quality that’s strange: just about every project manager I’ve ever met cannot, or will not, use it properly. Even those who otherwise exhibit fantastic PM skills produce sorry excuses for Gantt charts.

I’ll concede – it is hard to produce and maintain a good Gantt chart with MSP. But Excel is hard, and Photoshop is hard, but that doesn’t stop accountants and designers using them as their tools of the trade. What is it about project managers and MSP?

Most times I see a Gantt chart, it’s dead. By this I mean you can’t expect it to reflect reality, or ask it questions like “What if I went on holiday next month?” or “What if that task slipped three days?” and hope it’ll give you a answer. There are a variety of reasons I usually see that kill them:

1. Tasks lacking dependencies

Everything in a Gantt chart needs to have a dependency. Without a dependency, tasks won’t shift if their dependency shifts, so by definition they should not be on the Gantt because they’re not part of the project. Yet I see tasks floating in mid-air so often it’s comical. Mid-air tasks say “The creator of this plan doesn’t know what they are doing.”

2. Fixed-date tasks

Look on the far left of a Gantt, and if you see a little calendar icon next to most tasks (in the “Indicators” column), you’ll know: the Gantt is dead. This is because those tasks has been given date constraints. The PM has manually overridden the start or end date of that task. So the Gantt will never be allowed to tell the PM when a task will actually happen. Finito.

3. Short tasks

For all but the shortest projects, having lots of short tasks (less than about three days) is a sign that the Gantt will cease to be managed pretty soon. You can’t keep on top of a swarm of tiny tasks, people taking days off, acts of God, etc. and hope to keep it all up to date.

4. No resource pool

It’s not always a sign of failure, but if the PM is juggling resources around more than one project at a time, they’ll need a resource pool. Not having one means they’re assuming all tasks will somehow get the resources they need, when they need them. Bang bang – you’re dead.

5. Irregular task granularity

Gantts that reflect power politics usually corpse. You can tell if a phase dominated by one department has twice as many tasks allocated to it, it means that department has bullied the PM to put them there – usually at the expense of all the others. I’ve seen hugely detailed Gantts for tasks relating to marketing that then just have one long task called “build website” at the end.

6. Lack of debate about the tasks

This is more of a general PM failing, but it manifests itself in the Gantt: the uncanny ability of tasks to appear there without any consultation with the people then have to do them. Usually this means that most of the tasks that need to be there, aren’t. See also point 5 above…

There are other symptoms of dead Gantts, but no doubt by now any PM reading this will have something to say. So, let’s hear you. Why is MSP so neglected, and why do we so often have to suffer for it?