REPLY Society Strategy Development (SD7066)
SDMAIL Jack Harich
jack at thwink.org
Tue Jun 10 06:38:52 CDT 2008
Posted by Jack Harich <jack at thwink.org>
Kim and everyone,
The purpose of this message is to discuss a fine point of strategy. As I
see it, Kim will soon draw the goals brainstorming phase to a close, get
to a focused goal, and then move on to the next phase, which may
eventually lead to work groups. Somehow their end goal will be to
develop a strategic plan, which is itself the high level solution.
When solving insanely difficult problems, once you have assembled a team
of motivated, sharp, qualified problem solvers (as we have here), THE
critical factor is the process. Kim, I was pleased to see in your
"Competitive Strategy Dynamics" that this is the way you feel, so we are
on the same page.
Therefore a key milestone remaining in the project "to develop a vision
and strategy for the next 50 years" is the selection/design of a problem
solving process for how to reach the goal(s) we will soon agree upon.
Starting in chapter 6, your book illustrates how a standard problem
solving process is essential. I cant help but to assume you have a
specific process in mind to help the SD community along. It may be based
on the process presented in the book. For those who dont have a copy,
here are the seven steps of the "Dynamic Resource System View" (DRSV)
process:
1. Identify the time-path of performance.
2. Identify those few resources at the heart of the business
3. Get quantitative - identify the inflows and outflows causing the core
resources to grow, develop, or decline.
4. Identify how *flows* of each resource depend upon existing *levels*
of resources and other drivers.
5. Combine the resource dependencies from Step 4 into a strategic
architecture of the business.
6. Get quantitative - again - to see how the strategic architecture
explains performance to date and into the future.
7. Revising policy to uprate performance.
We have embarked on a long term self-transformation project, one that
has the potential to be the most important event in the field since it
was shot out of a cannon over 30 years ago by the work of Forrester and
the success of the LTG project. This is serious work, fraught with risk.
Thus it may help to remember what John Kotter wrote in his seminal
article on "Leading Change: Why Transformational Efforts Fail," 1995,
Harvard Business Review. The paper opened with:
"Over the past decade, I have watched more than 100 companies try to
remake themselves into significantly better competitors. They have
included large organizations (Ford) and small ones (Landmark
Communications), companies based in the United States (General Motors)
and elsewhere (British Airways), corporations that were on their knees
(Eastern Airlines), and companies that were earning good money
(Bristol-Myers Squibb). These efforts have gone under many banners:
total quality management, reengineering, right sizing, restructuring,
cultural change, and turnaround. But, in almost every case, the basic
goal has been the same: to make fundamental changes in how business in
conducted in order to help cope with a new, more challenging market
environment.
"A few of these corporate change efforts have been very successful. A
few have been utter failures. Most fall somewhere in between, with a
distinct tilt toward the lower end of the scale. The lessons that can be
drawn are interesting and will probably be relevant to even more
organizations in the increasingly competitive business environment of
the coming decade.
"The most general lesson to be learned from the more successful cases is
that the change process goes through a series of phases that, in total,
usually require a considerable length of time. *Skipping steps* creates
only the illusion of speed and never produces a satisfying result. A
second very general lesson is that *critical mistakes* in any of the
phases can have a devastating impact, slowing momentum and negating
hard-won gains."
These observations apply to any process, not just the one Kotter goes on
to present.
So, after the group settles on a first iteration of its goal(s), is the
next step selection/design of the problem solving process (our own
change process) we will use, along with a commitment to use it in a high
quality manner, so as to avoid critical mistakes? If so, this would give
us this *high level project plan* :
A. Roughly define the problem by setting the goal(s) to achieve.
B. Select/design a process to solve the problem.
C. Execute the process, continuously improving it as we go.
For a field to have *the capability* to accomplish anything reliably, it
must have a standardized "model" of "Normal Science" (using Kuhns terms
from his The Structure of Scientific Revolutions) to transmit to
newcomers to the field. If we have the process, we have the model.
Now heres an intellectual leap: If our goal is something like *the
capability* to reliably solve difficult complex social system problems,
then isnt the best way to express that capability a generic, flexible,
foundational problem solving *process* that applies to all difficult
complex social system problems?
If the answer to the above question is yes, then the backbone of the
process we use to solve our own problem becomes our key output.
This is much like the scientist who perfects and tests a solution on
himself before announcing it is ready to be used by others. Thus our
strategic plan would contain a self-referential step that looked
something like this: "When the process has proven itself to be
productive and stable, then publish and promote its core as the
foundation of the next generation of the science of social system
engineering."
Naturally, a key process tool would be system dynamics. But it would not
be the only tool, and it would be embedded in a greater context, one
that would dramatically amplify its power and reliability.
To me this would be a beautiful, elegant strategy. It couldnt be any
simpler. ;-)
Jack
Posted by Jack Harich <jack at thwink.org>
posting date Mon, 09 Jun 2008 10:51:30 -0400
More information about the SDMail
mailing list