PSI LogoParadigm Shift
International
USA-505-586-1536

Essay

  Home | Library | Corp Info | Press | What's New?
(pdf version)

Enterprise Agility—Culture, Language & 
Requirements Analysis
by Rick Dove, 12/10/04,  

"Long-term strategic planning is giving way to flexible approaches. But agile planning requires powerful analytics tools." said Business Finance, in a February 2003 article1. "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 changemoving 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 othersby 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 quicknesswhich 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 everwe 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 neededaddressed 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 solutionregardless 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 supportnow. 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.

Problem Priority-Issues (superficial examples)

Metric focus: time(t), cost(c), quality(q), scope(s)

Problem

M&A Rationalization

Application Integration

Proactive Domains

Create

▪ New M&A integration (t,c)

▪ New program support (t,c)

Improve

M&A capability (q)

▪ IT response (t,c,q)

Migrate

▪ Commonize ERP (s)

▪ IT staff skills & knowledge (t,s)

Modify

▪ Add new biz process (t,q)

▪ Add outsource (c)

Reactive Domains

Correct

▪ Lack of new-user knowledge (t)

▪ Lack of new-staff knowledge (t)

▪ Differing redundant data (t,c)

Vary

▪ Differing biz processes (t,c)

▪ Differing ERP (t,c)

▪ Differing IT staff culture (t,s)

▪ Interchange standards (s)

Expand

▪ M&A capacity (t,c,q)

▪ Absorb customer base (t,p)

▪ Management data visibility (s)

Reconfigure

▪ Financial reporting (t)

▪ Data base centralization (c)

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.


2004 RKDove - Attributed Copies Permitted - Essay #67 - First Published as
 Utility Agility - Culture, Language & Requirements Analysis - Part 4,
IssueAlert 12/10/04, UtiliPoint International

Would you like to offer some thoughts or add to the dialog? Your sending of a comment automatically grants us permission to edit and post at our discretion. Send your comment to .

========= Reply =========================


Home | Library
Send mail to with questions or comments about this web site.
1994-2005 Paradigm Shift International - Attributed Copies Permitted
Last modified: April 25, 2005