Oct 162014
 

I was listening to an old Java Posse episode, when the topic of a 5-year plan came up, only to be immediately be met with disdain and contempt. In fact, nobody took the idea of long-term planning seriously. What I don’t understand is, why? What’s wrong with having a plan beyond the next iteration or 2? Personally, I think with agile development we’ve gotten so used to short development cycles and rapid release and pivots that we’ve completely lost any and all sense of the point of having a long-term plan. The fact is, if you don’t have any type of long-term plan, then your entire business strategy can be summed up as “we’re putting out this fire and hoping for the best.”

First and foremost, let’s remind ourselves just why we have long-term plans in the first place. Multi-year plans exist to give people a big-picture of what they’re doing. More importantly, it answers the question of why they’re doing things the way they are. A long-term plan is the difference between running around like a chicken with its head cut off and having a purpose. What makes long-term plans valuable aren’t the details of how to carry them out, but rather having that reference point of what you’re working towards.

Most people’s complaints about things like a 5-year plan stems around the fact that things change so quickly they can’t be accurately predicted multiple years in advance. This is sort of implying that the people who built things that have effectively changed how life operates merely got lucky, or that out of all the things that got thrown at the figurative wall, those are what stuck. I’m pretty sure most people who are consistently successful in business won’t tell you that “throw crap at the wall and see what sticks” is a particularly sound business strategy.

It’s almost as if the people who scoff at these types of plans have no understanding that they aren’t carved into stone – it’s totally possible (and in fact a great idea) to change your long-term plan. Just because you have some type of long-term of what you’re doing and what you’d like to accomplish doesn’t mean it’s permanent – you’re talking about several years out for crying out loud. Not changing the long-term plan is probably more stupid than not having a plan in the first place. You should be adjusting your short-term plans as things change, and revisiting your long-term strategy every year to make sure it still makes sense. And if things change to the point where your long-term plans are utterly pointless, then you re-write them.

We’re totally OK with the idea that our short-term plans need to shift (or “pivot” as all the cool buzzword-using kids say these days), so why do these same people have such a hard time grasping the idea that long-term plans can’t change? Or are they seriously saying that the fact that long-term plans have to be changed regularly makes them pointless? That’s the whole point of rapid iteration in software development, you can change the plan on the fly with very little notice. However, all of the short-term changes need to either keep you on track with your long-term goals, or they should letting you know that your existing long-term plans are out of date and it’s time to re-think just where you’re going with this stuff. The point here is that any decision you make should be informed by some type of big-picture thinking, and you can’t have big-picture thinking without a big picture in the first place.

I’m not trying to come down on the idea of rapidly adapting and iterating as part of the development process, but I am trying to emphasize the role importance of having some context for all that rapid change beyond the immediate needs of the moment. Otherwise, you’re just running around like a chicken with your head cut off, and that lack of clear end state is ultimately going to do more harm to your product than good. You’ll be so busy running around doing whatever random thing seems pressing at the moment and ultimately you’re trying to sell a disjointed mess. Your business will be pretty much the same thing. “Well, we were selling software that did this, then we pivoted to a big-data services company, then we focused on solutions delivery, and now we’re a SaaS thing I think.” Your long-term plan is there to keep you focused, and your eye on the prize.

There is a point in the fact that there’s no way you can accurately predict what things will be like several years out. But your long-term plan shouldn’t rely on being able to predict the future years in advance, instead your long-term plan should be a fully-formed description what you consider to be a “win” state, along with the conditions that need to be met to achieve it. “Dominate the market for XXX” isn’t a long-term plan. “Offer our products/services in all 50 states, and have our services available to customers anywhere, at any time” is a better start, but still needs to be improved. Your short-term decisions should be the decisions that get you to that winning state. When your goal scenario starts to look unhinged from reality, you should stop and re-define what having achieved your end objective will look like before you start trying to make any serious business decisions. Remember, the point of your long-term planning is to define your purpose and to frame your decision-making in the present, not present of set of unalterable steps that cannot be changed until your 5 or 10 year commitment has run its course.

Your backlog is perfect for tracking your progress towards your long-term plan’s goals. As you get to a point where you’re ready to flesh out the details of how you intend to implement said long-term plan, you can start fleshing and tasking out your user stories and schedule them appropriately. Since you ought to be going through your backlog regularly anyhow, that process will serve as a good reminder to re-visit your long-term plan, especially if you find yourself trimming several stories out of the backlog or adding a lot of new ones. As stories get broken down, tasked out, and scheduled, you can also get a good sense of progress towards your long-term goals. It also gives your developers a good concrete reference for the type of work they can expect to see in the future. They can then, in turn, make decisions based on what the backlog looks like. In other words, by keeping your long-term plan up-to-date in the backlog, it gets your entire company thinking strategically and acting accordingly. Because you’re detailing and executing your long-term plan in small, discrete chunks, you still have the option to adjust it on-the-fly with a minimum of chaos.

While you’re  busy getting the benefits of using a long-term plan to stay on point, it’s also helpful to have some type of deadline by the time you want to have achieved your goal. Just like you don’t want the plan itself to get too bogged down in details, you probably want to keep your timeline relatively generic, something like “Fall <insert year here>” for instance. This just helps reinforce the idea of using your long-term plan to track your progress on your various goals and to stay on task. Remember, your long-term plan defines a successful “win” state, but it’s also nice to have an idea of when you intend to reach that point. The deadline helps inform of when and how your plan should change? Not going to hit your “win” condition by the time you thought you would? Then it’s time to go back to your long-term plan and reconsider just what you were hoping to accomplish and how you intend to go about it.

Long-term planning gets an unnecessarily bad rap, and it’s pretty undeserved. People seem to operate on the assumption that long-term strategies are more detailed than they need to be, and that they’re static. None of these are true. What long-term plans do give you is strategy, purpose, and big picture to work towards. They inform your team about how best to design your products and services, drive your backlog and product decisions, and keep you focused on what you really ought to be doing. They’re a vital part to being successful, and shouldn’t be dismissed or overlooked. Instead, you should not only have a useful long-term plan, but you should be regularly maintaining and updating it. If you ever intend to be successful, you’re going to need a plan, and you need to be checking in on that plan regularly to make sure you’re keeping your eye on the prize. Or you could go through with the “throwing crap at the way and see what sticks” strategy, I’m sure great things come from that as well.

 Posted by at 11:35 AM