Faulty Assumptions in Strategic Planning

When I say that the assumptions of traditional strategic planning are obsolete, which beliefs am I talking about? There are quite a few premises that are no longer valid:

• Managers know best: One of the key lessons that lean has taught us is that those closest to producing the actual, customer-facing value are most familiar with their constraints, struggles, and challenges, and are as likely as senior managers in the executive suite to have practical improvement ideas. The exclusivity of the traditional strategic planning model is one of its fatal flaws. Disconnection from the teams in the enterprise, the customers outside, and the reality of the dynamic, disruptive marketplace killed Kodak, and tolls the bell for all those who only face inward.

• Strategies can be built without input and feedback from the customer: In the traditional planning model, the executive team members strategize in isolation from their own customers, proceeding under the assumption that the past is predictive, that their read on the marketplace is correct, and that they know better than their own customers what the market values. Rather than getting out of the building and collaborating with customers, traditional strategic planning occurs in an off-site conference room or executive boardroom, with only internal players involved.

• Strategies can be long term: As noted previously, the long term gets shorter every year. As new entrants, new technologies, and new business models emerge on a faster cycle, plans become outdated quickly. As we’ve learned from waterfall software development, by the time the customer has a chance to react to the product, the market has evolved, and the product addresses last year’s needs. Adaptability trumps predictability every time. The idea that we can foresee the shape of our marketplace two years or even six months ahead is a fallacy.

• Experimentation and risk aredangerous and should be avoided: Traditional strategic planning, especially at old-line firms that believe new ideas will endanger their brand image and reputation, often relies on “brand extension” rather than innovation. Cherry Coke is a brand extension, but Red Bull is an innovation. Cherry Coke may incrementally improve results, appealing to a narrow segment of cherry lovers, but Red Bull creates a whole new category. Innovative companies, like Google and Amazon, aren’t afraid to try new ideas, test them in the marketplace, and retain or discard them based on customer reaction. The failure of the Amazon smartphone didn’t damage its brand, and the resounding rejection of Google Wave didn’t stop Google from learning about its customer’s preferences and trying again with Google+. Experimentation and failure, as long as it’s not existential, is a learning experience, and learning from prototypes and customer feedback loops turns out to be less dangerous than not venturing at all.

• It’s all about the data: The image of the 20th-century executive brings to mind a man in a mahogany-lined office, poring over a stack of green-lined computer paper and examining the data from last quarter, or last month. Sales numbers, year-over-year comparisons, competitive analysis, trend lines: these were the driving factors for the man in the gray flannel suit. Data was difficult to obtain, required large investments in computing power, and was thought to hold the key to competitiveness and success. Now data is ubiquitous, much cheaper and easier to get, and instantaneous; the problem becomes separating and analyzing the meaningful data from the dross, in real time. The “big data” problem is too much data, too fast, and too cheap, and competitive advantage is drawn from quickly figuring out which data to act upon. Google and Facebook give away the service to capture the data, and then build their strategies around what they’ve gleaned. Strategies based on last quarter’s data can only address last quarter’s problems.

• Stick to the plan: In the traditional model of project management, success meant on time, on budget, and within scope. Customer value wasn’t part of the equation, and the highest good was building a plan and sticking to it. Variance from the plan was a signal of failure. With the ascent of lean and agile thinking, we now understand that cost and schedule are constraints, but value is the goal. The same is true in strategic planning: those who stick to a plan are likely to be left behind in the value race, as customer needs and desires change. Adapting the plan, delivering minimum viable plans incrementally, getting rapid feedback, and letting that feedback drive your subsequent iterations is the new normal in strategic thinking.

In short, most of the assumptions and beliefs that were handed down from the military strategies of World War II, and became the basis of corporate strategy during the 20th century, are in question in our current business environment. Everything we did to gain efficiency and guide execution in the command-and-control organization is being challenged by the innovation and transparency brought by technology and the Internet. Migrating the dynamism of agility to the static domain of long-term, top-down strategic planning is the next step in enterprise evolution.

Adaptive Strategy

We’ve identified ideas and assumptions that no longer apply, which begs the obvious question, what does? What works in strategy today, and how is it related to the agility to which we’re guiding our clients? When the past is not prologue, and certainly not predictive, looking back on the successes and failures of the past loses its value. The deluge of data, generated in real-time by every transaction and every click, makes the selection and recognition of pertinent information more critical than trend lines and rear-view reports. The hierarchic command structure , with orders flowing down and compliance flowing up, does not result in the best outcomes. Each of these foundational ideas of strategy now must be questioned and adapted, based on the markets we play in and the customers we hope to attract. As in agile software development, strategies emerge, as leadership engages with the marketplace, the customers, the technology, and its own teams.

In Chapter 2, we noted that Alfred P. Sloan, the archetype of 20th-century management, believed companies would die if they didn’t “provide procedures for predicting change.” Venture capitalist Maxwell Wessel advises enterprises to “Predict the Future of Your Business.”¹ Wessel counsels businesses to ask three simple questions, and then, through scenario planning , think about how your answers to these questions change your markets, create new opportunities, and render old ideas passé. The questions are simple, but their analysis can reveal risks and options that smart, innovative enterprises can capitalize on:

• What’s changed?

• What business assumptions become irrelevant?

• How could new models take advantage of the change?

Wessel then enumerates some examples of clearly visible changes on the horizon, and speculates on how their inevitable evolution might present risks and opportunities for those who look forward with foresight. Machine learning, for example, has obvious implications in the practice of “big data” analysis , but it also presents the risk of massive dislocation as machines learn to do the jobs of professionals and other knowledge workers. Current software can predict the actions of hackers, for example, in order to prevent fraud but can also predict the likelihood that an individual will become a hacker in the first place. Everyone from Google to the U.S. Government uses algorithms to predict our predilection to purchase a product, or to engage in terrorism. How can enterprises steer their way through these scenarios, positive and negative, and navigate toward new business models that create value without unleashing chaos? From technology changes like the Internet of Things and Smart Cities, to cultural changes like resurging urban density or “the death of location” due to the ubiquitous grid, wise companies build future vision into their firms by asking, analyzing, and answering the three simple questions proposed by Wessel. This is an activity to which agile consultants can add significant value; facilitating planning teams to consider plausible future scenarios , and their ramifications to the firm, enables agile consultants to migrate up the chain from practice-focused consulting to strategic value.

Scenario planning, or “strategic foresight ,” as it’s often called in the academic world, is not new. Back in 1967, Royal Dutch Shell began an experiment called ”long-term studies." Ted Newland, a company veteran, describes the inauspicious beginnings of this initiative. “I was placed in a little cubicle on the 18th floor and told to think about the future, with no real indications of what was required of me,” he reported to Angela Wilkinson and Roland Kupers for their Harvard Business Review article.²

A small team began considering alternative futures, from different oil-price scenarios and their implications to the firm to the analysis of various economic and geopolitical shocks that could potentially impact the marketplace. This approach, according to Newland, helped to prepare the company to survive and prosper through the OPEC (Organization of the Petroleum Exporting Countries ) embargoes of the 1970s and the cataclysmic events of the 1980s such as the collapse of the Soviet Union.

It’s not only Shell that applies this future-planning practice; according to a 2013 study,³ scenario planning adds to the innovation capabilities of firms, and helps firms avoid missed opportunities and unrecognized threats. Using interdisciplinary teams that are highly networked within the firm, and in the broader marketplace in which the firm competes, can help “spot signals that are relevant . . . explore them, filter out noise . . . pursue opportunities ahead of the competition, and recognize early signs of trouble.”⁴ This sort of strategic thinking, according to the study, helps enterprises achieve some key aims:

• Enhanced capacity to perceive change,

• Enhanced capacity to interpret and respond to change, and

• Enhanced capacity for organizational learning.

In the 2015 version of Bain & Company’s annual “Management Tools and Trends” report,⁵ the top two findings, agreed upon by 75% of responders, were that the following:

• Our ability to adapt to change is a significant competitive advantage.

• Innovation is more important than cost reduction for long term success.

Bain’s definition of Scenario Planning tells us:

