2006 RM Guide 4 Aug 06final

RISK MANAGEMENT GUIDE FOR DOD ACQUISITION
Sixth Edition
(Version 1. !
A"#"st$ %
&
De'(rt)ent o* De*ense
+re*(,e
The Department of Defense (DoD) recognizes that risk management is critical to acquisition program success (see the Defense Acquisition Guidebook (DAG), Section 11.4). The purpose of a ressing risk on programs is to help ensure program cost, sche ule, an performance o!"ecti#es are achie#e at e#er$ stage in the life c$cle an to communicate to all stakehol ers the process for unco#ering, etermining the scope of, an managing program uncertainties. Since risk can !e associate %ith all aspects of a program, it is important to recognize that risk i entification is part of the "o! of e#er$one an not "ust the program manager or s$stems engineer. That inclu es the test manager, financial manager, contracting officer, logistician, an e#er$ other team mem!er. The purpose of this gui e is to assist DoD an contractor &rogram 'anagers (&'s), program offices an (ntegrate &ro uct Teams ((&Ts) in effecti#el$ managing program risks uring the entire acquisition process, inclu ing sustainment. This gui e contains !aseline information an e)planations for a %ell*structure risk management program. The management concepts an i eas presente here encourage the use of risk*!ase management practices an suggest a process to a ress program risks %ithout prescri!ing specific metho s or tools. (+ote, this gui e oes not attempt to a ress the requirements of DoD( -....1 to pre#ent an manage /n#ironment, Safet$, an 0ccupational 1ealth (/S01) hazar s. The rea er shoul refer to '(2 STD 334D, Stan ar &ractice for S$stem Safet$, for gui ance regar ing /S01 hazar s). Since this is a gui e, the information presente %ithin is not man ator$ to follo%, !ut &'s are encourage to appl$ the fun amentals presente here to all acquisition efforts5!oth large an small5an to all elements of a program (s$stem, su!s$stem, har %are, an soft%are). 6isk management is a fun amental program management tool for effecti#el$ managing future uncertainties associate %ith s$stem acquisition. The practice of risk management ra%s from man$ management isciplines inclu ing !ut not limite to program management, s$stems engineering, earne #alue management, pro uction planning, qualit$ assurance, logistics, s$stem safet$ an mishap pre#ention, an requirements efinition in or er to esta!lish a metho olog$ that ensures achie#ing program o!"ecti#es for cost, sche ule, an performance. &'s shoul tailor their risk management approaches to fit their acquisition program, statutor$ requirements, an life*c$cle phase. The gui e shoul !e use in con"unction %ith relate irecti#es, instructions, polic$ memoran a, or regulations issue to implement man ator$ requirements. This gui e has !een structure to pro#i e a !asic un erstan ing of risk management concepts an processes. (t offers clear escriptions an concise e)planations of core steps to assist in managing risks in acquisition programs. (ts focuses on risk mitigation planning an implementation rather on risk a#oi ance, transfer, or assumption. The gui e is not lai out in chronological or er of implementing a risk management program, !ut rather in a sequence to facilitate un erstan ing of the topic. 7or e)ample, the iscussion on planning 8 preparation for o#erall risk management is in Section 3 of the gui e to keep it separate from the risk management process. The planning 8 preparation function eals %ith planning to e)ecute the risk management process, !ut is not part of the e)ecution of the process itself. There are se#eral nota!le changes of emphasis in this gui e from pre#ious #ersions. These changes reflect lessons learne from application of risk management in DoD programs. /mphasis has !een place on,
09SD(AT:2) S$stems an Soft%are /ngineering8/nterprise De#elopment AT2*/D;os .mil
The role an management of future root causes, Distinguishing !et%een risk management an issue management, T$ing risk likelihoo to the root cause rather than the consequence, Tracking the status of risk mitigation implementation #s. risk tracking, an 7ocusing on e#ent* ri#en technical re#ie%s to help i entif$ risk areas an the effecti#eness of ongoing risk mitigation efforts.
The risk management techniques a#aila!le in the pre#ious #ersion of this gui e an other risk management references can !e foun on the Defense Acquisition 9ni#ersit$ <ommunit$ of &ractice %e!site at https,88acc. au.mil8rm, %here risk managers an other program team personnel can access the a itional information %hen nee e . This gui e is supplemente !$ Defense Acquisition 9ni#ersit$ (DA9) 6isk 'anagement <ontinuous 2earning 'o ule (ke$ %or s, =risk management> an course num!er <2'.1?). The 0ffice of the Secretar$ of Defense (0SD) office of primar$ responsi!ilit$ (0&6) for this gui e is 09SD(AT:2) S$stems an Soft%are /ngineering, /nterprise De#elopment (09SD(AT:2) SS/8/D). This office %ill e#elop an coor inate up ates to the gui e as require , !ase on polic$ changes an customer fee !ack. To pro#i e fee !ack to the 0&6, please e*mail the office at AT2*/D;os .mil.
ii
T(-.e o* Contents
1.Key Terms, Descriptions, and Principles......................................1 1.1. 6isk....................................................................................................................................1 1.4. <omponents of 6isk..........................................................................................................1 1.@. 6isk #ersus (ssue 'anagement.........................................................................................1 1.4. 6isk 'anagement 0!"ecti#e.............................................................................................4 2.Risk Management......................................................................3 4.1. The 6isk 'anagement &rocess.........................................................................................@ 4.4. The 6isk 'anagement &rocess 'o el .............................................................................4 4.@. <haracteristics of Successful 6isk 'anagement Approaches...........................................4 4.4. Top*2e#el Gui elines for /ffecti#e 6isk 'anagement....................................................3.Key Activity - Risk denti!ication................................................." @.1. &urpose..............................................................................................................................? @.4. Tasks..................................................................................................................................? @.@. ( entification of 6oot <auses............................................................................................3 #.Key Activity - Risk Analysis.......................................................11 4.1. &urpose............................................................................................................................11 4.4. 6isk 6eporting 'atri).....................................................................................................11 4.@. Tasks................................................................................................................................14 -. &erformance (&) <onsi erations.........................................................................................1A. Sche ule (S) <onsi erations...............................................................................................1?. <ost (<) <onsi erations.....................................................................................................1A ?.1. 6isk Anal$sis (llustration................................................................................................1A $.Key Activity - Risk Mitigation Planning......................................1$ 3.1. &urpose............................................................................................................................13 3.4. Tasks................................................................................................................................13 %. Key Activity - Risk Mitigation Plan mplementation...................1% B.1. &urpose............................................................................................................................1B B.4. Tasks................................................................................................................................1B 1&.Key Activity - Risk Tracking.....................................................2&
iii
1..1. &urpose..........................................................................................................................4. 1..4. Tasks..............................................................................................................................4. 1..@. 6eporting : Documentation.........................................................................................41 11.Planning ' Preparation !or Risk Management...........................22 11.1. 6isk &lanning.................................................................................................................44 11.4. 6isk 'anagement &lan..................................................................................................44 11.@. 0rganizing for 6isk 'anagement.................................................................................44 11.4. 6isk 'anagement Coar s..............................................................................................44 11.-. 6isk Assessment Approaches........................................................................................411.A. 6isk 'anagement 6oles................................................................................................4A 11.A.1. &rogram /)ecuti#e 0fficers 8 'ilestone Decision Authorities..................................4A 11.A.4. &rogram 'anagers......................................................................................................4A 11.A.@. (ntegrate &ro uct Team............................................................................................4? 11.A.4. 6isk 'anagement Coar s...........................................................................................4? 11.A.-. Support Acti#ities.......................................................................................................43 11.A.A. <ontractor...................................................................................................................43 11.?. Training.........................................................................................................................4B Appendi( A. Applica)le Re!erences..............................................3& Appendi( *. Acronyms................................................................31 Appendi( +. De!initions...............................................................33
T(-.e o* Fi#"res
,ig-re 1. DoD Risk Management Process........................................# ,ig-re 2. Risk Reporting Matri( ..................................................11 ,ig-re 3. .evels o! .ikeli/ood +riteria..........................................12 ,ig-re #. .evels and Types o! +onse0-ence +riteria......................13 ,ig-re 1. Risk Analysis and Reporting ll-stration.........................1# ,ig-re 2. An 3(ample o! Risk Reporting........................................1"
i#
1. Ke/ Ter)s$ Des,ri'tions$ (nd +rin,i'.es

1.1. Ris0 6isk is a measure of future uncertainties in achie#ing program performance goals an o!"ecti#es %ithin efine cost, sche ule an performance constraints. 6isk can !e associate %ith all aspects of a program (e.g., threat, technolog$ maturit$, supplier capa!ilit$, esign maturation, performance against plan,) as these aspects relate across the Dork Creak o%n Structure (DCS) an (ntegrate 'aster Sche ule (('S). 6isk a resses the potential #ariation in the planne approach an its e)pecte outcome. Dhile such #ariation coul inclu e positi#e as %ell as negati#e effects, this gui e %ill onl$ a ress negati#e future effects since programs ha#e t$picall$ e)perience ifficult$ in this area uring the acquisition process. 1.%. Co)'onents o* Ris0 6isks ha#e three components, A future root cause ($et to happen), %hich, if eliminate or correcte , %oul pre#ent a potential consequence from occurring, A pro!a!ilit$ (or likelihoo ) assesse at the present time of that future root cause occurring, an The consequence (or effect) of that future occurrence.
A future root cause is the most !asic reason for the presence of a risk. Accor ingl$, risks shoul !e tie to future root causes an their effects. 1.1. Ris0 2ers"s Iss"e M(n(#e)ent 6isk management is the o#erarching process that encompasses i entification, anal$sis, mitigation planning, mitigation plan implementation, an tracking. 6isk management shoul !egin at the earliest stages of program planning an continue throughout the total life*c$cle of the program. A itionall$, risk management is most effecti#e if it is full$ integrate %ith the programEs s$stems engineering an program management processes5as a ri#er an a epen enc$ on those processes for root cause an consequence management. A common misconception, an program office practice, concerning risk management is to i entif$ an track issues (#ice risks), an then manage the consequences (#ice the root causes). This practice ten s to mask true risks, an it ser#es to track rather than resol#e or mitigate risks. This gui e focuses on risk mitigation planning an implementation rather on risk a#oi ance, transfer or assumption. +ote, 6isks shoul not !e confuse %ith issues. (f a root cause is escri!e in the past tense, the root cause has alrea $ occurre , an hence, it is an issue that nee s to !e resol#e , !ut it is not a risk. Dhile issue management is one of the main functions of &'s, an important difference between issue management and risk management is that issue management applies resources to address and resolve current issues or problems, while risk management applies resources to mitigate future potential root causes and their consequences. To illustrate the ifference !et%een a risk an an issue, consi er, for e)ample, a commercial*off* the*shelf (<0TS) sourcing ecision process. Fuestions such as the follo%ing shoul !e aske an ans%ere prior to the <0TS ecision,
Is there any assurance the sole source provider of critical !"# components will not discontinue the product during government acquisition and usage$% Does the government have a back&up source$% an the government acquire data to facilitate production of the critical components$%
. These statements lea to the i entification of root causes an possi!le mitigation plans. (f a <0TS acquisition is eci e , an sometime later the manufacturer of a <0TS circuit car has informe the GHI ra ar !uil er that the circuit car %ill !e iscontinue an no longer a#aila!le %ithin 1. months, then an issue has emerge an %ith upfront planning the issue might ha#e !een pre#ente . A risk is the .i0e.ihood (nd ,onse3"en,e o* *"t"re pro uction sche ule ela$s in ra ar eli#eries if a replacement car cannot !e foun or e#elope an ma e a#aila!le %ithin 1. months. (f a program is !ehin sche ule on release of engineering ra%ings to the fa!ricator, this is not a riskJ it is an issue that has alrea $ emerge an nee s to !e resol#e . 0ther e)amples of issues inclu e failure of components un er test or anal$ses that sho% a esign shortfall. These are program pro!lems that shoul !e han le as issues instea of risks, since their pro!a!ilit$ of occurrence is 1.. (certain to occur or has occurre ). (t shoul also !e note that issues ma$ ha#e a #erse future consequences to the program (as a risk %oul ha#e). 1.4. Ris0 M(n(#e)ent O-5e,ti2e &'s ha#e a %i e range of supporting ata an processes to help them integrate an !alance programmatic constraints against risk. The Acquisition &rogram Caseline (A&C) for each program efines the top*le#el cost, sche ule, an technical performance parameters for that program. A itionall$, acquisition planning ocuments such as 2ife*<$cle <ost /stimates (2<</), S$stems /ngineering &lans (S/&), ('S, (ntegrate 'aster &lans (('&), Test an /#aluation 'aster &lans (T/'&) an Technolog$ 6ea iness Assessment (T6A) pro#i e etaile cost, sche ule, an technical performance measures for program management efforts. Since effecti#e risk management requires a sta!le an recognize !aseline from %hich to access, mitigate, an manage program risk it is critical that the program use an ('&8('S. &rocesses manage !$ the contractor, such as the ('&, contractor ('S, an /arne Kalue 'anagement (/K'), pro#i e the &' %ith a itional insight into !alancing program requirements an constraints against cost, sche ule, or technical risk. The o!"ecti#e of a %ell*manage risk management program is to pro#i e a repeata!le process for !alancing cost, sche ule, an performance goals %ithin program fun ing, especiall$ on programs %ith esigns that approach or e)cee the state*of*the*art or ha#e tightl$ constraine or optimistic cost, sche ule, an performance goals. Dithout effecti#e risk management the program office ma$ fin itself oing crisis management, a resource*intensi#e process that is t$picall$ constraine !$ a restricte set of a#aila!le options. Successful risk management epen s on the kno%le ge gleane from assessments of all aspects of the program couple %ith appropriate mitigations applie to the specific root causes an consequences. A ke$ concept here is that the go#ernment shares the risk %ith the e#elopment, pro uction, or support contractor (if commercial support is chosen), an oes not transfer all risks to the contractor. The program office al%a$s has a responsi!ilit$ to the s$stem user to e#elop a capa!le an supporta!le s$stem an can not a!sol#e itself of that responsi!ilit$. Therefore, all program risks, %hether primaril$ manage !$ the program office or !$ the e#elopment8support
contractor, are of concern an must !e assesse an manage !$ the program office. 0nce the program office has etermine %hich risks an ho% much of each risk to share %ith the contractor, it must then assess the total risk assume !$ the e#eloping contractor (inclu ing su!contractors). The program office an the e#eloper must %ork from a common risk management process an ata!ase. Successful mitigation requires that go#ernment an the contractor communicate all program risks for mutual a "u ication. Coth parties ma$ not al%a$s agree on risk likelihoo s, an the go#ernment &' maintains ultimate appro#al authorit$ for risk efinition an assignment. A common risk ata!ase a#aila!le an open to the go#ernment an the contractor is an e)tremel$ #alua!le tool. 6isk mitigation in#ol#es selection of the option that !est pro#i es the !alance !et%een performance an cost. 6ecall that sche ule slips generall$ an irectl$ impact cost. (t is also possi!le that throughout the s$stem life c$cle there ma$ !e a nee for ifferent near*term an long*term mitigation approaches. An effecti#e risk management process requires a commitment on the part of the &', the program office an the contractor to !e successful. 'an$ impe iments e)ist to risk management implementation, ho%e#er, the program team must %ork together to o#ercome these o!stacles. 0ne goo e)ample is the natural reluctance to i entif$ real program risks earl$ for fear of "eopar izing support of the program !$ ecision makers. Another e)ample is the lack of sufficient fun s to properl$ implement the risk mitigation process. 1o%e#er, %hen properl$ resource an implemente , the risk management process supports setting an achie#ing realistic cost, sche ule, an performance o!"ecti#es an pro#i es earl$ i entification of risks for special attention an mitigation.
%.
Ris0 M(n(#e)ent
%.1. The Ris0 M(n(#e)ent +ro,ess 6isk management is a continuous process that is accomplishe throughout the life c$cle of a s$stem. (t is an organize metho olog$ for continuousl$ i entif$ing an measuring the unkno%nsJ e#eloping mitigation optionsJ selecting, planning, an implementing appropriate risk mitigationsJ an tracking the implementation to ensure successful risk re uction. /ffecti#e risk management epen s on risk management planningJ earl$ i entification an anal$ses of risksJ earl$ implementation of correcti#e actionsJ continuous monitoring an reassessmentJ an communication, ocumentation, an coor ination. Acquisition program risk management is not a stan *alone program office task. (t is supporte !$ a num!er of other program office tasks. (n turn, the results of risk management are use to finalize those tasks. (mportant tasks, %hich must !e integrate as part of the risk management process, inclu e requirements e#elopment, logical solution an esign solution (s$stems engineering), sche ule e#elopment, performance measurement, /K' (%hen implemente ), an cost estimating. &lanning a goo risk management program integral to the o#erall program management process ensures risks are han le at the appropriate management le#el. /mphasis on risk management coinci es %ith o#erall DoD efforts to re uce life*c$cle costs (2<<) of s$stem acquisitions. +e% processes, reforms, an initiati#es are !eing implemente %ith risk management as a ke$ component. (t is essential that programs efine, implement an ocument an appropriate risk management an mitigation approach. 6isk management shoul !e esigne to enhance program management effecti#eness an pro#i e &'s %ith a ke$ tool to re uce 2<<, increase program likelihoo of success, an assess areas of cost uncertaint$.
%.%. The Ris0 M(n(#e)ent +ro,ess Mode. The risk management process mo el (see figure 1) inclu es the follo%ing ke$ acti#ities, performe on a continuous !asis, 6isk ( entification, 6isk Anal$sis, 6isk 'itigation &lanning, 6isk 'itigation &lan (mplementation, an 6isk Tracking.
Risk Identification
Risk Analysis
Risk Tracking
Risk Mitigation Planning
Risk Mitigation Plan Implementation
Fi#"re 1. DoD Ris0 M(n(#e)ent +ro,ess Acquisition programs run the gamut from simple to comple) procurements an support of mature technologies that are relati#el$ ine)pensi#e to state*of*the*art an !e$on programs #alue in the multi!illions of ollars. /ffecti#e risk management approaches generall$ ha#e consistent characteristics an follo% common gui elines regar less of program size. Some characteristics of effecti#e risk management approach are iscusse !elo%. %.1. Ch(r(,teristi,s o* S",,ess*". Ris0 M(n(#e)ent A''ro(,hes Successful acquisition programs %ill likel$ ha#e the follo%ing risk management characteristics, 7easi!le, sta!le, an %ell*un erstoo user requirements, supporte !$ lea ership 8 stakehol ers, an integrate %ith program ecisionsJ A close partnership %ith users, in ustr$, an other stakehol ersJ A planne risk management process integral to the acquisition process, especiall$ to the technical planning (S/& an T/'&) processes, an other program relate partnershipsJ <ontinuous, e#ent* ri#en technical re#ie%s to help efine a program that satisfies the userLs nee s %ithin accepta!le riskJ ( entifie risks an complete risk anal$sesJ
De#elope , resource , an implemente risk mitigation plansJ Acquisition an support strategies consistent %ith risk le#el an risk mitigation plansJ /sta!lishe threshol s an criteria for proacti#el$ implementing efine risk mitigation plansJ <ontinuous an iterati#e assessment of risksJ The risk anal$sis function in epen ent from the &'J A efine set of success criteria for performance, sche ule, an cost elementsJ an A formall$ ocumente risk management process.
To support these efforts, assessments #ia technical re#ie%s shoul !e performe as earl$ as possi!le in the life c$cle (as soon as performance requirements are e#elope ) to ensure critical performance, sche ule, an life*c$cle cost risks are a resse , %ith mitigation actions incorporate into program planning an !u get pro"ections. As the a%ar of a contract requiring /K' approaches, preparation an planning shoul commence for the e)ecution of the (ntegrate Caseline 6e#ie% ((C6) process in accor ance %ith the Defense Acquisition Gui e!ook. <hapter 3 a resses risk planning an 6isk 'anagement &lans (6'&s). %.4. To'67e2e. G"ide.ines *or E**e,ti2e Ris0 M(n(#e)ent Assess the root causes of program risks an e#elop strategies to manage these risks uring each acquisition phase. * ( entif$ as earl$ as possi!le, an intensi#el$ manage those esign parameters that criticall$ affect capa!ilit$, rea iness, esign cost, or 2<<. * 9se technolog$ emonstrations, mo eling an simulation, an aggressi#e protot$ping to re uce risks. * (nclu e test an e#aluation as part of the risk management process. (nclu e in ustr$ participation in risk management. 0fferors shoul ha#e a risk approach as part of their proposals as suggeste in this gui e to i entif$ root causes an e#elop plans to manage those risks an shoul inclu e a raft 6'&. A itionall$, the offerors shoul i entif$ risks as the$ percei#e them as part of the proposal. This not onl$ helps the go#ernment i entif$ risks earl$, !ut pro#i es a itional insight into the offerorLs le#el of un erstan ing of the program requirements. 9se a proacti#e, structure risk assessment an anal$sis acti#it$ to i entif$ an anal$ze root causes. * 9se the results of prior e#ent*!ase s$stems engineering technical re#ie%s to anal$ze risks potentiall$ associate %ith the successful completion of an upcoming re#ie%. 6e#ie%s shoul inclu e the status of i entifie risks. * 9tilize risk assessment checklists (a#aila!le for all e#ent*!ase technical re#ie%s) in preparation for an uring the con uct of technical re#ie%s. The DA9 Technical 6e#ie%s <ontinuous 2earning 'o ule (ke$ %or s, =technical re#ie%s> an course num!er <2/..@) pro#i es a s$stematic process an access to checklists for continuousl$ assessing the esign maturit$, technical risk, an programmatic risk of acquisition programs, an pro#i es links to these checklists. * /sta!lish risk mitigation plans an o!tain resources against that plan. * &ro#i e for perio ic risk assessments throughout each program life*c$cle phase.
/sta!lish a series of =risk assessment e#ents,> %here the effecti#eness of risk re uction con ucte to ate is re#ie%e . These =risk assessment e#ents> can !e hel as part of technical re#ie%s, risk re#ie% !oar meetings, or perio ic program re#ie%s. These e#ents shoul inclu e the s$stems engineering technical re#ie%s, !e tie to the ('& at each le#el, an ha#e clearl$ efine entr$ an e)it criteria re#ie%e uring (C6s. (nclu e processes as part of risk assessment. This %oul inclu e the contractorLs managerial, e#elopment, an manufacturing processes as %ell as repair processes for the sustainment phase. 6e#ie% the contractorLs !aseline plans as part of the (C6 process %hich inclu es "oint go#ernment8contractor e#aluation of the inherent risks in the contractorLs integrate earne #alue !aseline (%ork efinition, sche ule, an !u gets). 6e#ie% the contractorLs Sche ule 6isk Assessment (S6A) %hen pro#i e as part of the ('S ata item (D(*'G'T*31A-.). 6e#ie% the realism of the contractorLs estimate at completion. Assess the o#erall likelihoo of the contractor achie#ing the forecaste sche ule or final costs against the programLs constraints. /sta!lish a realistic sche ule an fun ing !aseline for the program as earl$ as possi!le in the program, incorporating not onl$ an accepta!le le#el of risk, !ut a equate sche ule an fun ing margins. <learl$ efine a set of e#aluation criteria for assigning risk ratings (lo%, mo erate, high) for i entifie root causes. Determine the programLs approach to risk prioritization, commonl$ presente in the risk reporting matri) iscusse in Section 4.4.
1.
Ke/ A,ti2it/ 6 Ris0 Identi*i,(tion
The first ke$ acti#it$ in the risk management process is 6isk ( entification. Dhile in some pu!lications =risk assessment> is use as an um!rella term that inclu es the primar$ acti#ities of !oth risk i entification an risk anal$sis this gui e a resses these t%o critical risk management acti#ities separatel$ in Sections @ an 4, respecti#el$. 1.1. +"r'ose The intent of risk i entification is to ans%er the question =Dhat can go %rongM> !$, 2ooking at current an propose staffing, process, esign, supplier, operational emplo$ment, resources, epen encies, etc., 'onitoring test results especiall$ test failures (rea iness results an rea iness pro!lems for the sustainment phase), 6e#ie%ing potential shortfalls against e)pectations, an Anal$zing negati#e tren s. 6isk i entification is the acti#it$ that e)amines each element of the program to i entif$ associate root causes, !egin their ocumentation, an set the stage for their successful management. 6isk i entification !egins as earl$ as possi!le in successful programs an continues throughout the program %ith regular re#ie%s an anal$ses of Technical &erformance 'easurements (T&'s), sche ule, resource ata, life*c$cle cost information, /K' ata8tren s, progress against critical path, technical !aseline maturit$, safet$, operational rea iness, an other program information a#aila!le to program (&T mem!ers. 1.%. T(s0s 6isk can !e associate %ith all aspects of a program, e.g., operational nee s, attri!utes, constraints, performance parameters inclu ing Ne$ &erformance &arameters (N&&s), threats, technolog$, esign processes, or DCS elements. <onsequentl$ it is important to recognize that risk i entification is the responsi!ilit$ of e#er$ mem!er of the (&T, not "ust the &' or s$stems engineer. /)amination of a program is accomplishe through ecomposition into rele#ant elements or areas. Decomposition ma$ !e oriente to requirements, processes, functional areas, technical !aselines, or acquisition phases. Another metho is to create a DCS as earl$ as possi!le in a program for a pro uct*oriente ecomposition, %hich is particularl$ useful in i entif$ing pro uct an some process oriente risks. 0ther means, such as a process*oriente frame%ork, %oul !e require to sufficientl$ illuminate process*!ase root causes, %hich coul !e tracke #ia the DCS structure to #ie% impacts to sche ule, resource loa ing, etc. To i entif$ risks an their root causes, (&Ts shoul !reak o%n program elements to a le#el %here su!"ect matter e)perts (S'/s) can perform #ali i entification !$ DCS or ('S line item num!er. The information necessar$ to o this #aries accor ing to the life*c$cle phase of the program. A program risk assessment checklist is a#aila!le #ia the DA9 Technical 6e#ie%s <ontinuous 2earning 'o ule (ke$ %or s, =technical re#ie%sJ> course num!er <2/..@). During ecomposition, risks can !e i entifie !ase on prior e)perience, !rainstorming, lessons learne from similar programs, an gui ance containe in the program office 6'& (see Section 11.4). A structure approach escri!es each DCS element in terms of sources or areas of risk.
'(2*1DCN*331, =Dork Creak o%n Structures for Defense 'ateriel (tems,> ser#es as the !asis for i entif$ing the first three le#els of the program DCS, an e#eloping the contract DCS. The e)amination of each element an process against each risk area is an e)plorator$ e)ercise to i entif$ the critical root causes. The in#estigation ma$ sho% that risks are inter* relate . DCS pro uct an process elements an in ustrial engineering, manufacturing an repair processes are often sources of significant root causes. 6isks are etermine !$ e)amining each DCS element an process in terms of causes, sources, or areas of risk. Dhen /K' is applie on a contract it can help i entif$ DCS program elements that are e)periencing issues. This information can !e use to help prioritize DCS elements that ma$ contain uni entifie risks. 1.1. Identi*i,(tion o* Root C("ses &rogram offices shoul e)amine their programs an i entif$ root causes !$ re ucing program elements to a le#el of etail that permits an e#aluator to un erstan the significance of an$ risk an i entif$ its causes. This is a practical %a$ of a ressing the large an i#erse num!er of risks that often occur in acquisition programs. 7or e)ample, a DCS le#el 4 or - element ma$ !e ma e up of se#eral root causes associate %ith a specification or function, e.g., potential failure to meet tur!ine !la e #i!ration requirements for an engine tur!ine esign. 6oot causes are i entifie !$ e)amining each DCS pro uct an process element in terms of the sources or areas of risk. 6oot causes are those potential e#ents that e#aluators (after e)amining scenarios, DCS, or processes) etermine %oul a #ersel$ affect the program at an$ time in its life c$cle. An approach for i entif$ing an compiling a list of root causes is to, 2ist DCS pro uct or process elements, /)amine each in terms of risk sources or areas, Determine %hat coul go %rong, an Ask =%h$> multiple times until the source(s) is isco#ere . The risk i entification acti#it$ shoul !e applie earl$ an continuousl$ in the acquisition process, essentiall$ from the time performance an rea iness requirements are e#elope . The program office shoul e#elop an emplo$ a formalize risk i entification proce ure, an all personnel shoul !e responsi!le for using the proce ure to i entif$ risks. Specific opportunities to i entif$ risks (e.g., at e#ent* ri#en technical re#ie%s) an e)plore root causes against o!"ecti#e measures (e.g., meeting the entr$ criteria for an upcoming technical re#ie%, requirements sta!ilit$, technical maturit$, soft%are lines of co e an reuse ratios, critical paths or near critical paths) shoul not !e o#erlooke . (f technical re#ie%s are sche ule, #ice e#ent ri#en, their usefulness as risk assessment tools can !e impacte , an the full !enefits of risk assessment ma$ not !e achie#e . The earl$ i entification an assessment of critical risks allo%s for the formulation of risk mitigation approaches an the streamlining of !oth the program efinition an the 6equest 7or &roposal (67&) processes aroun those critical pro uct an process risks. 6isk i entification shoul !e one again follo%ing an$ ma"or program change or restructure such as significant sche ule a "ustment, requirements change, or scope change to the contract. T$pical risk sources inclu e,
Thre(t. The sensiti#it$ of the program to uncertaint$ in the threat escription, the egree to %hich the s$stem esign %oul ha#e to change if the threatEs parameters change, or the #ulnera!ilit$ of the program to foreign intelligence collection efforts (sensiti#it$ to threat countermeasure). Re3"ire)ents. The sensiti#it$ of the program to uncertaint$ in the s$stem escription an requirements, e)clu ing those cause !$ threat uncertaint$. 6equirements inclu e operational nee s, attri!utes, performance an rea iness parameters (inclu ing N&&s), constraints, technolog$, esign processes, an DCS elements. Te,hni,(. 8(se.ine. The a!ilit$ of the s$stem configuration to achie#e the programEs engineering o!"ecti#es !ase on the a#aila!le technolog$, esign tools, esign maturit$, etc. &rogram uncertainties an the processes associate %ith the =ilities> (relia!ilit$, supporta!ilit$, maintaina!ilit$, etc.) must !e consi ere . The s$stem configuration is an agree *to escription (an appro#e an release ocument or a set of ocuments) of the attri!utes of a pro uct, at a point in time, %hich ser#es as a !asis for efining change. Test (nd E2(."(tion. The a equac$ an capa!ilit$ of the test an e#aluation program to assess attainment of significant performance specifications an etermine %hether the s$stem is operationall$ effecti#e, operationall$ suita!le, an interopera!le. Mode.in# (nd Si)".(tion (M9S!. The a equac$ an capa!ilit$ of ':S to support all life*c$cle phases of a program using #erifie , #ali ate , an accre ite mo els an simulations. Te,hno.o#/. The egree to %hich the technolog$ propose for the program has emonstrate sufficient maturit$ to !e realisticall$ capa!le of meeting all of the programEs o!"ecti#es. 7o#isti,s. The a!ilit$ of the s$stem configuration an associate ocumentation to achie#e the programEs logistics o!"ecti#es !ase on the s$stem esign, maintenance concept, support s$stem esign, an a#aila!ilit$ of support ata an resources. +rod",tion:F(,i.ities. The a!ilit$ of the s$stem configuration to achie#e the programEs pro uction o!"ecti#es !ase on the s$stem esign, manufacturing processes chosen, an a#aila!ilit$ of manufacturing resources (repair resources in the sustainment phase). Con,"rren,/. The sensiti#it$ of the program to uncertaint$ resulting from the com!ining or o#erlapping of life*c$cle phases or acti#ities. Ind"stri(. C('(-i.ities. The a!ilities, e)perience, resources, an kno%le ge of the contractors to esign, e#elop, manufacture, an support the s$stem. Cost. The a!ilit$ of the s$stem to achie#e the programEs life*c$cle support o!"ecti#es. This inclu es the effects of !u get an affor a!ilit$ ecisions an the effects of inherent errors in the cost estimating technique(s) use (gi#en that the technical requirements %ere properl$ efine an taking into account kno%n an unkno%n program information). M(n(#e)ent. The egree to %hich program plans an strategies e)ist an are realistic an consistent. The go#ernmentLs acquisition an support team shoul !e qualifie an sufficientl$ staffe to manage the program. S,hed".e. The sufficienc$ of the time allocate for performing the efine acquisition tasks. This factor inclu es the effects of programmatic sche ule ecisions, the inherent errors in sche ule estimating, an e)ternal ph$sical constraints.
Extern(. F(,tors. The a#aila!ilit$ of go#ernment resources e)ternal to the program office that are require to support the program such as facilities, resources, personnel, go#ernment furnishe equipment, etc. 8"d#et. The sensiti#it$ of the program to !u get #ariations an re uctions an the resultant program tur!ulence. E(rned V(."e M(n(#e)ent S/ste). The a equac$ of the contractorLs /K' process an the realism of the integrate !aseline for managing the program.
De#elopersL engineering an manufacturing processes that historicall$ ha#e cause the most ifficult$ uring the e#elopment phases of acquisition programs are frequentl$ terme critical risk processes. These processes inclu e, !ut are not limite to, esign, test an e#aluation, pro uction, facilities, logistics, an management. DoD 444-.?*', "ransition from Development to 'roduction, escri!es these processes using templates. The templates are the result of a Defense Science Coar task force, compose of go#ernment an in ustr$ e)perts %ho i entifie engineering processes an control metho s to minimize risk in !oth go#ernment an in ustr$. A itional areas, such as manpo%er, /S01, an s$stems engineering, that are anal$ze uring program plan e#elopment pro#i e in icators for a itional risk. The program office shoul consi er these areas for earl$ assessment, since failure to o so coul cause significant consequences in the programEs latter phases. (n a ition, &'s shoul a ress the uncertaint$ associate %ith securit$ O an area sometimes o#erlooke !$ e#elopers !ut a resse un er the topic of acquisition s$stem protection in the Defense Acquisition Guidebook (DAG), as %ell as in DoDD -4...1, DoD Information #ecurity 'rogramJ DoDD -4...@B, #ecurity, Intelligence, and ounterintelligence #upport to Acquisition 'rogram 'rotectionJ an DoD -4...1*', Acquisition #ystems 'rotection 'rogram. 1o%e#er, in a ition to the gui ance gi#en there, &'s must recognize that, in the past, classifie programs ha#e e)perience ifficult$ in access, facilities, clearances, an #isitor control. 7ailure to manage these aspects of a classifie program coul a #ersel$ impact sche ules. +ot onl$ are classifie programs at risk, !ut an$ program that encompasses (nformation Assurance is !ur ene !$ e#er increasing securit$ requirements an certifications. These risks must !e i entifie as earl$ as possi!le as the$ affect esign, e#elopment, test, an certification requirements that %ill impose sche ule challenges to the program.
1.
4. Ke/ A,ti2it/ 6 Ris0 An(./sis

4.1. +"r'ose The intent of risk anal$sis is to ans%er the question =1o% !ig is the riskM> !$, <onsi ering the likelihoo of the root cause occurrenceJ ( entif$ing the possi!le consequences in terms of performance, sche ule, an costJ an ( entif$ing the risk le#el using the 6isk 6eporting 'atri) sho%n in 7igure 4. 4.%. Ris0 Re'ortin# M(trix /ach un esira!le e#ent that might affect the success of the program (performance, sche ule, an cost) shoul !e i entifie an assesse as to the likelihoo an consequence of occurrence. A stan ar format for e#aluation an reporting of program risk assessment fin ings facilitates common un erstan ing of program risks at all le#els of management. The 6isk 6eporting 'atri) !elo% is t$picall$ use to etermine the le#el of risks i entifie %ithin a program. The le#el of risk for each root cause is reporte as lo% (green), mo erate ($ello%), or high (re ).
; 7i0e.ihood 4 1 % 1 1 % 1 4 ; Conse3"en,e
Fi#"re %. Ris0 Re'ortin# M(trix
11
The le#el of likelihoo of each root cause is esta!lishe utilizing specifie criteria (7igure @). 7or e)ample, if the root cause has an estimate -. percent pro!a!ilit$ of occurring, the correspon ing likelihoo is 2e#el @.
7e2e.
7i0e.ihood
+ro-(-i.it/ o* O,,"rren,e
+ot 2ikel$
P1.Q
2o% 2ikelihoo
P@.Q
7i0e.ihood
2ikel$
P-.Q
1ighl$ 2ikel$
P?.Q
+ear <ertaint$
PB.Q
Fi#"re 1. 7e2e.s o* 7i0e.ihood Criteri( The le#el an t$pes of consequences of each risk are esta!lishe utilizing criteria such as those escri!e in 7igure 4. A single consequence scale is not appropriate for all programs, ho%e#er. <ontinuing %ith the prior e)ample of a root cause %ith a -. percent pro!a!ilit$ of occurring, if that same root cause has no impact on performance or cost, !ut ma$ likel$ result in a minor sche ule slippage that %onLt impact a ke$ milestone, then the correspon ing consequence is a 2e#el @ for this risk. 7or clarit$ it is also classifie as a schedule risk since its root cause is sche ule relate .
14
7e2e.
Te,hni,(. +er*or)(n,e
S,hed".e
Cost
'inimal or no consequence to technical performance
'inimal or no impact
'inimal or no impact
'inor re uction in technical performance or supporta!ilit$, can !e tolerate %ith little or no impact on program
A!le to meet ke$ ates. S.i' < = )onth(s!
Cu get increase or unit pro uction cost increases. < == (1> o* 8"d#et!
Consequence
'inor sche ule slip. A!le to meet ke$ milestones %ith no sche ule float. @ 'o erate re uction in technical performance or supporta!ilit$ %ith limite impact on program o!"ecti#es S.i' < = )onth(s! S"-6s/ste) s.i' ? = )onth(s! '."s (2(i.(-.e *.o(t.
Cu get increase or unit pro uction cost increase < == (;> o* 8"d#et!
Significant egra ation in technical performance or ma"or shortfall in supporta!ilit$J ma$ "eopar ize program success
&rogram critical path affecte . S.i' < = )onths
Cu get increase or unit pro uction cost increase < == (1 > o* 8"d#et!
Se#ere egra ation in technical performanceJ <annot meet N&& or ke$ technical8supporta!ilit$ threshol J %ill "eopar ize program success
<annot meet ke$ program milestones. S.i' ? = )onths
/)cee s A&C threshol ? == (1 > o* 8"d#et!
Fi#"re 4. 7e2e.s (nd T/'es o* Conse3"en,e Criteri( The results for each risk are then plotte in the correspon ing single square on the 6isk 6eporting 'atri). (n this e)ample, since the le#el of likelihoo an consequence %ere !oth =@,> the correspon ing sche ule risk is reporte as =$ello%,> as sho%n in 7igure -, using a recommen e ispla$ metho that inclu es the risk title (%here (S) i entifies this risk as a sche ule risk), risk causal factor, an mitigation approach.
1@
Risk Title (S) Risk Causal Factor Mitigation Approach
Fi#"re ;. Ris0 An(./sis (nd Re'ortin# I.."str(tion 4.1. T(s0s 6isk anal$sis is the acti#it$ of e)amining each i entifie risk to refine the escription of the risk, isolate the cause, etermine the effects, ai in setting risk mitigation priorities. (t refines each risk in terms of its likelihoo , its consequence, an its relationship to other risk areas or processes. Anal$sis !egins %ith a etaile stu $ of the risks that ha#e !een i entifie . The o!"ecti#e is to gather enough information a!out future risks to "u ge the root causes, the likelihoo , an the consequences if the risk occurs. The frequentl$ use term =risk assessment> inclu es the istinct acti#ities of risk i entification an risk anal$sis. 6isk anal$sis sequence of tasks inclu e, De#elop pro!a!ilit$ an consequence scales !$ allocating consequence threshol s against the DCS or other !reakoutJ Assign a pro!a!ilit$ of occurrence to each risk using the criteria presente in Section 4.4J Determine consequence in terms of performance (&), sche ule (S), an 8or cost (<) impact using the criteria presente in Section 4.4J an Document the results in the program risk ata!ase. +ote, 6isk anal$sis is a snapshot in time an ma$ change significantl$ uring the program. 6isk anal$ses must !e perio icall$ re*accomplishe to ensure the anal$sis remains current. (n a DCS approach, risks are i entifie , assesse , an tracke for in i#i ual DCS elements at their respecti#e le#els (primaril$ for impact on cost an sche ule performance) an for their
14
resulting effect on the o#erall pro uct. Since DoD programs are generall$ esta!lishe aroun the DCS, each pro uctLs associate costs an sche ule can !e rea il$ !aseline , an its risk consequence can !e measure as a e#iation against this !aseline. Taking the DCS to successi#el$ lo%er le#els %ill help to assure all require pro ucts are i entifie , along %ith allocations for cost an sche ule performance (as %ell as operational performance) goals. (ntegration of performance, sche ule, an cost anal$ses into a single process pro#i es a final pro uct that starts %ith %ell* efine requirements, !uil s upon a soli technical foun ation, e#elops a realistic program sche ule, an ocuments the resources nee e in the program cost estimates. &rogram root cause i entification an anal$sis integrates the technical performance assessment, sche ule assessment, an cost estimates using esta!lishe risk e#aluation techniques. /ach of these risk categories (cost, sche ule, performance) has acti#ities of primar$ responsi!ilit$, !ut is pro#i e inputs an support from the other t%o risk categories. This helps to keep the process integrate an to ensure the consistenc$ of the final pro uct. The follo%ing paragraphs pro#i e rele#ant questions to ask in assessing performance, sche ule, an cost root causes. ;. +er*or)(n,e (+! Consider(tions Is there an impact to technical performance and to what level$ (f so, this risk has a performance consequence. These risks generall$ ha#e associate sche ule an cost impacts, !ut shoul !e carrie as a performance risk. 0perational (e.g., (nitial <apa!ilities Document ((<D), <apa!ilit$ De#elopment Document (<DD), <apa!ilit$ &ro uction Document (<&D), threats, suita!ilit$, effecti#eness). Technical (e.g., S/&, Technolog$ 6ea iness 2e#els, specifications, T/'&, technical !aselines, stan ar s, materiel rea iness ) 'anagement (e.g., organization, staffing le#els, personnel qualifications8e)perience, fun ing, management processes, planning, ocumentation, logistics) &. S,hed".e (S! Consider(tions Is there an impact to schedule performance and to what levelM (f the risk oes not ha#e a first or er performance impact, then ask this question. (f the risk oes impact the critical path, then it impacts !oth sche ule an cost, !ut shoul !e carrie as a sche ule risk. (ere any problems that caused schedule slips identified as risks prior to their occurrence$ If not, why not$ If yes, why didn)t the associated mitigation plan succeed$ The (&Ts shoul anal$ze impact of the risk to the ('S an the critical path(s), to inclu e, /#aluating !aseline sche ule inputs ( urations an net%ork logic)J (ncorporating technical assessment an sche ule uncertaint$ inputs to the program sche ule mo elJ /#aluating impacts to program sche ule !ase on technical team assessmentJ &erforming sche ule anal$sis on the program ('S, incorporating the potential impact from all contract sche ules an associate go#ernment acti#itiesJ Fuantif$ing sche ule e)cursions reflecting the effects of cost risks, inclu ing resource constraintsJ
1-
&ro#i ing a go#ernment sche ule assessment for cost anal$sis an fiscal $ear planning, reflecting the technical foun ation, acti#it$ efinition, an inputs from technical an cost areasJ an Documenting the sche ule !asis an risk impacts for the risk assessment. &ro"ecting an in epen ent forecast of the planne completion ates for ma"or milestones. @. Cost (C! Consider(tions Does the risk only impact life&cycle cost$ (f so, %ith no performance or sche ule impacts, the risk is a cost risk, an ma$ impact estimates an assessments such as, Cuil ing on technical an sche ule assessment resultsJ Translating performance an sche ule risks into life*c$cle costJ Deri#ing life*c$cle cost estimates !$ integrating technical assessment an sche ule risk impacts on resourcesJ /sta!lishing !u getar$ requirements consistent %ith fiscal $ear planningJ Determining if the a equac$ an phasing of fun ing supports the technical an acquisition approachesJ &ro#i ing program life*c$cle cost e)cursions from near*term !u get e)ecution impacts an e)ternal !u get changes an constraintsJ an Documenting the cost !asis an risk impacts. +0T/, <ost an fun ing are not the same. <ost is relate to the amount of mone$ require to acquire an sustain a commo it$, an fun ing is the amount of mone$ a#aila!le to acquire an sustain that commo it$. @.1. Ris0 An(./sis I.."str(tion The follo%ing e)ample illustrates %hat has !een presente in this section %ith the critical car e)ample use earlier, The program office has i entifie a risk in con ucting a e#elopmental test. The first question to ask is %h$ the test might not !e a!le to !e con ucte . The ans%er is that the circuit car s for one component ma$ not !e a#aila!le. (n asking the question =%h$> a secon time, the ans%er is that po%er con#ersion circuit car s for one component ma$ not !e a#aila!le in time for s$stem integration to meet the test sche ule. The risk causal factor is this a#aila!ilit$ of po%er con#ersion circuit car s. (Alternatel$, if the po%er con#ersion circuit car is no longer in pro uction, then $ou ha#e a completel$ ifferent risk that %ill require a ifferent mitigation plan.) Thus, this is a sche ule risk. The ne)t question to ask is %hether this test is on the critical path or near the critical path. Again, the ans%er is etermine to !e =no> !ecause the test has some sche ule risk mitigating slack. Therefore the consequence is minimal since it %ill not likel$ impact a ma"or milestone. Thus, this risk is reporte as sho%n in 7igure A.
1A
Circuit Card A aila!ility (S) Aggressi e de elopment pro"ect may not deli er circuit cards in time to support de elopment testing# $e elop interim test !ench and test methods to support integral de elopment and test acti ity until full capa!ility is a aila!le#
Fi#"re &. An Ex()'.e o* Ris0 Re'ortin#
1?
A. Ke/ A,ti2it/ 6 Ris0 Miti#(tion +.(nnin#

A.1. +"r'ose The intent of risk mitigation planning is to ans%er the question (hat is the program approach for addressing this potential unfavorable consequence$% 0ne or more of these mitigation options ma$ appl$, A#oi ing risk !$ eliminating the root cause an 8or the consequence, <ontrolling the cause or consequence, Transferring the risk, an 8or Assuming the le#el of risk an continuing on the current program plan. 6isk mitigation planning is the acti#it$ that i entifies, e#aluates, an selects options to set risk at accepta!le le#els gi#en program constraints an o!"ecti#es. 6isk mitigation planning is inten e to ena!le program success. (t inclu es the specifics of Bh(t shoul !e one, Bhen it shoul !e accomplishe , Bho is responsi!le, an the *"ndin# require to implement the risk mitigation plan. The most appropriate program approach is selecte from the mitigation options liste a!o#e an ocumente in a risk mitigation plan. The le#el of etail epen s on the program life*c$cle phase an the nature of the nee to !e a resse . 1o%e#er, there must !e enough etail to allo% a general estimate of the effort require an technological capa!ilities nee e !ase on s$stem comple)it$. A.%. T(s0s 7or each root cause or risk, the t$pe of mitigation must !e etermine an the etails of the mitigation escri!e . 0nce alternati#es ha#e !een anal$ze , the selecte mitigation option shoul !e incorporate into program planning, either into e)isting program plans or ocumente separatel$ as a risk mitigation plan (not to !e confuse %ith the risk management plan). The risk mitigation plan nee s to !e realistic, achie#a!le, measura!le, an ocumente an a ress the follo%ing topics, A escripti#e title for the i entifie riskJ The ate of the planJ The point of contact responsi!le for controlling the i entifie root causeJ A short escription of the risk (inclu ing a summar$ of the performance, sche ule, an resource impacts, likelihoo of occurrence, consequence, %hether the risk is %ithin the control of the program)J Dh$ the risk e)ists (root causes lea ing to the risk)J The options for mitigation (possi!le alternati#es to alle#iate the risk)J Definition of e#ents an acti#ities inten e to re uce the risk, success criteria for each plan e#ent, an su!sequent =risk le#el if successful> #aluesJ 6isk status ( iscuss !riefl$)J The fall!ack approach ( escri!e the approach an e)pecte ecision ate for consi ering implementation)J A management recommen ation (%hether !u get or time is to !e allocate , an %hether or not the risk mitigation is incorporate in the estimate at completion or in other program plans)J
13
Appropriate appro#al le#els ((&T lea er, higher*le#el &ro uct 'anager, S$stems /ngineer, &')J an ( entifie resource nee s.
C. Ke/ A,ti2it/ 6 Ris0 Miti#(tion +.(n I)'.e)ent(tion

C.1. +"r'ose The intent of risk mitigation (plan) e)ecution is to ensure successful risk mitigation occurs. (t ans%ers the question *ow can the planned risk mitigation be implemented$% (t, Determines %hat planning, !u get, an requirements an contractual changes are nee e , &ro#i es a coor ination #ehicle %ith management an other stakehol ers, Directs the teams to e)ecute the efine an appro#e risk mitigation plans, 0utlines the risk reporting requirements for on*going monitoring, an Documents the change histor$. C.%. T(s0s 6isk assessment (i entification an anal$sis) is accomplishe !$ risk categor$. /ach risk categor$ (e.g., performance, sche ule, an cost) inclu es a core set of assessment tasks an is relate to the other t%o categories. These interrelationships require supporti#e anal$sis among areas to ensure the integration of the assessment. (mplementing risk mitigation shoul also !e accomplishe !$ risk categor$, an it is important for this process to !e %orke through the (&T structure, requiring the (&Ts at each DCS le#el to scru! an en orse the risk mitigations of lo%er le#els. (t is important to mitigate risk %here possi!le !efore passing it up to the ne)t DCS le#el. (n a ition, each (&T must communicate potential cost or sche ule gro%th to all le#els of management. (t is imperati#e that the S$stems /ngineer an &' un erstan an appro#e the mitigation plan an e)amine the plan in terms of secon ar$, unforeseen impacts to other elements of the program outsi e of the risk o%ning (&T. As part of this effort, the (&Ts shoul ensure effecti#e mitigation plans are implemente an ongoing results of the risk management process are formall$ ocumente an !riefe , as appropriate, uring program an technical re#ie%s. Dhen etermining that it ma$ !e appropriate to lo%er the consequence of a risk, careful consi eration shoul !e gi#en to the "ustification for oing so, inclu ing i entif$ing e)actl$ %hat a!out the risk has change !et%een the time of the original consequence assessment an the current risk state to "ustif$ such a reassessment.
1B
1 .Ke/ A,ti2it/ 6 Ris0 Tr(,0in#

1 .1. +"r'ose The intent of risk tracking is to ensure successful risk mitigation. (t ans%ers the question *ow are things going$% !$, <ommunicating risks to all affecte stakehol ers, 'onitoring risk mitigation plans, 6e#ie%ing regular status up ates, Displa$ing risk management $namics !$ tracking risk status %ithin the 6isk 6eporting 'atri) (see Section 4.4), an Alerting management as to %hen risk mitigation plans shoul !e implemente or a "uste . 6isk tracking acti#ities are integral to goo program management. At a top le#el, perio ic program management re#ie%s an technical re#ie%s pro#i e much of the information use to i entif$ an$ performance, sche ule, rea iness, an cost !arriers to meeting program o!"ecti#es an milestones. 6isk tracking ocuments ma$ inclu e, program metrics, technical reports, earne #alue reports, %atch lists, sche ule performance reports, technical re#ie% minutes8reports, an critical risk processes reports. An e#entEs likelihoo an consequences ma$ change as the acquisition process procee s an up ate information !ecomes a#aila!le. Therefore, throughout the program, a program office shoul ree#aluate kno%n risks on a perio ic !asis an e)amine the program for ne% root causes. Successful risk management programs inclu e timel$, specific reporting proce ures tie to effecti#e communication among the program team. 1 .%. T(s0s 6isk tracking is the acti#it$ of s$stematicall$ tracking an e#aluating the performance of risk mitigation actions against esta!lishe metrics throughout the acquisition process. (t fee s information !ack into the other risk acti#ities of i entification, anal$sis, mitigation planning, an mitigation plan implementation as sho%n in 7igure 1. The ke$ to the tracking acti#it$ is to esta!lish a management in icator s$stem o#er the entire program. The &' uses this in icator s$stem to e#aluate the status of the program throughout the life c$cle. (t shoul !e esigne to pro#i e earl$ %arning %hen the likelihoo of occurrence or the se#erit$ of consequence e)cee s pre*esta!lishe threshol s8limits or is tren ing to%ar e)cee ing pre*set threshol s8limits so timel$ management actions to mitigate these pro!lems can !e taken. The program office shoul re*e)amine risk assessments an risk mitigation approaches concurrentl$. As the s$stem esign matures, more information !ecomes a#aila!le to assess the egree of risk inherent in the effort. (f the risk changes significantl$, the risk mitigation approaches shoul !e a "uste accor ingl$. (f the risks are foun to !e lo%er than pre#iousl$ assesse , then specific risk mitigation actions ma$ !e re uce or cancele an the fun s reprogramme for other uses. (f the$ are higher, or ne% root causes are foun , appropriate risk mitigation efforts shoul !e implemente .
4.
(n a ition to reassessing (i entif$ing an anal$zing) risks, the program office shoul look for ne% risk mitigation options. Alternati#e technologies ma$ mature, ne% pro ucts ma$ !ecome a#aila!le in the market place, or ma$ !e information foun in une)pecte places. All of these ma$ !e of use to the program office for risk mitigation. A perio ic re#ie% of e#elopments in the la!orator$, an the market place is time %ell in#este for an$ program. 1 .1. Re'ortin# 9 Do,")ent(tion The purpose of risk reporting is to ensure management recei#es all necessar$ information to make timel$ an effecti#e ecisions. This allo%s for coor ination of actions !$ the risk team, allocation of resources, an a consistent, iscipline approach. A primar$ goal of risk reporting shoul !e to pro#i e the &' %ith an effecti#e earl$ %arning of e#eloping risk. 6isk ocumentation is the recor ing, maintaining, an reporting of i entifications, anal$ses, mitigation planning an implementation, an tracking results. 6isk tracking shoul !e one as part of technical re#ie%s, risk re#ie% !oar meetings, or perio ic program re#ie%s. Documentation inclu es all plans an reports for the &' an ecision authorities an reporting forms that ma$ !e internal to the program office. This is consoli ate in the 6isk 'itigation &lan. 6isk reporting shoul present stan ar likelihoo an consequence screening criteria, as %ell as the 6isk 6eporting 'atri) presente in Section 4.4. The etails regar ing consequences for cost, sche ule, an performance shoul !e ocumente in each 6isk 'itigation &lan. The plotte position on the risk reporting matri) shoul sho% the &'Ls current assessment of the riskLs likelihoo an the estimate se#erit$ of its effect on the program if mitigation fails. As risk mitigation succee s in a program, a $ello% or re riskLs position on the 6isk 6eporting 'atri) %ill migrate in successi#e assessments from its current location to%ar the green. /ach risk escription shoul inclu e three ke$ elements (7igure A pro#i es an e)ample), A !rief escription, inclu ing !oth the title an t$pe (&, S or <), of the risk, A !rief escription of the risk root causal factor(s), an The planne mitigations, along %ith critical ates (risk re uction milestones), that a ress the root cause(s) an effect(s).
41
11.+.(nnin# : +re'(r(tion *or Ris0 M(n(#e)ent

6isk management is a ke$ element of a &'Ls e)ecuti#e ecision*making. DoD risk management is !ase on the principles that risk management must !e for%ar *looking, structure , continuous, an informati#e. The ke$ to successful risk management is earl$ planning, resourcing, an aggressi#e e)ecution. Goo planning ena!les an organize , comprehensi#e, an iterati#e approach for managing root causes. +et%orking %ithin go#ernment an in ustr$ to e)tract the !est i eas, techniques, metho s, an information can onl$ help teams seeking to impro#e their implementation of risk management. 11.1. Ris0 +.(nnin# 6isk planning is the acti#it$ of e#eloping an ocumenting an organize , comprehensi#e, an interacti#e strateg$ an metho s for i entif$ing an tracking root causes, e#eloping risk* mitigation plans, performing continuous risk assessments to etermine ho% risks an their root causes ha#e change , an assigning a equate resources. 6isk planning is the etaile formulation of a program of action for the management of root causes. 6isk planning, an the resultant plan, shoul ans%er the questions, =%ho, %hat, %here, %hen, an ho%.> (t is the acti#it$ to, /nsure the principles of this gui e are applie to the programJ De#elop an ocument an organize , comprehensi#e, an interacti#e risk management planJ Determine the metho s to !e use to e)ecute a &'Es 6isk 'anagement &lan (6'&)J an &lan for a equate resources, inclu ing personnel. 6isk planning is iterati#e, an inclu es escri!ing an sche uling the tasks for risk i entification, risk anal$sis, risk mitigation planning, resourcing, risk mitigation plan implementation, an risk tracking throughout a programLs life c$cle. Since contractor a!ilities to e#elop an manufacture the s$stem affect program risks, the contractor shoul !e consi ere a #alua!le partner in risk planning. The result is the 6'&. 11.%. Ris0 M(n(#e)ent +.(n The program office shoul esta!lish the !asic approach an %orking structure it %ill use an ocument that approach it in a 6'&. A comprehensi#e an consistent approach ensures all aspects of the program are e)amine for risk. The 6'& is integral to o#erall program planning an the program ('&, an 8or the S/&, or it ma$ !e a stan *alone ocument, as long as the acti#ities are integrate an consistent. &lanning !egins !$ e#eloping an ocumenting a risk management strateg$. /arl$ efforts esta!lish the purpose an o!"ecti#e, assign responsi!ilities for specific areas, i entif$ a itional technical e)pertise nee e , escri!e the assessment process an areas to consi er, elineate consi erations for mitigation planning, efine a rating scheme, ictate the reporting an ocumentation nee s, an esta!lish report requirements. This planning shoul also a ress e#aluation of the capa!ilities of potential sources as %ell as earl$ in ustr$ in#ol#ement. The &'Es strateg$ to manage root causes pro#i es the program team %ith irection an a !asis for planning.
44
6isk planning consists of the upfront acti#ities nee e for a successful risk management program. At the en of each acquisition phase, risk planning is the heart of the preparation for the ne)t phase. (nitiall$ formalize uring <oncept 6efinement or other first*phase planning, an up ate for each su!sequent acquisition phase in all increments of the program, the risk management process shoul !e reflecte in the program S/& an in the technolog$ e#elopment, acquisition, an support strategies. These strategies, along %ith requirement an threat ocuments, an s$stem an program characteristics, are sources of information for the program office to use in e#eloping the 6'&. The 6'& tells the go#ernment an contractor team ho% to get from %here the program is to a$ to %here the &' %ants it to !e in the future. The ke$ to %riting a goo plan is to pro#i e the necessar$ information so the program team kno%s the goals, o!"ecti#es, an the program officeEs risk management process. Although the plan ma$ !e specific in some areas, such as the assignment of responsi!ilities for go#ernment an contractor participants an efinitions, it ma$ !e general in other areas to allo% users to choose the most efficient %a$ to procee . 7or e)ample, a escription of techniques that suggests se#eral metho s for e#aluators to use to assess risk is appropriate, since e#er$ technique ma$ ha#e a #antages an isa #antages epen ing on the situation. As a program transitions through e#elopmental an operational testing, an then to the en users uring sustainment, a program 6'& shoul !e structure to i entif$, assess, an mitigate risks that ha#e a impact on o#erall program life*c$cle cost, sche ule, an 8or performance. The 6'& shoul also efine the o#erall program approach to capture an manage root causes. 6isks that are safet$ relate are outsi e the scope of this gui e an are manage in accor ance %ith '(2*STD* 334D as the &' irects. An e)ample 6'& format summar$ ma$ inclu e, (ntro uction &rogram Summar$ 6isk 'anagement Strateg$ an &rocess 6esponsi!le8/)ecuting 0rganization 6isk 'anagement &rocess an &roce ures 6isk ( entification 6isk Anal$sis 6isk 'itigation &lanning 6isk 'itigation (mplementation 6isk Tracking +ormall$, ocumentation an reporting proce ures are efine as part of the risk management process planning !efore contract a%ar , !ut the$ ma$ !e a e or mo ifie uring contract e)ecution as long as the efforts remain %ithin the scope of the contract or are appro#e as part of a contract change. The program office shoul perio icall$ re#ie% the 6'& an re#ise it, if necessar$. /#ents such as these ma$ ri#e the nee to up ate an e)isting 6'&, A change in acquisition strateg$, &reparation for a milestone ecision,
4@
6esults an fin ings from e#entO!ase technical re#ie%s, An up ate of other program plans, &reparation for a &rogram 0!"ecti#e 'emoran um su!mission, or A change in support strateg$.
11.1. Or#(niDin# *or Ris0 M(n(#e)ent (n s$stems engineering, risk management e)amines all aspects of the program phases as the$ relate to each other, from conception to isposal. This risk management process integrates esign (performance) requirements %ith other life*c$cle issues such as manufacturing, operations, an support. The &' shoul esta!lish a risk management process that inclu es not onl$ risk planning, !ut risk i entification, risk anal$sis, risk mitigation planning, resourcing, risk mitigation plan implementation, an risk tracking to !e integrate an continuousl$ applie throughout the program, inclu ing uring the esign process. 6isk assessment inclu es i entification an anal$sis of sources of root causes to inclu e performance, sche ule, an cost, an is !ase on such factors as the technolog$ !eing use an its relationship to esignJ manufacturing capa!ilitiesJ potential in ustr$ sourcesJ an test an support processes. (n a ecentralize program office risk management organization, the programEs risk management coor inator ma$ !e responsi!le for risk management planning, an (&Ts t$picall$ perform the risk assessments. (n a centralize program office risk management organization, the programLs risk management coor inator ma$ !e responsi!le for risk management planning an perform the risk assessments. (n either case, if necessar$, the team ma$ !e augmente !$ people from other program areas or outsi e e)perts. Section 11.- ela!orates on this for each of the escri!e assessment approaches. T$picall$, a program*le#el (&T ma$ con uct a quick* look assessment of the program to i entif$ the nee for technical e)perts (%ho are not part of the team) an to e)amine areas that appear most likel$ to contain risk. /ffecti#e risk management requires in#ol#ement of the entire program team an ma$ also require help from outsi e e)perts kno%le gea!le in critical risk areas (e.g., threat, technolog$, esign, manufacturing, logistics, sche ule, cost). (n a ition, the risk management process shoul co#er har %are, soft%are, the human element, an interfaces an other integration issues. 0utsi e e)perts ma$ inclu e representati#es from the user, la!orator$, contract management, specialt$ engineering, test an e#aluation, logistics, in ustr$, an sustainment communities. /n pro uct users, essential participants in program tra e anal$ses, shoul !e part of the assessment process so that an accepta!le !alance among performance, sche ule, cost, an risk can !e reache . A close relationship !et%een the go#ernment an in ustr$, an later %ith the selecte contractor(s), promotes an un erstan ing of program risks an assists in e#eloping an e)ecuting the management efforts. 11.4. Ris0 M(n(#e)ent 8o(rds A risk management tool use on man$ programs is the 6isk 'anagement Coar (6'C). This !oar is chartere as the senior program group that e#aluates all program risks an their root causes, unfa#ora!le e#ent in ications, an planne risk mitigations. (n concept, it acts similar to a
44
configuration control !oar . (t is an a #isor$ !oar to the &' an pro#i es a forum for all affecte parties to iscuss their concerns. 6'Cs can !e structure in a #ariet$ of %a$s, !ut share the follo%ing characteristics, The$ shoul !e formall$ chartere !$ the &' an ha#e a efine area of responsi!ilit$ an authorit$. +ote that 6'Cs ma$ !e organize as program office onl$, program office %ith other Go#ernment offices (such as &/0 S$stems /ngineer, 9ser, Defense <ontract 'anagement Agenc$, test organizations, S'/s), or as com!ine go#ernment*contractor* su!contractor. The structure shoul !e a apte to each program officeLs nee s. Dorking relationships !et%een the !oar an the program office staff functional support team shoul !e efine . The process flo% for the 6'C shoul !e efine . The frequenc$ of the 6'C meetings shoul !e often enough to pro#i e a thorough an timel$ un erstan ing of the risk status, !ut not too frequent to interfere %ith the e)ecution of the program plan. 7requenc$ ma$ epen on the phase of the programJ e.g., a e#elopment program ma$ require monthl$ 6'Cs, %hile a pro uction or support program ma$ hol quarterl$ 6'Cs. (nterfaces %ith other program office management elements (such as the #arious %orking groups an the configuration control !oar ) shoul !e formall$ efine . 0n programs %ith man$ significant root causes, the 6'C pro#i es an effecti#e #ehicle to ensure each root cause is properl$ an completel$ a resse uring the program life c$cle. (t is important to remem!er that successful risk tracking is epen ent on the emphasis it recei#es uring the planning process. 7urther, successful program e)ecution requires the continual tracking of the effecti#eness of the risk mitigation plans. The program management team can assign the risk management responsi!ilit$ to in i#i ual (&Ts or to a separate risk management team. (n a ition, the program office shoul esta!lish the %orking structure for risk i entification an risk anal$sis an appoint e)perience Go#ernment an in ustr$ personnel as %ell as outsi e help from S'/s, as appropriate. 11.;. Ris0 Assess)ent A''ro(,hes 7or each risk assessment, the program office team must esta!lish ho% the actual assessment (root cause i entification an risk anal$sis) %ill !e con ucte . At least four choices are a#aila!le, <on uct the assessment as part of the normal (&T acti#it$ of the program officeJ /sta!lish a program office risk assessment team, as either a temporar$ a *hoc team or a permanent organizationJ /sta!lish a Go#ernment*in ustr$ teamJ or 6equest an outsi e team or com!ine program office*outsi e team con uct the assessment. /ach approach has its o%n merits an costs. 1o%e#er, the choices are not mutuall$ e)clusi#e. &rogram offices coul use t%o or more of these options in com!ination or for ifferent aspects of the program. An internal effort shoul al%a$s !e con ucte so that program office personnel are familiar %ith the risks. Teams outsi e the program office ma$ !e appropriate if the resources nee e to o the assessment are !e$on those a#aila!le from %ithin the program team. 7irst, esta!lish a core risk assessment
4-
team if the program team is not alrea $ follo%ing a iscipline program acquisition process %hich incorporates risk assessment acti#ities. This team is the core group of in i#i uals %ho %ill con uct the risk assessment an normall$ inclu es in i#i uals %ith e)pertise in s$stems engineering, logistics, manufacturing, test, sche ule anal$sis, an cost estimating. 6egar less of the metho (s) chosen, the contractor teamLs input shoul !e solicite an inclu e in the final assessment. (f the program is not alrea $ on contract, the risk assessment team shoul also tr$ to gain insight from in ustr$, %ithin the !oun s of competiti#e non isclosure an protection of proprietar$ ata. 11.&. Ris0 M(n(#e)ent Ro.es The follo%ing responsi!ilities are recommen e relati#e to the program risk management process. 11.&.1. +ro#r() Exe,"ti2e O**i,ers : Mi.estone De,ision A"thorities /nsure program acquisition plans an strategies pro#i e for risk management, an that i entifie risks an their root causes are consi ere in milestone ecisions. (n con"unction %ith the program contracting officer, ensure program contract(s) Statement of 0!"ecti#es, Statements of Dork, an <ontract Deli#era!le 6equirements 2ists inclu e pro#isions to support a efine program risk management plan an process. &erio icall$ re#ie% program*le#el risks. +ro#r() M(n(#ers /sta!lish, use, an maintain an integrate risk management process. &'s shoul ensure their integrate risk management process inclu es all isciplines require to support the life c$cle of their s$stem (e.g., s$stems safet$, logistics, s$stems engineering, pro uci!ilit$, in*ser#ice support, contracts, test, earne #alue management, finance). (f the contract is require to compl$ %ith A+S(8/(A*?43, /arne Kalue 'anagement S$stems, risk management shoul !e an integral part of the <ontract &erformance 6eport (<&6) an the associate ('S. De#elop an maintain a program ('S that incorporates contractor sche ules an e)ternal Go#ernment acti#ities in a single, integrate sche ule. &ro"ect in epen ent estimates of completion ates for ma"or milestones an assess the pro!a!ilit$ of maintaining the !aseline sche ule. <on uct sche ule risk anal$sis as nee e an etermine the potential impact to the program estimate an appro#e fun ing. 6e#ie% the contractorLs sche ule risk anal$sis. Anal$ze the contractorLs monthl$ ('S su!missions, an monitor contractor progress against risk mitigation acti#ities. Rointl$ con uct I8Rs Bith the ,ontr(,tor te() to re(,h )"t"(. "nderst(ndin# o* ris0s inherent in the ,ontr(,torEs -(se.ine '.(ns. Cond",t I8Rs (s ne,ess(r/ thro"#ho"t the .i*e o* the 'ro#r(). The Program Managers Guide to the Integrated Baseline Review Process pro#i es etails on con ucting effecti#e (C6s. Anal$ze earne #alue information containe in the <&6 for i entification of emerging risk items or %orsening performance tren s for kno%n risk items. Assess
11.&.%.
4A
realism of contractorLs pro"ecte estimate at completion an a equac$ of correcti#e action plans. S$nthesize an correlate the status of ne% an ongoing risk elements in the ('S, <&6, risk mitigation plans, technical status ocumentation, program status re#ie%s, an other sources of program status. /sta!lish a realistic sche ule an fun ing !aseline for the program as earl$ as possi!le in the program, incorporating not onl$ an accepta!le le#el of risk, !ut a equate sche ule an fun ing margins. &rotect the program !$ !u geting to a conser#ati#e estimate %ith a high pro!a!ilit$. /nsure the program has a efine 6'&, an that risk assessments are con ucte per that plan. /nsure the program 6'& efines the require relationships %ith other risk relate irecti#es. 7orm a program 6'C to inclu e the &'8(&T 2ea er, &rogram 6isk 'anagement <oor inator, <hief or 2ea S$stems /ngineer, program logistician, !u get an financial manager, &rime <ontractor &'82ea S$stems /ngineer, an other mem!ers rele#ant to the program strateg$, phase, an risks. Appro#e appropriate risk mitigation strategies. (nclu e operational users an other stakehol ers in the formulation an acceptance of risk mitigation plans. Assign responsi!ilit$ for risk mitigation acti#ities an monitor progress through a formal tracking s$stem. 6eport program risks to appropriate &rogram /)ecuti#e 0fficer (&/0)8&'8S$stems <omman ers an user personnel prior to 'ilestone ecisions, follo%ing significant risk changes, or as requeste . 9se the 6isk 6eporting 'atri) (see Section 4.4) ocumente in the program 6'& to report program risks. Inte#r(ted +rod",t Te()
11.&.1.
11.&.4.
Document an implement the 6'&, an support the program 6'C as require . Assess (i entif$ an anal$ze) risks an their root causes using ocumente risk assessment criteria. An ongoing8continual risk assessment is highl$ recommen e , an is useful uring all phases of a programLs life c$cle. A tailore program risk assessment shoul !e con ucte for each of the applica!le technical re#ie%s an for each ke$ program ecision point. 6eport risks using the 6isk 6eporting 'atri) ocumente in the program 6'& to report program risks to appropriate &/08&'8S$stems <omman er an user personnel. 6ecommen appropriate risk mitigation strategies for each i entifie root cause, an estimate fun ing requirements to implement risk mitigation plans. Ce prepare to pro#i e require risk mitigation support. (mplement an o!tain user acceptance of risk mitigation in accor ance %ith program gui ance from the 6'C per the program 6'&. Ris0 M(n(#e)ent 8o(rds /#aluate program risk assessments in accor ance %ith the 6'&.
4?
/#aluate an continuall$ assess the program for ne% root causes, a ress the status of e)isting risks, an manage risk mitigation acti#ities. The root causes to !e i entifie an anal$ze are those that "eopar ize the achie#ement of significant program requirements, threshol s, or o!"ecti#es. 2ike (&T composition, the 6'C is ma e up of Go#ernment program management, in ustr$8contractor, an appropriate Go#ernment support personnel. /#aluate an prioritize program risks an appropriate risk mitigation strategies for each i entifie root cause, an estimate fun ing requirements to implement risk mitigation plans. Ce prepare to request require risk mitigation support. (mplement an o!tain user acceptance of risk mitigation in accor ance %ith program gui ance per the program 6'&. 6eport risk information, metrics, an tren s, using the stan ar likelihoo an consequence matri) format, to appropriate &/08&'8S$stems <omman er an user personnel. S"''ort A,ti2ities &ro#i e the people, processes, an training to support program risk management acti#ities. Designate S'/s an make them a#aila!le to assist %ith risk assessments. 9pon request of &'s or higher authorit$, Go#ernment support acti#ities shoul pro#i e personnel to con uct in epen ent risk assessments on specific programs. Contr(,tor De#elop an internal risk management program an %ork "ointl$ %ith the go#ernment program office to e#elop an o#erall risk management program. <on uct risk i entification an anal$sis uring all phases of the program, inclu ing proposal e#elopment. De#elop appropriate risk mitigation strategies an plans. Assess impacts of risk uring proposal an !aseline e#elopment. 9se pro"ecte consequences of high pro!a!ilit$ risks to help esta!lish the le#el of management reser#e an sche ule reser#e. Rointl$ con uct (C6s %ith the Go#ernment team to reach mutual un erstan ing of risks inherent in the program !aseline plans. <on uct sche ule risk anal$ses at ke$ points uring all phases of the program, inclu ing proposal e#elopment. (ncorporate risk mitigation acti#ities into ('S an program !u gets as appropriate. 9se ('S an /K' information (tren s an metrics) to monitor an track ne%l$ i entifie risks an monitor progress against risk plans. ( entif$ ne% risk items, an report status against risk mitigation plans to compan$ management an the Go#ernment program office. Assess impact of i entifie performance, sche ule an costs risks to estimate at completion, an inclu e in the estimate as appropriate. De#elop a range of estimates (!est case, most likel$, %orst case).
11.&.;.
11.&.&.
43
S$nthesize an correlate the status of ne% an ongoing risk elements in the ('S, <&6, risk mitigation plans, technical status ocumentation, program status re#ie%s, an other sources of program status. Assign responsi!ilit$ for risk mitigation acti#ities, an monitor progress through a formal tracking s$stem. 0nce risks ha#e !een realize (1..Q pro!a!ilit$) an turn into an issue, incorporate the issue into %ork planning ocuments, ('S, an earne #alue !u gets, an ensure integration %ith ongoing %ork to minimize impacts.
11.@. Tr(inin# Getting the program team organize an traine to follo% a iscipline , repeata!le process for con ucting a risk assessment (i entification an anal$sis) is critical, since perio ic assessments are nee e to support ma"or program ecisions uring the program life c$cle. /)perience teams o not necessaril$ ha#e to !e e)tensi#el$ traine each time an assessment is performe , !ut a quick re#ie% of lessons learne from earlier assessments, com!ine %ith a!!re#iate #ersions of these suggeste steps, coul a#oi false starts. The programEs risk coor inator, or an outsi e e)pert, ma$ train the (&Ts, focusing on the programEs 6'&, risk strateg$, efinitions, suggeste techniques, ocumentation, an reporting requirements. A risk assessment training package for the full team (core team plus S'/s) is often #er$ !eneficial. This package t$picall$ inclu es the risk assessment process, anal$sis criteria, ocumentation requirements, team groun rules, an a program o#er#ie%. Train the full team together in an integrate manner an the use of a facilitator ma$ !e useful.
4B
A''endix A. A''.i,(-.e Re*eren,es

AT:2 Nno%le ge Sharing S$stem (ANSS) (http,88 esk!ook. au.mil8"sp8 efault."sp) <(6<92A6 +0. AO11 ,&A6T ?, &2A++(+G, C9DG/T(+G, A<F9(S(T(0+, A+D 'A+AG/'/+T 07 <A&(TA2 ASS/TS (http+,,www.whitehouse.gov,omb,circulars,a--,current.year,s/00.pdf <ontinuous 6isk 'anagement Gui e!ook 1http+,,www.sei.cmu.edu,publications,books,other&books,crm.guidebk.html2 Defense Acquisition Guidebook (http,88akss. au.mil8 ag8) Defense Acquisition 9ni#ersit$ <ontinuous 2earning 'o ules (https,88learn. au.mil8html8clc8<lc."sp) DoD 444-.?*', "ransition from Development to 'roduction (http,88%%%. tic.mil8%hs8 irecti#es8corres8html8444-?m.htm) DoD -4...1*', Acquisition #ystems 'rotection 'rogram (http,88%%%. tic.mil8%hs8 irecti#es8corres8p f8-4..1mS.@B48p-4..1m.p f) DoDD -4...1, DoD Information #ecurity 'rogram (http,88%%%. tic.mil8%hs8 irecti#es8corres8p f8 -4..1S141@BA8 -4..1p.p f) DoDD -4...@B, #ecurity, Intelligence, and ounterintelligence #upport to Acquisition 'rogram 'rotection (http,88%%%. tic.mil8%hs8 irecti#es8corres8p f8 -4..@BS.B1.B?8 -4..@Bp.p f) DoD 3arned 4alue 5anagement (http%&&'''#ac(#osd#mil&pm&) DoD 3arned 4alue 5anagement Implementation Guide 1345IG2 (http,88gui e!ook. cma.mil8?B8gui e!ookSprocess.htm) '(2 STD 334D, Stan ar &ractice for S$stem Safet$ (https,88acc. au.mil8<ommunit$Cro%ser.asp)Mi T@.@.B) '(2*1DCN*331 Dork Creak o%n Structure 1an !ook (http,88%%%.acq.os .mil8pm8currentpolic$8%!s8'(2S1DCN* 331A8'(21DCN331A8De!1elp@8'(21DCN331A.htm) &rogram 'anagersL Gui e to the (ntegrate Caseline 6e#ie% &rocess (http,88%%%.acq.os .mil8pm8currentpolic$8(C6SGui eSAprilS4..@. oc) 6isk 'anagement <ommunit$ of &ractice (https,88acc. au.mil8<ommunit$Cro%ser.asp)Mi T1?A.?)
@.
A''endix 8. A,ron/)s
ANSS A&C < <DD <0TS <&D <&6 DAG DA9 DoD /S01 /K' (C6 (<D ('& ('S (&T N&& 2<< 2<</ ':S 0&6 0SD AT:2 Nno%le ge Sharing S$stem Acquisition &rogram Caseline <ost <apa!ilit$ De#elopment Document <ommercial*off*the*shelf <apa!ilit$ &ro uction Document <ontract &erformance 6eport Defense Acquisition Gui e!ook Defense Acquisition 9ni#ersit$ Department of Defense /n#ironment, Safet$, an 0ccupational 1ealth /arne Kalue 'anagement (ntegrate Caseline 6e#ie% (nitial <apa!ilities Document (ntegrate 'aster &lan (ntegrate 'aster Sche ule (ntegrate &ro uct Team Ne$ &erformance &arameter 2ife*<$cle <ost 2ife*<$cle <ost /stimate 'o eling an Simulation 0ffice of &rimar$ 6esponsi!ilit$ 0ffice of the Secretar$ of Defense
09SD(AT:2) 0ffice of the 9n ersecretar$ of Defense for Acquisition, Technolog$ an 2ogistics & &/0 &' 67& 6'C 6'& &erformance &rogram /)ecuti#e 0ffice or &rogram /)ecuti#e 0fficer &rogram 'anager 6equest for &roposal 6isk 'anagement Coar 6isk 'anagement &lan
@1
S S/& S'/ S6A T/'& T&' DCS
Sche ule S$stems /ngineering &lan Su!"ect 'atter /)pert Sche ule 6isk Assessment Test an /#aluation 'aster &lan Technical &erformance 'easure Dork Creak o%n Structure
@4
A''endix C. De*initions
Conse3"en,e, The outcome of a future occurrence e)presse qualitati#el$ or quantitati#el$, !eing a loss, in"ur$, isa #antage or gain. F"t"re Root C("se, The reason, %hich, if eliminate or correcte , %oul pre#ent a potential consequence from occurring. (t is the most !asic reason for the presence of a risk. Iss"eF A pro!lem or consequence %hich has occurre ue to the realization of a root cause. A current issue %as likel$ a risk in the past that %as ignore or not successfull$ mitigate . Ris0F A measure of future uncertainties in achie#ing program performance goals %ithin efine cost an sche ule constraints. (t has three components, a future root cause, a likelihoo assesse at the present time of that future root cause occurring, an the consequence of that future occurrence. Ris0 An(./sisF The acti#it$ of e)amining each i entifie risk to refine the escription of the risk, isolate the cause, an etermine the effects an ai ing in setting risk mitigation priorities. (t refines each risk in terms of its likelihoo , its consequence, an its relationship to other risk areas or processes. Ris0 Identi*i,(tionF The acti#it$ that e)amines each element of the program to i entif$ associate future root causes, !egin their ocumentation, an set the stage for their successful management. 6isk i entification !egins as earl$ as possi!le in successful programs an continues throughout the life of the program. Ris0 M(n(#e)entF An o#erarching process that encompasses i entification, anal$sis, mitigation planning, mitigation plan implementation, an tracking of future root causes an their consequence. Ris0 M(n(#e)ent +.(nnin#F The acti#it$ of e#eloping an ocumenting an organize , comprehensi#e, an interacti#e strateg$ an metho s for i entif$ing an tracking future root causes, e#eloping risk*mitigation plans, performing continuous risk assessments to etermine ho% risks an their root causes ha#e change , an assigning a equate resources. Ris0 Miti#(tion +.(n I)'.e)ent(tionF The acti#it$ of e)ecuting the risk mitigation plan to ensure successful risk mitigation occurs. (t etermines %hat planning, !u get, an requirements an contractual changes are nee e , pro#i es a coor ination #ehicle %ith management an other stakehol ers, irects the teams to e)ecute the efine an appro#e risk mitigation plans, outlines the risk reporting requirements for on*going monitoring, an ocuments the change histor$. Ris0 Miti#(tion +.(nnin#F The acti#it$ that i entifies, e#aluates, an selects options to set risk at accepta!le le#els gi#en program constraints an o!"ecti#es. (t inclu es the specifics of %hat shoul !e one, %hen it shoul !e accomplishe , %ho is responsi!le, an the fun ing require to implement the risk mitigation plan. Ris0 Tr(,0in#F The acti#it$ of s$stematicall$ tracking an e#aluating the performance of risk mitigation actions against esta!lishe metrics throughout the acquisition process an e#elops further risk mitigation options or e)ecutes risk mitigation plans, as appropriate. (t fee s
@@
information !ack into the other risk management acti#ities of i entification, anal$sis, mitigation planning, an mitigation plan implementation.
@4

2006 RM Guide 4 Aug 06final

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

2006 RM Guide 4 Aug 06final

Uploaded by

Copyright:

Available Formats

RISK MANAGEMENT GUIDE FOR DOD ACQUISITION

09SD(AT:2) S$stems an Soft%are /ngineering8/nterprise De#elopment AT2*/D;os .mil

09SD(AT:2) S$stems an Soft%are /ngineering8/nterprise De#elopment AT2*/D;os .mil

09SD(AT:2) S$stems an Soft%are /ngineering8/nterprise De#elopment AT2*/D;os .mil

1. Ke/ Ter)s$ Des,ri'tions$ (nd +rin,i'.es

Risk Mitigation Planning

Risk Mitigation Plan Implementation

09SD(AT:2) S$stems an Soft%are /ngineering8/nterprise De#elopment AT2*/D;os .mil

Ke/ A,ti2it/ 6 Ris0 Identi*i,(tion

09SD(AT:2) S$stems an Soft%are /ngineering8/nterprise De#elopment AT2*/D;os .mil

4. Ke/ A,ti2it/ 6 Ris0 An(./sis

Fi#"re %. Ris0 Re'ortin# M(trix

09SD(AT:2) S$stems an Soft%are /ngineering8/nterprise De#elopment AT2*/D;os .mil

09SD(AT:2) S$stems an Soft%are /ngineering8/nterprise De#elopment AT2*/D;os .mil

'inimal or no consequence to technical performance

A!le to meet ke$ ates. S.i' < = )onth(s!

&rogram critical path affecte . S.i' < = )onths

<annot meet ke$ program milestones. S.i' ? = )onths

/)cee s A&C threshol ? == (1 > o* 8"d#et!

09SD(AT:2) S$stems an Soft%are /ngineering8/nterprise De#elopment AT2*/D;os .mil

Risk Title (S) Risk Causal Factor Mitigation Approach

09SD(AT:2) S$stems an Soft%are /ngineering8/nterprise De#elopment AT2*/D;os .mil

Fi#"re &. An Ex()'.e o* Ris0 Re'ortin#

09SD(AT:2) S$stems an Soft%are /ngineering8/nterprise De#elopment AT2*/D;os .mil

A. Ke/ A,ti2it/ 6 Ris0 Miti#(tion +.(nnin#

C. Ke/ A,ti2it/ 6 Ris0 Miti#(tion +.(n I)'.e)ent(tion

09SD(AT:2) S$stems an Soft%are /ngineering8/nterprise De#elopment AT2*/D;os .mil

1 .Ke/ A,ti2it/ 6 Ris0 Tr(,0in#

09SD(AT:2) S$stems an Soft%are /ngineering8/nterprise De#elopment AT2*/D;os .mil

11.+.(nnin# : +re'(r(tion *or Ris0 M(n(#e)ent

09SD(AT:2) S$stems an Soft%are /ngineering8/nterprise De#elopment AT2*/D;os .mil

09SD(AT:2) S$stems an Soft%are /ngineering8/nterprise De#elopment AT2*/D;os .mil

A''endix A. A''.i,(-.e Re*eren,es

09SD(AT:2) S$stems an Soft%are /ngineering8/nterprise De#elopment AT2*/D;os .mil

S S/& S'/ S6A T/'& T&' DCS

09SD(AT:2) S$stems an Soft%are /ngineering8/nterprise De#elopment AT2*/D;os .mil

09SD(AT:2) S$stems an Soft%are /ngineering8/nterprise De#elopment AT2*/D;os .mil

You might also like