. 6
( 9)


Brainstorming To create a large body of related ideas
Benchmarking To discover/research ˜˜Best Practices™™ or ˜˜Best-in-Class™™ for your industry
or product
Standard Processes To discover/research standard processes in your industry or in support of
your industry
Customer Processes To discover/research processes unique to your customers
Enterprise Processes To discover/research processes characteristic of your enterprise to serve this
(these) business areas
Project/Program Processes To provide processes speci¬cally for this project/program

6.2 Brainstorming

Ken Blanchard™s notion that ˜˜None of us is as smart as all of us™™2 is synergy
epitomized. If you try to come up with all the answers yourself, you™ll end up
with only a few of the potential answers and those will be from a single vector
of thinking. I heartily recommend brainstorming as a technique to create a large
list of potential solutions. The entries on that list can be evaluated later.
Brainstorming can be the function of a local group or it can be the function
of a dispersed group using the distributed method. The advantage accrues by
having a greater number of people, and thus ideas, involved in the process. The
advantage of the distributed method is that more experts of a higher level or
experts of more diversity (whatever that means to you) can be applied to the
task. The main thing to remember when brainstorming is to include all inputs,
no matter how unusual or inappropriate they may seem to be at the time.
Rejecting any input will have the effect of throwing cold water on the process.
If your approach is to use a local group, you will need a room to accommo-
date the people involved. Experts suggest that the group be from two to twenty
people. Seating in a circle or a ˜˜U™™ is preferred. Flipcharts or sticky notes can
be used to capture the ideas offered by the group. These techniques have been
updated by many companies through using overhead viewgraph projectors with
blank slides to write on or by using computer projection techniques”that is,
simply typing in the ideas as they come up and maintaining a permanent record
of what went on. It is best to use a facilitator to moderate the activity. My
suggestion is to use a professional (someone from your training department is

appropriate) rather than trying to do it yourself. This is especially true if you
are in charge of the program. The group will tend to defer to you, and you will
miss a lot of good inputs. Write down all the inputs (even those that are repeti-
tive). Keep the ¬‚ow going . . . pump the participants for ideas . . . get the best
from them. When everyone is totally exhausted, take a break. Come back and
eliminate items and group the overall list by voting on the individual inputs.
Sometimes changing a word or two will ˜˜commonize™™ the inputs, and they can
be combined. The point is though, do it through a voting technique rather than
by ¬at.
Nowadays, the Internet makes distributed brainstorming an inexpensive al-
ternative to a local group. This method is very good for very large companies
spread across the nation or the world. You use the same techniques except you
create a ˜˜chat group™™ with a moderator. This is extremely powerful when you
can call upon the best minds in the business, no matter where they are. Using
the ˜˜Track Changes™™ function of a word processing application also works very
well for this process. In fact, the peer review of this book was conducted in
exactly that way.
Software to provide brainstorming is listed in Table 6-2.

Ta b l e 6 - 2 ” B r a i n s t o r m i n g S o f t w a r e

Tool Product Vendor
˜˜Brainstorming™™ In¬nite Innovations, Ltd
˜˜PathMaker™™ SkyMark

Following is contact information for the companies listed in Table 6-2:

In¬nite Innovations Ltd.
Innovation House
71 Sheldon Road
Shef¬eld S7 1GU
Phone/Fax: 44 114 2967546
Web site: www.brainstorming.co.uk
E-mail: info@brainstorming.co.uk

7300 Penn Avenue,
Pittsburgh, PA 15208
Order: 800-826-7284
Phone: 412-371-0680
Fax: 412-371-0681
Web site: www.skymark.com
E-mail: sales@skymark.com

For in-depth information on brainstorming, see Edward de Bono, Serious
Creativity, New York: Harper Business, 1992.

6.3 Researching Appropriate Benchmarks

Webster de¬nes Benchmark as ˜˜a point of reference from which measurements
may be made; something that serves as a standard by which others may be
Benchmarks, in the business world, are results achieved by enterprises, com-
panies, corporations, etc., and are held up as standards for that particular appli-
cation, function, etc. The use of the term ˜˜Benchmark™™ in industry means that
benchmarks are the highest value achieved for that particular function in that
particular business area. Therefore, that Benchmark is (or should be) a goal for
others in the same business area to achieve. Reviewing benchmarks is akin to
employing the old adage of ˜˜not reinventing the wheel.™™ If another company in
your business area has already solved a problem and created a process and a
metric that indicates success, why not use it? Some companies hold their bench-
marks (read successes) close to their chests, and discovering them may be dif¬-
Several organizations have been created for the purpose of sharing bench-
marks. One such organization is the Project Management Benchmarking Net-
work. They can be reached at:

Project Management Benchmarking Network
4606 FM 1960 West
Suite 250
Houston, TX 77069
Phone: 281-440-5044
Fax: 281-440-6677
Web site: www.pmbn.org

According to their Web site, ˜˜The Project Management Benchmarking Net-
work (PMBN) is currently a free association of Project Management organiza-
tions within major corporations. PMBN conducts benchmarking studies to
identify practices that improve the overall operations of the members.™™

Best Practices, LLC
6320 Quadrangle Dr., Suite 200
Chapel Hill, NC 27514-7815
Phone: 919-403-0251
Fax: 919-403-0144
E-mail: best@best-in-class.com

Use these recommended methodologies as you see ¬t. You may or may not
need them all. The point is to expand the constituents of your cause database
so that it re¬‚ects the milieu in which you and your project or program operate.
One thing to remember though is that just because some company has cre-
ated or holds claim to a ˜˜Benchmark™™ doesn™t mean that is an absolute. It is
entirely possible that another ˜˜Benchmark™™ of higher order or greater quality,
etc., could be found . . . and you could ¬nd it!

6.4 Researching the Processes

It is imperative that you understand the processes that drive your projects and
programs. The processes will likely drive the requirements and the metrics that
evaluate the implementation of the project/program requirements. These proc-
esses fall into four categories: Standard Processes, Customer Processes, Enter-
prise Processes, and Project/Program Processes. They are placed in this order
because Standard Processes cover an entire area of interest. Customer Processes
cover the entire customer span of control and so on. The order of precedence
is quite another matter. The customer may well modify a Standard Process, and
that modi¬cation would take precedence over the Standard Process with regard
to the contract you are bidding or performing.


The Standard Processes referred to here are those processes common to ev-
eryday problem solving and are probably referred to in Project/Program, Enter-

prise, or Customer Processes rather than being speci¬cally rewritten. Such proc-
esses are Professional and Association general processes standardized by such
organizations as IEEE, IATA, ISO, EIA, ASME, ASTM, CCITT, NEMA, UL, and
a host of others. You can use these processes as standards during your problem
analysis, or your customer can speci¬cally invoke them as a part of your con-
tract or requirements document.


Customer Processes are those processes established by the customer with
which you are dealing for this speci¬c project. Examples of such processes are:
Military Standards, DOD Standards, Data Item Descriptions (DIDs), NASA
Standards, FAA Standards, Municipal Government Standards, and so on. Some-
times standards are just that, standards and not processes at all. They are, how-
ever, just as appropriate.


Enterprise Processes are those processes established by the enterprise, com-
pany or corporation as a whole and apply to all projects or programs run by that
enterprise. Examples of such processes are: Customer Processes, Administration
Processes, Finance Processes, Legal and Contracts Processes, Personnel/Human
Resources Processes, Material Processes, Research and Development Processes,
Quality Processes, Projects/Programs Processes, Engineering Processes, Manu-
facturing and Production Processes, Field Operations Processes, Warranty Proc-
esses, and Operations and Maintenance Processes. Within the enterprise, these
processes usually begin as policies from the highest level in the enterprise. Proc-
esses, procedures, and plans are derived from and driven by policies (at least
they should be).


Project/Program Processes are, quite aptly, those processes you generate for
your Project or Program. Usually, these are extensions of enterprise, company,
or corporate processes and are written by those organizations and directed to
be incorporated into your project or program plans. Usually, you extend and
incorporate these processes or parts of these processes into your Program Plan
or the plans that support the Program Plan. Examples of these kinds of proc-

esses are the speci¬cs of Team Members and Alliance Processes, Subcontracts
Processes, Materials Management Processes (including Make/Buy Decisions),
Data Management Processes, Con¬guration Management Processes, Quality
Assurance Processes, as well as Training Processes, Safety Processes, Security
Processes, and Facilities Processes as they apply to your speci¬c project or pro-
On the technical side of the house, these processes frequently include: Tech-
nical Strategy, Functional Analyses, Requirements Allocation, Generation of
Speci¬cations, Generation and Control of Drawings, Alternative Designs, and
By way of example, Table 6-3, Policy-to-Program Plan Cross Reference,

Ta b l e 6 - 3 ” P o l i c y - t o - P r o g r a m P l a n C r o s s R e f e r e n c e

Reference Para Title
M-M 11000 Series 5 Management
M-M 05010 5.1 Organization and Responsibilities
M-M 11010 5.1.1 General
M-M 12000 Series 5.1.2 System Management
M-M 06000 Series 5.1.3 Subcontracts and Materials
M-M 11050 5.1.4 Data Management
M-M 11030 5.1.5 Con¬guration Management
M-M 09000 Series 5.1.6 Quality Assurance
M-M 04020 5.1.7 Team Members and Alliances
M-M 06040 5.2 Make/Buy Decisions
M-M 02030 5.3 Safety
M-M 02040 5.4 Security
M-M 02020 5.5 Facilities
M-M 11060 5.6 Standardization
M-M 11028 5.7 Program Risks
M-M 11020 6 Program Controls
M-M 11022/3 6.1 Cost and Schedule Controls
M-M 11040 6.2 Communication Control
M-M 11041 6.3 Status Meetings
M-M 12010 6.4 Design Reviews
M-M 12090 6.5 Speci¬cation Control

shows which Enterprise Policies, Plans, and Processes should be referenced or
˜˜¬‚owed into™™ which paragraph of the Program Plan. The references in the refer-
ence column are to Modern-Management Policies, Plans, and Processes, the
details of which will be available in future books in my Strategy for Success
series. For your use, however, you should enter your enterprise, company, or
corporate policy reference. The paragraph (Para) number refers to the para-
graphs in the Standard Program Plan which can be found in Attachment 1 in
this book.


1. Mary Ellen Guffey, Business Communication: Process and Product. 2nd ed. (Cincin-
nati: South-Western College Publishing, 1997), chapter 1.

2. Kenneth Blanchard, ˜˜None of Us Is as Smart as All of Us™™ (¬rst appeared in
Kenneth Blanchard and Johnson Spencer, The One Minute Manager (New York: Wil-
liam Morrow and Co., Inc., 1982), and continues to be used in his High Performing
Teams program, lectures, and workshops).


7.1 General

Now that you have a pile of data, you need to turn it into information. You
need to organize the data so that it is understandable by itself and in relation to
other data items. This chapter will present four techniques to assist you in the
organization of your data. These four were selected from the dozens, if not
hundreds, of techniques available because they individually and collectively
cover most of the ordering techniques that need to be covered.

7.2 Ordering Techniques

Ordering techniques are needed to make sense of the mound of data you have
created by brainstorming, researching processes, and reviewing ˜˜Best Practices.™™

.......................... 9758$$ $CH7 12-09-02 08:30:14 PS

There are many, many ordering techniques available but I have chosen only a
few (see Table 7-1). These few have either a primary and secondary purpose or
lead directly to a secondary purpose. For example, the 85:15 Rule not only
orders data but also places it into two primary categories. Cause and Effect
Diagrams not only lay out the causes and reasons for the causes but provide a
trail of sorts to the effect. Furthermore, the Cause and Effect Diagram leads
directly to Failure Mode and Effect Analysis (FMEA). (You may or may not
want to use FMEA depending on the issue with which you are dealing. It is
more appropriate to technical issues than programmatic issues.)

Ta b l e 7 - 1 ” O r d e r i n g Te c h n i q u e s

Ordering Technique Purpose
85:15 Rule To organize information into ˜˜process™™ or ˜˜people™™ categories.
Cause and Effect Diagrams To show the relationship of reasons to causes and causes to effects
Af¬nity Diagrams To organize large groups of information into meaningful categories
Relationship Diagrams To show the relationship(s) between elements

7.2.1 85:15 RULE

The 85:15 Rule is used to separate causative data into process-related groups
and people-related groups. The basis of the 85:15 Rule is that 85 percent of
problems are process related while only 15 percent of problems are people re-
lated. Be careful when interpreting this rule, though. It does not mean that if
you have rules, they will create 85 percent of your problems. It simply means
that there is a signi¬cantly higher probability that an error was caused by a
process than by a person.
There are some who say, ˜˜There are no good rules, just good sense.™™ I believe
that™s half right. There are indeed good rules, but everything needs to be inter-
preted with good sense.
The 85:15 Rule is used extensively in the area of education. Brenda Barnes
and James Van Wormer state:

Deming and others have established that the potential to elimi-
nate mistakes and errors in the workplace lies mostly in im-
proving the systems through which work is done, not in chang-
ing the individual workers. Their observations have evolved

into the rule of thumb that at least 85% of work problems can
be corrected by changing the work system and less than 15%
can be corrected by changing individual workers. Current re-
search indicates that the split probably leans even more towards
the system. The rule probably should be 95/5 or 97/3. In his
famous Red Bead Experiment, Dr. Deming proved that the only
way to improve a product or service is for management to im-
prove the system that creates that product or service.1

The appropriateness of that statement here is that it not only con¬rms the
ratio but also implies it is even greater than the 85:15 stated.
This rule is particularly appropriate for use in this process because our Pro-
gram Plans and Technical Plans are directly driven by Standard, Customer, and
Enterprise Processes.
The 85:15 Rule is used for separating process issues from people issues for
the purpose of problem solution. I suggest using this technique ¬rst to orient
your actions to the potentially most rewarding group of solutions. It is a simple
way to put your data into two piles.
The 85:15 Rule is a very simple and highly effective technique to evaluate
each issue you come up with. Look at the issue. What is the issue, what affects
it, and what does it affect? If the answer to the questions is process, put it in
Pile A. If the answer is people, put it in Pile B. If you follow the precepts of the
85:15 Rule, there is an 85 percent probability that the answer lies in Pile A and
a 15 percent probability that the answer lies in Pile B. Which one would you
address ¬rst?


The Cause and Effect Diagram shown in Figure 7-1 is used to create multiple
pathways to ¬nd causes and then reasons for the causes that contribute to a
The cause and effect process is a logical process and has been around for a
long time. Cause and effect analysis is an effective tool that allows people to
easily see the relationship between factors to study processes and situations and
to use them for planning.
The Cause and Effect diagram is also called the Ishikawa Diagram (after its
creator, Kaoru Ishikawa of Japan), or the Fishbone Diagram (due to its shape).

Figure 7-1 ” Fishbone Diagram

Cause Cause


Cause Cause

The Cause(s) in the diagram would be major contributors to the program or
project such as Processes, People, Machinery, Materials, and Environment. You
will need to adjust these Causes to ¬t your situation. In some cases, for instance,
you may want to use elements of the organization as Causes. In other cases, you
may want to use elements of your speci¬c process as Causes. The Causes for
your program could be similar to these but not necessarily the same. The Rea-
sons are why the Cause is contributing to the problem. For instance, Reasons
that contribute to Materials Cause could be: 1) The wrong materials were speci-
¬ed or 2) the SOW was incorrect or 3) the subcontractor or vendor did not
perform properly. These Reasons will go on and on, and they will be speci¬c to
your project and to the product you are creating. Process Reasons could be an
incorrect process that falls short of specifying some critical action necessary for
this project. And so on.
Some time later, a modi¬cation to the classical ¬shbone diagram was created
to make it into what is called a ˜˜Tree Diagram.™™ A drawing of the Tree Diagram
can be seen in Figure 7-2. If you use a drawing program to support your ˜˜Cause
and Effect™™ analysis, your end product will resemble that ¬gure.
An even simpler method than drawing the ¬‚ow is to use a spreadsheet pro-
gram to create an ordering of ˜˜Reasons,™™ ˜˜Causes,™™ and ˜˜Effects.™™ For purposes
of organization, the presentation is reversed: the Effect is on the left, the Cause
in the middle, and the Reason on the right, as they appear in Table 7-2. The
Effects are numbered as 1, 2, 3, and so on. The Causes are numbered 1a, 1b,
and 2a, 2b, and so on. The reasons are numbered 1.a.1, 1.a.2, and 2.a.1, 2.a.2,
and so on. Using this technique, you can develop your Causes and Reasons in
a nonlinear or random fashion, so long as you maintain the relationships. A
simple ˜˜sort™™ will place the Reasons, Causes, and Effects in their proper places.

F i g u r e 7 - 2 ” Tr e e D i a g r a m




Ta b l e 7 - 2 ” C a u s e a n d E f f e c t Ta b l e

Sequence Effect Cause Reason

You can also use three columns of data and one column of sequencing as shown
in Table 7-2. If necessary, another column can be added.
The Cause and Effect Diagram is used for listing the primary, secondary, and
even tertiary causes that relate to some selected problem area and provides a
visual display of a list in which you identify and organize possible causes of

problems, or factors needed to ensure success of some effort. It was created so
that all possible causes of a result could be listed in such a way as to allow a
user to graphically show these possible causes. From this diagram, the user can
de¬ne the most likely causes of a result. This diagram was adopted by Dr. W.
Edwards Deming as a helpful tool in improving quality. Dr. Deming has taught
Total Quality Management in Japan since World War II. He has also helped
develop statistical tools to be used for the census and taught the military his
methods of quality management. Both Ishikawa and Deming use the Fishbone
Diagram as one of the ¬rst tools in the quality management process.
One limitation of the Cause and Effect Diagram, whatever presentation tech-
nique is used, is that the diagram does not show magnitude. One might say that
it is ˜˜a good map but it lacks time and distance data.™™2 Data Sheets, Histograms,
Pareto Analysis, Failure Mode Effect Analysis (FMEA), and other data collection
and analysis tools can be used to quantify the data.
For additional information on the Cause and Effect Process, see:

John F. Early, ed. Quality Improvement Tools. Wilton, Conn.: Juran Institute,
P.E. Plsek. ˜˜Tutorial: Management and Planning Tools of TQM.™™ Quality
Management in Health Care 1, no.3 (1993).
Peter Senge. The Fifth Discipline. New York: Doubleday, 1990.

Software used to support the Cause and Effect Process is listed in Table 7-3.

Ta b l e 7 - 3 ” C a u s e a n d E f f e c t S o f t w a r e

Tool Product Vendor
Cause and Effect
˜˜REASON 4™™ DECISION Systems, Inc.
˜˜Flowcharting Cause & Effect Module™™ for ˜˜Six Sigma
Software Suite™™ Quality America, Inc.
˜˜Root Cause Analysis (RCA)™™ Root Cause Analyst
˜˜PathMaker™™ SkyMark

Following is contact information for the companies listed in Table 7-3:

DECISION Systems, Inc.
802 N. High St. Ste. C
Longview, TX 75601
Phone: 903-236-9973
Fax: 903-236-3794
Web site: www.rootcause.com/
E-Mail: dsi@rootcause.com

Quality America, Inc.
P.O. Box 18896
Tucson, AZ 85731-8896
Order: 800-643-9889
Phone: 520-722-6154
Fax: 520-722-6705
Web site: www.qualityamerica.com/
E-mail: sales@qualityamerica.com

Root Cause Analyst
Orion Healthcare Technology
1823 Harney Street, Suite 101
Omaha, NE 68102
Phone: 800-324-7966
Fax: 402-341-8911
Web site: www.rcasoftware.com/
E-mail: info@casoftware.com

7300 Penn Avenue,
Pittsburgh, PA 15208
Phone: 800-826-7284
Fax: 412-371-0681
Web site: www.skymark.com
E-mail: info@skymark.com

The purpose of the Af¬nity Diagram, shown in Figure 7-3, is to organize
large groups of information into meaningful categories.

Figure 7-3 ” Affinity Diagram


1 2 11 12 21 22

3 4 13 14

5 6

The Af¬nity Diagram or KJ Method (so named for Kwakita Jiro) helps break
old patterns of thought, reveal new patterns, and generate more creative ways
of thinking. The Af¬nity Diagram helps organize the team™s thoughts most ef-
fectively when the families seem too large and complex; you need to break out
of old, traditional ways of thinking; everything seems chaotic; or there are many
If you research this process, you will ¬nd there are two schools of thought.
The ¬rst is to start at the top and work down. The second is to start at the
bottom and work up. The following process is my favorite; that is, starting from
the bottom and working up. The reason I choose this methodology is because it
creates its own organization rather than being forced into some predetermined

1. Convert the mound of data created earlier to 3 x 5 cards or to Post-it Notes.
2. Begin arranging these notes into related categories. These are the numerical
squares shown in Figure 7-3. No doubt you will create a lot of categories and
a lot of piles. As time goes on though, you will begin changing a word here
and there and combining these piles into more closely related groups. Just
don™t lose the essence of the card entry.
3. At some point, it will make sense to create a ˜˜Header™™ card that describes
the group. The ˜˜Header™™ cards become the Alpha cards shown in Figure 7-
3. Iterate until the groupings and entries are, in your judgment, optimized.
Your ˜˜gut™™ will tell you when you are through. The software shown in Table
7-4 is available to assist in this chore.

Ta b l e 7 - 4 ” A f f i n i t y D i a g r a m S o f t w a r e

Tool Product Vendor
Af¬nity Diagram
˜˜EDGE Diagrammer™™ Pacestar Software
˜˜SmartDraw™™ SmartDraw.com
˜˜Six Sigma for Excel™™ BaRaN Systems LLC

Following is contact information for the companies listed in Table 7-4:

BaRaN Systems, LLC
Phone: 780-449-6554
Web site: www.baran-systems.com

Pacestar Software
P.O. Box 51974
Phoenix, AZ 85076-1974
Phone: 480-893-3046
Fax: 413-480-0645
Web site: www.pacestar.com
E-mail: pacestar@compuserve.com

10085 Carroll Canyon, Suite 220
San Diego, CA 92131
Phone: 800-501-0314
Fax: 858-549-2830


The next step is to evaluate and classify the data. One of the best tools to
accomplish this task is a Relationship Diagram. The Relationship Diagram was
reportedly invented by P. Chen and presented in his article in 1976.3 The pur-
pose of the Relationship Diagram is to show the interrelationships between
causative factors that relate to a problem.
A Relationship Diagram, as shown in Figure 7-4, is one that shows connec-

Figure 7-4 ” Relationship Diagram

tions or relationships between the elements of the diagram. In this case, the
elements are Issues.
The Relationship Diagram, in contrast to the Af¬nity Diagram, which only
shows logical groupings, helps map the logical relationships between the related
items uncovered in the Af¬nity Diagram. The Relationship Diagram shows
cause and effect relationships among many key elements. It can be used to
identify the causes of problems or to work backward from a desired outcome
to identify all of the causal factors that would need to exist to ensure the
achievement of an outcome. The Relationship Diagram doesn™t necessarily need
to follow the form of the ˜˜bubble™™ chart shown. A traditional organization
chart and a ¬‚ow diagram are examples of other presentations of Relationship
The process to be used is as follows:

1. State the problem or family under discussion”software defects, customer
retention, process steps, whatever.
2. Capture that problem or issue in a box, bubble, or whatever.
3. Begin a process of looking for ˜˜drivers™™; that is, functions or issues that
drive the issue being considered. You can also use the rationale of the
PERT Chart (see glossary) in considering ˜˜predecessors™™ for this part of
the process. In other words, you are looking for items that drive or must
be completed before the issue at hand.
4. Begin a process of looking for ˜˜drivens,™™ that is, functions or issues that
are being driven by the issue at hand. If you prefer, use the term ˜˜prede-
cessors™™ for ˜˜drivers™™ and ˜˜successors™™ for ˜˜drivens.™™
5. When you have diagrammed the issue and have located all the ˜˜drivers™™
and ˜˜drivens™™ something will jump out at you. That bubble or square

that has ˜˜drivers™™ but no ˜˜drivens™™ is the primary issue whether that™s
the one you started with or not!

If you want or need to go beyond the simple relationships of one issue driv-
ing another, consider the following:

’ The bubble is the issue.
’ The lines (arrows) connecting the bubbles are the actions.
’ The value of the line (arrow) is the magnitude.
’ The characteristics of the bubble are its attributes.

A veritable glut of information exists on Relationship Diagrams. Much of it
is Entity-Relationship Diagrams as a result of our software society. The source
of a lot of the information is the use and application of relational databases
such as Microsoft™s Access. Most written information regarding Relationship
Diagrams is in the form of articles rather than books.
Software used to support Relationship Diagrams is listed in Table 7-5.

Ta b l e 7 - 5 ” R e l a t i o n s h i p D i a g r a m S o f t w a r e

Tool Product Vendor
Relationship Diagrams
˜˜EDGE Programmer™™ Pacestar Software
˜˜SmartDraw™™ SmartDraw.com

Following is contact information for the companies listed in Table 7-5:

Pacestar Software
P.O. Box 51974
Phoenix, AZ 85076-1974
Phone: 480-893-3046
Fax: 413-480-0645
Web site: www.pacestar.com
E-mail: mail@pacestar.com

