К оглавлению
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 
17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 
34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 
51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 
68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 
85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 
102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 
119 120 121 122 123 

At the outset, I introduced the Phoenix—a mythical bird that died and reconstituted

itself and rose from the ashes. That was the theme of the book—to rise

from the ashes created by a failure of the project or program somewhere in its


In Chapter 1, you searched for a cause for the problem by defining the ‘‘Family

of Causes’’ to which the problem or issue belonged and then using the Search

Tables to find the Causes that contributed to the problem or issue. When you

found the Cause, you turned to the Cause Description to discover a Recovery

Plan to bring the project back into tolerance again. At the end of Chapter 1, it

was recognized that the Search Tables and Cause Descriptions provided in the

book would not be all-encompassing for every problem or issue that could

possibly exist in any or all projects/programs. You recognized that you needed

a process to expand the Search Tables and Cause Descriptions to tailor them to

your particular situation.

To support Chapter 1 and to continue with the idea of creating new issues

unique (or peculiar, if you prefer) to your product or company, I provided

several techniques in Chapter 6 to broaden the scope of the Search Tables and

the supporting Cause Descriptions. The techniques presented were: Brainstorming,

Benchmarking, Standard Processes, Customer Processes, Enterprise

Processes, and Project/Program Processes.

Now that you had this large amount of data, you needed to organize it. In

Chapter 7, I presented four ordering techniques to quickly order the data. The

techniques were: The 85:15 Rule, Cause and Effect Diagrams, Affinity Diagrams,

and Relationship Diagrams.

It is good to have the data ordered, but now the data must be evaluated. In

Chapter 8, I presented four analysis techniques to accomplish this end. Remember,

these analytical techniques were: Pareto Analysis, Force Field Analysis, Failure

Mode Effect Analysis (FMEA), and finally, Monte Carlo Simulation. At the

end of the chapter you were able to select the causes you wanted to include in

your expanded Search Tables and Cause Descriptions and the order in which

you should incorporate them.

To review the overall process, consider Table 12-1. This table is a composition

of the data originally presented as Table 6-1 Expansion Methodologies,

Table 7-1 Ordering Techniques, and Table 8-1 Analysis Techniques.

Consider solving a typical problem. In the Process Table, use all the techniques

to generate the largest pile of data you can. Then proceed to the Ordering

Table, and first use the 85:15 technique to separate your data into a ‘‘process’’

pile and a ‘‘people’’ pile. Then create a Cause and Effect Diagram to organize

your data (perhaps you chose to only use the ‘‘process’’ pile). Finally, go to the

Analysis Table and perform a Pareto Analysis to get the ‘‘biggest bang for the

buck.’’ If you are solving a technical problem, you may want to continue on

(using the dotted lines) to the Failure Mode Effect Analysis to predict the results

before you implement the solution.

This is only one ‘‘data trail’’ you can choose through the tables. That’s why

I provided a number of alternatives to allow you to choose the ones that are

right for you. In Chapter 9, you were confronted with how to incorporate the

new causes into your project and indeed, into the other projects/programs of

the enterprise. I presented three methods for incorporating these new causes.

You will recall that those techniques were called Creating ‘‘On-Ramps,’’ ‘‘Slipping

in the Fix,’’ and ‘‘Dumping’’ the Fix. You were then given methods for

selecting your technique based on the needs of the project, the time available,

and your own personality. And, to provide the tools to incorporate these

changes, I left room in the Search Tables for you to ‘‘Slip in the Fixes’’ or to

‘‘Dump the Fixes.’’

T a b l e 1 2 - 1 — P r o c e s s F l o w - T h r o u g h T a b l e s

Process Purpose

Brainstorming To create a large body of related data

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 specifically for this


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

Affinity Diagrams To organize large groups of information into

meaningful categories

Relationship Diagrams To show the relationship(s) between


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


Failure Mode Effect Analysis (FMEA) To predict potential failures

Monte Carlo Simulation To refine estimates

Finally, the whole thing was concluded by recognizing that the ‘‘thing’’ that

had allowed the project to be derailed in the first place needed to be corrected.

It was suggested that you use Quantum Improvement methods and then update

the documentation and that you provide a complete data trail back to the ‘‘offending’’

direction and the ‘‘how’’ of modifying. The technical aspects of modification

as well as the diplomatic efforts were discussed.

Throughout the whole book, I have advocated using the Search Tables as a

checklist and the Cause Descriptions as the detail for planning your project.

Please, don’t let your project get to the point of failure before looking ahead at

what might happen and then building in processes, steps, and metrics to avoid

the issue and determine when a problem is about to occur.

You all know this is what you should do, but for some reason it rarely gets

done completely. When that occurs and a project element goes out-of-tolerance,

you will find that this book is worth its weight in gold.