Failing to Plan is Planning to Fail

Winston Churchill

It was Winston Churchill, during World War II, who memorably said:

He who fails to plan is planning to fail.

But in our smaller projects how many times should we plan, and when?

I propose 4 possible answers: 0, 1, 2, many times.

0: Seat of the pants
This is perhaps permissible for small tasks, and certain expert work, especially when it's been done by said experts many times before.  Jazz musicians and theatrical improvisors are ace at this.

In software development this is called "cowboy coding", and is not recommended for serious projects.

1: Classic waterfall and variations
The big risk here is that on larger projects that if and when the plan fails, we must now re-plan (and we've already blown our whole planning budget) or follow the original plan to ruin.  If the project is long, complex, requirements are poorly understood or subject to change it is prudent to reserve a portion of the planning budget for later re-planning.

A superior variation to doing all planning at the start of the project is what I call "research then development".  This consists of a research phase at the start with no planning in which prototyping and other risk-ameliorating work is undertaken, before the big plan is laid down.  It allows for key learning during the research phase.  From a governance perspective these two phases may be considered as separately funded projects.  It's only after the research phase that we are in position to estimate the cost of the more expensive development part.

2: Build one to throw away (and other variations)
Buiding a cheap prototype to explore risks and gain understanding of the challenges of the particular project before locking down the full plan is quite a good strategy.  Recommended in the original waterfall paper by Winston Royce and by Fred Brooks in The Mythical Man Month (although Brooks now advocates the next approach).

Many times: The Agile way
If we accept that projects involve learning, then it makes sense to plan repeatedly, first in a broad sense, and then refining as we learn more.  Adaptive planning embraces change, both in inner factors (learning) and outer factors (changing requirements or circumstances).  The refinement of fixed length iterations and repeated planning encourages us to expend our planning budget over the course of the project, and minimizes the amount of early planning under incorrect or outdated assumptions that is not only a waste in itself, but also leads to other misguided (hence wasteful) activities.

Conclusion
What would Winnie do?  The picture suggests that he would plan twice (or possibly follow the V method of development!).

For my part, bad experiences with too much planning up-front (and the consequent waste and lack of resources to re-plan) led me to more successful iterative and incremental approaches, and later to the shorter, fixed length iterations of Agile.

Agile is, in part, about not being surprised "when our best laid plans go astray", and instead of being disappointed or abandoning planning, "planning to re-plan" ... cheaply.