I recently re-read Dwight D. Eisenhower’s 1957 speech (link) in which he referenced this famous paradoxical quote “Plans are worthless, but planning is everything”.
As a software leader/manager/developer, when I encounter resistance during the planning and design stages of software projects, the source of miscommunication often stems back to this fundamental concept of “plans vs planning”.
This approach to planning, as it turns out, is rooted in the US Army. And as an Army Veteran, I suspect I’ve picked up this philosophy through osmosis. The intent of this project management exercise is to help teams overcome roadblocks through “planning”, but not necessarily to create a perfect “plan”.
To better understand this principal, let’s look at Eisenhower’s comment in more detail. In the full context of this quote he says:
“I tell this story to illustrate the truth of the statement I heard long ago in the Army: Plans are worthless, but planning is everything. There is a very great distinction because when you are planning for an emergency you must start with this one thing: the very definition of “emergency” is that it is unexpected, therefore it is not going to happen the way you are planning.”
Eisenhower is acknowledging that the act of planning is synthesizing and imagining an unpredictable future, and that the outcomes of a plan do not reflect how things will actually unfold.
Although he’s referring to planning in the context of emergencies, it generally applies to any planning processes in chaotic environments; such as Software Design and Development.
Why dwell on what could go wrong in a project?
This practice is rooted in Stoic philosophy. Seneca wrote that “nothing happens to the wise man contrary to his expectation”. The Stoics practiced “negative visualization” — meditating on worst case scenarios outside their control to eliminate the unpleasantness of surprise.
But what if you can control certain unpleasant surprises? The art of risk management is taking preventative steps to ensure fewer surprises beyond your control.
Okay, so back to President Eisenhower and his approach to iterative planning:
“So, the first thing you do is to take all the plans off the top shelf and throw them out the window and start once more. But if you haven’t been planning you can’t start to work, intelligently at least.”
This statement refers to the dilemma of getting started on a project. When undertaking software projects, the greatest obstacle is simply writing that first line of code. So give yourself some basis of dialogue with an initial plan and a prototype, then throw that away, if necessary, and start on the next iteration.
“That is the reason it is so important to plan, to keep yourselves steeped in the character of the problem that you may one day be called upon to solve — or to help to solve.”
He’s basically saying that planning puts you in a position for success, so when the actual events unfold, you are that much closer to making the detailed decisions to ensure a successful outcome.
“Now in the statements I have made, I don’t mean to say there are not some verities, some unchanging truths, although again, to quote a military man: The only unchanging factor in war is the most changeable, uncertain, unpredictable element in war, and that is human nature. But the human nature of today is exactly what it was, apparently, in the time of Pericles and Alexander and down through the ages to this day. Everything else, even terrain, even weather, seems to change.”
Software is deterministic, but people are not. We program machines to do exactly what we want them to do, but projects largely revolve around people. Therefore any plans that make assumptions based upon the actions of people are non-deterministic and subject to change.
A good leader understands that people on the front lines will ultimately make the final decisions, therefore the goal of planning and plans are simply to prepare people for what they might encounter, and trust they’ll do the right thing when confronted with complete information.
Coincidentally, the Manifesto for Agile Software Development adopts this spirit of planning, just in different words. Learn more….