No Plan Survives First Contact With the Enemy

... or friends, for that matter.

This saying, from the context of battles, applies equally to projects where outside influences are significant.  Initial planning swiftly becomes outdated, so it wise to plan at first in only broad brush strokes -- at a high level -- perform detailed planning as we go along.

For those who have limited experience as military command consider instead a game of chess (or checkers).  One might go in with certain intentions (play aggressively, use set plays when possible), but there is no way that you can plan out the whole game in advance!  You might plan a few moves ahead, but as soon as your opponent moves, everything shifts, and it's time to re-plan.

1972: Fischer challenges Spassky

As for friends (or family), suggest a plan and they'll want to get on board ;-) too!  Your plans will shift.  In a project this is the equivalent of an internal customer or product owner suggesting a better idea mid-way through the project -- and you acknowledge that it really is better.  Hmmm ... better re-plan.

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.

The Agile Triangle

Jim Highsmith gave a great opening keynote at the 2010 Agile Australia Conference.  One of his most striking visuals was a proposal to replace the traditional "iron triangle" -- cost, scope, schedule -- with an Agile upgrade:

Note that the original triangle has not gone away; rather it has been subsumed under Constraints.

The full slides of the talk are available, as are more extensive reports of the session from Craig Smith and my colleague Shane Hastie.

The Agile Triangle

1. Value: releasable product
2. Quality: reliable, adaptable product 
3. Constraints: cost, schedule, scope

In other words, in Agile we're looking at a bigger picture: making software that organizations want, because

• they deliver real Value now by addressing reals needs, even if these weren't well-captured at the start of the project, and
• are of a Quality that will stand up now, and also and in the future when modifications are (inevitably) required, while 
• smart choices are made to keep the Constraints under a reasonable level of control.