While rereading Richard Rumelt’s book Good Strategy/Bad Strategy, it occurred to me that his strategy kernel looks like the structure of every solution to every problem. Ever. I solve problems for a living, and every solution has three components: (1) a description of the problem, (2) an overall approach to solving it, and (3) an architecture for a solution. In Rumelt’s terminology, these are the diagnosis, the guiding principles and policies, and the set of coherent actions. He makes it pretty clear that the latter two are part of an architecture for the solution, which must then be deliberately designed.
Rumelt further describes a strategy as a hypothesis and the execution of that strategy as an experiment. This parallels Henry Petroski’s description of design as hypothesis. The implication is that developing a strategy is much like engineering a structure or designing a product: It requires a clear understanding of the problem at hand, an idea about how to approach the problem, and some idea of what the solution will take. Furthermore, these various parts must be designed deliberately, or else they fail to coalesce and actually solve the problem.
The hypothesis in a structure’s design is that a structure built according to the design, used for the specified purposes, for the specified length of time, will not fail. The hypothesis in a strategy is similar: an organization built to execute the strategy as designed will succeed in the market given the specified market conditions. Rumelt’s own words are more elegant: “A strategy is, like a scientific hypothesis, an educated prediction of how the world works.”
Now, that’s not to say that developing strategy is exactly like designing structures or systems, only that the structure of the results are very similar, as are the basic skills both require. The main differences are the level of uncertainty inherent in the solution and the specific kinds of domain knowledge required. While the behaviors of structures and software systems are fairly well defined by their design and implementations, that is not true with a strategy. The success or failure of a strategy depends on many outside factors, from the willingness and ability of the organization to absorb the necessary changes, to the responses from customers, competitors, and others. In this manner, strategy is more like the game of poker than the concept of building.
Developing strategy requires all the skills possessed by competent, experienced enterprise architects, plus the ability to deal with uncertainty and ranges of responses. Scenarios, as described in Peter Schwartz’s book The Art of the Long View, are a valuable tool for dealing with uncertainty. Since all participants in a strategy can respond in a range of ways, you can use scenarios to describe various combinations of those responses in order to work out the likely outcomes in each case. Schwartz doesn’t suggest you build a scenario for every combination, only for a likely bad outcome, a likely good outcome, and the most likely outcome. You should probably also develop a scenario for the worst case.
It's All in the Story
A scenario is a story, several forms of which are provided in Schwartz’s book. The story describes the situation and outcomes in terms of actions and reactions of the various players. An essential part of the story is a thread from the present to the eventual outcome that provides clues that the scenario might happen as described. A separate strategy is developed for each scenario, the idea being that developing conditions in the present guide you to determine which strategy to use. You may find that multiple scenarios can be covered by the same strategy with minor tweaks to the coherent actions. In other words, small adjustments may be all that is required instead of wholesale architectural changes.
Skills in the use of scenarios are not a normal part of the enterprise architect’s toolbox. Honestly, they aren’t a normal part of anyone’s toolbox. Some of us in the profession are trying to change that because scenarios are applicable in solving many different kinds of problems. The main skill, storytelling, is useful all by itself. A good story motivates people more than any other kind of communication, in just about every kind of setting. Want a group of employees to get excited about a proposed change? Tell a story. Want a group of executives to approve a project? Tell a story. All enterprise architects should become adept at using scenarios. Once that happens, they have all the skills to develop, implement, and monitor an organization’s strategy. As leaders, your job is to point them in the right direction and get out of the way.