Scenario Planningallows executives to explore and prepare for several alternative futures. It examines the outcomes a company might expect under a variety of operating strategies and economic conditions. By raising and testing various “what-if” scenarios, managers can brainstorm together and challenge their assumptions in a nonthreatening, hypothetical environment before they decide on a certain course of action. ⁶

The advantages of this approach, according to Bain, is that it allows planners to challenge implicit and widely held beliefs, test the impact of key variables, and identify the key levers that can influence the company’s future course. The unfortunate news is that only 18% of Bain’s survey responders worldwide reported applying scenario planning as a key element of their strategic planning process. Maybe this is why Bain analysts report that the following:

We see a significant risk in 75% of respondents believing that they have a competitive advantage relative to their peers. Statistically, it doesn’t add up. (A more realistic number is probably 25%.) Executives who believe that their companies are more competitive because sales and profits are rising in the midst of a recovery risk making wrong moves due to complacency.

The results of scenario planning , according to these surveys, illustrate its connection to agility. Perceiving, interpreting, and responding to change is at the heart of agile development. The scrum cycle of development is specifically designed to respond to changes in a turbulent business environment; bringing that mentality to strategic planning through scenarios is a proven technique to enhance change readiness and responsiveness. When agile teams develop the solution to a customer problem, they engage in tactical scenario planning, in such conversations as the following: “If we change this, what happens to the rest of the product?” or “What’s the impact of moving this feature earlier in the release cycle?” This informal, tactical scenario planning is an implicit element of innovation, as teams think through the implications of various decisions. Evolving this sort of future thinking in the strategic process enables strategic planners to scan and evaluate the world outside their office, visualize the changing landscape, analyze the effects of various plausible future states, and make plans based on where the puck will be, not where it is now or was in the past.

Agile Strategic Thinking

Scenario planning is, of course, just one tool in a toolbox that includes other instruments like benchmarking, customer relationship management, and big data analytics. The tools applied are less important than the mind-set through which we approach strategy. Agile strategic planning accepts the foundation ideas that experimentation and innovation are more meaningful than predictions based on past events, that recognizing and acting on patterns in the data is more helpful than looking at data in the rearview mirror, and that planning and execution are better served by inclusion, participation, and consensus than by top-down edicts from an exclusive team of executives.

Agile or adaptive planning is, of course, inextricably linked to the adaptive leadership we discussed in Chapter 9. For adaptive planning to work, leaders must shed their need for predictive plans and budgets and become accustomed to the uncertainty and mutability of reality. The model of management before the advent of lean was based on executives dictating that certain projects be executed, in a prioritized order, connected to a set of static objectives negotiated behind closed doors and handed down in a long-term plan. Budgets were assigned, completion dates were mandated, and any changes to date, budget, or scope were subject to lengthy negotiation processes, and seen as “deviations.”

When strategic planning is adaptive, and the enterprise embraces mutability, everything is a deviation. Scopes, dates, and budgets emerge from the circumstances we encounter by reading the market, reading our performance, reading the customer, and constantly deviating from our plans to create new, reality-based designs. Strategy becomes a series of 3, 6, and 12-month visions, each subject to many variables and open to changes based on the forces of the marketplace and the circumstances of execution. I’ll reiterate that this is far beyond the capacity of the practice-oriented coach; the capability to explain, persuade, and guide leaders to this new way of thinking about their business requires mature consultative skills. We must, as agile consultants, be able to persuade reluctant leaders and teams to let go of their comfortable habits of false predictability and ride through the waves of uncertainty and change that are the norm in today’s business environment.

An Agile Strategic Framework

Back in 2012, I had a lengthy conversation with Tom Conrad, a member of the founding team at Pandora. We chatted about agile development, and how that approach had influenced strategic planning at Pandora. I’ve included that full interview⁷ at the end of this chapter. Here’s a quote from Conrad that outlines Pandora’s current style of strategic planning:

Every 90 to 120 days, we’d build a list of new opportunities. . . . We’d generate a list of maybe 60 different product ideas. . . . Then we passed the list to the engineers who articulated the resources required to deliver, but certainly nothing like a full specification. Then we’d bring all the executives together, hang all the sixty or so ideas on the wall, and I’d give a walkthrough, describe who supported them and what revenue might be tied to them…the CEO, myself, every exec would walk around and vote for the ideas they supported…at the end we’d have about 10 to 15 ideas that were fully supported…we’d hand off 10 or 15 initiatives to the engineering team and let them run with them for 90 days, and at the end of that time we’d go through the process again.

