During the first World War Winston Churchill famously lost his job as First Lord of the Admiralty as a result of the failed Gallipoli campaign (despite it not really being his fault). He then oversaw the far more difficult and arguably more important effort of taking on the Axis Powers in the second World War. You might say he had plenty of experience, both good and bad, about plans and planning.
“Plans are of little importance, but planning is essential” – Winston Churchill
The Cynefin Framework suggests that in complex environments plans have limited value. What sort of planning is valuable then? In general, we can say that the longer the time-frame between cause and effect, the less we can reliably predict the outcome of our actions – making detailed planning highly perishable. There are also effects that become more unpredictable when higher levels of coordination and collaboration is required. This would suggest a difference between planning at the strategic large-scale vs planning at the more tactical small-scale.
Whilst war is not a perfect analogy for product development, they are similar in terms of complexity. The level of planning needed on the battlefield depends on the chosen strategy (blitzkrieg, trench warfare, maneuver warfare, guerilla warfare). Consider also how much planning sports teams do. Coaches and managers are often seen as responsible for strategy for the game (or season) while the players themselves are responsible for tactics at the individual level from moment to moment. Some planning is needed to pull off a particular strategy (say a wider formation to better leverage your team’s strengths). Different strategies require collaboration, coordination and indeed discipline to be effective. At the opposite extreme, the internet and P2P networks operate without detailed planning. Instead, there are a set of process policies to handle the flow of zeros and ones.
So it seems that the level of complexity affects the value of planning. The more complex a system is, the less value a plan is likely to have. Because product development involves a lot of variability and many “known unknowns” this makes it inherently complex. More specifically, there are three things we know to be true about software: The customer doesn’t know what they want; the developer doesn’t know how to build it; and things change. On top of this there are the “unknown unknowns” that Nicholas Nassim Taleb wrote about in his book “The Black Swan”. With these as system conditions we can see that the value of planning is fairly limited. This is important because you can’t really make an effective plan for things you don’t know. You can make a plan to react, but any more detail or specificity than that is likely to be waste.
Given these conditions, why might planning be “essential”, even in complex environments? Perhaps we might attempt to separate out two important aspects of planning, at least from a product development perspective: planning the delivery vs planning the product.
Planning the delivery
Most of the plans we see in software development are about trying to work out how you’re going to do what needs to be done. We often find ourselves going to the proverbial nth degree of scheduling and identifying dependencies and constraints of the delivery. The questions this attempts to answer is usually: when am I going to get it, and how much is it going to cost. Unfortunately, our ability to predict these parameters are pretty useless. This is especially true when you haven’t even started delivering, when it’s almost entirely guess-work.
Despite the painful experiences we’ve had when it comes to planning the delivery of software, we still whip ourselves, trying to make it work. “Plan the work, work the plan!” is the refrain ringing in our ears. Perhaps if we try harder this time, spend longer, maybe it’ll work. It’s a necessary evil though: zero plan isn’t going to fly. The only trick we’ve discovered that works here is to restrict our plans to short horizons. Like 2-4 weeks.
But that’s not enough I hear you cry, and I’d agree. In my view, the more important thing to focus on is not about the delivery, or “how you’re going to do it” though – it’s about the product or desired outcome (the “what needs to be done”).
Planning the product
What does need to be done? Strangely (or not, as it’s basically human nature) the scope of a project is often the least questioned aspect. Whilst I’m not a huge fan of MMFs or MVPs (or any other “minimums”), they do encourage some thought about what the smallest increment of value might be.
Even better, consider a feature injection approach with a CD3 ordered dynamic priority list to order the features by. To complement this, sketch out how the product might evolve over time and consider how the pieces (or features) might need to fit together from the customer or end-user perspective. This sketch of how the product might evolve could suggest adjustments to the Cost of Delay of individual features. Often, this is either because of information value associated with testing assumptions about market risks, or technical wrong turns and dead-ends. In these cases having that information earlier is valuable to you so you don’t build the wrong thing, or build it the wrong way. A sketch of how the product might evolve should answer questions like: which features to start working on first to validate assumptions; which customers or users to target first; what is needed to make the product coherent; when might the product become a usable increment (as opposed to simply another iteration of unrealised value). None of these require time-frames. I’d go so far to say that attempting to put time-frames on it is a fools game.
So, when considering planning it can help to separate the planning of the delivery and the product – if you possibly can decouple these two aspects, even better. Like so much in software and innovation, the best route from here to there is something you discover along the way. So perhaps the best plan is one which plans the product as a series of short bursts. Act and react. Act and react. But make any plans you produce about the product first, fast learning second – and the date when it will all be done, last.