Home > Work > In a Nutshell: Five Principles of Project Management

In a Nutshell: Five Principles of Project Management

Glenn Alleman (Herding Cats) has recently suggested Five Immutable Principles of Project Management, five questions without which your project is almost certainly doomed to failure

His five principles are:

  1. Know where you are going by defining “done” at some point in the future.

  2. Have some kind of plan to get to where you are going.

  3. Understand the resources needed to execute the plan.

  4. Identify the impediments to progress along the way to the destination.

  5. Have some way to measure your planned progress, not just your progress.

There is no real magic to Project Management other than trying to keep one step ahead of all the forces that can come along to trip everyone up. I agree with his summary – if you focus on these five, that’s the bulk of the work done.

To get a definition of “done”, you need to define the scope (requirements). Scope management takes up a lot of time, not just at the beginning but also especially during the busy period in the middle when there has been time for the business to change its mind, and as the detail is uncovered. This is rightly top of the list; not only does it come first sequentially, but without it you can’t do the rest.

Planning means much more than just an MS Project gantt chart of tasks and dependencies – how we are going to achieve our target. I have worked on several projects where the Project Manager (not me!) maintained a plan in MS Project, meticulously, tracking our failure perfectly.

I would swap 3 and 4 in the list, as once you have a plan you also have to identify all the Risks and Issues that need to be addressed (straight away, usually). It’s also about getting obstructions out of the way in time so the team can keep working, or having a Plan B (and Plan C…) if you can’t.

Resources doesn’t just mean effort, but also what kind of people you need, and making sure you have the right equipment – not just hardware but the banal like offices and desks for the team. Producing good estimates is a black art and the subject of many books, but however you do it you need a benchmark to refine as you go along. Measuring progress is just as elusive, as developers, especially, are always overoptimistic, and can often cheerfully report a 90% complete status for days on end. I prefer to report either on the basis of 0 or 100% done, and break the tasks down to a low enough level of granularity to be able to add up the completed tasks as a percentage of the total.

Of course, as well as the project as a whole, you can ask the same questions of each task.

I think back to all the failed projects I’ve worked on, and (as I’ve commented before) the main contributory factor of almost all of them was that right from the beginning, we never had the scope or the requirements set down clearly and correctly. This meant we started off badly, and never recovered. Define “done” and you are halfway there.

Categories: Work Tags: ,
  1. No comments yet.
  1. No trackbacks yet.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: