The Difference between Plans and Planning
Some people don’t like plans. To them, plans feel too rigid, too restrictive, too inflexible. These people don’t like to be boxed in, tied down, or locked up.
Of course, there’s a difference between not having plans when you’re heading out on a bike ride and not having plans when you’re carrying out a multiyear, multimillion-dollar project.
There’s also a difference between plans and planning. As former president Dwight Eisenhower famously said, "In preparing for battle I have always found that plans are useless, but planning is indispensable." This is true not just in battles. Whether for an event, a project, a trip, or anything else, it’s rare that a plan proceeds precisely as set forth at the outset. Almost always—and especially in software projects—problems emerge that disrupt or divert progress.
But the fact that plans may have to change does not mean that planning is a waste of time. In fact, it’s just the opposite. Planning is a deliberate, continuous process of evaluating and discussing what the effort needs to accomplish and how it can do so. It's also an opportunity to consider the obviously relevant factors, such as budgeting, resources, and timelines, and to identify other factors that may be equally relevant but are easy to overlook.
One of the key benefits of planning is to help you think about what can go wrong in carrying out a project. Dilbert’s boss may consider it stupid to plan for failure, but it seems foolhardy to ignore the vast number of ways that projects fail and to blithely move forward as if success is guaranteed. By considering the worst-case scenario, or even just some of the undesirable case scenarios, you’re in a better position to avoid those situations or to recover from them if they occur.
It may help both those who favor planning and those who are averse to it to determine where planning is valuable and where it’s stifling. Planning may be justified when the effort is complex, expensive, unfamiliar, or a fast track to disaster if things go wrong. But in other situations, going with the flow and letting things play out may be a better approach.
Planner though I tend to be, I’ve found that we learn the most—and often have the most fun—when we don’t do too much planning. But I’d never recommend that approach for software projects.
