In today’s highly competitive industrial environment, many high-tech businesses are using Technical Risk Management (TRM) in their engineering design programs as a means of improving the chances of success. TRM allows program mangers to pinpoint potential failure modes of a project early in the process, so that corrective actions can be taken in the most effective manner. TRM also allows managers to appropriately prioritize program tasks so as to achieve optimum use of available technical resources. TRM requires that a methodology of practices and processes be implemented on an ongoing basis. These processes identify, evaluate, mitigate, and manage technical risks affecting program success. This chapter will discuss implementation of the TRM process and provide a simple example to show how the process works.
A recent risk analysis survey, conducted in the aerospace industry, stated, “Increasingly, Government customers and Industry contractors seek better methods to identify and manage technical, schedule, and cost risk.” (Black, 2001, p. 1) The survey documented that 39% of industry representatives surveyed expect their technical staff to play the major role in risk management, whereas 33% placed responsibility for risk management on the cost estimators, 14% on management and 14% elsewhere. Clearly the technical staff in aerospace firms is expected to participate heavily in the management of technical risks. The medical device industry is another industry with this expectation. Kaye and Crowley (2000) have described the use of TRM in that industry, saying “Risk Management is a systematic application of policies, procedures, and practices to the analysis, evaluation, and mitigation of risks. It is a key component of quality management systems, and is a central requirement of the implementation of design controls in the Quality Systems Regulation.” (p. 8) Software development engineering is yet another arena where the importance of managing risk has been recognized. Kendall (2007) has stated that at least 25% of software design projects are cancelled before completion and 89% overrun budget. Based on this, the report goes on to say “It is no surprise, then, that one of the drivers in the evolution of software engineering, as a discipline, has been the desire to indentify reliable, quantifiable ways to manage software development risks.” (p. 1)
For U.S. Department of Defense programs, guidelines for estimating the probability of occurrence and the magnitude of failure impact are published as part of military standard MIL-STD-882, System Safety Program Requirements, which states “A formal safety program that stresses early hazard identification and elimination or reduction of associated risk to a level acceptable to the managing activity is the principle contribution to effective system safety.” (U.S. DoD, 1984, p. 2) The TRM concept is required for virtually all new military contracts. Plans are frequently subject to monthly tracking by program-wide risk review boards comprised of members of the technical staff of both the vendor and the contracting agency. Additional government agencies are adopting this practice and many commercial customers contracting for new designs in high-tech industries are instituting internal requirements for TRM to be part of every program.
Key Terms in this Chapter
Probability of Occurrence: A value assigned to the likelihood that a particular failure will occur. This may be quantitatively assigned using approaches like those from probabilistic design analysis, or may be qualitative based on the instincts and experience of a design team.
Risk Ranking: The phase of a risk management process where all identified risks are assessed either quantitatively or qualitatively, to ascertain which ones have the highest likelihood of occurrence and which ones have the greatest consequence of occurrence so as to rank the risks in overall order of importance.
Consequence of Occurrence: A measure of the negative result associated with the occurrence of a failure mode identified in a risk analysis study.
Risk Management: A process to identify and quantify sources of technical risks and their program impacts and find ways to avoid or control them. (Babcock, 2007, p. 217)
Probabilistic Design Analysis: A design approach which attempts to assign numerical, quantitative probabilities to the likelihood of a failure occurring. This process uses the theories of statistical analysis and the variance of statistically quantifiable terms to calculate such numeric probabilities.
Technical Risk: Any occurrence which could negatively impact the result of a program which could be mitigated by application of technical skills resulting in an improved design of a component, system, or process, thereby reducing the potential impact on the program.
Risk Reduction Plan: A plan, created as part of a risk management process, wherein steps are determined which will address a particular program risk so as to reduce either its likelihood of occurrence, or the consequence of its occurrence, or both, such that there is a reduction in its potential impact to the program.
Risk Identification: The phase of a risk management process where identification is made of all possible risks which could potentially impact the result of a program.
Impact of Occurrence: The quantitative or qualitative measurement of the consequence occurring when a failure mode is realized.
Complete Chapter List
Robert K. Hiltbrand
Terry T. Kidd
James W. Price Jr., Pamila Dembla
A. J. Gilbert Silvius
Gregory J. Skulmoski, Francis T. Hartman
Melanie S. Karas, Mahesh S. Raisinghani, Kerry S. Webb
Evon M. O. Abu-Taieh, Asim A. El Sheikh, Jeihan M. Abu-Tayeh, Maha T. El-Mahied
Francisco Chia Cua, Tony C. Garrett
Otavio Prospero Sanchez, Alberto Luiz Albertin
Bendik Bygstad, Gjermund Lanestedt
Jaby Mohammed, Ali Alavizadeh
Dawn M. Owens, Deepak Khazanchi
Fayez Ahmad Albadri
Michele De Lorenzi
Henryk R. Marcinkiewicz
Joni A. Amorim, Carlos Machado, Rosana G.S. Miskulin, Mauro S. Miskulin
Patricia McGee, Veronica Diaz
Bimal P. Nepal, Leslie Monplaisir
Debra D. Orosbullard
Geoffrey Corb, Stephen Hellen
Owen G. McGrath