Magic fairy dust

A confession

I like the Agile approach to project management,

There I’ve said it.

I’m trying to resist the zealotry of the new(ish) convert but there is a programme I’m involved in where my colleagues have started timing how long I can go without starting a sentence with “In Agile…”

Not long typically.

But I also like the waterfall approach to project management.

PRINCE2 is my preferred poison.

Which is something very few people confess to.

And I also like the IEM approach to project management which is not often described as project management at all. (That’s Integrated Emergency Management, it’s how we co-ordinate efforts to look after people in emergencies and try to return everything to normal quickly).

And I have come to the conclusion that there is no magic fairy dust.

There is no single way in which projects (or change management processes or whatever it is that you want to do) can or should be safely delivered.

There may be the right tool for the right job

1 Where you know what you are doing

Projects that are delivering in a well understood environment are probably best run in a waterfall framework. So the comms work necessary to deliver a change in bin collection services if probably best planned using products and managed using ganntt charts. It benefits from lots of planning up front and then just getting on a doing.

2 Where you don’t know what you are doing

Projects that are delivering completely new products can’t be safely delivered in waterfall. If you have no idea what the new product looks like then planning is largely meaningless. Agile provides a much better framework for this. Transformation or change processes should look much more closely at Agile IMHO

3 Where you want to start delivering straight away

If you are under pressure to start showing some results (or at least progress) immediately then you, probably, don’t want to use waterfall. I can see ways in which quick delivery could be crowbarred into waterfall but frankly it’s not what it’s for. Agile is exactly the right approach for jumping in quickly and then changing your maind.

4 Where you want a big bang

If you’re delivering something that will be a big bang at some point in the future. Like, for example, a football world cup tournament, then Agile is probably not the right approach. This is, in fact, the key use case for waterfall. Except because Agile is timeboxed it can be suitable for delivering something on a defined date, as long as you aren’t to worried about the scope of what you get on that date.

5 Where you want to co-ordinate lots of organisations

Multi-agency projects can be a real challenge. One way to handle this is to create a financial or contractual relationship, so that one organisation buys things from the other organisations. If you CAN do that then waterfall or Agile as appropriate will probably work well.

If you can’t do that then neither will. Agile adherents would probably argue that Agile has more to offer because of the emphasis on teamwork and visibility and I would tend to agree.

But I think Integrated Emergency Management has a lot to tell us here. Essentially IEM emphasises teamwork and communication (like Agile) and rapid delivery (like Agile). But unlike Agile it provides a framework for scaling projects and involving all levels of the organisations whilst keeping a focus on delivering the work at the coalface.

Enough already

This has been rambling on to long enough now. I might return to this IEM theme at a later date.

Or my butterfly mind might take me elsewhere completely.