In this risk-handling technique, the Government and contractor take active steps to reduce the probability/likelihood of a risk event occurring and to reduce the potential impact on the program. Most risk-control steps share two features: they require a commitment of program resources, and they may require additional time to accomplish them. Thus, the selection of risk-control actions will undoubtedly require some tradeoff between resources and the expected benefit of the actions. Some of the many risk-control actions include the following:
Multiple Development Efforts - The use of two or more independent design teams (usually two separate contractors, although it could also be done internally) to create competing systems in parallel that meet the same performance requirements.
Alternative Design - Sometimes, a design option may include several risky approaches, of which one or more must come to fruition to meet system requirements. However, if the PMO studies the risky approaches, it may be possible to discover a lower-risk approach (with a lower performance capability). These lower-risk approaches could be used as backups for those cases where the primary approach(es) fail to mature in time. This option presumes there is some trading room among requirements. Close coordination between the developer and the user is necessary to implement lower capability options.
Trade Studies - Systems engineering decision analysis methods include trade studies to solve a complex design problem. The purpose of the trade studies is to integrate and balance all engineering requirements in the design of a system. A properly done trade study considers risks associated with alternatives.
Early Prototyping - The nature of a risk can be evaluated by a prototype of a system (or its critical elements) built and tested early in the system development. The results of the prototype can be factored into the design and manufacturing process requirements. In addition to full-up systems, prototyping is very useful in software development and in determining a system's man-machine interface needs. The key to making prototyping successful as a risk-control tool is to minimize the addition of new requirements to the system after the prototype has been tested (i.e., requirement changes not derived from experience with the prototype). Also, the temptation to use the prototype design and software without doing the necessary follow-on design and coding/manufacturing analyses should be avoided.
Incremental Development - Incremental development is completion of the system
design and deployment in steps, relying on pre-planned product improvements
(P3I) or software improvements after the system is deployed to achieve the
final system capability. Usually, these added capabilities are not included originally because of the high risk that they will not be ready along with the remainder of the system. Hence, development is split, with the high-risk portion given more time to mature. The basic system, however, incorporates the provisions necessary to include the add-on capabilities. Incremenal development of the initial system requirements are achieved by the basic system.
Technology Maturation Efforts - Technology maturation is an off-line development effort to bring an element of technology to the necessary level so that it can be successfully incorporated into the system (usually done as part of the technology transition process). Normally, technology maturation is used when the desired technology will replace an existing technology, which is available for use in the system. In those cases, technology maturation efforts are used in conjunction with P3I efforts. However, it can also be used when a critical, but immature, technology is needed. In addition to dedicated efforts conducted by the PMO, Service or DoD-wide technology improvement programs and advanced technology demonstrations by Government laboratories as well as industry should be considered.
Robust Design - This approach uses advanced design and manufacturing techniques that promote achieving quality through design. It normally results in products with little sensitivity to variations in the manufacturing process.
Reviews, Walk Throughs, and Inspections - These three risk control actions can be used to reduce the probability/likelihood and potential consequences/impacts of risks through timely assessments of actual or planned events in the development of the product. They vary in the degree of formality, level of participants, and timing.
Reviews are formal sessions held to assess the status of the program, the adequacy and sufficiency of completed events, and the intentions and consistency of future events. Reviews are usually held at the completion of a program phase, when significant products are available. The team conducting the review should have a set of objectives and specific issues to be addressed. The results should be documented in the form of action items to be implemented by the PMO or contractor. The type of review will dictate the composition of the review team, which may include developers, users, managers, and outside experts.
A walk through is a technique that can be very useful in assessing the progress in the development of high or moderate risk components, especially software modules. It is less formal than a review, but no less rigorous. The person responsible for the development of the component "walks through" the product development (to include perceptions of what is to be done, how it will be accomplished, and the schedule) with a team of subject-matter experts. The team reviews and evaluates the progress and plans for developing the product and provides immediate and less formal feedback to the responsible person, thus enabling improvements or corrective actions to be made while the product is still under development. This technique is applied during the development phases, as opposed to reviews, which are normally held at the completion of a phase or product.
Inspections are conducted to evaluate the correctness of the product under development in terms of its design, implementation, test plans, and test results. They are more formal and rigorous than either reviews or walk throughs and are conducted by a team of experts following a very focused set of questions concerning all aspects of the product.
Design of Experiments - This is an engineering tool that identifies critical design factors that are difficult to meet.
Open Systems - This approach involves the use of widely accepted commercial specifications and standards for selected system interfaces, products, practices, and tools. It provides the basis for reduced life-cycle costs, improved performance, and enhanced interoperability, especially for long life systems with short-life technologies. Properly selected and applied commercial specifications and standards can result in lower risk through increased design flexibility; reduced design time; more predictable performance; and easier product integration, support, and upgrade. However, a number of challenges and risks are associated with the use of the open systems approach and must be considered before implementation. These include such issues as: maturity and acceptability of the standard, and its adequacy for military use; the loss of control over the development of products used in the system; the amount of product testing done to ensure conformance to standards; and the higher configuration management workload required.
See Deskbook Section 126.96.36.199.5 for a more detailed discussion of the use of open systems. (Additional information is also available at the Open Systems Joint Task Force Website at www.acq.osd.mil/osjtf/.)
Use of Standard Items/Software Reuse - The use of standard items and software module reuse should be emphasized to the extent possible to minimize development risk. Standard items range from components and assemblies to full-up systems. A careful examination of the proposed system option will often find more opportunities for the use of standard items or existing software modules than first considered. Even when the system must achieve previously unprecedented requirements, standard items can find uses. A strong program policy emphasizing the use of standard items and software reuse is often the key to taking advantage of this source of risk control. Standard items and software modules have proven characteristics that can reduce risk. However, the PMO must be cautious when using standard items in environments and applications for which they were not designed. A misapplied standard item often leads to problems and failure. Similarly, if the cycle for a fielded product extends for many years, it is possible that key software tools and products will become obsolete or will no longer be supported. If this occurs, costly redesign may result if software re-development is necessary.
Two-Phase Development - This risk control approach incorporates a formal risk-reduction effort in the initial part of the SDD phase. It may involve using two or more contractors with a down-select occurring at a predefined time (normally after the preliminary design review). A logical extension of this concept is the "spiral" development model, which emphasizes the evaluation of alternatives and risk assessments throughout the system's development and initial fielding.
Use of Mockups - The use of mockups, especially man-machine interface mock-ups, can be used to conduct early exploration of design options. They can assist in resolving design uncertainties and providing users with early views of the final system configuration.
Modeling/Simulation - The use of modeling and simulation can provide insights into a system's performance and effectiveness sensitivities. Decision makers can use performance predictions to assess a system's military worth not only before any physical prototypes are built, but also throughout the system life cycle. Modeling and simulation can help manage risk by providing information on design capabilities and failure modes during the early stages of design. This allows initial design concepts to be iterated without having to build hardware for testing. The T&E community can use predictive simulations to focus the use of valuable test assets on critical test issues. They can also use extrapolated simulations to expand the scope of evaluation into areas not readily testable, thus reducing the risk of having the system fail in the outer edges of the "test envelope." Additionally, a model can serve as a framework to bridge the missing pieces of a complete system until those pieces become available.
Although modeling and simulation can be a very effective risk-handling tool, it requires resources, commitment to refine models as the system under development matures, and a concerted verification and validation effort to ensure that decisions are based on credible information.
Key Parameter Control Boards - When a particular parameter (such as system weight) is crucial to achieving the overall program requirements, a control board for that parameter may be appropriate. This board has representatives from all affected technical functions and may be chaired by the PM. It provides management focus on the parameter and signals the importance of achieving the parameter to the technical community. If staffed properly by all affected disciplines, it can also help avoid sacrificing other program requirements to achieve that requirement.
Manufacturing Screening - For programs in late SDD and early production and
deployment, various manufacturing screens (including environmental stress
screening (ESS)) can be incorporated into test article production and low-rate
initial production to identify deficient manufacturing processes. ESS is a
manufacturing process for stimulating parts and workmanship defects in
electronic assemblies and units. These data can then be used to develop the
appropriate corrective actions.