Rick Dove, Paradigm Shift International, www.parshift.com,

A problem definition discipline should be used
in a project's requirements development phase.

A problem definition discipline should be used in a project's requirements development phase. Unfortunately, most of what masquerades as requirements development today is in reality an attempt to define a problem in terms of a preordained solution. People get what they want this way, and they find out what the really need later on when they live with the result.
   Before we look at the RS analysis process we will first describe its principle tool. This structural tool gives us both a language and a framework of change types: four in the proactive category and four in the reactive category. The language aspect is critical – our understandings are formed by how we express things. The framework aspect provides a questioning structure that circles the problem as we look for issues in eight different change domains. By all means make up your own questions, but typical samples are included below.

Proactive Dynamics

Proactive change proficiency is the wellspring of leadership and innovative activity. Proactive changes are generally triggered internally by the application of new knowledge to generate new value. They are still proactive changes even if the values generated are not positive and even if the knowledge applied is not new – self initiation is the distinguishing feature here. A proactive change is usually one that has effect rather than mere potential; thus, it is an application of knowledge rather than the invention or possession of unapplied knowledge. In some cases, however, a seemingly unapplied invention may in fact have an effect – such as an atomic bomb invented and tested but not dropped might have had. Proactive changes typically introduce new approaches; and especially effective ones make existing approaches obsolete, change the rules for everyone, and may even disrupt markets. The four proactive change domains are creation, improvement, migration, and addition/subtraction.

Creation/Termination - Issues that involve the development of something new where nothing was before, or the termination of something in use. The principle creation issue is usually a statement of the top level change. For instance, in the product development process a prime issue is the creation of a new product. Termination of an existing product may also be a (tough) issue. Another issue might be the creation of innovative thought. Questions: What is it that must be created? What supporting factors also require creation? Is termination potentially difficult or a of concern?

Improvement - Issues involved with incremental improvement of performance factors. Questions: What is it that must/should undergo sporadic or continuous improvement during operational life? What performance factors will be expected to improve with time?

Migration - Issues associated with eventual and fundamental changes, such as changes to the supporting infrastructure or transitions to next generation replacements. Questions: What in the future will replace (not simply modify) what we have? What support structures are likely to change with time? What could, or is likely, to change that would invalidate our current and basic assumptions?

Addition/Subtraction - Issues that involve addition or subtraction of unique capabilities, either in the adding of something unlike anything already present, or in the removal of some unique capability. Questions: What new capabilities will we (might we) need to add with time? What capabilities present might be candidates for removal if operating conditions change?

Reactive Dynamics

Reactive change proficiency is the foundation of viability and opportunistic activity. Reactive changes are generally triggered by events which, once recognized, demand a response. Maybe they are problems that must be attended to or fixed, or maybe they are opportunities that must be addressed. The principle differentiation is that there is little if any choice in the matter – a reaction is required. Reactive changes are often a response to competitive dynamics: Japan makes car quality an issue, electronic commerce changes customer relationship expectations. They can also be responses to customer demands, order fulfillment requirements, equipment malfunctions, legal and regulatory disasters, product failures, market restructuring, and other self-induced or non-competitor generated events. Reactive changes typically respond to the voice of the customer, say yes to opportunity, mitigate the down-side of problems, and provide general resiliency. The four reactive change domains are correction, variation, expansion/contraction, and reconfiguration.

Correction - Issues arising because something ceases to function as expected. Questions: What can break? What can fail? How can a relationship become dysfunctional? What assumptions may become invalid?

Variation - Issues among the normal course of operational performance that require unscheduled (or new schedule) accommodations from time to time. Questions: What types of scheduling changes are typical? What latitude is possible in orders, product features, supplier performance, employee skills? How big are the variations likely to be? How have we been surprised before?

Expansion/Contraction - Issues involved with quantity and capacity changes, when either more or less of something or some capability that already exists is more appropriate. Questions: What does quantitative capacity mean in this situation? Where are the upper and lower capacity limits, and how would they become a problem?

Reconfiguration - Issues involved with re-ordering or re-relating a set of existing components and their interactive relationships. Questions: What relationships might change with time or need? What sequences will change? What components might be moved to another location? When could some components offer value if they were moved?

The RS Analysis Process

As a language these eight change domains help us categorize and discuss concepts. At times there may be heated debate about which domain a specific issue belongs in. This is indicative that it may well be more than one issue; as it obviously is for the debaters. In any event, the discussion and debate is a healthy way to expand the understanding of the essence of the issue, a positive factor when evaluating subsequent potential solutions.
   Though RS analysis can be done by a single person, it is better done in collaborative company. Its purpose is to develop a comprehensive understanding of a problem, and different minds will definitely have different perspectives. You don't need a lot of questions under each category if you have a lot of people responding to the question – each will hear a question differently. Asking one question gets a result multiplied by the number of people that respond to it. Chalk one more up for collaborative working groups. With fewer people in a group more questions have to be asked, more time has to be spent in each domain. If you're all alone it can get tough to be really objective and comprehensive. After all, you have an agenda to complete.
   Typically the best way to start is to brainstorm for issues of any type, especially with groups unfamiliar with the change domains and RS analysis. Then separate these issues into proactive and reactive categories, and reword them so the operating dynamic is obvious. It often helps to reword them so that they specifically include the change domain that they belong to. The purpose here is to focus the issue more precisely on the nature of the dynamic that makes it an issue. This categorization is sometimes problematic in a group setting – but has the advantage of clarifying what is meant, and often expands the list of issues as you find that one statement is meant differently and validly by more than one person. These differences surface when you categorize an issue to the satisfaction of one person and the dissatisfaction of another.
   It is important to establish the boundaries of the system under analysis. For instance, the business practice employed when launching a new product is a separate "system" from the ongoing product production system. You might analyze the launch practice itself, or you might analyze the ongoing production process established during the launch; both are interesting and related dynamic activities. The customer for the launch practice is the production operation – so analyzing launch should benefit from a simultaneous analysis of production, to help put the launch practice in context. In the end it is important to review the final issues to see if they are isolated to the system under analysis or have migrated to the next higher or lower systems, or to predecessor or successor systems, as could be the case with launch and production.

Summary: Response Situation Analysis Process

1. Assemble a mixed collaborative team.
2. Bound the system, establishing the perimeter.
3. Brainstorm issues into pro- and re-active categories, specifying the change proficiency metric(s) of interest: time, cost, quality/robustness, scope (see Essays #5 and #18).
4. Sort brainstorm issues into change domains.
5. Develop and ask questions specific to each change domain, adding categorized issues as they surface.
6. Review all issues for applicability to the system under analysis, and separate those involved with higher or lower level systems.
7. Finally, have a single mind privately reword and rationalize all the issues.
8. Optional: it is often useful to purposely analyze higher and lower level (or predecessor and successor) systems as it helps put the focused system in context.

========= Reply =========================
From: (Rick Dove), Date: Tue, 17 Aug 1999
Yes it does, Gail. The article you referenced was the one you offered, and we posted, for our January '99 Guest Speaker Feature ( http://www.parshift.com/Speakers/Speak012.htm). I had thought the this current essay would run concurrently with your insights but other issues sidetracked that plan.

========= Reply =========================
From: "Gail Taylor" gail.taylor@mgtaylor.com Date: Tue, 17 Aug 1999
I do refer many people to the site and enjoy reading it. Gail

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