Tuesday, January 1, 2013

Models for Strategy Development

In my earlier rumination on applying the models for strategy development to customer experience problems/opportunities, my consideration of existing models seemed a bit abrupt: "Do a Google Search." That's likely a just and adequate response in the context where the process itself is incidental, but it does merit further consideration.

And so, I've looked into a number of such systems and what follows is an attempt to consolidate the research.


Framework: The IDEA Model

In spite my general disdain for models based on acronyms, the "IDEA" model (identify, define, execute, assess) seems to be the best in terms of providing a high-level framework.

Other models that provide a more detailed approach seem to follow the very same pattern, breaking down some of the steps into sub-steps for more granular consideration, and making each of these four basic tasks into five or more sub-tasks.


Identify the Problem

Strategy development seems to begin with a problem (something that exists has gone sour), but the same methodology is also applicable to exploring opportunities. The difference seems to be that problem solving is backward facing and deals with hard data (what has caused sales to drop by ten percent), whereas opportunity exploration is forward-looking and often deals with hazy estimates of what might be (what might we do to increase sales by ten percent).

The first step in the identification phase is the recognition that a problem or opportunity exists, resulting in a succinct statement that defines the desired outcome. Second, is the validation of the problem. Much effort is wasted in pursuit of imaginary problems or those whose impact is trivial (less than the cost of solving or pursing them).  Next is an analysis of the problem or opportunity, to uncover all relevant information about the phenomenon in whose context the problem is assumed to exist. Ultimately, this arrives at a well-considered analysis of cause and effect.

Some methodologies include the statement that immediate action should be taken to mitigate the damage until a strategic solution can be implemented. I have the sense this is wise (you don't want the patient to bleed out while you're diagnosing their condition) but can also be destructive where a tactical action taken in a panic worsens the damage for lack of understanding the problem, or where it obfuscates the strategic solution.


Define a Solution

The definition of a solution is often broken into a few different tasks that are intended to ensure that various options are explored (we do not simply jump on the first thing that comes to mind) and carefully evaluated before committing to a single solution.

The first step is to consider the root causes of the problem and brainstorm a wide array of ideas that could possibly address the problem. This is generally a free-form discussion in which anything goes, so as not to stop the flow of ideas. The next step is to evaluate each idea in terms of its effectiveness in addressing the problem. Given that the initial brainstorming will result in a large number of poorly considered options, many of them will need to be winnowed away. Following that is a more detailed analysis of each idea, primarily based on the cost and availability of resources to address the problem, and weighing the likelihood of success against the cost of success.  Ultimately, these steps are geared toward identifying which of the ideas to purse, with the note that it may be multiple promising actions rather than a single best solution.

A few systems return to brainstorming at this point to discover the possible side-effects of a proposed course of action. This seems highly advisable, given that focusing on the benefits of undertaking a course of action often fail to recognize the full measure of the consequences.


Execute the Plan

Surprisingly little is said about the execution phase. It's not clear to me whether this is because the nature of execution is highly idiosyncratic, or because it is assumed that the actions to undertake are spelled out in the definition problem and all that's left is to simply follow the plan that was created. Either seems likely, and entirely reasonable as to why this phase lacks more granular definition.

A few of the systems included a prerequisite step to execution: selling and socializing the plan, by way of change management. This is an excellent point, too often overlooked, as a plan can be starved for support or even attacked by those who are devoted to preserving the status quo.

There were also a few discussions about evaluation during execution, as some problems may not become evident until the gears are started in motion. In theory, the development phase would have gone perfectly so that nothing is unexpected - but in practice, stuff happens, and it's critical not to be so egocentric or myopic as to disregard the possibility of adaptation as exigencies arise.


Assess the Results

The last phase also lacks much detail, as it also seems entirely mundane - an for the same reason, it is often neglected and rituals arise of people going through the motions without considering whether they are actually having any positive results.  Assessment generally looks back to earlier phases, to reflect on what the plan intended to accomplish, and then considering the actual results to see if they matched up.

Some systems also consider adaptation to be part of the assessment phase, though this does not seem sensible: where problems are noticed, or where a plan does not seem to be having the intended results, there's too great a temptation to tinker with the solution without much deliberation.

For most systems, the assessment phase spins up an entirely new problem-solving process, and this seems the more sensible approach: rather than to merely assume a negative result can be corrected on the fly, consider it as a problem unto itself, implement a tactical adjustment if necessary, but ultimately consider it to be part of the status quo that represents a fresh approach and a repeat of the process.

***

This has been rather a long post, but at the same time seems somewhat superficial - and the result is some general groundwork that likely needs further consideration and elaboration.

No comments:

Post a Comment