Better Project Management via a Better Definition

This last year has seen a number of changes to the way our business is managed. We have tried just about every project management tool under the sun, from the popular Basecamp and open-source web-based alternatives, thought to the bloated Microsoft Project – all without much success.

And it turns out that my struggle to get this part of my business right has been based on a bad definition. (Or probably, more accurately, no definition.)

So in order to find the right tool – the question must be asked: “What is project management?”

And the answer is best summed up in explaining what it’s not.

Earlier this year I purchased Sitepoint’s The Principles of Project Management – and on page 8 the obvious truth stood out:

Firstly, project management is not personal productivity. This is an easy mistake to make, however. Most folks’ early experience with project management is on smaller projects on which they’re doing most of the work themselves. It’s easy to start treating the project schedule as your diary, the task list as your to-do list. But as soon as you add anyone else to the project, be it a client who wants to understand the time line or a colleague helping out with some of the work, this approach starts to cause problems.

If you make your project management tools double as personal productivity tools, you’ll almost certainly be including far too much detail. Keep a clean line between what you need for yourself personally, and what the project needs. This way, when you have slightly larger projects with more people involved, your tools will scale.

If you think about it, many of the project management tools pitched at web design businesses are very much focussed on tasks. Way too much detail – and the whole project management things just gets way too hard.

So I have found a solution that is surprisingly low-tech:

A whiteboard.

Yep – that’s it. It happens to be a magnetic whiteboard though. So here’s what I do.

  1. The whiteboard is divided up into columns – with each column representing a milestone. “Received Content”… “Design Approved”…  I have about 7 stages I think from memory (I’m writing this from home) but there’s no magic number. Divide your workflow into milestones you can tick off.
  2. Each project is represented by a little piece of paper with some essential details. And it’s held to the whiteboard with an amazing piece of technology called a magnet. When you have received the content, move it into the next column!

This overcame a couple of problems:

  1. Software wants you to enter due dates for everything, whereas in reality a lot of when something gets finished depends on the client. So due dates regularly got missed, and planning went out the window. The whiteboard has no dates.
  2. It’s quite easy to stand back and see any bottlenecks on your process. Got a lot of projects sitting in stage x? Why? Then do something about moving some of those along.

That’s about it. Check the whiteboard once or twice a week with your team and get progress on where everything is at, and what projects can be moved to the next column.

This does not address the question of the detail though. What actually needs to be done during each stage of development? And how do you know when it’s done?

Ah, well that’s a topic for another post…