Having a Strategy is Not Having a (Rigid) Plan
One of the biggest problems getting started with a development project — especially one where some of the work is being outsourced — is getting over the need for a concrete plan at the start of the project.
I suspect this is because many people are mistakenly confusing having a plan with having a strategy. Both are necessary for moving forward, of course. Strategies need to be clear before you start, and change very little. Plans, on the other hand, can and should change as the project unfolds.
Master the distinction, and you will find that a lot of the work that goes into specifying a project is just wasted energy.
Strategy vs. Plan: The Main Difference, Illustrated with a Road Trip
While both are required to achieve a goal, the main difference between a strategy and a plan is that of how vs. what.
A strategy describes how you intend to achieve your goal. It’s the approach to the endpoint. A plan details what you will do. It outlines steps, processes, deadlines, and milestones; and it is informed by the strategy.
It might be helpful to think about the distinction in terms of a long family trip. Let’s say your family is taking a trip to Disney World. That’s your goal. Your strategy would be how you intend to get there — for example, by driving (road trip!).
The plan would dive into the details of this trip, which can only be determined once the strategy is in place. When should you leave home? How many hours will you be on the road? Where do you plan on taking rests? Which route is the fastest to take? (Will you trust Google’s directions, or strike out on your own?)
Naturally, you will want both a strategy and a plan at the start of the road trip. But notice that your plans might change while you are on the road. Maybe you plan on a pit stop in Atlanta, , but one of your kids really needs to use the bathroom in Nashville. Or maybe your significant other discovers that there’s a cool roadside attraction worth a small detour. Or you could simply be making good time, and so have to find a lunch place a little further out.
In short, plans change as conditions change in pursuit of your goal.
At the same time, the overall strategy does not change. Your family still wants to end up at Disney World, and you are still getting there by car (versus, say, flying). Having your plans change simply means that: What you are doing differs a little from how you pictured things at the start. But if your strategy changes, you are now doing something entirely different, by definition.
The Important Part: Your Strategy Should Include Having Flexible Plans
Here’s why the distinction is really important to grasp: For many types of activities, your strategy should include that you will have flexible plans that change as the project develops.
That doesn’t mean you should never have any sort of plans to start. It’s OK to have an idea of what step 1 is. But you should anticipate that your plans will change. No, more than that — you should desire that the plans change to accommodate the evolving situation. That is really what agile frameworks are getting teams to do.
And that means planning out every step or milestone of a project from start to finish is just a waste of time. You could spend weeks, even months, outlining steps one through twelve, only to discover at step three that plans need to change in order to stay true to the strategy.
It is equally dangerous to have flexible plans but no strategy. Flexible plans without a strategy to guide you are just random changes. That can lead to a lot of busy work — either abandoned half done tasks, redundant work, or both. It can also lead to indecision, or vacillating between different decisions (“thrashing”). Without a strategy as the north star, flexible plans become a hamster wheel of change.
Why Plans Need to Change When Developing Software (or Any New Product)
We have had clients come to my company with binders full of requirements, deadlines, and milestones to hit for producing their software product. Their impulse was to plan everything out so that there were no surprises, especially when it came to budget and timelines.
In my experience, having everything planned out does not prevent budget and timeline surprises. In fact, the opposite happens.
Consider what kinds of things can happen during development — the software equivalent, if you will, of restless children and roadside stops:
- A new feature is deemed necessary.
- Several features that were originally deemed necessary turn out not to be so.
- A major defect becomes apparent.
- Stakeholders come to understand a new requirement (or modify an existing one).
- A competitor comes out with a better, simpler, slicker product before you.
- A new technology is developed that the team can take advantage of.
- Someone discovers a new and exciting use for an existing feature.
- The talent needed for completing the project faces turnover due to external factors.
I’m sure there are more. Given this list, it is surprising that a development project ever meets all of its deadlines and budget constraints. The fact that they rarely do is not a fault of the teams themselves. More often than not, it is the fault of the plan.
Going back to our road trip metaphor: Imagine if I rigidly forced my family to stick with a Disney World road trip plan that I had crafted entirely while sitting at home:
- When my wife finds that cool roadside attraction worth the detour, I say “Nope — we’ve got to make time and get to the next rest stop!”
- When my kid needs me to pull over for a bathroom break, I refuse to stop.
- When our progress is hampered by an accident on the road, my wife offers a shortcut she finds on Google maps…but I respond “Thanks, but we’re locked into route.” Hours later I curse my luck, wondering why we’re not making good time.
- When the car develops a strange rattling noise, I shake my head and say “Having a mechanic take a look is not within our road trip budget.”
- When there are signs for a road closure ahead, I carry on…
Rigidly sticking to the plan doesn’t make me a responsible steward of our time, money, and sanity. It just makes me a jerk.
A successful road trip means that part of my strategy for getting to Disney World should be to have flexible plans that develop as we go.
If that’s true for something as straightforward as a road trip, it is definitely true of software development.
So, if you are in a role where you hire developer talent or help to outsource it (IT leader, Product Manager, etc.), I challenge you to shift your thinking. Leave the binder behind. Get clear on your goal, get your strategy in place, and include the idea that you will develop your plans, over time, with your developers. Do that with developers who also get this distinction, and you will find that the road ahead is much smoother, and the trip much more pleasant.
