К оглавлению
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 is to define the issue. Have the technical requirements been

met? Have the contractual requirements been met? Likely not, so let’s separate

the issues into logical pairs, as in Table 5-5, and recover from there.

T a b l e 5 - 5 — I s s u e P a i r s a n d R e c o v e r i e s

Technical Contractual Recovery

Not Met Not Met Continue until one or the other is met then proceed as shown below

Met Not Met If you have met the technical objectives but not met the contractual

objectives, it usually means you are in an overrun condition. If you

have a cost plus contract, you should be able to adjust the manpower

or schedule to fit the actual profile. If you have a fixed price contract,

you may well have to absorb the costs. The general rule-of-thumb is

that you do not take an R&D task on a fixed price basis.

Not Met Met One of three alternatives: 1) Change the technical requirement, 2)

Change the contractual conditions, 3) Quit.*

Met Met No issue

*Assumes neither Alternative (1) nor (2) will work and there is common agreement with the customer.

Additional Resources:

Guides to physical inventory can be found in:

IEEE Std 610.12-1990

MIL-STD-973, 1521, 2167, and 498

DID DD-1423


Guides to functional inventory can be found in:


DID DD-1423



55b (NO) Prototypes were not constructed incrementally.

If prototypes are not constructed incrementally and two or more modules

are put together and fail testing, you will likely have no idea where the problems

lie. Prototypes can be constructed incrementally either vertically or horizontally.

A vertical increment means that modules are constructed serially and the subsequent

modules are added on to existing modules. A horizontal increment means

that increments are constructed concurrently then integrated one by one to

form another module, a subsystem, or a system.


In order to recover properly, you must go all the way back to the original

input requirement and then follow the ‘‘decomposition’’ process into the various

WBS elements (see Cause Description 51c). The next step is to go through

the composition and unit testing of the modules (see Cause Description Family

59) and the interface requirements of the modules. You are looking for specific

inconsistencies, so this document cannot possibly address the questions, much

less the answers, to these issues.

55c (NO) Prototype changes were not incorporated into the design

using the Change Control Process.

Prototype changes were not incorporated into the design using the Change

Control Process (see Technical Cause Descriptions 61a, 61b, and 61c) when

the changes are not traceable through the product to the documentation that

authorized the change.


Prototypes must be treated the same as First Articles in their development.

This is particularly true if your process takes the prototype (or Breadboard or

Brassboard) directly to development or production. Granted, many changes are

devised during the prototype process and incorporated into the prototype to

validate their efficacy. Indeed, that’s what the prototype process is all about.

However, if it is concluded that the in-process change should be a part of the

prototype, the changes must be incorporated through the Change Control


See the glossary for definitions of all these terms.

55d (NO) Each prototype change was not reviewed and accepted by

the originator of the requirements.

Each prototype change was not reviewed and accepted by the originator of

the requirements whenever an acceptance of the change is not documented and

made a part of the project documentation.


When you get a verbal requirement, stop and document the requirement,

even if it’s just a note. You can use that documentation as a basis for sign-off

by the originator of the requirements.


56a (NO) The sum of all subcontracts does not reflect all tasks


The sum of all subcontracts does not reflect all tasks allocated if the totality

of all subcontracts and all work to be performed internally do not add up to the

total requirements in the requirements document (contract).