Conrad illustrates a real implementation of some of the ideas I’ve been outlining here: short time horizons, inclusiveness, minimum viable plans, as opposed to the 152 objectives I’ve seen some organizations commit to (and never deliver), with the understanding that some of the initiatives might work and many might not, and the commitment to revisit the whole process on a quarterly basis to keep pace with the market reality outside their doors.

Many of these ideas have now migrated into a planning process known as “big-room planning ,” which, in many agile organizations, has all but supplanted the traditional executive off-site that was the accepted planning model. In both Pandora’s process, as described by Conrad, and in the big-room planning sessions that are becoming ubiquitous in agile enterprises, plans and ideas are made visible to the entire organization, priorities are set by consensus rather than edict (although executives still reserve the right to manage the priorities and flow of work), and, critically, a connection is established between commitments and the capacity and capability to deliver.

I want to emphasize this element; many organizations accustomed to traditional planning often generate their portfolio of projects based on wish lists and political bargaining, with no thought to the teams’ actual capacity to deliver their dream list of projects. By focusing on the limited list of initiatives that the enterprise can actually deliver, minimum viable plans keep the focus on high-value efforts and avoid the trap of starting many projects and finishing none.

Tom Conrad’s description is a rough outline for a big-room planning session, but the idea has evolved and become more consistently applied. These sessions typically include a representative selection of executives, managers, customer-facing experts, technical experts, and other leaders, managers and “do-ers.” They often cascade, from the full organization (if that’s reasonable based on size) to the individual program teams, and even to the actual delivery teams if their initiatives are broad enough to require a strategic approach . Every enterprise that decides to engage in big-room planning designs its own participation program, with the caveat that we want to avoid exclusivity and make these as participative as is reasonable and productive.

In preparation for big-room planning, executives should understand their priorities and expectations for the planning period but must also come prepared for surprises, adaptation, and negotiation. Managers and their teams should have thought about their real capacity and capability to deliver, and should also have their planned work mapped out and prioritized for the planning period, usually one quarter. It’s also critical that teams have thought about their risks, dependencies and resource gaps, as big-room planning is the perfect venue for negotiating and trading for resources and deliverables to ensure that commitments that are made are feasible and properly resourced. Agile consultants should be adept at the planning and execution of big-room planning sessions. Deep and careful planning is the key to emerging with a reasonable and valuable set of initiatives to which the enterprise can commit.

A typical agenda for a big-room planning session begins with an introduction by a senior leader , setting the stage for expectations from the session, and encouraging the teams to be open and collaborative. For command-oriented organizations evolving to agile, it’s important for executives to ensure that there will be no repercussions from conflict or debate, and that the session is reality based, even if commitments have been made. Each delivery team then has a short window, typically five or ten minutes, to present its current plan for the quarter, any new ideas or requests that have emerged this planning period, and any high-level risks or dependencies of which the entire population should be aware. Teams are often encouraged to rank their projects in order of risk, with initiatives that have heavy external dependencies or resource needs listed in red. It’s typical, after these introduction presentations, to give the teams an hour or so to update their plans based on what they’ve heard, as this visibility into their peers’ plans can often trigger other questions, concerns or ideas.

The next stage is often called a “marketplace ,” in which all teams have an opportunity to meet with the other teams attending, to negotiate for resources, ensure that dependencies are considered and can be achieved, and generally to make sure that everyone’s plans and needs are synchronized, and that commitments are made to satisfy requirements for deliverables and resources. This session is the core of the exercise; it enables teams, which often work in isolation in large agile enterprises, to collaborate, not just within teams but across the enterprise to ensure that their planned work is feasible and resourced, and that risks are mitigated. It also gives, finally, a holistic view of the organization’s overall goals and priorities, both to the executive team and to the actual team members or their representative leadership.

