A metric framework for defining and measuring proficiency will be discussed first, then a framework for analyzing change in specific domains. An organization's proficiency may exist in one or a few of these domains of change and not in others—by design or by accident. These domains form an analysis framework for understanding current needs and values, setting improvement and strategic priorities, characterizing solution requirements, and evaluating solutions.

Proficiency Metrics

Naive discussions often confuse change proficiency with quickness—which reduces simply to cycle-time reduction. Time, as the metric, shows its inadequacy when we test it against extreme conditions. Would you call it proficient if a short-notice change was completed in the time required, but at a cost that eventually bankrupted the organization? Or if the changed environment thereafter required the special wizardry and constant attention of a specific employee to keep it operational? Is it proficient if the change is virtually free and painless, but out-of-sync with market opportunity timing? Is it proficient if it can readily accommodate a broad latitude of change that is no longer needed, or too narrow for the latest tricks thrown at it by the business environment?

These questions let us tease apart change proficiency into four metric dimensions: time, cost, quality, and scope. Exploring the interrelations of these four shows a need to score sufficiently well in each.

Completing a change in a timely manner is the only effective way to respond at all in an environment of continuous and unrelenting change. After all, we do need some time in-between changes for a little value-added work. But the time of change alone does not provide a sufficient metric. 

You can change virtually anything if cost is no object. However, if your cost of change is too much relative to your competitor's costs, and changes happen with any frequency, there will be a steady erosion of working capital, or shareholder dividends, or both. Change at any cost is not viable, else we need not restructure anything ever—we can simply throw out the old and buy a new capability; assuming, of course, that we can bring something new to the operational level quick enough.

If after a change the result is a house of cards which requires constant attention or repair to remain functional, the change process quality was insufficient. If we cut corners in the process of changing in order to do it quickly and cheaply, we end up with a brittle, fragile result. Encompassing robustness, quality implies predictability. Proficient change is sufficient change, accomplished on time, on budget, and on spec.

Change is a transitional term that implies a starting point and some new ending point. How far away can the ending point be from the starting point, and still be a quality, affordable, and timely change? The dimension of scope addresses this question. Are we change proficient if we can accommodate any change that comes our way so long as it is within a narrow 10% of where we already are? Scope is the principal difference between flexibility and response ability. Flexibility is a characteristic fixed at specification time. It is a range of planned response to anticipated contingencies. Change proficiency, on the other hand, is capable of dealing effectively with virtually any magnitude of unanticipated change. At the heart of scope is the architectural issue: rather than design something which anticipates a bounded set of options, design it so it can be deconstructed and reconstructed as needed—addressed at another time when we'll look at the system response architecture element of response ability.

Domains of Change

The term problem is used in this discussion to describe anything in search of a solution—regardless of whether it is a new market strategy that needs developed, an opportunity to merge with another company, a business process that might be outsourced, or simply an intolerable integration mess that needs fixed.

We have all observed human nature to characterize problems in terms of known or favored solutions. Often a problem is not perceived to exist until a solution is perceived, placing continuation of the status quo in question. Unfortunately, the awareness of solutions tends to color the perception of a problem's true breadth and depth. To mitigate this confusion a knowledge-development problem-analysis framework was developed at the Agility Forum in the nineties, and successfully disciplined the process of problem characterization, in hundreds of diverse cases, to generate solution-independent understandings.

A Flexible Strategic Roadmap created by the Cooperative Research Network for NRECA Members - October 2002² "...summarizes a comprehensive strategic planning process for the National Rural Electric Cooperative Association...The Roadmap contemplates significant work in four knowledge development strategies." The third one on the list reads, in part: "Education to help co-op staff understand how to select and/or reject technology from an ever-increasing array of options..." Developing solution-independent requirements is facilitated by structured knowledge-development frameworks.

Understanding a problem space effectively requires an understanding of the dynamics that will constantly change its nature. A problem stated in today's immediate and static terms is a fleeting characterization, as the environment that causes and defines the problem will continue to change. The analysis-framework forces problems to be understood in terms of their dynamics, and results in problem characterizations that demand solutions which will accommodate change.

Change can be structured into two general categories: reactive and proactive. Reactive change responds to a situation that threatens viability. Proactive change responds to a possibility for innovation. A reactive change might be the response needed for new-regulation compliance, a proactive change might be the initiation of outsourcing to reduce costs or provide new income-generating services.

General Reactive Domains:

• Correction: Rectify a dysfunction. Issues are generally involved with the failure to perform as expected, recovery from malfunction and side effects, and the rectification of a problem.

• Variation: Real-time change within the mission of the solution space. Issues are generally associated with daily activity, performance adjustments, and interaction variances which must be accommodated.

• Expansion/Contraction: Increase or decrease of existing capacity. Issues are generally involved with quantity and capacity changes, when either more or less of something is demanded or desired.

• Reconfiguration: Reorganize resource or process relationships. Issues are generally involved with the reconfiguration of existing elements and their interactions, sometimes with added elements as well.

General Proactive Domains:

• Creation/Elimination: Make or eliminate something. Issues are generally involved with the development of something new where nothing was before, or the elimination of something in use. This might be the creation of new products and services, a new corporate culture, new knowledge and skills, a new IT infrastructure, or a new operating strategy.

• Improvement: Incremental improvement. Issues are generally involved with competencies and performance factors, and are often the focus of continual, open-ended campaigns.

• Migration: Foreseen, eventual, and fundamental change. Issues are generally associated with changes to supporting infrastructure, or transitions to next generation replacements.

• Modification: Addition or subtraction of unique capability. Issues are generally involved with the inclusion of something unlike anything already present, or the removal of something unique.

IT is often called upon for greater agility first, even when agility is not on the corporate strategic agenda. This is caused by application integration difficulties, management's call for better data visibility, merger and acquisition rationalization, out-of-control projects, inadequate budgets, and other departments wanting more support—now. How an IT department addresses this need for better change proficiency depends on how well it understands its problems. IT vendors and consulting firms are quick with solutions, but what is the real problem? We'll look at two IT areas that are typical corporate priorities today: a better capability to rationalize merger/acquisition IT, and a better capability to add and integrate software applications within the enterprise.

The issues shown might be the initial issues one particular company senses. These issues will change as more experience and capability shift the focus to more advanced issues. Items are bulleted here, so they do not convey the depth of explanation needed in a complete issues/requirements analysis. Note that the issues are more staff and departmental capability oriented than technology oriented. The lack of a specific technology is not the nature of the issue.

What problems and potential strategies need dynamic response analysis? Influence topic coverage: Click here to answer fast check-box questions. Results will be published when 100 responses are received.

---------- References ------------

1. Business Finance, "Strategic Planning Meets Business Performance", Tad Leahy, contributing editor.

2. NRECA strategic roadmap.