Life is all about balance, live too conservatively and you run the risk of missing out on life’s adventures and opportunities. Live too wildly and you run the risk of misfortune and regret, we have to walk a fine line guided by our personal view of where that correct boundary is.

Planning is similar; the adages of “Look before you leap” and “Cross that bridge when we come to it” speak to the differing views towards project planning. However, instead of being guided by some moral compass, we should be guided by the quality of our planning inputs and likelihood of changes.

To some people a mentality of “Cross that bridge when we come to it” strikes them as the irresponsible abandonment of project management rigor and fiscal responsibility trusted to them by project sponsors. Why would you not always do as much planning as possible before starting a project? Surely, that is only right and proper! Well, not if doing so would be harmful, it all depends on the quality of that input data. When the input data is good, we can reliably plan, when the input data is bad, or the project’s final destination is likely to change then we need to get better data and keep evolving the plans.

When aiming at a fixed target it is appropriate to aim, aim, and aim some more and then fire. In the project world this is akin to plan, plan, and plan some more and then execute. However, when trying to hit a moving target this approach is ineffective. Where do you aim? Where the target is right now, where you think it might be next, where you hope it might be at completion time? Instead a different approach is needed; something more like a guided missile that makes many mid-course adjustments to hit a moving target.

When we know our project requirements may change, or there is technological uncertainty, or market volatility from competing products, we need to equip the projects with the abilities to make multiple mid-course adjustments. Instead of plan, plan, plan we point the team in the right direction, get them started and give them the tools and authority to make these mid-course adjustments through build feedback cycles to hit that moving target.

Jim Highsmith says it best, there are times when “You cannot plan away uncertainty; you have to execute away uncertainty”. It is not really in the best interests of the sponsor to consume project time and budget trying to plan something with incomplete or erroneous data. It would be more prudent to get closer to the problem, try a few things and then come up with a better plan now we have more information.

Yet this idea of doing less upfront planning presents a large obstacle to many stakeholders because the words we often use to describe exploratory information gathering are poor. For a start we don’t often call it “exploratory information gathering” instead using phrases like “we will build a small portion”, “start coding”, or “do a spike”. To people not familiar with why we are doing this work it seems counter intuitive and rash. So, we can do ourselves a favour and use words like “more data gathering”, “proof of concepts” and “options exploration” instead of “development” to explain the goal of this work.

Another tool we can use to convince the skeptics that less upfront planning is sometimes better value is the planning-risk graphs developed by Barry Boehm. The first risk presented by Boehm is the obvious risk of not doing enough planning and running into problems of people not knowing what they are doing, duplicating work, and building poor solutions that need to be corrected.

From the graph above, we can see that as more time is invested in planning, the risks due to inadequate plans reduce. While these risks are intuitive, there exists another set of risks that are less intuitive or obvious; the risks of doing too much upfront planning. 

This second, red line denotes how the risks of creating very detailed, brittle plans that do not survive contact with reality increase as we spend more time planning. So too do the risks of delaying the project and getting a late Return On Investment (ROI) because the project spent too long in the planning phase.