By Rick Dove
“Long-term strategic planning is giving way to flexible approaches. But agile planning requires powerful analytics tools.” said Business Finance, in a February 2003 article. “Few sectors of the economy have undergone more dramatic changes than those currently sweeping the utilities industry. The Enron debacle and a series of other crises have caused major shifts in strategy, away from deregulated markets and toward alternative profit sources,” according to Jill Israel, vice president of financial processes at Entergy Corp.
That same article quotes Michael E. Raynor, Ph.D., director at Deloitte Consulting in Toronto, saying: “‘Strategic flexibility’ sounds like an oxymoron. ‘Strategy is about commitment — to market positions, technologies, customers. Flexibility is about avoiding commitment, about creating the ability to bob and weave, to exploit whatever opportunities come along…’Strategic flexibility is a way to combine the power of commitment-based strategy with the benefits of flexibility in the face of an unpredictable environment.'” This is a culture change-moving toward enterprise agility, and developing a culture of change proficiency.
A culture of change proficiency is an enabling element of response ability, one of the three cornerstones of enterprise agility. Change proficiency is a competency that is facilitated or impeded by an organization’s culture; and is fostered, nurtured, and developed in organizations by people who recognize it as a worthwhile pursuit. It is practiced, refined, talked about, debated, valued, and taught; and seeps into the culture through this frequent exercise of language.
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.
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 20022 “…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.
See the chart below
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: Go to www.AgileSecurityForum.com/Surveys to answer fast check-box questions. Results will be published when 100 responses are received.
Your comments, issues and concerns are solicited at firstname.lastname@example.org. They will influence this continuing exploration of Agility. References and sources for more information include:
1. Business Finance, “Strategic Planning Meets Business Performance”, Tad Leahy, contributing editor: http://www.businessfinancemag.com/magazine/archives/article.html?articleID=13938
2. NRECA strategic roadmap: www.climatevision.gov/sectors/electricpower/pdfs/nreca_roadmap.pdf
About Rick Dove
Rick Dove is a recognized thought leader and change agent for agile enterprise and agile systems of all kinds. He co-led the seminal effort that defined agility in the early nineties as the survival need of the new millennium. He subsequently organized and led the Agility Forum’s industry-collaborative work that identified and defined concepts and principles for achieving agility in all aspects of enterprise.
He’s developed and managed deployment of agile enterprise business processes and IT infrastructure. He is a prolific writer and frequent speaker on the subject, and the author of Response Ability: The Language, Structure, and Culture of The Agile Enterprise (Wiley 2001) and Value Propositioning – Perception and Misperception in Decision Making (Iceni Books, 2005).
(c) Rick Dove, 2004, attributed republishing permitted with notification to email@example.com.
First published as Utility Agility – Culture, Language & Requirements Analysis – Part 4, IssueAlert® 12/10/04, UtiliPoint International