Should You Build Strategy Like You Build Software?

The strategic planning model is due for a “new release,” one that enables companies to keep pace with changing environments, quickly create and adapt strategy and empower people throughout the organization to make effective choices.

In many companies, the corporate planning department has gone the way of the dot-matrix printer. But if the analyst-driven, top-down, formal process of the previous era is dead, what have companies replaced it with? Not much, according to recent surveys of executives and managers of global companies. Many companies still hew to the decades-old annual strategic planning process, only now the responsibility for creating plans falls on group managers and department heads, with little central support. Other companies have jettisoned formal strategic planning altogether — centralizing strategy discussions to a few top executives or replacing planning with a hodgepodge of informal or semiformal retreats, executive leadership councils and board committees. Some observers have gone so far as to argue that strategy making is simply too uncertain and complex to be handled by a defined process. Unfortunately, senior managers may be throwing the proverbial baby out with the bath water. The fact that the process is failing doesn’t mean that strategy making is resistant to a process approach.

Consider software development. Around the same time that managers were losing confidence in strategic planning, software development went through its own crisis, as the demand for faster design and integration of increasingly robust systems began to make the traditional “waterfall” approach to software development obsolete.(See “The ‘Waterfall’ for Software Development/Strategic Planning.”) The crisis in software prompted a few visionaries to rethink how software gets built. They didn’t abandon a process approach to the problem; rather, they invented new development processes, such as rapid application development, extreme programming and agile software development, to confront the new realities.

The pressure to accelerate and at the same time cope with increased uncertainty and complexity led to the decline of traditional software development in some settings — and similar pressures seem to have played a pivotal role in the demise of formal strategic planning. What’s interesting, though, is how differently people in these distinct worlds responded. Software developers went to work rethinking how software should be created. But strategy making didn’t really change.

The insights upon which new software development approaches are based may point the way for the development of newer, faster and more effective strategy-making processes. Over the past six years, my colleagues and I have experimented with some of these principles to streamline the strategy-making processes at around 60 companies, in industries including hospitality, heavy manufacturing, financial services, education, healthcare and distribution.

Read the Full Article:

Sign in, buy as a PDF or create an account.

References

1. S. McConnell, “Rapid Development” (Redmond, Washington: Microsoft Press, 1996), 139.

2. P Drucker, “The Essential Drucker” (New York: Harper Business, 2001), 225.

3. Unpublished survey, McFarland Strategy Partners, 2006.

4. Manifesto for Agile Software Development, 2001, http://agilemanifesto.org.

5. B. Boehm, “A Spiral Model of Software Development and Enhancement,” ACM SIGSOFT Engineering Notes 11, no. 4 (1986): 21–42.

6. J. Welch, J. Immelt, D.D. Dammerman and R.C. Wright, “Letter to Share Owners,” in “GE Annual Report: 2000” (Fairfield, Connecticut: General Electric, 2001), 1–7.

7. Mitchell Kapor, founder of Lotus Development Corp., said, “If design and implementation are in watertight compartments, it can be a recipe for disaster because the natural process of refinement and change is prevented.” See S. Rosenberg, “Dreaming in Code” (New York: Crown, 2007), 150.

8. Ibid., 23.

9. “Improving Strategic Planning: A McKinsey Survey,” McKinsey Quarterly (September 2006).

10. F.P. Brooks, “No Silver Bullet: Essence and Accidents of Software Engineering,” Computer 20, no. 4 (April 1987): 10–19.