10085 Carroll Canyon Road, Suite 220
San Diego, CA 92131
Phone: 858-549-0314
Order: 800-501-0314
Fax: 858-549-2830
Web site: www.smartdraw.com
E-mail: mail@smartdraw.com

7.3 Interrelationships of Causes

Many causes will have interrelationships with other causes. That™s not necessar-
ily bad but what you must look for is duplication and overlapping. Duplication
is a waste of time and money. Overlapping causes will tend to present an unclear
picture of what the problem really is when you try to classify the problem.
When you have reached a stopping point or believe you have reached a
plateau in your search and organization of causes and potential causes, step
back for a moment and review what you have created, and take an objective
view of your new cause package. If you have not reached Shangri-la, don™t
worry. Tomorrow is another day.
If you have solved the immediate problem, that™s wonderful. If you are per-
forming this process before you have a problem, congratulations. What you
want to do now that you have a feel for the overall process is to look back at
your business area standards, your customer references, and your enterprise
policies and processes and make certain your new Search Table and Cause De-
scriptions re¬‚ect all these standards.


1. Brenda J. Barnes and James W. Van Wormer, ˜˜Process Thinking and the 85:15 Rule
Applied to Education.™™ Source: www.grand-blanc.k12.mi.us/qip/ProcessThinking.htm,
last accessed August 5, 2002.

2. Robert Luttman and Associates Online Article, ˜˜Cause and Effect.™™ Source: www.
robertluttman.com/cause-effect.html, last accessed August 5, 2002.

3. P. Chen, ˜˜The Entity-Relationship Model: Toward a Uni¬ed View of Data,™™ ACM
Transactions on Database Systems, 1, no. 1 (1976): 9“36.


8.1 General

In Chapter 6, you expanded the original causes to include additional causes
necessary to solve the problem at hand. In addition, you probably expanded the
causes to include those that are unique to your product area, customer, or
product. Finally, you ordered the new causes into categories that are meaningful
to you.
Now is the time to evaluate those causes you have chosen and ordered. The
point of evaluation, of course, is to add a quantitative dimension to the causes
that permits you to select the most important cause(s).
Table 8-1 summarizes the purpose of each of the techniques that will be
talked about in this chapter.
You must be the judge of which and how many of these techniques you need

.......................... 9758$$ $CH8 12-09-02 08:30:26 PS

to use for your particular problem set. Base your choice on the purpose of each
of the techniques as shown in Table 8-1.

Ta b l e 8 - 1 ” A n a l y s i s Te c h n i q u e s

Analysis Technique Purpose
Pareto Analysis To select the 20 percent of the issues that provide 80 percent of
the results
Force Field Analysis To understand restraining forces and driving forces
Failure Mode Effect Analysis (FMEA) To predict potential failures
Monte Carlo Simulation To re¬ne estimates

8.2 Evaluation Techniques

There are numerous techniques available to assist you in evaluating your
Causes. Some of the other techniques available are Blue Slipping, Consensus
Gram, Flow Charting, Gallery Walking, Histograms, Light Voting, Lotus Flower
Diagrams, Radar Diagrams, Run Charts, and Scattergrams. I have tried to select
several that are the most appropriate for the general ¬eld of technical project
management. Even at that, you will probably not use all of them to solve any
one problem. Possibly, you may not use one or more of them ever. Still, you
should know what is available to you.


The Italian economist Vilfredo Pareto (1848“1923), established a theory for
the purpose of evaluating the sources of a society™s wealth. His thesis was later
con¬rmed by Juran, and the Pareto Principle was established as: ˜˜Not all of the
causes of a particular phenomenon occur with the same frequency or with the
same impact.™™
Pareto analysis is used to get a quick assessment of the most important fac-
tors involved in the data you are assessing.
To perform a Pareto analysis, you must ¬rst list all the issues. Next, you
must determine the number of occurrences or the amount of deviation or apply
whatever metric you use to determine ˜˜goodness™™ or ˜˜badness.™™ Once you have
achieved this evaluation, it is recommended that you create a bar chart. As the
issues begin to unfold, you will see the relative sizes of the bars begin to take

shape. The bar chart, similar to Figure 8-1, will give you a relative representation
of the issues.
The next step is to reorder the bars of the chart so that the ¬rst bar is the
tallest with the adjacent bar the next tallest and so on until you run out of bars.
Rearranged, the issues now look like Figure 8-2. Clearly Issue 2 and Issue 3
constitute the most number of occurrences. Pareto™s Principle suggests focusing
on identifying these key issues. Interestingly, Jay Arthur1 has created what he
calls his 4“50 rule. His principle suggests that 4 percent of the problems contrib-
ute to 50 percent of the losses. Or 4 percent of the zones contribute 50 percent

Figure 8-1 ” Pareto Analysis: Raw Data

1 2 3 4 5

Figure 8-2 ” Pareto Analysis: Ordered Data

2 3 4 1 5

of the sales, and so on. I would not argue with either thesis. The principles are
clearly the same in suggesting a few of the issues cost you the most money.
Attack those few ¬rst to get the biggest ˜˜bang for the buck.™™ Interestingly, the
Arthur modi¬cation to Pareto Analysis is quite similar to the Barnes and
Wormer modi¬cation of the 85:15 Rule (see paragraph 7.2.1).
Obviously, in order to invoke the 4“50 rule, one would need to have a sig-
ni¬cant number of issues to evaluate, certainly more than four.
There are many, many books that contain the Pareto Principle, but most are
sociology books and economics books. The Pareto Principle, Pareto Analysis,
etc., does not warrant a book per se. You will ¬nd all the information you need
in articles and short references. If you want more detail, do an Internet search
on Pareto and you will ¬nd more detail than you ever wanted.
See Table 8-2 for Pareto Analysis software.
Ta b l e 8 - 2 ” P a r e t o A n a l y s i s S o f t w a r e

Tool Product Vendor
Pareto Analysis
˜˜PathMaker™™ SkyMark

Following is contact information for the company listed in Table 8-2:

7300 Penn Avenue,
Pittsburgh, PA 15208
Phone: 800-826-7284 or
Fax: 412-371-0681
Web site: www.skymark.com
E-mail: info@skymark.com

The purpose of Force Field Analysis is to list the driving and the restraining
forces of an issue so that you can take the next step”to neutralize the restrain-
ing causes and to amplify the driving causes.
The Force Field Analysis concept was developed by the American social psy-
chologist Kurt Lewin based on the premise that any problem or situation is a

result of the forces acting upon it. The forces acting upon a problem are issues
of two kinds: driving forces and restraining forces. Driving forces are those that
are trying to cause a change in a static condition. Restraining forces are those
that are trying to maintain the static condition; not at all unlike Newton™s First
Law. When attempting change or improvement, if the restraining and driving
forces can be understood, the process improvement team can look for ways to
enhance the driving forces and moderate or eliminate the restraining forces.
Force ¬eld analysis uses a graphical technique to map the forces that are
affecting the situation. All driving forces are shown on one side of the issue, and
all restraining forces are shown on the other side, as in Figure 8-3.
An interesting, and frequently useful, modi¬cation to the basic approach
assigns a number (value) to each of the forces, both positive and negative, affect-
ing the issue. The value of the numbering system must be the same on both
sides. By assigning values, one can add the total values and make an initial
determination of the dif¬culty of changing the issue as well as the value of each
force. This gives the project manager an idea of the magnitude of the problem
and the power of the tool being used as well as the easiest and most dif¬cult
restraining forces with which to deal.
From a practical standpoint, Force Field Diagrams are generally constructed
with two columns of data for each effect. The driving forces are listed in the

Figure 8-3 ” Force Field Schematic

Driving Restraining
Forces Forces


¬rst column and the restraining forces are listed in the second column. The
same technique can obviously be used to list strengths and weaknesses, pros
and cons, and any other positive and negative in¬‚uence that acts upon an effect.
You can map these forces in a number of ways. The easiest way is to use a
spreadsheet to list the forces.
Once all of the forces are mapped, it becomes possible to see how opposing
forces line up and then look for ways to counter the forces against each other
so that the current situation moves in the direction of the desired improvement.
Additional columns can be added to the left and right of the two central col-
umns to list factors that can emphasize (driving force) or neutralize (restraining
force) the data in the center two columns. You can add columns outside the
opposing forces to give each a Force Value. This will give you an idea of ˜˜How
much of A™™ or ˜˜How much of B™™ you need to apply to counter its opposing
force. You can use the sum function to balance or eliminate the forces.
Once the causes are known, cause and effect analysis can again be used to
determine exactly what kind of incentive package (driving force) it would take
to overcome this restraining force. There could be situations where you do not
want to maintain the status quo or stop some activity. In those cases, simply
reverse all the activities above. In other words, you want the restraining forces
rather than the driving forces to ˜˜win.™™
Software used to support Force Field Analysis is called ˜˜PathMaker™™ from:
7300 Penn Avenue,
Pittsburgh, PA 15208
Phone: 800-826-7284 or
Fax: 412-371-0681
Web site: www.skymark.com
E-mail: info@skymark.com
Failure Mode Effect Analysis (FMEA), sometimes called Failure Mode, Ef-
fects, and Criticality Analysis (FMECA) is intended to result in preventive ac-
tions. FMEA and FMECA are ˜˜before-the-fact,™™ exercises and you will most
likely use this technique when evaluating technical, rather than programmatic,
aspects of the system. A comprehensive FMEA will take a signi¬cant amount of
time so be sure to allocate the time necessary.

An FMEA is performed from the bottom up by evaluating the lowest part of
the system ¬rst. This involves the Lowest Replaceable Unit (LRU), the smallest
or the least signi¬cant unit. In electronic systems, this ˜˜unit™™ is frequently a
resistor or transistor or some such unit. After each unit is reviewed, it is used
as a ˜˜building block™™ to ultimately re-create the entire system. The usual way
to conduct an FMEA is to look at a ˜˜failed™™ unit and making a prediction by
asking the question: ˜˜What happens when this unit fails?™™
The purpose of the FMEA exercise is to identify critical components in a
system and evaluate the impact of the failure of that component and then, if
warranted, provide an alternate path, or back up or change the unit so that the
impact of failure is removed. By way of example, we did an FMEA on two
alternative data links from Cape Canaveral to Houston back before the ¬rst
mission was run from Houston. The system was designed to have two com-
pletely diverse data paths. One route was completely land-line (telephone line)
and the other was completely RF (microwave). We traced the design through
the entire thousand miles from the Cape to the Mission Control Center (MSC)
in Houston only to ¬nd that both diverse routes entered the Telco building just
outside the Control Center, and both routes went through the same ampli¬er.
Consider the effect of that failure!
Using reliability data is a good way to predict failure rates for components.
For instance, if ˜˜X™™ fails, it will take the ˜˜Y™™ function with it. However, the
probability of ˜˜X™™ not failing is 0.999999, so it™s not likely ˜˜X™™ or ˜˜Y™™ will be a
big contributor to overall system failure.
There are two kinds of failure, total and partial. In many systems, you will
get a different result with a partial failure than with a total failure. Other than
the obvious, a partial failure may affect the productivity of another unit in the
system and that unit will change the direction of the failure. For instance,
changing the bias on an electronic circuit will cause a different effect in a sec-
ondary circuit than if the circuit were completely dead.
Software to provide FMEA analyses is available as ˜˜Relex FMEA/FMECA™™

Relex Corporation
40 Pellis Road
Greensburg, PA 15601
Phone: 724-836-8800
Fax: 724-836-8844

For additional information on FMEA, see:

McDermott, Robin E., et al. The Basics of FMEA. Portland, Ore.: Productivity
Press, Inc., 1996.
Stamatis, Dean H. Failure Mode and Effect Analysis: FMEA from Theory to
Execution. Milwaukee, Wis.: ASQ Quality Press, 1995.


