« Should we measure the ROI of IT? | Main | Innovative Disruption »

August 20, 2006

How To Manage Strategy

This model for managing strategy abstracts the phases of a strategy's lifecycle and identifies the connections between the phases which bring about implementation and revision.

This management model offers two major areas of attention -- "Delivery" and "Support", borrowing the somewhat unusual British terminology for (respectively) production and maintenance that many people first encountered in the IT Infrastructure Library (ITIL). No other assumptions about the model's resemblance to ITIL should be drawn from this borrowing, as there is no other intentional resemblance.

Meanwhile, some observers may also get a sense of the Deming Cycle ("Plan, Do, Check, Act") from the illustration. That is not a particularly intentional resemblance either, but instead it just reflects that lifecycles are normally not difficult to lay out in a context of ongoing responsibility for quality or improvement.

The more important general observation is that a strategy is identified as a conceptual entity, so it is the life of the concept that is being managed. The distinction between delivery and support is to emphasize that one cluster of attention and activity is busy introducing and "staging" strategies while another cluster is busy aligning them to the realities of execution. Why is the distinction important?

The main reason is that we're so strongly tempted to see the lifecycle as a "pipeline" or "queue" -- and that might be a bad perspective. For example, one question that arises in that perspective is: how many different strategies are put into the "queue" by delivery, versus the capacity and rate of "support" to process them? If we imagine a "bottleneck" in processing, we imagine that we can explain failures of strategy that way. But this is not how strategies fail.

Strategies fail the same way a house falls apart. A cheap roof in a rainy season; a weak foundation on soft ground, and so forth. The house stands when all of its supports are good enough. They all need to be good enough at the same time. But you still don't put the roof on before the floor and the walls are there or at least framed.

The breakthrough observation is that while a new strategy may be adopted one phase after another, it doesn't leave behind the earlier phases as it progresses. Instead, it finally "lives" in all phases simultaneously, and all of its phases must be continually attended, if necessary rebuilt and/or reconnected, in the face of constant change.

Strategies fail due to incompatibilites that go unresolved -- at two levels of reckoning. At a high level akin to design, there is the issue of outright misfits, the square pegs against the round holes, things that just don't work together. At the low levels of operational detail, the problem is not like congestion in the pipe, but rather more like an erosion of structural integrity leading to fragility and a breakdown.

To make this issue more explicit, first consider the high level -- two points in the cycle that are major "reality checks" on the strategy.
- One is the decision on whether the strategy is important enough to develop in competition with other concerns. This is the matter of "optional" versus "must have", or as represented in the model, Portfolio vs. Requirement. Here, funders consider the investment versus the significance.
- The other most critical point is where the agreed concept has to be formally expressed (not just intended) as operations. In the model this is represented as Plan vs. Initiative. Here, people are concluding whether their effort has discernable impact of a valuable kind.

Why are these two points the most critical? Because a lot of the cycle is "thinking about" the strategy, and a lot of the cycle is "already using" the strategy -- but these two points represent where the strategy is accepted or rejected by the organization that must "realize" the strategy.

Also, they explain where a strategy not born of the organization can enter the organization, or where one born of the organization might have to exit. For example:
- Perhaps the strategy is actually delivered by a third party (including cases where a consultant or a new organizational leader brings it in, or where the example of some other organization's strategy is adopted).
- Perhaps the supporting organization exhibits a competency that indicates new options and probabilities, stimulating the conception and/or development of a new strategy. However, incompetency can signal the demise or retirement of an existing strategy.

Those two reality checks are prominent, but they are not effective on their own. The other points between lifecycle phases are also part of the decisiveness of the strategy's management in practice. They are required to move from one phase to another. The decisiveness comes from resolving the pairs, such as scenarios versus actors, or agreements versus policy.

Why do we say "versus" ? This refers to an aspect visible in an expanded view of the model (click here, then save or print landscape). Each of the pairs opposes two kinds of management resources -- an "artifact" resource against an "environment" resource.
- Artifacts (like scenarios and agreements) document the description of the concept in its current phase. These would be the items such as scenarios, agreements, initiatives, etc. (in blue). They communicate the strategy.
- Environments (like actors and policy) constrain the activity that the artifact indicates is necessary at each phase. These constraints in essence become the key ingredients of the strategy's workflow.

Realization of the strategy occurs mainly through synchronizing the communication of the strategy and the conduct of its activity appropriate to the communications. The synchronized pairs then become the "inputs" into their respective following lifecycle phases.

The expanded view of the model also reaches down to the low level of resolution detail. It points out that at each lifecycle phase, the processing of the synchronized input should be designed, and the model identifies what the phase design is like. For example, a key design parameter is "Fit to Organization"... at various phases shown in the model, "best practice" in this design aspect has the following features:
- Research is cross-disciplinary
- Modeling is iterative
- Publishing is cataloged
- Etc.

And as activities, each phase has a design with a "Functional Goal"; for example:
- Research is automated
- Modeling is synthetic (not organic)
- Publishing is networked
- Etc.

In terms of development, the model also maps to the conventional concerns of vision, mission and implementation:
- Vision is addressed through the span of the cycle from Adjusting (including its evaluation and measures inputs) through Research (including its scenarios and actors outputs).
- Mission is addressed likewise, from inputs to Modeling, through outputs from Publishing.
- Implementation sits between inputs to Tracking and outputs from Examining.

Given that arrangement, the most notable aspect is that Vision must stretch across strategy Delivery and strategy Support -- and while that span does not guarantee success, it's hard to think of a successful strategy that didn't span that way.

All that said, the model is a work in progress. As with most Archestra models, this one is intended to diagnostically expose points at which current efforts may have had a critical failure, or conversely where the development of efforts should prioritize attention.

For elaboration on the model's other design parameters of strategy management, or to provide your commentary on the model, contact me by email. Other commentary on the progress of process management is posted in the July 04, 2006 Archestra entry on "Managing the process of internal Business Change".

Posted by Malcolm Ryder at August 20, 2006 9:05 AM

Trackback Pings

TrackBack URL for this entry:
http://www.malcolmryder.com/cgi-bin/mt-tb.cgi/272

Comments

Post a comment