Project management methodologies: again

Following another of those conversations about projects where people told me they “don’t like Agile” or think that we should use “proper” project management techniques I decided to write down my thoughts on project management methodologies. I rather hope this will be cathartic. It will also mean I have something to send people when I find myself embroiled in another of those conversations again.

Where I come from on this.

I have been trained in and have applied in my career three different project management techniques:

  • Scrum: an agile methodology
  • PRINCE2: a waterfall methodology
  • Integrated Emergency Management: a methodology for… well… managing emergencies

This doesn’t, of itself, make me a better project manager but it does give me a distinct perspective on project management.

Essentially I don’t believe there is a “proper” way to manage projects. I do believe that one technique may be safer (ie less risky) than the others in any given context.

Different techniques for different scenarios.

Like the railways

I don’t know anything about managing railways. So let’s use that as a way for me to illustrate what I’m talking about.


Lets say my project is to install a brand new signalling system at a railway junction. Network Rail is going to give me 8 hours (or 4? I don’t know) overnight to do the job. This project has some distinctive features:

– it is incredibly important that I get this exactly right. No-one is going to let trains run past my new signalling system unless they are completely satisfied that it does what it is supposed to do. In every regard.

– it is clear what exactly right means in this context. Clever engineers (I choose to believe) have spent a lot of time thinking about how trains interact with signals and once I have finished installing it; my new system will be checked by a clever engineer, against every single criteria.

– I can reduce the risk of this project going horribly wrong by preparing really well in advance. This is a process known to project managers as planning. In fact I will probably spend orders of magnitude more time planning the project than I will delivering it.

– if I get it horribly wrong and at the end of my 8 (or 4) hour window, the signalling system isn’t exactly right, the time will be extended. Of course people will be very cross, my company will be fined lots of money and I may lose my job but so important is the specification that, if necessary we will extend the time and pay more to make sure we get it exactly right.

This is a job for waterfall project management. In fact it is for this sort of situation that product descriptions and GANNTT charts were invented.

Build me a brand new thing

Let’s suppose that, flush with my successful delivery of a signalling system, my company decides that they want to market a brand new signalling system. This will be a signalling system to rule them all. The marketing folk want to demonstrate it at the global signalling expo in 6 months time and they have a long list of things they would, in an ideal world, like it to do. This project also has some distinctive features:

– it is incredibly important to deliver something on time. If we can’t demonstrate something at the global signalling expo then we can’t sell it.

– I don’t need to get it exactly right. OK the marketing folk have a wish list but if I only deliver half the things on their list that’s still better than what we have now. And if I asked them if they would like half the list delivered in time for the expo of the whole list 6 months later, we know what they would say.

– there is a limit to how much I can reduce the risk of this going horribly wrong through planning. Because by definition we have never built a signalling system like this before. In fact, hopefully, no-one else has. It would be more sensible to start and to keep checking how we’re doing against the wish list (iteration).

This is a job for Agile project management. Time is a constraint, specification is flexible and we’ve never done this before.

Save me

Now let’s suppose I’ve moved jobs. A train has come off the tracks (not as a result of my excellent signalling system). Hundreds of people need evacuating, many are injured, some seriously. Perhaps 150 people are involved in the response from over 10 different organisations. People need help right now. You’ve guessed it, this project also has distinctive features.

– the situation is very complex and likely to change rapidly. And at the start of the project we have a fairly hazy picture of what is going on.

– we must start delivering immediately.

– planning can help to reduce the risk of things going (more) wrong. We can’t plan for this exact scenario but we can imagine that sometime, somewhere a train might come off the rails and so we can think about how we might approach that situation. That said we will need to allow flexibility because we know that every situation will be different.

– short term and rapid planning can also help to reduce the risk of things going (more) wrong. We can get some people to think about how bad things might get and start planning for those situations: what if all the passengers needed to go to hospital for example.

– resource is not a primary constraint. That said, we can’t magic money or trained staff, or ambulances out of thin air. We’ll need to find them, get them to the scene and work out what is going to happen to the jobs they were, presumably, supposed to be doing.

This is a job for integrated emergency management. Work must start immediately. The situation is complex and poorly understood. Resource is not a primary constraint.

If you think Agile looks crazy you should investigate IEM.

Common features

Ultimately project management is about getting the job done, as well as possible.

There are surprising numbers of common features between all three techniques (though they handle them in very different ways):

– communication is key

– senior people need to take big decisions but if they micromanage they increase risk

– people working on the project need to know what the task is

– people working on the project need to be familiar with how the project is managed

There. I’m not sure anyone else is interested but, in the future, if I have directed you to this page it is only to save you 30 minutes of increasingly frustrated ranting.

And I’d be really interested in your views…








One reply on “Project management methodologies: again”

Comments are closed.