The real use of Monte Carlo Simulation in support of a project or program
is risk control. You want to control schedule risk or cost risk and usually both.
Monte Carlo Simulation almost demands the use of a computer because of the
nature of the process. The utilization of an available software package that sup-
ports all these objectives is highly desirable. Fortunately, such things exist.
In times past, we made use of the ˜˜wet-¬nger-in-the-wind™™ technique to
establish risk, and therefore contingency, in programs. If you have a small proj-
ect and the overall risk is not perceived as great, you can still use this technique.
Simply, the technique is to do a ˜˜bottom up™™ estimate of task cost and task
schedule. Assign a value factor to your estimate. I have always used the value
factors 10/90, 50/50, and 90/10. The factors go from more risk (10/90) to less
risk (90/10). If you are involved in a proposal, the proposal manager will proba-
bly insist on a 50/50 (most likely) estimate based on the assumption that 10/90
is too risky and 90/10 is too costly. You can then estimate the variance of what
it will take to get the task from 50/50 to 90/10. That estimate is the amount of
risk money or time that should be included with your bid along with a state-
ment of the task to be accomplished. Note: When I say ˜˜Included with your bid,™™
you need to follow the directions of your proposal manager. I insist that the time
and money allocated to risk be kept separate so that it can be collected at the
program level. Risk is then summarized, apportioned, and calculated at the pro-
gram level. If you include risk money at the task level you will end up with a bid
that will never win because of excessive cost.
Even though Monte Carlo techniques have been around for centuries, they
were not used extensively until the 1940s. History has it that Metropolis, associ-
ate of Stan Ulam, brought the technique to the fore during the Manhattan
Project of World War II mainly to support Ulam™s penchant for gambling”
hence the name Monte Carlo. Ulam used the technique to solve mathematical
problems using statistical sampling in the development of the hydrogen bomb.
Monte Carlo techniques were not used too often in project planning until
the last ten or so years. There are two reasons for this: First, projects are more

expensive today and pro¬t and schedule sensitivities are critical. Second, soft-
ware is now available to be used independently or in conjunction with other
software that makes the job of planning much simpler and faster, not to men-
tion more accurate.
The concept of the Monte Carlo technique is to assign Probability Density
Functions (PDFs) to outcomes. For example: Assume you have established a
task that is thirty days in duration. What is the probability that the task will be
four days late? What is the probability that the task will be done on time? What
is the probability that the task will be accomplished four days ahead of schedule?
The probability ¬gure is the traditional 0“1 where 1 is the equivalent of 100
percent. Note that each of the ¬gures is independent and the sum of all the
¬gures do not add up to one. Now, you don™t have to run too many projects or
programs to realize that, in the real world, the probability of schedule occur-
rence grows with time. In other words, the later the estimate, the more likely it
is that the task will be completed. If the original estimate is anywhere near
correct, you will get a distribution that looks something like:
Y 4 days .1
0 days .7
4 days .9

These are the PDFs that you run. It™s clear that, even with all the objectivity
of the computer and its processes, the basic data is subjective. In other words,

you established the original thirty days and you established the PDFs that apply
to each of the variances. That selection was, at least to some degree, subjective.
The computer will now select some random numbers and run the probabili-
ties over and over. You will end up with a high probability that the task will be
completed near the originally scheduled date but will be skewed slightly for-
ward. The early/late probabilities will center on this highest probability and
create a traditional bell curve or standard distribution curve. This foregoing has
been an extremely simpli¬ed example of what you might encounter in the ¬eld.
As promised at the outset of this book, I will not go into the math involved
in this process. If you are interested, I suggest you get a copy of any of the books
dealing with the Monte Carlo method. There are many, many of them out there.
You might consider the following books:

Rubenstein, Reuven Y. Simulation and the Monte Carlo Method. New York:
John Wiley, 1981.

Fishman, George S. Monte Carlo. New York: Springer-Verlag, 1996.
Sobol, Ilya M. A Primer for the Monte Carlo Method. Boca Raton: CRC Press,
Software, compatible with Microsoft products to provide Monte Carlo Simu-
lation, is available as ˜˜@RISK for Project™™ from:

Technology Associates
The Mansley Centre
Warwickshire CV37 9NQ
Worldwide Sales Of¬ce:
Phone: 44 (0) 1789 297000
Fax 44 (0) 1789 292191
E-mail: info@techassoc.com
U.S. Of¬ce
Phone: 917-210-8120
Fax: 917-210-8182
Voice mail: 206-374-2154

8.3 Eliminating Holes and Overlaps

Holes exist when a requirement or issue is uncovered. Overlaps exist when re-
quirements or issues are covered more than once, either totally or partially. The
point in determining holes and overlaps is to make our processes more ef¬cient
by covering all the requirements or issues without unnecessary redundancy.
One problem that overlaps will exhibit, if they are allowed to remain in the
system, is to provide multiple answers to the same problem. If, in future, a
change is necessary, it is possible that only one of the approaches will be
changed, thereby leaving different answers to the same issue in the system. That
creates, rather than solves, a problem.
Once all the approaches have been identi¬ed, they should be laid side-by-
side, so to speak, and carefully analyzed for holes and overlaps. The best way to
accomplish this task is to create yet another matrix with the requirement or
issue across the top and the approaches up the side. Holes will be manifest by
the lack of an intersect between a requirement or issue and an approach. Over-
laps will be manifest by the existence of more than one intersect with a require-
ment or issue.

You should understand that it is possible that one approach can be used to
resolve more than one requirement or issue, as in Approach A in Table 8-3.
However, two approaches to the same requirement or issue create an overlap,
as in Requirement 3.

Ta b l e 8 - 3 ” A n a l y z i n g H o l e s a n d O v e r l a p s

Requirement 1 Requirement 2 Requirement 3
Approach A X X
Approach B X
Approach C Hole
Approach D X

8.4 Choosing the Causes

You should now have a pretty clear idea of the requirements and the answers.
Looking at the matrix you just created should show which approaches to choose
and where you have more work to do. You will want to choose approaches that
give you the most ˜˜bang for the buck.™™ As you continue to review the ap-
proaches, you may well want to combine the best of them into a single approach
that applies to the greatest number of problems. As you read through the book
and the Attachments, you will ¬nd that some approaches or forms or techniques
apply to a great number of requirements or issues. The Requirements Traceabil-
ity Matrix (RTM), presented in Chapter 1 and Attachment 7, is one such ap-
proach that is applied to many issues. Use this same applicability as you choose
your causes.


1. Jay Arthur
2244 S. Olive St.
Denver, CO 80224
Phone: 888-468-1537
E-mail: jay@qimacros.com


9.1 General

This chapter presents three diverse techniques for implementing new Cause
Descriptions and a process to assist you in selecting the technique or techniques
you will use.

9.2 Implementation Techniques

There are undoubtedly many techniques you can use to implement these new
causes you have developed. Naturally, you are free to use your own. I show
three techniques in this chapter that will help greatly. In fact, I have already
made accommodation in the existing Search Tables for two of the techniques.
First, you will ¬nd blanks in the Search Tables provided so that you can ˜˜slip

.......................... 9758$$ $CH9 12-09-02 08:30:28 PS

