Is reactive planning a good approach to running projects? Or is waterfall a better approach?

I often tell my wife that I am a lucky project manager – that I can often just let things play out let them come together. 

My wife claims it is not project management at all if there is no planning and no management.  She is right of course, but there is such a thing as “reactive project management” which pushes the boundaries a little.

Reactive project management means starting the project with a rough idea of what to do but no clear plan.  Then you form a plan as events unfold.

This is a common approach in television shows where high drama results from watching the characters almost die each episode.  So, should we plan projects the way they do in TV shows or is that a little dodgy?

Forming a plan as you go can be a valid approach to projects in two situations that I can see:

1. Crisis management where the original plan just went out the window.  In  these cases it is necessary to keep moving forward while coming up with a new plan.  I have used this approach in disaster recovery situations and it is both more fun than watching TV and very effective.  But these projects only last 24-36 hours, and after that I think it is time to down tools and do some formal planning if things are still dragging on.
2. Pure research where you don’t know what opportunities or risks exist in a situation and you want to experiment for a while to see what you can learn.  For example if you want to know how Ipads work with your internal IT systems you might give some ipads to some developers and tell them to play with the new toys for a couple of weeks.  This can be quite effective as long as you (and your paying customer) are clear that all you are likely to get from the exercise is some more knowledge rather than any clear deliverables.
3. Where situations are so unheard of and people so clever that the best thing to do is to train them well and then parachute them in to work out what to do.  This is similar to the situation above but aims to achieve an actual outcome.  In this case though you would have to assume both a high risk of failure and an almost innevitable series of hits, misses and rework.
4. When things are trivial or simple so there is no need to plan.  Of course these situations rarely constitute projects.

So if we define “agile projects” for a team as “coming up with a plan as we go” then I think the approach will have only limited use. Yet on many projects, if you ask the team what the plan is then they will look confused or tell you that they don’t really have time to plan.

This is good news if you want to be involved in high drama (like tv shows) or in rescuing the project down the track.  But generally it spells trouble, as predicted by the old waterfall saying that “failing to plan is the same as planning to fail”. 

In these cases I would say that predictive planning (waterfall) is generally a better approach than what the team is calling “agile”.

So I think I have established that agile is generally better than bureaucracy (see my previous article) and waterfall is generally better than letting a plan emerge as you go.