Is this really strategic planning? Where are the long-term visions and objectives? There’s a common misconception that objectives, like “Dominate the market in shoelaces” or “double our penetration of the robotic vacuum market” are strategic, when, in fact, these are objectives only and don’t address the core elements of a comprehensive strategy . As in chess, saying “I want to win every game” is not a strategy, it’s an objective, and it misses the key element of a plan to achieve that ambitious and ambiguous goal. Strategy, in chess or in business, requires us to think about components such as timing, approach, where to compete, what our unique tactical advantages might be, and how we intend to sustain our execution. The beginning chess player won’t achieve her winning goals by competing with grandmasters, and the small enterprise won’t achieve its strategy by competing in saturated markets dominated by giants (unless they’re Tesla). These strategic ideas probably won’t emerge from a big-room planning session, although they will inform, and be informed by, its outcomes. There is still a place for executive vision in an agile strategic planning process, but without big-room planning as an input and output of that high-level strategizing, plans risk becoming disconnected from reality, from the market and the customer, and from the teams doing the work. Strategies tend to fail when the enterprise doesn’t understand both the holistic strategy and the means and tactics to get there, and are not bought in through participation in their framing.

The agile consultant engaging at the strategic level is undertaking a monumental task , far beyond the practice-based coaching that occurs at the grassroots level. The concepts we’ve discussed essentially tell the executive team that everything they’ve learned, and practiced throughout their careers, is wrong. This message is difficult to transmit, and difficult to swallow, especially for hierarchical command organizations that are accustomed to leading from the top and avoiding risk and experimentation. The ability to meet executive teams where they are, to avoid proselytizing and instead persuade through results and data, and to incrementally build the understanding of the benefits of the agile approach, are core competencies of the effective agile advisor. As we succeed in developing agile teams, and they begin to display their successes, the migration to agility across the enterprise becomes an imperative. Agile teams can’t survive if the enterprise, through stubborn adherence to outmoded techniques, works against them. No agile coach or consultant can be truly effective in creating an agile enterprise without understanding this strategic and human challenge, and devising strategies to guide the strategic process in an adaptive direction.

Summary

We’ve looked at the typical strategic planning processes of the 20th century and examined some of the outmoded beliefs that drove that approach. The speed of digital disruption and market change, the changing tastes and requirements of customers, and the visibility of formerly secret information are all drivers of a new approach to strategy. Those organizations that can let go of false ideas of predictability and sustainable advantage, and migrate to adaptive leadership and adaptive planning, are more likely to succeed in our turbulent environment, to innovate, and to foresee market challenges. We’ve reviewed some approaches to adaptive planning, such as the Pandora model and the big-room planning approach, and reviewed the importance for agile consultants of engaging at the strategic level to ensure that agility at the team level is sustainable.

Interview: Agile Strategic Planning and Innovation at Pandora

Pandora’s CTO and VP Tom Conrad describes how the company’s agile strategic planning process diverged from the traditional, annual, all-hands product planning session. ⁸

I recently had an extended conversation with Tom Conrad, Chief Technology Officer and Executive Vice President of Product at Pandora, the Internet radio pioneer. Tom was a user interface designer for Mac OS at Apple, held posts at Pets.com and Documentum, and was the Technical Director for the You Don’t Know Jack line of video games before joining the founding team at Pandora.

My interest in chatting with Tom was not in the “so you’re doing agile development” vein; rather, I’m interested in innovative companies that have migrated from agile development to agile strategy, and Pandora is a prime example of this wave of management philosophy. As many organizations have discovered, agile development can help add flexibility and responsiveness to their development cycle, but these improvements only go so far when the rest of the organization has not evolved to a more agile approach.

Tom began our conversation by poking a hole in one of the foundation ideas of the IT revolution of the past few decades: the suggestion that the rapid changes we’ve seen have been due mostly to rapid technological advance. He said:

If you’d asked me during the first 12 years of my career, what were the biggest innovations, I wouldn’t have said laptops, or the Internet, I definitely would have said that the massive changes in the way that we write software was the single most disruptive thing I’d seen to that point.