in ¬xes™™ with subalphas that start where the ¬lled-in Search Table subalphas
leave off. When you review the Search Tables, you will ¬nd that each ˜˜family of
causes™™ can accommodate seven potential causes (a through g) even though
only two or three may have been used. The unused entry lines are designed to
allow you to slip in new causes that relate to that family but may be unique to
your product or company. You can simply ¬ll in the new causes as they are
Second, you will ¬nd additional blanks for the Search Tables that start at the
end of the ¬lled-in Cause Descriptions. These are provided as ˜˜On-Ramps™™ to
allow you to add additional ˜˜families of causes™™ you discover that are unique
to your product or company.

The process of ˜˜Slipping in the Fix™™ is one of putting the ¬x in where it
belongs but not changing the basic ordering technique. This will put the ¬xes
in approximately the right place for future use. Space has been left in the basic
tables for you to make these entries. These rows have been left uncoded so you
can type your entries directly into the tables. A representation of this technique
is shown in Table 9-1.
Ta b l e 9 - 1 ” S p a c e s f o r ˜ ˜ S l i p p i n g i n t h e F i x ™ ™

3a There is a clear trail between standard policies, plans, and program/project Expand No Yes
technical plans
3b There is a clear trail between customer policies and the program/project Expand No Yes
and technical plans
3c There is a clear trail between enterprise policies and the program/project Expand No Yes
and technical plans
Expand No Yes
Expand No Yes
Expand No Yes

The process of creating On-Ramps is a part of the planning process. When
you are modifying the Search Tables and Cause Descriptions for your own use,
simply accommodate changes that are sure to come. On-Ramps have been cre-

ated for your data entry within the compact disk (CD) that accompanies this
book. A representation of this technique is shown in Table 9-2.
The blank lines in the tables have been left uncoded so you can type your
entries directly into the tables. The links however are coded and will work the
same as they do in the provided tables.
Ta b l e 9 - 2 ” S p a c e s f o r ˜ ˜ O n - R a m p s ™ ™
70a Expand No Yes
70b Expand No Yes
70c Expand No Yes
70d Expand No Yes
70e Expand No Yes
70f Expand No Yes
70g Expand No Yes

The process of ˜˜Dumping™™ the ¬x is simply a matter of dumping in the ¬x
whenever it is discovered. This is a ˜˜quick and dirty™™ method of getting the job
done and may be what you need because of time constraints. My suggestion is
that you go back later and clean up the result of this technique by better organ-
izing its incorporation when you have time.

9.3 Selecting Your Technique

The selection of your technique will probably be controlled by two things: the
time available and your personality. If you have the time available, meaning you
are in the Planning Phase, and if your personality is one of organization, you
will probably use the technique of ˜˜Creating On-Ramps.™™ If you are in the
middle of your program and pressed for time but you have an organized per-
sonality, you will probably choose the technique of ˜˜Slipping in the Fix.™™ If you
are up to your hips in alligators and just want to get the job done and get on to
the next issue, you will probably use the ˜˜Dumping™™ technique. Personally, I
prefer the ˜˜On-Ramp™™ technique but I have ˜˜been there, done that™™ and have
had to use the other techniques at times.


10.1 General

As a project manager, you probably consider yourself through. After all, you
found the problem, created a ¬x, invented new metrics, and incorporated the
whole thing into your project that is now operating as it should. You™ve done
your part so you™re through, right? Wrong! Now is the time to follow through.
Even though the program or project is temporary, by de¬nition it has a begin-
ning and an end, and you have a responsibility to the continuum, the enterprise.
It was the enterprise that created the project or program in the ¬rst place, and
it will be the enterprise that prevails after the project or program is completed.
Every company operates a little differently so you™ll need to make your
involvement consistent with how your company does business. Whatever it is,
the ¬ndings you came up with must be incorporated back into how the com-
pany, the enterprise, the program, and the project do business. The ˜˜thing™™ that

.......................... 9758$$ CH10 12-09-02 08:30:33 PS

created the problem in the ¬rst place must be corrected. If you followed all the
steps in this plan, you should know what the ˜˜thing™™ is. Now the issue is how
to ¬x it.

10.2 The Concluding Process

Now that you have been through ¬nding the causes of problems and expanding
the cause base, you are in good position to carry the concept to the entire
enterprise. Now is the time to gather together all the project managers, the
quality manager, and the training manager and apply all this to the entire enter-
prise. It could well be that your enterprise wants you to continue with your
project essentially unencumbered. After all, that™s your primary task. In this
case, hand off the ¬ndings to the person designated by the enterprise for follow-
up. If you are an executive above the project level, ensure that the responsible
project manager is involved in the conclusion process.


The principal thesis of Quantum Improvement (QI) is really just an exten-
sion of the 80/20 Rule by compounding the multipliers. Fundamentally, QI
assumes that the top 20 percent of the 80/20 Rule is nonlinear and projects that
one percent of the problems cost (or return) 50 percent of the money. What
you want to do in this part of the process is to ensure that at least the most
important ¬ndings are incorporated into the ongoing process.
Remember how the 85:15 Rule and the Pareto Principle and the Monte Carlo
Simulation technique work? What was common to all of them? That just a few
problems cause the most trouble or cost the most money, or both. That™s the
idea behind Quantum Improvement: To make a quantum leap with a minimum
of effort.
This is the perfect place to implement or reimplement the concept of bench-
marking. Pull together the benchmarks that represent your competition and
evaluate your position with regard to them. Use Quantum Improvement tech-
niques to select the best of the best of the best and make startling improvements.
There are many processes available that claim to do all things for all people:
Total Quality Management (TQM), Total Quality Leadership (TQL), Quantum
Improvement (QI), Quantum Process Improvement (QPI), Reengineering, Six
Sigma, Business Process Redesign (BPR), Business Process Improvement (BPI)

and a host of others. The truth is that each has something to offer but none is
a panacea.
I can™t recommend a company or consultant to perform this task for you.
You need to do your own analysis based on your own needs. I do suggest you
use a consultant or company that doesn™t promise to solve all your problems.
Your improvement process should be accomplished in stages. Until now, I have
recommended using some technique, such as Pareto Analysis, that gives the
greatest result ¬rst. Now however, you are dealing with people, with manage-
ment, with employees. The approach in this instance is to attack the ˜˜lowest
hanging fruit™™ ¬rst, so long as they represent important issues, and then evalu-
ate the results. Early successes are important motivators to continue the effort.
To try to change the entire culture of the enterprise is a sure path to failure.
Don™t leave it all behind just because you made a breakthrough. Institute a


. 6
( 9)