RECOVERY

К оглавлению
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 

The first step in this process is to create a CSF Checklist. Begin by creating a

matrix as shown in Table 5-2. Notice that the requirement is in the far left

column and the final proof is in the far right column. Scour the requirements

document (contract) for requirement inputs and complete that column first.

T a b l e 5 - 2 — C r i t i c a l S u c c e s s F a c t o r ( C S F ) M a t r i x

CSF Unit A Unit B Unit C Unit D Final Proof

MTTR 0.5 hrs 0.5 hrs 0.5 hrs 0.5 hrs RMA Analysis

0.5 hrs Para 3.2.1

MTBF 30,000 hrs 30,000 hrs 30,000 hrs 30,000 hrs RMA Analysis

30,000 hrs Para 3.2.2

document each issue and get a full reading to determine its validity and

whether it has been properly defined. Qualify each requirement as mandatory,

highly desirable, desirable, or nice to have. Keep very careful notes

(minutes) of these sessions with the customer. Turn these notes into Change

Notices and formalize them with the customer. Even if the changes are denied,

you have a basis for change if the issue arises later on.

After the project is formalized:

1. This means that you have already signed up to the requirement as it exists

and is documented. Consequently, it may be more difficult to get the requirement

incorporated into the SOW or Spec and considered ‘‘in-scope.’’

This is particularly true if you are operating under a fixed price contract. Use

the same techniques as above. If you are working on a project instead of a

program, you shouldn’t have to worry about the contractual issues. In either

event, it is best to understand the requirements to the fullest extent possible

as early as possible. The nature of a Research and Development (R&D) project

or program is that it will probably be under constant change. The same

rules apply, however, and the baseline must be updated constantly.

2. Another technique that can be used after the job has started is to interview

or simply walk through with the people who are performing the job. Sometimes

these results are surprising because the performing people are not in a

formal mode or mood and you learn what the real issues are. You should be

performing In-Process Reviews, as described in Cause Description Family 54,

In-Process Reviews.

51c (NO) All key functions such as time, length, weight, performance

requirements, and interfaces, etc., listed in the

requirements are not appropriately covered.

All key functions, performance requirements, and interfaces listed in the requirements

are not appropriately covered when all are not listed on the ordinate

(the ‘‘Y’’ axis—up the side) of the Requirements Traceability Matrix (RTM)

(see Attachment 7) and the Requirements Flow-Down Matrix (RFM) (see Attachment

8) or the WBS locations are not listed on the abscissa (the ‘‘X’’ axis—

across the top or bottom). The requirements are only appropriately covered

when there is an intersect between all requirements and all the WBS locations

showing dispositions.