This is, in my view, an important insight; as critical as new hardware, software, and connectivity technologies have been to the IT revolution, none of these developments have been as meaningful as the migration to more iterative, collaborative, and change-friendly development techniques. I’m in vehement agreement with Tom on this point; these new development approaches have enabled the rapid, responsive release of products that solve customer and consumer problems, and that have facilitated the evolutionary release cycle we’ve all become accustomed to, with new iPads and iPhones, new versions of cloud-based software, and new generations of digital cameras and microprocessors every few months. While many of these new capabilities are delivered in hardware, they’re based on software, and iterative, incremental evolution focused on the needs of the marketplace has been the real enabling technology of the revolution.

Tom next reminded me of the restrictions of the "bad old days," even at a company seen as the poster-child of innovation:

At Apple we couldn’t change a single byte without a year-long certification and release cycle. When I was there, that cycle was, pragmatically speaking, closer to two or three years. We did a little better than the automotive industry, in terms of innovating and getting to market quickly, but not much.

Tom and I chatted a bit about how these agile ideas have manifested at Pandora. He started by describing how traditional, multi-year strategic planning would handicap an innovative company like Pandora:

Mobile systems, new advertising technologies, are all changing at a tremendous pace; we know more about the opportunities there today than we did 90 days ago. 90 days from now the world will be further fleshed out. It’s important for us to react to new information. If the iPhone SDK becomes available, and 90 days later the apps store opens, if you’re in a multi-year cycle, obviously you’ve risked missing an opportunity to react to critical new information.

Tom has defined in a brief comment the challenges that today’s innovative companies face that Westinghouse or Proctor & Gamble, for example, may not have faced 20 years ago. While innovation and new products have always been an element of strategy for leading companies, the marketplace was significantly more stable and the product cycle much more deliberate and long-term than it is now. Maytag may have had to release new features and functions in its household appliances, but it was unlikely that entire new markets and platforms for their products were opening up and mutating month-by-month.

Tom went on to describe how these new conditions influenced Pandora’s innovation cycle:

Everything we do here has been based on a 90 to 120 day calendar. I can tell you, based on the marketplace reaction to our products, where we might be 90 or 120 days out, but for each month beyond that it gets foggier and foggier. What that allowed us to do is be reactive to new opportunities as they come along. This planning philosophy informs how we perform all the way to the CEO level, and we have great support for this approach from the CEO.

I asked Tom how the strategic planning process at Pandora diverged from the traditional, annual, all-hands session that often ended up with a 100 item project list of initiatives that never got prioritized or acted upon because it was so large and overwhelming.

For six of the years since we’ve launched, from 2005 to 2011, we used an agile version of the old-school, facilitated off-site approach. Every 90 to 120 days, we’d build a list of new opportunities presented to the business. This was a product-management facilitated process, with the advertising team bringing in ad opportunities that had come along, and the product teams speaking with the voice of the consumer. We’d generate a list of maybe 60 different product ideas. There’d be a single PowerPoint slide for each opportunity with a few bullet points fleshing it out. The only requirement for getting on the list was that there was some stakeholder somewhere in the business that thought we’d be foolish not to pursue that idea in the next 90 days. Then we passed the list to the engineers who articulated the resources required to deliver, but certainly nothing like a full specification. Then we’d bring all the executives together, I’d hang all the sixty or so ideas on the wall, and I’d give a walkthrough, describe who supported them and what revenue might be tied to them. We’d hand out little sticky notes, and everyone would get the same number of votes, and the CEO, myself, every exec would walk around and vote for the ideas they supported. There’d be some horse-trading and some reconfiguration of some ideas, and at the end we’d have about 10 to 15 ideas that were fully supported and the rest with a few votes here and there. So at the end of the process we’d hand off 10 or 15 initiatives to the engineering team and let them run with them for 90 days, and at the end of that time we’d go through the process again.

I think that Tom’s description of the original Pandora planning process is instructive for a few reasons. Firstly, it’s more agile and iterative than most corporate planning processes I’ve experienced, and is a great fit with an agile software development approach. The number of projects generated by the process is small enough so that they can be tried and either accepted or rejected based on real-world engineering or market results, rather than on politics and positional jockeying. The cycle is quick enough to frequently consider new developments in the marketplace or the technology. The realities of resource constraints are built in to the process, since under-resourced projects are bound to fail, and so will bubble up to the vision of the executive team at the next session.