RECOVERY
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
MIL-STD-1521
Guides to functional inventory can be found in:
MIL-STD-973
DID DD-1423
ISO-9000-3:1991(E)
MIL-STD-1521
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.
RECOVERY
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.
RECOVERY
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
process.
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.
RECOVERY
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.
56 SUBCONTRACTS
56a (NO) The sum of all subcontracts does not reflect all tasks
allocated.
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).