Friday, June 29, 2012

A Complex Systems Approach to Strategy



One of the problems with current strategy development techniques is that they vastly overestimate predictability.  At a very high level, these techniques involve identifying the desired future state, and then listing circumstances that might help or hinder achieving that future state.  Basically, this means listing challenges and figuring out in advance how to overcome them.  It's called scenario development.

If the future were perfectly predictable, there would be no need for scenario development.  Everyone would know what's going to happen.  That isn't the case, though.  The future holds uncertainty, and the scenario development is an attempt to deal with that uncertainty.  In complex environments, however, the future is sufficiently uncertain that developing scenarios is, well, almost useless, other than from an understanding perspective.

If the future is perfectly predictable, our scenarios would match one-to-one with what happens.  The scenarios would have a 100 percent accuracy.  For example, if we play a game where we flip a coin, we have two scenarios: heads and tails.  Our strategy, then, has an action for heads, and an action for tails.  "Heads" and "tails" are the two scenarios, and we have 100 percent knowledge of the conditions we have to accommodate.

Business environments, however, don't deal with such simplistic conditions.  The number of variables is high, they're often continuous rather than discrete, and simply listing them can be an impossible task.  Scenario development, under those conditions, becomes an exercise of asking "experts" or "business leaders" what they think is likely to happen, or doing it ourselves, and then guessing at the probabilities of those events. Often, it ends up being a list of goals and a plan for accomplishing them, with two or three possible challenges for each goal, along with some ideas for dealing with those challenges.  These "strategies" may have ten goals, and three or four scenarios associated with each, for a sum total of 30 or 40 scenarios.  (Or, worse, they don't list scenarios at all - they just state the goals.)

Let's consider a game again.  This time, two players each role a die.  Their game strategy depends on the outcome of the die roll.  This requires 36 scenarios.

Are we really saying that running a business is no more complex than a game involving two dice?

No?  Then our approach to developing strategy is deficient!  

The problem here is that people developing strategies believe A) they can predict the future very accurately, B) they have significant control over events, and C) the systems are not complex.  All three of these are demonstrably wrong.

A much more effective approach is to acknowledge these realities and change the way we talk about strategy.  A general strategic framework includes four things:
  1. Robustness
  2. Dynamics
  3. Sensing
  4. Agility
Robustness, as I've said before, is feature persistence across structural change. The first step in developing a strategy is to determine what features need to be persistent. These should be phrased as behaviors or characteristics, rather than specific structures.  For example, state the feature as "supply chain logistics management" instead of "leverage ABF and FedEx for raw material delivery."  Robust features can absorb environmental or internal changes and continue to function.  If there are critical capabilities that are dependent on structure (such as a physical location), then the strategy should include enhancements to make those capabilities robust. 

Dynamics are the trajectories of critical dimensions over time, and the interactions and dependencies amongst them.  If your customer satisfaction and loyalty are both skyrocketing, your strategy may be to maintain that direction, but if your customer satisfaction and loyalty are plummeting, the strategy is (probably?) to change the direction.  The questions to ask are, "what are the important dynamics" and "what are trends?"  The follow-on questions include
  • What kinds of events will change these dynamics?
  • What do we do if those events occur?
  • What other things will these dynamics affect?
Sensing is our ability, and the system's ability, to foresee critical changes in the system dynamics in sufficient time to adapt to the impending change.  At the Santa Fe Institute they have used the phrase "regime shift" to describe these changes.  In physics it's a phase transition.  Regardless, a critical change is a perturbation (exogenous or endogenous) that materially changes our ability to deliver persistent features.  If our strategy has created robustness, the perturbation may not require a change in execution.  If we know, however, that we must adapt or mutate in response to the perturbation, we need sufficient lead time.  

Agility is the system's ability to mutate or adapt to critical changes, and it's usually measured in terms of rate of change.  More agile systems can adapt quickly to changing conditions.  Less agile systems need better sensing and predicting!  

There are two significant challenges with this approach.  First, it's still dependent on our ability to recognize and understand the dynamics; it's not clear that we can do this well.  Second, we have to be able to describe and phrase the results in ways that are understandable and acceptable to non-scientists.  We can't underestimate the importance of the latter challenge.  Trust me - you can't go to a business leader and start talking about "exogenous perturbations" without losing their attention.  It's the translation and presentation problem that seems to be the most difficult to overcome.








1 comment:

  1. I think the points you mentioned have ramifications in the way we look at Enterprise Architecture. James Urqhart recently wrote in Giga OM that the complex cloud environment( which he refers to as as Complex Adaptive System) has made technology blue-printing out-dated. When I discussed this with enterprise architects, their response was for more control and better blue-printing. It seems that the impulsive response to increasing complexity has always been to increase control. How do we incorporate robustness in enterprise architecture such that it can persist the flows ( as there are several moving parts and thus higher complexity) without imposing structural changes and manage the flows well?

    ReplyDelete