2006 rm guide 4 aug 06final

8/13/2019 2006 RM Guide 4 Aug 06Final

http://slidepdf.com/reader/full/2006-rm-guide-4-aug-06final 1/39

RISK

MANAGEMENTGUIDE 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

aressing risk on programs is to help ensure program cost, scheule, an performanceo!"ecti#es are achie#e at e#er$ stage in the life c$cle an to communicate to all stakeholers 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

ientification is part of the "o! of e#er$one an not "ust the program manager or s$stems

engineer. That inclues the test manager, financial manager, contracting officer, logistician, ane#er$ other team mem!er.

The purpose of this guie is to assist DoD an contractor &rogram 'anagers (&'s), program

offices an ntegrate &rouct Teams (&Ts) in effecti#el$ managing program risks uring the

entire acquisition process, incluing sustainment. This guie contains !aseline information aneplanations for a %ell*structure risk management program. The management concepts an

ieas presente here encourage the use of risk*!ase management practices an suggest a process to aress program risks %ithout prescri!ing specific methos or tools. (+ote thisguie oes not attempt to aress the requirements of DoD -.1 to pre#ent an manage

/n#ironment, Safet$, an 0ccupational ealth (/S0) hazars. The reaer shoul refer to '2

STD 33D, Stanar &ractice for S$stem Safet$, for guiance regaring /S0 hazars).

Since this is a guie, the information presente %ithin is not manator$ to follo%, !ut &'s areencourage to appl$ the funamentals 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 funamental program management tool for effecti#el$ managing futureuncertainties associate %ith s$stem acquisition. The practice of risk management ra%s from

man$ management isciplines incluing !ut not limite to program management, s$stems

engineering, earne #alue management, prouction planning, qualit$ assurance, logistics, s$stemsafet$ an mishap pre#ention, an requirements efinition in orer to esta!lish a methoolog$

that ensures achie#ing program o!"ecti#es for cost, scheule, an performance. &'s shoul

tailor their risk management approaches to fit their acquisition program, statutor$ requirements,

an life*c$cle phase. The guie shoul !e use in con"unction %ith relate irecti#es,instructions, polic$ memorana, or regulations issue to implement manator$ requirements.

This guie has !een structure to pro#ie a !asic unerstaning of risk management concepts

an processes. t offers clear escriptions an concise eplanations of core steps to assist in

managing risks in acquisition programs. ts focuses on risk mitigation planning animplementation rather on risk a#oiance, transfer, or assumption. The guie is not lai out in

chronological orer of implementing a risk management program, !ut rather in a sequence tofacilitate unerstaning of the topic. 7or eample, the iscussion on planning 8 preparation foro#erall risk management is in Section 3 of the guie to keep it separate from the risk

management process. The planning 8 preparation function eals %ith planning to eecute the risk

management process, !ut is not part of the eecution of the process itself.

There are se#eral nota!le changes of emphasis in this guie from pre#ious #ersions. Thesechanges reflect lessons learne from application of risk management in DoD programs.

/mphasis has !een place on09SD(AT:2) S$stems an Soft%are /ngineering8/nterprise De#elopment

AT2*/D;os.mil

i

http://akss.dau.mil/dag/Guidebook/IG_c11.4.asp


mailto:[email protected]





• 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 ientif$ 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 guie an other risk

management references can !e foun on the Defense Acquisition 9ni#ersit$ <ommunit$ of&ractice %e!site at https88acc.au.mil8rm, %here risk managers an other program team

personnel can access the aitional information %hen neee. This guie is supplemente !$

Defense Acquisition 9ni#ersit$ (DA9) 6isk 'anagement <ontinuous 2earning 'oule (ke$

%ors =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

guie 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 coorinate upates to the guie as

require, !ase on polic$ changes an customer fee!ack. To pro#ie fee!ack to the 0&6, please e*mail the office at AT2*/D;os.mil.

09SD(AT:2) S$stems an Soft%are /ngineering8/nterprise De#elopment

AT2*/D;os.mil

ii

https://acc.dau.mil/rm


https://learn.dau.mil/html/clc/Clc.jsp









T-e o* Contents

1.Key Terms, Descriptions, and Principles......................................1

1.1. 6isk....................................................................................................................................1

1.. <omponents of 6isk..........................................................................................................1

1.@. 6isk #ersus ssue 'anagement.........................................................................................1

1.4. 6isk 'anagement 0!"ecti#e.............................................................................................

2.Risk Management......................................................................3

.1. The 6isk 'anagement &rocess.........................................................................................@

.. The 6isk 'anagement &rocess 'oel .............................................................................4

.@. <haracteristics of Successful 6isk 'anagement Approaches...........................................4

.4. Top*2e#el Guielines for /ffecti#e 6isk 'anagement....................................................-

3.Key Activity - Risk denti!ication................................................."@.1. &urpose..............................................................................................................................?

@.. Tasks..................................................................................................................................?

@.@. entification of 6oot <auses............................................................................................3

#.Key Activity - Risk Analysis.......................................................11

4.1. &urpose............................................................................................................................11

4.. 6isk 6eporting 'atri.....................................................................................................11

4.@. Tasks................................................................................................................................14

-. &erformance (&) <onsierations.........................................................................................1-

. Scheule (S) <onsierations...............................................................................................1-

?. <ost (<) <onsierations.....................................................................................................1

?.1. 6isk Anal$sis llustration................................................................................................1

$.Key Activity - Risk Mitigation Planning......................................1$

3.1. &urpose............................................................................................................................13

3.. Tasks................................................................................................................................13

%. Key Activity - Risk Mitigation Plan mplementation...................1%

B.1. &urpose............................................................................................................................1B

B.. Tasks................................................................................................................................1B

1&.Key Activity - Risk Tracking.....................................................2&


AT2*/D;os.mil

iii





1.1. &urpose..........................................................................................................................

1.. Tasks..............................................................................................................................

1.@. 6eporting : Documentation.........................................................................................1

11.Planning ' Preparation !or Risk Management...........................22

11.1. 6isk &lanning.................................................................................................................

11.. 6isk 'anagement &lan..................................................................................................

11.@. 0rganizing for 6isk 'anagement.................................................................................4

11.4. 6isk 'anagement Coars..............................................................................................4

11.-. 6isk Assessment Approaches........................................................................................-

11.. 6isk 'anagement 6oles................................................................................................

11..1. &rogram /ecuti#e 0fficers 8 'ilestone Decision Authorities..................................

11... &rogram 'anagers......................................................................................................

11..@. ntegrate &rouct Team............................................................................................?

11..4. 6isk 'anagement Coars...........................................................................................?

11..-. Support Acti#ities.......................................................................................................3

11... <ontractor...................................................................................................................3

11.?. Training.........................................................................................................................B

Appendi( A. Applica)le Re!erences..............................................3&

Appendi( *. Acronyms................................................................31

Appendi( +. De!initions...............................................................33

T-e o* Fi#"res

igre 1. DoD Risk Management Process........................................#

igre 2. Risk Reporting Matri( ..................................................11

igre 3. evels o! ikeli/ood +riteria..........................................12

igre #. evels and Types o! +onse0ence +riteria......................13

igre . Risk Analysis and Reporting llstration.........................1#

igre . An (ample o! Risk Reporting........................................1"


AT2*/D;os.mil

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, scheule 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 ork Creako%n Structure (CS) an ntegrate 'aster Scheule ('S). 6isk aresses the potential #ariation in the planne

approach an its epecte outcome. hile such #ariation coul inclue positi#e as %ell asnegati#e effects, this guie %ill onl$ aress negati#e future effects since programs ha#e

t$picall$ eperience 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. Accoringl$, risks shoul

!e tie to future root causes an their effects.

1.. Ris0 2ers"s Iss"e Mn#e)ent

6isk management is the o#erarching process that encompasses ientification, 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.

Aitionall$, risk management is most effecti#e if it is full$ integrate %ith the programEss$stems engineering an program management processes5as a ri#er an a epenenc$ on

those processes for root cause an consequence management. A common misconception, an

program office practice, concerning risk management is to ientif$ an track issues (#ice risks),an then manage the consequences (#ice the root causes). This practice tens to mask true risks,

an it ser#es to track rather than resol#e or mitigate risks. This guie focuses on risk mitigation

planning an implementation rather on risk a#oiance, transfer or assumption.

+ote 6isks shoul not !e confuse %ith issues. f a root cause is escri!e in the past tense, theroot cause has alrea$ occurre, an hence, it is an issue that nees to !e resol#e, !ut it is not a

risk. hile 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 toaddress 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, consier, for eample, a commercial*off*

the*shelf (<0TS) sourcing ecision process. Fuestions such as the follo%ing shoul !e askean ans%ere prior to the <0TS ecision


AT2*/D;os.mil

1





• “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 ientification of root causes an possi!le mitigation plans. f a

<0TS acquisition is ecie, an sometime later the manufacturer of a <0TS circuit car has

informe the HI raar !uiler 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 i0eihood nd ,onse3"en,e o* *"t"re prouction scheule ela$s

in raar eli#eries if a replacement car cannot !e foun or e#elope an mae a#aila!le %ithin1 months.

f a program is !ehin scheule on release of engineering ra%ings to the fa!ricator, this is not a

riskJ it is an issue that has alrea$ emerge an nees to !e resol#e. 0ther eamples of issues

inclue failure of components uner test or anal$ses that sho% a esign shortfall. These are

program pro!lems that shoul !e hanle as issues instea of risks, since their pro!a!ilit$ ofoccurrence 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 Mn#e)ent O-5e,ti2e

&'s ha#e a %ie 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, scheule, an technical performance parameters for that

program. Aitionall$, 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$ 6eainess Assessment (T6A) pro#ie etaile

cost, scheule, an technical performance measures for program management efforts. Sinceeffecti#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#ie the &' %ith aitional insight into !alancing program requirements an

constraints against cost, scheule, or technical risk. The o!"ecti#e of a %ell*manage risk

management program is to pro#ie a repeata!le process for !alancing cost, scheule, an

performance goals %ithin program funing, especiall$ on programs %ith esigns that approachor ecee the state*of*the*art or ha#e tightl$ constraine or optimistic cost, scheule, an

performance goals. ithout 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 epens on the kno%lege gleane fromassessments 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, prouction, orsupport 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


AT2*/D;os.mil





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 (incluingsu!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"uication. Coth parties ma$ not al%a$sagree on risk likelihoos, 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 etremel$ #alua!le tool. 6isk mitigation in#ol#es selection of the option that !est pro#ies the !alance !et%een performance an cost. 6ecall that scheule 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 programoffice an the contractor to !e successful. 'an$ impeiments eist to risk management

implementation, ho%e#er, the program team must %ork together to o#ercome these o!stacles.

0ne goo eample is the natural reluctance to ientif$ real program risks earl$ for fear of

"eoparizing support of the program !$ ecision makers. Another eample is the lack ofsufficient funs to properl$ implement the risk mitigation process. o%e#er, %hen properl$

resource an implemente, the risk management process supports setting an achie#ing realistic

cost, scheule, an performance o!"ecti#es an pro#ies earl$ ientification of risks for specialattention an mitigation.

%. Ris0 Mn#e)ent

%.1. The Ris0 Mn#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 methoolog$ for continuousl$ ientif$ing an measuring the

unkno%nsJ e#eloping mitigation optionsJ selecting, planning, an implementing appropriaterisk mitigationsJ an tracking the implementation to ensure successful risk reuction. /ffecti#e

risk management epens on risk management planningJ earl$ ientification an anal$ses of

risksJ earl$ implementation of correcti#e actionsJ continuous monitoring an reassessmentJ ancommunication, ocumentation, an coorination.

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, inclue requirements e#elopment, logical solution an esign solution (s$stems

engineering), scheule 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 hanle at the appropriate management le#el.

/mphasis on risk management coincies %ith o#erall DoD efforts to reuce 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 anocument an appropriate risk management an mitigation approach. 6isk management shoul

!e esigne to enhance program management effecti#eness an pro#ie &'s %ith a ke$ tool to

reuce 2<<, increase program likelihoo of success, an assess areas of cost uncertaint$.


AT2*/D;os.mil

@





%.%. The Ris0 Mn#e)ent +ro,ess Mode

The risk management process moel (see figure 1) inclues 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

Mitigation

Plan Implementation

Risk

Mitigation

Planning

Risk

Analysis

Risk

Tracking

Fi#"re 1. DoD Ris0 Mn#e)ent +ro,ess

Acquisition programs run the gamut from simple to comple procurements an support ofmature technologies that are relati#el$ inepensi#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 guielines regarless of program size. Somecharacteristics of effecti#e risk management approach are iscusse !elo%.

%.. Chr,teristi,s o* S",,ess*" Ris0 Mn#e)ent A''ro,hes

Successful acquisition programs %ill likel$ ha#e the follo%ing risk management characteristics

• 7easi!le, sta!le, an %ell*unerstoo user requirements, supporte !$ leaership 8

stakeholers, an integrate %ith program ecisionsJ• A close partnership %ith users, inustr$, an other stakeholersJ

• 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 nees %ithin accepta!le riskJ

• entifie risks an complete risk anal$sesJ


AT2*/D;os.mil

4





• De#elope, resource, an implemente risk mitigation plansJ

• Acquisition an support strategies consistent %ith risk le#el an risk mitigation plansJ

• /sta!lishe threshols an criteria for proacti#el$ implementing efine risk mitigation

plansJ

• <ontinuous an iterati#e assessment of risksJ

• The risk anal$sis function inepenent from the &'J

• A efine set of success criteria for performance, scheule, 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, scheule, an life*c$cle cost risks are aresse, %ith mitigation actions

incorporate into program planning an !uget pro"ections. As the a%ar of a contract requiring

/K' approaches, preparation an planning shoul commence for the eecution of the ntegrateCaseline 6e#ie% (C6) process in accorance %ith the Defense Acquisition Guie!ook. <hapter

3 aresses risk planning an 6isk 'anagement &lans (6'&s).

%.4. To'67e2e G"ideines *or E**e,ti2e Ris0 Mn#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$, reainess, esign cost, or 2<<.

* 9se technolog$ emonstrations, moeling an simulation, an aggressi#e

protot$ping to reuce risks.* nclue test an e#aluation as part of the risk management process.

• nclue inustr$ participation in risk management. 0fferors shoul ha#e a risk

approach as part of their proposals as suggeste in this guie to ientif$ root causes an

e#elop plans to manage those risks an shoul inclue a raft 6'&. Aitionall$, theofferors shoul ientif$ risks as the$ percei#e them as part of the proposal. This not

onl$ helps the go#ernment ientif$ risks earl$, !ut pro#ies aitional insight into the

offerorLs le#el of unerstaning of the program requirements.

• 9se a proacti#e, structure risk assessment an anal$sis acti#it$ to ientif$ 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 inclue the status of ientifie risks.* 9tilize risk assessment checklists (a#aila!le for all e#ent*!ase technical re#ie%s)

in preparation for an uring the conuct of technical re#ie%s. The DA9 Technical6e#ie%s <ontinuous 2earning 'oule (ke$ %ors =technical re#ie%s> an coursenum!er <2/@) pro#ies a s$stematic process an access to checklists for

continuousl$ assessing the esign maturit$, technical risk, an programmatic risk of

acquisition programs, an pro#ies links to these checklists.* /sta!lish risk mitigation plans an o!tain resources against that plan.

* &ro#ie for perioic risk assessments throughout each program life*c$cle phase.


AT2*/D;os.mil

-









• /sta!lish a series of =risk assessment e#ents,> %here the effecti#eness of risk reuction

conucte 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 perioic program re#ie%s. Thesee#ents shoul inclue the s$stems engineering technical re#ie%s, !e tie to the '& at

each le#el, an ha#e clearl$ efine entr$ an eit criteria re#ie%e uring C6s.

• nclue processes as part of risk assessment. This %oul inclue 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 inclues "oint

go#ernment8contractor e#aluation of the inherent risks in the contractorLs integrate

earne #alue !aseline (%ork efinition, scheule, an !ugets).

• 6e#ie% the contractorLs Scheule 6isk Assessment (S6A) %hen pro#ie as part of the

'S ata item (D*'G'T*31-). 6e#ie% the realism of the contractorLs estimate atcompletion. Assess the o#erall likelihoo of the contractor achie#ing the forecaste

scheule or final costs against the programLs constraints.

• /sta!lish a realistic scheule an funing !aseline for the program as earl$ as possi!le

in the program, incorporating not onl$ an accepta!le le#el of risk, !ut aequatescheule an funing margins.

• <learl$ efine a set of e#aluation criteria for assigning risk ratings (lo%, moerate,

high) for ientifie root causes.

• Determine the programLs approach to risk prioritization, commonl$ presente in the

risk reporting matri iscusse in Section 4..


AT2*/D;os.mil





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

The first ke$ acti#it$ in the risk management process is 6isk entification. hile in some

pu!lications =risk assessment> is use as an um!rella term that inclues the primar$ acti#ities of

!oth risk ientification an risk anal$sis this guie aresses these t%o critical risk management

acti#ities separatel$ in Sections @ an 4, respecti#el$..1. +"r'ose

The intent of risk ientification is to ans%er the question =hat can go %rongM> !$

• 2ooking at current an propose staffing, process, esign, supplier, operational

emplo$ment, resources, epenencies, etc.,

• 'onitoring test results especiall$ test failures (reainess results an reainess pro!lems

for the sustainment phase),

• 6e#ie%ing potential shortfalls against epectations, an

• Anal$zing negati#e trens.

6isk ientification is the acti#it$ that eamines each element of the program to ientif$associate root causes, !egin their ocumentation, an set the stage for their successful

management. 6isk ientification !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), scheule, resource ata, life*c$cle cost information, /K' ata8trens, progress against critical path, technical !aseline maturit$, safet$, operational reainess, an other

program information a#aila!le to program &T mem!ers.

.%. Ts0s

6isk can !e associate %ith all aspects of a program, e.g., operational nees, attri!utes,constraints, performance parameters incluing Ne$ &erformance &arameters (N&&s), threats,

technolog$, esign processes, or CS elements. <onsequentl$ it is important to recognize that

risk ientification is the responsi!ilit$ of e#er$ mem!er of the &T, not "ust the &' or s$stemsengineer.

/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 CS as earl$ as possi!le in a

program for a prouct*oriente ecomposition, %hich is particularl$ useful in ientif$ing prouctan 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

CS structure to #ie% impacts to scheule, resource loaing, etc.

To ientif$ risks an their root causes, &Ts shoul !reak o%n program elements to a le#el

%here su!"ect matter eperts (S'/s) can perform #ali ientification !$ CS or 'S line itemnum!er. The information necessar$ to o this #aries accoring 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 'oule (ke$ %ors =technical re#ie%sJ> course num!er <2/@).

During ecomposition, risks can !e ientifie !ase on prior eperience, !rainstorming, lessons

learne from similar programs, an guiance containe in the program office 6'& (see Section

11.). A structure approach escri!es each CS element in terms of sources or areas of risk.


AT2*/D;os.mil

?









'2*DCN*331, =ork Creako%n Structures for Defense 'ateriel tems,> ser#es as the

!asis for ientif$ing the first three le#els of the program CS, an e#eloping the contract

CS. The eamination of each element an process against each risk area is an eplorator$eercise to ientif$ the critical root causes. The in#estigation ma$ sho% that risks are inter*

relate.

CS prouct an process elements an inustrial engineering, manufacturing an repair processes are often sources of significant root causes. 6isks are etermine !$ eamining eachCS element an process in terms of causes, sources, or areas of risk. hen /K' is applie on

a contract it can help ientif$ CS program elements that are eperiencing issues. This

information can !e use to help prioritize CS elements that ma$ contain unientifie risks.

.. Identi*i,tion o* Root C"ses

&rogram offices shoul eamine their programs an ientif$ root causes !$ reucing program

elements to a le#el of etail that permits an e#aluator to unerstan the significance of an$ risk

an ientif$ its causes. This is a practical %a$ of aressing the large an i#erse num!er of

risks that often occur in acquisition programs. 7or eample, a CS le#el 4 or - element ma$ !e

mae up of se#eral root causes associate %ith a specification or function, e.g., potential failureto meet tur!ine !lae #i!ration requirements for an engine tur!ine esign.

6oot causes are ientifie !$ eamining each CS prouct an process element in terms of the

sources or areas of risk. 6oot causes are those potential e#ents that e#aluators (after eaminingscenarios, CS, or processes) etermine %oul a#ersel$ affect the program at an$ time in its

life c$cle.

An approach for ientif$ing an compiling a list of root causes is to

• 2ist CS prouct 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 ientification acti#it$ shoul !e applie earl$ an continuousl$ in the acquisition

process, essentiall$ from the time performance an reainess requirements are e#elope. The program office shoul e#elop an emplo$ a formalize risk ientification proceure, an all

personnel shoul !e responsi!le for using the proceure to ientif$ risks. Specific opportunities

to ientif$ risks (e.g., at e#ent*ri#en technical re#ie%s) an eplore 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 coe an reuse ratios, critical paths or

near critical paths) shoul not !e o#erlooke. f technical re#ie%s are scheule, #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$ ientification an assessment of critical risks allo%sfor the formulation of risk mitigation approaches an the streamlining of !oth the program

efinition an the 6equest 7or &roposal (67&) processes aroun those critical prouct an process risks. 6isk ientification shoul !e one again follo%ing an$ ma"or program change or

restructure such as significant scheule a"ustment, requirements change, or scope change to the

contract.

T$pical risk sources inclue


AT2*/D;os.mil

3

http://www.acq.osd.mil/pm/currentpolicy/wbs/MIL_HDBK-881A/MILHDBK881A/WebHelp3/MILHDBK881A.htm






• Thret. 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, ecluing those cause !$ threat uncertaint$. 6equirements inclueoperational nees, attri!utes, performance an reainess parameters (incluing N&&s),constraints, technolog$, esign processes, an CS elements.

• Te,hni, 8seine. 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 consiere. The s$stem configuration is

an agree*to escription (an appro#e an release ocument or a set of ocuments) ofthe attri!utes of a prouct, at a point in time, %hich ser#es as a !asis for efining

change.

• Test nd E2"tion. The aequac$ an capa!ilit$ of the test an e#aluation program

to assess attainment of significant performance specifications an etermine %hetherthe s$stem is operationall$ effecti#e, operationall$ suita!le, an interopera!le.

• Modein# nd Si)"tion (M9S!. The aequac$ an capa!ilit$ of ':S to support

all life*c$cle phases of a program using #erifie, #aliate, an accreite moels an

simulations.

• Te,hnoo#/. 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,iities. The a!ilit$ of the s$stem configuration to achie#e the programEs

prouction o!"ecti#es !ase on the s$stem esign, manufacturing processes chosen, ana#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'-iities. The a!ilities, eperience, resources, an kno%lege 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 inclues the effects of !uget an affora!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).

• Mn#e)ent. The egree to %hich program plans an strategies eist an are realistic

an consistent. The go#ernmentLs acquisition an support team shoul !e qualifie ansufficientl$ staffe to manage the program.

• S,hed"e. The sufficienc$ of the time allocate for performing the efine acquisition

tasks. This factor inclues the effects of programmatic scheule ecisions, the inherenterrors in scheule estimating, an eternal ph$sical constraints.


AT2*/D;os.mil

B





• Extern F,tors. The a#aila!ilit$ of go#ernment resources eternal 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 !uget #ariations an reuctions an the

resultant program tur!ulence.

• Erned V"e Mn#e)ent S/ste). The aequac$ of the contractorLs /K' processan the realism of the integrate !aseline for managing the program.

De#elopersL engineering an manufacturing processes that historicall$ ha#e cause the mostifficult$ uring the e#elopment phases of acquisition programs are frequentl$ terme critical

risk processes. These processes inclue, !ut are not limite to, esign, test an e#aluation, prouction,

facilities, logistics, an management. DoD 44-.?*', "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 inustr$ eperts %ho ientifie engineering processes an

control methos to minimize risk in !oth go#ernment an inustr$.

Aitional areas, such as manpo%er, /S0, an s$stems engineering, that are anal$ze uring

program plan e#elopment pro#ie inicators for aitional risk. The program office shoulconsier these areas for earl$ assessment, since failure to o so coul cause significant

consequences in the programEs latter phases.

n aition, &'s shoul aress the uncertaint$ associate %ith securit$ O an area sometimeso#erlooke !$ e#elopers !ut aresse uner the topic of acquisition s$stem protection in the

Defense Acquisition Guidebook (DAG) , as %ell as in DoDD -.1, DoD Information #ecurity

'rogramJ DoDD -.@B, #ecurity, Intelligence, and ounterintelligence #upport to Acquisition 'rogram 'rotectionJ an DoD -.1*', Acquisition #ystems 'rotection 'rogram . o%e#er, in

aition to the guiance gi#en there, &'s must recognize that, in the past, classifie programs

ha#e eperience ifficult$ in access, facilities, clearances, an #isitor control. 7ailure tomanage these aspects of a classifie program coul a#ersel$ impact scheules. +ot onl$ are

classifie programs at risk, !ut an$ program that encompasses nformation Assurance is !urene !$ e#er increasing securit$ requirements an certifications. These risks must !e

ientifie as earl$ as possi!le as the$ affect esign, e#elopment, test, an certificationrequirements that %ill impose scheule challenges to the program.


AT2*/D;os.mil

1

http://www.dtic.mil/whs/directives/corres/html/42457m.htm




http://akss.dau.mil/dag/welcome.asp



http://www.dtic.mil/whs/directives/corres/pdf/d52001_121396/d52001p.pdf







http://www.dtic.mil/whs/directives/corres/pdf/52001m_0394/p52001m.pdf














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

4.1. +"r'ose

The intent of risk anal$sis is to ans%er the question =o% !ig is the riskM> !$

• <onsiering the likelihoo of the root cause occurrenceJ

• entif$ing the possi!le consequences in terms of performance, scheule, an costJ an

• entif$ing the risk le#el using the 6isk 6eporting 'atri sho%n in 7igure .

4.%. Ris0 Re'ortin# Mtrix

/ach unesira!le e#ent that might affect the success of the program (performance, scheule, an

cost) shoul !e ientifie an assesse as to the likelihoo an consequence of occurrence. A

stanar format for e#aluation an reporting of program risk assessment finings facilitatescommon unerstaning 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 ientifie %ithin a program. The

le#el of risk for each root cause is reporte as lo% (green), moerate ($ello%), or high (re).

7 i 0 e . i h o o d

Conse3"en,e

1

%

4

;

1 % 4 ;

Fi#"re %. Ris0 Re'ortin# Mtrix


AT2*/D;os.mil

11





The le#el of likelihoo of each root cause is esta!lishe utilizing specifie criteria (7igure @).

7or eample, if the root cause has an estimate - percent pro!a!ilit$ of occurring, the

corresponing likelihoo is 2e#el @.

7 i 0 e

. i h o o d

PB.Q +ear <ertaint$-

P?.Qighl$ 2ikel$4

P-.Q2ikel$@

[email protected]% 2ikelihoo

P1.Q +ot 2ikel$1

+ro-(-i.it/ o* O,,"rren,e7i0e.ihood7e2e.

Fi#"re . 7e2es o* 7i0eihood 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 eample of a root cause %ith a - percent pro!a!ilit$ of occurring, ifthat same root cause has no impact on performance or cost, !ut ma$ likel$ result in a minor

scheule slippage that %onLt impact a ke$ milestone, then the corresponing consequence is a

2e#el @ for this risk. 7or clarit$ it is also classifie as a schedule risk since its root cause isscheule relate.


AT2*/D;os.mil

1





Fi#"re 4. 7e2es nd T/'es o* Conse3"en,e Criteri

The results for each risk are then plotte in the corresponing single square on the 6isk

6eporting 'atri. n this eample, since the le#el of likelihoo an consequence %ere !oth =@,>

the corresponing scheule risk is reporte as =$ello%,> as sho%n in 7igure -, using arecommene ispla$ metho that inclues the risk title (%here (S) ientifies this risk as a

scheule risk), risk causal factor, an mitigation approach.


AT2*/D;os.mil

1@

7e2e Te,hni, +er*or)n,e S,hed"e Cost

1 'inimal or no consequence to technical

performance'inimal or no impact

'inimal or no

impact

'inor reuction in technical performance or

supporta!ilit$, can !e tolerate %ith little or noimpact on program

A!le to meet ke$ ates.

Si' < = )onth(s!

Cuget increase orunit prouction cost

increases.

< == (1> o*

8"d#et!

@

'oerate reuction in technical performance or

supporta!ilit$ %ith limite impact on programo!"ecti#es

'inor scheule slip. A!leto meet ke$ milestones

%ith no scheule float.

Si' < = )onth(s!

S"-6s/ste) si' ? =

)onth(s! '"s 2i-e

*ot.


increase

< == (;> o*

8"d#et!

4Significant egraation in technical performance or

ma"or shortfall in supporta!ilit$J ma$ "eoparize program success

&rogram critical path

affecte.

Si' < = )onths


increase

< == (1> o*

8"d#et!

-Se#ere egraation in technical performanceJ

<annot meet N&& or ke$ technical8supporta!ilit$thresholJ %ill "eoparize program success

<annot meet ke$ program

milestones.

Si' ? = )onths

/cees A&Cthreshol

? == (1> o*

8"d#et!

C o n s e q u e n c e





7 i 0 e . i h o o d

Conse3"en,e

1

%

4

;

1 % 4 ;

Risk Title (S)

Risk Causal Factor

Mitigation Approach

Fi#"re ;. Ris0 An/sis nd Re'ortin# I"strtion

4.. Ts0s

6isk anal$sis is the acti#it$ of eamining each ientifie 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 ientifie. The

o!"ecti#e is to gather enough information a!out future risks to "uge the root causes, thelikelihoo, an the consequences if the risk occurs. The frequentl$ use term =risk assessment>

inclues the istinct acti#ities of risk ientification an risk anal$sis.

6isk anal$sis sequence of tasks inclue

• De#elop pro!a!ilit$ an consequence scales !$ allocating consequence threshols

against the CS or other !reakoutJ

• Assign a pro!a!ilit$ of occurrence to each risk using the criteria presente in Section

4.J

• Determine consequence in terms of performance (&), scheule (S), an8or cost (<)

impact using the criteria presente in Section 4.J 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 perioicall$ re*accomplishe to ensure the anal$sis remains current.

n a CS approach, risks are ientifie, assesse, an tracke for ini#iual CS elements at

their respecti#e le#els (primaril$ for impact on cost an scheule performance) an for their


AT2*/D;os.mil

14





resulting effect on the o#erall prouct. Since DoD programs are generall$ esta!lishe aroun the

CS, each prouctLs associate costs an scheule can !e reail$ !aseline, an its risk

consequence can !e measure as a e#iation against this !aseline. Taking the CS tosuccessi#el$ lo%er le#els %ill help to assure all require proucts are ientifie, along %ith

allocations for cost an scheule performance (as %ell as operational performance) goals.

ntegration of performance, scheule, an cost anal$ses into a single process pro#ies a final prouct that starts %ith %ell*efine requirements, !uils upon a soli technical founation,e#elops a realistic program scheule, an ocuments the resources neee in the program cost

estimates. &rogram root cause ientification an anal$sis integrates the technical performance

assessment, scheule assessment, an cost estimates using esta!lishe risk e#aluation techniques./ach of these risk categories (cost, scheule, performance) has acti#ities of primar$

responsi!ilit$, !ut is pro#ie 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 prouct.

The follo%ing paragraphs pro#ie rele#ant questions to ask in assessing performance, scheule,an cost root causes.

;. +er*or)n,e (+! Considertions

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 scheule 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$ &rouction Document (<&D), threats, suita!ilit$,

effecti#eness).

• Technical (e.g., S/&, Technolog$ 6eainess 2e#els, specifications, T/'&, technical

!aselines, stanars, materiel reainess )

• 'anagement (e.g., organization, staffing le#els, personnel qualifications8eperience,

funing, management processes, planning, ocumentation, logistics)

&. S,hed"e (S! Considertions

Is there an impact to schedule performance and to what level M f the risk oes not ha#e afirst orer performance impact, then ask this question. f the risk oes impact the critical

path, then it impacts !oth scheule an cost, !ut shoul !e carrie as a scheule 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 inclue

• /#aluating !aseline scheule inputs (urations an net%ork logic)J

•

ncorporating technical assessment an scheule uncertaint$ inputs to the programscheule moelJ

• /#aluating impacts to program scheule !ase on technical team assessmentJ

• &erforming scheule anal$sis on the program 'S, incorporating the potential impact

from all contract scheules an associate go#ernment acti#itiesJ

• Fuantif$ing scheule ecursions reflecting the effects of cost risks, incluing resource

constraintsJ


AT2*/D;os.mil

1-





• &ro#iing a go#ernment scheule assessment for cost anal$sis an fiscal $ear planning,

reflecting the technical founation, acti#it$ efinition, an inputs from technical an

cost areasJ an

• Documenting the scheule !asis an risk impacts for the risk assessment.

• &ro"ecting an inepenent forecast of the planne completion ates for ma"or

milestones.

@. Cost (C! Considertions

Does the risk only impact life&cycle cost$ f so, %ith no performance or scheuleimpacts, the risk is a cost risk, an ma$ impact estimates an assessments such as

• Cuiling on technical an scheule assessment resultsJ

• Translating performance an scheule risks into life*c$cle costJ

• Deri#ing life*c$cle cost estimates !$ integrating technical assessment an scheule risk

impacts on resourcesJ

• /sta!lishing !ugetar$ requirements consistent %ith fiscal $ear planningJ

• Determining if the aequac$ an phasing of funing supports the technical an

acquisition approachesJ

• &ro#iing program life*c$cle cost ecursions from near*term !uget eecution impacts

an eternal !uget changes an constraintsJ an

• Documenting the cost !asis an risk impacts.

+0T/ <ost an funing are not the same. <ost is relate to the amount of mone$

require to acquire an sustain a commoit$, an funing is the amount of mone$

a#aila!le to acquire an sustain that commoit$.

@.1. Ris0 An/sis I"strtion

The follo%ing eample illustrates %hat has !een presente in this section %ith the critical car

eample use earlier

The program office has ientifie a risk in conucting a e#elopmental test.

• The first question to ask is %h$ the test might not !e a!le to !e conucte. The

ans%er is that the circuit cars for one component ma$ not !e a#aila!le. n asking thequestion =%h$> a secon time, the ans%er is that po%er con#ersion circuit cars for

one component ma$ not !e a#aila!le in time for s$stem integration to meet the test

scheule. The risk causal factor is this a#aila!ilit$ of po%er con#ersion circuit cars.(Alternatel$, if the po%er con#ersion circuit car is no longer in prouction, then $ou

ha#e a completel$ ifferent risk that %ill require a ifferent mitigation plan.) Thus,

this is a scheule risk.

•

The net 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 scheule

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 .


AT2*/D;os.mil

1





7 i 0 e . i h o o d

Conse3"en,e

1

%

4

;

1 % 4 ;

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


AT2*/D;os.mil

1?

Circuit Card Aaila!ility (S)

Aggressie deelopment pro"ect may not delier circuitcards in time to support deelopment testing#

$eelop interim test !ench and test methods to supportintegral deelopment and test actiity until full capa!ility isaaila!le#





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

.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#oiing risk !$ eliminating the root cause an8or the consequence,

• <ontrolling the cause or consequence,

• Transferring the risk, an8or

• Assuming the le#el of risk an continuing on the current program plan.

6isk mitigation planning is the acti#it$ that ientifies, e#aluates, an selects options to set risk ataccepta!le le#els gi#en program constraints an o!"ecti#es. 6isk mitigation planning is intene

to ena!le program success. t inclues the specifics of Bht 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 epens on the program life*c$cle phase an the nature of the nee to !e

aresse. o%e#er, there must !e enough etail to allo% a general estimate of the effort

require an technological capa!ilities neee !ase on s$stem compleit$.

.%. Ts0s

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 eisting program plans or ocumente separatel$ as a risk

mitigation plan (not to !e confuse %ith the risk management plan). The risk mitigation plannees to !e realistic, achie#a!le, measura!le, an ocumente an aress the follo%ing topics

• A escripti#e title for the ientifie riskJ

• The ate of the planJ

• The point of contact responsi!le for controlling the ientifie root causeJ

• A short escription of the risk (incluing a summar$ of the performance, scheule, an

resource impacts, likelihoo of occurrence, consequence, %hether the risk is %ithin the

control of the program)J

• h$ the risk eists (root causes leaing 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 intene to reuce 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 epecte ecision ate for

consiering implementation)J

• A management recommenation (%hether !uget 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


AT2*/D;os.mil

13





• Appropriate appro#al le#els (&T leaer, higher*le#el &rouct 'anager, S$stems

/ngineer, &')J an

• entifie resource nees.

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

.1. +"r'ose

The intent of risk mitigation (plan) eecution is to ensure successful risk mitigation occurs. tans%ers the question “*ow can the planned risk mitigation be implemented$% t

• Determines %hat planning, !uget, an requirements an contractual changes are

neee,

• &ro#ies a coorination #ehicle %ith management an other stakeholers,

• Directs the teams to eecute the efine an appro#e risk mitigation plans,

• 0utlines the risk reporting requirements for on*going monitoring, an

• Documents the change histor$.

.%. Ts0s

6isk assessment (ientification an anal$sis) is accomplishe !$ risk categor$. /ach risk

categor$ (e.g., performance, scheule, an cost) inclues 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 !eaccomplishe !$ risk categor$, an it is important for this process to !e %orke through the &T

structure, requiring the &Ts at each CS le#el to scru! an enorse the risk mitigations of

lo%er le#els. t is important to mitigate risk %here possi!le !efore passing it up to the net CSle#el. n aition, each &T must communicate potential cost or scheule gro%th to all le#els of

management. t is imperati#e that the S$stems /ngineer an &' unerstan an appro#e the

mitigation plan an eamine the plan in terms of seconar$, unforeseen impacts to otherelements of the program outsie 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 technicalre#ie%s.

hen etermining that it ma$ !e appropriate to lo%er the consequence of a risk, carefulconsieration shoul !e gi#en to the "ustification for oing so, incluing ientif$ing eactl$ %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.


AT2*/D;os.mil

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 stakeholers,

• 'onitoring risk mitigation plans,

• 6e#ie%ing regular status upates,

• Displa$ing risk management $namics !$ tracking risk status %ithin the 6isk 6eporting

'atri (see Section 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, perioic

program management re#ie%s an technical re#ie%s pro#ie much of the information use to

ientif$ an$ performance, scheule, reainess, an cost !arriers to meeting program o!"ecti#es an

milestones.

6isk tracking ocuments ma$ inclue program metrics, technical reports, earne #alue reports,

%atch lists, scheule performance reports, technical re#ie% minutes8reports, an critical risk

processes reports.

An e#entEs likelihoo an consequences ma$ change as the acquisition process procees an

upate information !ecomes a#aila!le. Therefore, throughout the program, a program office

shoul ree#aluate kno%n risks on a perioic !asis an eamine the program for ne% root causes.

Successful risk management programs inclue timel$, specific reporting proceures tie toeffecti#e communication among the program team.

1.%. Ts0s

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 feesinformation !ack into the other risk acti#ities of ientification, 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 inicator s$stem o#er the entire

program. The &' uses this inicator s$stem to e#aluate the status of the program throughout thelife c$cle. t shoul !e esigne to pro#ie earl$ %arning %hen the likelihoo of occurrence or the

se#erit$ of consequence ecees pre*esta!lishe threshols8limits or is trening to%ar eceeing

pre*set threshols8limits so timel$ management actions to mitigate these pro!lems can !e taken.

The program office shoul re*eamine risk assessments an risk mitigation approachesconcurrentl$. 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 accoringl$. f the risks are foun to !e lo%er than pre#iousl$

assesse, then specific risk mitigation actions ma$ !e reuce or cancele an the funsreprogramme for other uses. f the$ are higher, or ne% root causes are foun, appropriate risk

mitigation efforts shoul !e implemente.


AT2*/D;os.mil





n aition to reassessing (ientif$ing an anal$zing) risks, the program office shoul look for

ne% risk mitigation options. Alternati#e technologies ma$ mature, ne% proucts ma$ !ecome

a#aila!le in the market place, or ma$ !e information foun in unepecte places. All of these ma$ !e of use to the program office for risk mitigation. A perioic re#ie% of e#elopments in the

la!orator$, an the market place is time %ell in#este for an$ program.

1.. Re'ortin# 9 Do,")enttion

The purpose of risk reporting is to ensure management recei#es all necessar$ information to maketimel$ an effecti#e ecisions. This allo%s for coorination of actions !$ the risk team, allocation

of resources, an a consistent, iscipline approach. A primar$ goal of risk reporting shoul !e to

pro#ie the &' %ith an effecti#e earl$ %arning of e#eloping risk.

6isk ocumentation is the recoring, maintaining, an reporting of ientifications, 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 perioic program re#ie%s.

Documentation inclues all plans an reports for the &' an ecision authorities an reporting

forms that ma$ !e internal to the program office. This is consoliate in the 6isk 'itigation &lan.

6isk reporting shoul present stanar likelihoo an consequence screening criteria, as %ell as

the 6isk 6eporting 'atri presente in Section 4.. The etails regaring consequences for cost,

scheule, 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 riskLslikelihoo an the estimate se#erit$ of its effect on the program if mitigation fails. As risk

mitigation succees 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 riskescription shoul inclue three ke$ elements (7igure pro#ies an eample)

• A !rief escription, incluing !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 reuction milestones), thataress the root cause(s) an effect(s).


AT2*/D;os.mil

1





6isk planning consists of the upfront acti#ities neee for a successful risk management program.

At the en of each acquisition phase, risk planning is the heart of the preparation for the net

phase. nitiall$ formalize uring <oncept 6efinement or other first*phase planning, an upatefor 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 programcharacteristics, 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 toa$ to

%here the &' %ants it to !e in the future. The ke$ to %riting a goo plan is to pro#ie thenecessar$ 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 eample,

a escription of techniques that suggests se#eral methos for e#aluators to use to assess risk is

appropriate, since e#er$ technique ma$ ha#e a#antages an isa#antages epening 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 ientif$, assess, an mitigate risks

that ha#e a impact on o#erall program life*c$cle cost, scheule, an8or performance. The 6'&

shoul also efine the o#erall program approach to capture an manage root causes. 6isks that aresafet$ relate are outsie the scope of this guie an are manage in accorance %ith '2*STD*

33D as the &' irects.

An eample 6'& format summar$ ma$ inclue

• ntrouction

• &rogram Summar$

• 6isk 'anagement Strateg$ an &rocess• 6esponsi!le8/ecuting 0rganization

• 6isk 'anagement &rocess an &roceures

• 6isk entification

• 6isk Anal$sis

• 6isk 'itigation &lanning

• 6isk 'itigation mplementation

• 6isk Tracking

+ormall$, ocumentation an reporting proceures are efine as part of the risk management

process planning !efore contract a%ar, !ut the$ ma$ !e ae or moifie uring contracteecution 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 perioicall$ re#ie% the 6'& an re#ise it, if necessar$. /#ents such as

these ma$ ri#e the nee to upate an eisting 6'&

• A change in acquisition strateg$,

• &reparation for a milestone ecision,


AT2*/D;os.mil

@





• 6esults an finings from e#entO!ase technical re#ie%s,

• An upate of other program plans,

• &reparation for a &rogram 0!"ecti#e 'emoranum su!mission, or

• A change in support strateg$.

11.. Or#niin# *or Ris0 Mn#e)ent

n s$stems engineering, risk management eamines 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 inclues not onl$ risk planning, !ut risk

ientification, risk anal$sis, risk mitigation planning, resourcing, risk mitigation planimplementation, an risk tracking to !e integrate an continuousl$ applie throughout the

program, incluing uring the esign process.

6isk assessment inclues ientification an anal$sis of sources of root causes to inclue

performance, scheule, an cost, an is !ase on such factors as the technolog$ !eing use an itsrelationship to esignJ manufacturing capa!ilitiesJ potential inustr$ sourcesJ an test an support

processes.

n a ecentralize program office risk management organization, the programEs risk management

coorinator ma$ !e responsi!le for risk management planning, an &Ts t$picall$ perform therisk assessments. n a centralize program office risk management organization, the

programLs risk management coorinator 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 outsie eperts. Section 11.- ela!orates on this foreach of the escri!e assessment approaches. T$picall$, a program*le#el &T ma$ conuct a quick*

look assessment of the program to ientif$ the nee for technical eperts (%ho are not part of theteam) an to eamine areas that appear most likel$ to contain risk.

/ffecti#e risk management requires in#ol#ement of the entire program team an ma$ also requirehelp from outsie eperts kno%legea!le in critical risk areas (e.g., threat, technolog$, esign,

manufacturing, logistics, scheule, cost). n aition, the risk management process shoul co#er

har%are, soft%are, the human element, an interfaces an other integration issues. 0utsieeperts ma$ inclue representati#es from the user, la!orator$, contract management, specialt$

engineering, test an e#aluation, logistics, inustr$, an sustainment communities. /n prouct

users, essential participants in program trae anal$ses, shoul !e part of the assessment process sothat an accepta!le !alance among performance, scheule, cost, an risk can !e reache. A close

relationship !et%een the go#ernment an inustr$, an later %ith the selecte contractor(s),

promotes an unerstaning of program risks an assists in e#eloping an eecuting themanagement efforts.

11.4. Ris0 Mn#e)ent 8ords

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 inications, an planne risk mitigations. n concept, it acts similar to a


AT2*/D;os.mil

4





configuration control !oar. t is an a#isor$ !oar to the &' an pro#ies 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 aapte to each program officeLs nees.

• orking 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#ie a thorough an

timel$ unerstaning of the risk status, !ut not too frequent to interfere %ith the

eecution 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 prouction or support

program ma$ hol quarterl$ 6'Cs.

• nterfaces %ith other program office management elements (such as the #arious %orkinggroups an the configuration control !oar) shoul !e formall$ efine.

0n programs %ith man$ significant root causes, the 6'C pro#ies an effecti#e #ehicle to ensure

each root cause is properl$ an completel$ aresse uring the program life c$cle. t is

important to remem!er that successful risk tracking is epenent on the emphasis it recei#es

uring the planning process. 7urther, successful program eecution requires the continual trackingof the effecti#eness of the risk mitigation plans.

The program management team can assign the risk management responsi!ilit$ to ini#iual &Ts

or to a separate risk management team. n aition, the program office shoul esta!lish the

%orking structure for risk ientification an risk anal$sis an appoint eperience Go#ernment

an inustr$ personnel as %ell as outsie 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 ientification an risk anal$sis) %ill !e conucte. At least four choices are a#aila!le

• <onuct 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*inustr$ teamJ or

• 6equest an outsie team or com!ine program office*outsie team conuct the

assessment.

/ach approach has its o%n merits an costs. o%e#er, the choices are not mutuall$ eclusi#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 conucte so that program office personnel arefamiliar %ith the risks.

Teams outsie the program office ma$ !e appropriate if the resources neee to o the assessment

are !e$on those a#aila!le from %ithin the program team. 7irst, esta!lish a core risk assessment


AT2*/D;os.mil

-





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 ini#iuals %ho %ill

conuct the risk assessment an normall$ inclues ini#iuals %ith epertise in s$stemsengineering, logistics, manufacturing, test, scheule anal$sis, an cost estimating.

6egarless of the metho(s) chosen, the contractor teamLs input shoul !e solicite an inclue

in the final assessment. f the program is not alrea$ on contract, the risk assessment team shoulalso tr$ to gain insight from inustr$, %ithin the !ouns of competiti#e nonisclosure an protection of proprietar$ ata.

11.&. Ris0 Mn#e)ent Roes

The follo%ing responsi!ilities are recommene relati#e to the program risk management process.

11.&.1. +ro#r) Exe,"ti2e O**i,ers : Miestone De,ision A"thorities

• /nsure program acquisition plans an strategies pro#ie for risk management, an

that ientifie risks an their root causes are consiere in milestone ecisions.

• n con"unction %ith the program contracting officer, ensure program contract(s)

Statement of 0!"ecti#es, Statements of ork, an <ontract Deli#era!le6equirements 2ists inclue pro#isions to support a efine program risk

management plan an process.

• &erioicall$ re#ie% program*le#el risks.

11.&.%. +ro#r) Mn#ers

• /sta!lish, use, an maintain an integrate risk management process. &'s shoul

ensure their integrate risk management process inclues all isciplines require to

support the life c$cle of their s$stem (e.g., s$stems safet$, logistics, s$stems

engineering, prouci!ilit$, in*ser#ice support, contracts, test, earne #aluemanagement, finance). f the contract is require to compl$ %ith A+S8/A*?43,

/arne Kalue 'anagement S$stems, risk management shoul !e an integral part ofthe <ontract &erformance 6eport (<&6) an the associate 'S.

• De#elop an maintain a program 'S that incorporates contractor scheules an

eternal Go#ernment acti#ities in a single, integrate scheule. &ro"ect

inepenent estimates of completion ates for ma"or milestones an assess the pro!a!ilit$ of maintaining the !aseline scheule. <onuct scheule risk anal$sis as

neee an etermine the potential impact to the program estimate an appro#e

funing. 6e#ie% the contractorLs scheule risk anal$sis. Anal$ze the contractorLsmonthl$ 'S su!missions, an monitor contractor progress against risk mitigation

acti#ities.

• Rointl$ conuct I8Rs Bith the ,ontr,tor te) to re,h )"t" "nderstndin#

o* ris0s inherent in the ,ontr,tors -seine 'ns. Cond",t I8Rs s

ne,essr/ thro"#ho"t the i*e o* the 'ro#r). The Program Managers’ Guide

to the Integrated Baseline Review Process pro#ies etails on conucting effecti#e

C6s.

• Anal$ze earne #alue information containe in the <&6 for ientification of

emerging risk items or %orsening performance trens for kno%n risk items. Assess


AT2*/D;os.mil

http://www.acq.osd.mil/pm/currentpolicy/IBR_Guide_April_2003.doc








realism of contractorLs pro"ecte estimate at completion an aequac$ 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 scheule an funing !aseline for the program as earl$ as possi!le in the program, incorporating not onl$ an accepta!le le#el of risk, !utaequate scheule an funing margins. &rotect the program !$ !ugeting to a

conser#ati#e estimate %ith a high pro!a!ilit$.

• /nsure the program has a efine 6'&, an that risk assessments are conucte

per that plan. /nsure the program 6'& efines the require relationships %ith

other risk relate irecti#es.

• 7orm a program 6'C to inclue the &'8&T 2eaer, &rogram 6isk 'anagement

<oorinator, <hief or 2ea S$stems /ngineer, program logistician, !uget anfinancial 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. nclue operational users an otherstakeholers 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

<ommaners an user personnel prior to 'ilestone ecisions, follo%ing significantrisk changes, or as requeste. 9se the 6isk 6eporting 'atri (see Section 4.)

ocumente in the program 6'& to report program risks.

11.&.. Inte#rted +rod",t Te)

• Document an implement the 6'&, an support the program 6'C as require.

• Assess (ientif$ an anal$ze) risks an their root causes using ocumente risk

assessment criteria. An ongoing8continual risk assessment is highl$ recommene,

an is useful uring all phases of a programLs life c$cle. A tailore program risk

assessment shoul !e conucte for each of the applica!le technical re#ie%s anfor 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 <ommaner an user

personnel.

• 6ecommen appropriate risk mitigation strategies for each ientifie root cause,

an estimate funing requirements to implement risk mitigation plans. Ce prepareto pro#ie require risk mitigation support.

• mplement an o!tain user acceptance of risk mitigation in accorance %ith

program guiance from the 6'C per the program 6'&.

11.&.4. Ris0 Mn#e)ent 8ords

• /#aluate program risk assessments in accorance %ith the 6'&.


AT2*/D;os.mil

?





• /#aluate an continuall$ assess the program for ne% root causes, aress the status

of eisting risks, an manage risk mitigation acti#ities. The root causes to !e

ientifie an anal$ze are those that "eoparize the achie#ement of significant program requirements, threshols, or o!"ecti#es. 2ike &T composition, the 6'C

is mae up of Go#ernment program management, inustr$8contractor, an

appropriate Go#ernment support personnel.• /#aluate an prioritize program risks an appropriate risk mitigation strategies for

each ientifie root cause, an estimate funing requirements to implement risk

mitigation plans. Ce prepare to request require risk mitigation support.

mplement an o!tain user acceptance of risk mitigation in accorance %ith program guiance per the program 6'&.

• 6eport risk information, metrics, an trens, using the stanar likelihoo an

consequence matri format, to appropriate &/08&'8S$stems <ommaner an user personnel.

11.&.;. S"''ort A,ti2ities

• &ro#ie the people, processes, an training to support program risk managementacti#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#ie personnel to conuct inepenent risk assessments on specific programs.

11.&.&. 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.

• <onuct risk ientification an anal$sis uring all phases of the program, incluing

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 scheule reser#e.

• Rointl$ conuct C6s %ith the Go#ernment team to reach mutual unerstaning of

risks inherent in the program !aseline plans.

• <onuct scheule risk anal$ses at ke$ points uring all phases of the program,

incluing proposal e#elopment.

• ncorporate risk mitigation acti#ities into 'S an program !ugets as appropriate.

• 9se 'S an /K' information (trens an metrics) to monitor an track ne%l$

ientifie risks an monitor progress against risk plans. entif$ ne% risk items,

an report status against risk mitigation plans to compan$ management an theGo#ernment program office.

• Assess impact of ientifie performance, scheule an costs risks to estimate at

completion, an inclue in the estimate as appropriate. De#elop a range of

estimates (!est case, most likel$, %orst case).


AT2*/D;os.mil

3





• 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 (1Q pro!a!ilit$) an turn into an issue,incorporate the issue into %ork planning ocuments, 'S, an earne #alue !ugets, an ensure integration %ith ongoing %ork to minimize impacts.

11.@. Trinin#

Getting the program team organize an traine to follo% a iscipline, repeata!le process forconucting a risk assessment (ientification an anal$sis) is critical, since perioic assessments are

neee to support ma"or program ecisions uring the program life c$cle. /perience teams o

not necessaril$ ha#e to !e etensi#el$ traine each time an assessment is performe, !ut a quickre#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 coorinator, or an outsie epert, 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$ inclues 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.


AT2*/D;os.mil

B





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

AT:2 Nno%lege Sharing S$stem ( ANSS)

(http88esk!ook.au.mil8"sp8efault."sp)

<6<92A6 +0. AO11 ,&A6T ?, &2A+++G, C9DG/T+G, A<F9ST0+, A+D

'A+AG/'/+T 07 <A&TA2 ASS/TS(http+www.whitehouse.govombcircularsa--currentyears/00.pdf

<ontinuous 6isk 'anagement Guie!ook

1http+www.sei.cmu.edupublicationsbooksother&bookscrm.guidebk.html2

Defense Acquisition Guidebook

(http88akss.au.mil8ag8)

Defense Acquisition 9ni#ersit$ <ontinuous 2earning 'oules

(https88learn.au.mil8html8clc8<lc."sp)

DoD 44-.?*', "ransition from Development to 'roduction

(http88%%%.tic.mil8%hs8irecti#es8corres8html844-?m.htm)

DoD -.1*', Acquisition #ystems 'rotection 'rogram

(http88%%%.tic.mil8%hs8irecti#[email protected])DoDD -.1, DoD Information #ecurity 'rogram

(http88%%%.tic.mil8%hs8irecti#[email protected])

DoDD -.@B, #ecurity, Intelligence, and ounterintelligence #upport to Acquisition

'rogram 'rotection

(http88%%%.tic.mil8%hs8irecti#es8corres8pf8-@[email protected])

DoD 3arned 4alue 5anagement

(http%&&'''#ac#osd#mil&pm&)

DoD 3arned 4alue 5anagement Implementation Guide 1345IG2

(http88guie!ook.cma.mil8?B8guie!ookprocess.htm)

'2 STD 33D, Stanar &ractice for S$stem Safet$

(https88acc.au.mil8<ommunit$Cro%ser.aspMi@@B)'2*DCN*331 ork Creako%n Structure an!ook

(http88%%%.acq.os.mil8pm8currentpolic$8%!s8'2DCN*

331A8'2DCN331A8e!elp@8'2DCN331A.htm)

&rogram 'anagersL Guie to the ntegrate Caseline 6e#ie% &rocess

(http88%%%[email protected])

6isk 'anagement <ommunit$ of &ractice

(https88acc.au.mil8<ommunit$Cro%ser.aspMi1??)


AT2*/D;os.mil

@

http://deskbook.dau.mil/jsp/default.jsp

http://www.whitehouse.gov/omb/circulars/a11/current_year/s300.pdf

http://www.sei.cmu.edu/publications/books/other-books/crm.guidebk.html

http://akss.dau.mil/dag/














http://www.acq.osd.mil/pm/

http://guidebook.dcma.mil/79/guidebook_process.htm





https://acc.dau.mil/CommunityBrowser.aspx?id=17607



http://deskbook.dau.mil/jsp/default.jsp

http://www.whitehouse.gov/omb/circulars/a11/current_year/s300.pdf

http://www.sei.cmu.edu/publications/books/other-books/crm.guidebk.html

http://akss.dau.mil/dag/







http://www.acq.osd.mil/pm/











A''endix 8. A,ron/)s

ANSS AT:2 Nno%lege Sharing S$stem

A&C Acquisition &rogram Caseline

< <ost<DD <apa!ilit$ De#elopment Document

<0TS <ommercial*off*the*shelf

<&D <apa!ilit$ &rouction Document

<&6 <ontract &erformance 6eport

DAG Defense Acquisition Guie!ook

DA9 Defense Acquisition 9ni#ersit$

DoD Department of Defense

/S0 /n#ironment, Safet$, an 0ccupational ealth

/K' /arne Kalue 'anagement

C6 ntegrate Caseline 6e#ie%

<D nitial <apa!ilities Document

'& ntegrate 'aster &lan

'S ntegrate 'aster Scheule

&T ntegrate &rouct Team

N&& Ne$ &erformance &arameter

2<< 2ife*<$cle <ost

2<</ 2ife*<$cle <ost /stimate

':S 'oeling an Simulation

0&6 0ffice of &rimar$ 6esponsi!ilit$

0SD 0ffice of the Secretar$ of Defense

09SD(AT:2) 0ffice of the 9nersecretar$ of Defense for Acquisition, Technolog$ an

2ogistics

& &erformance

&/0 &rogram /ecuti#e 0ffice or &rogram /ecuti#e 0fficer

&' &rogram 'anager

67& 6equest for &roposal

6'C 6isk 'anagement Coar

6'& 6isk 'anagement &lan


AT2*/D;os.mil

@1





S Scheule

S/& S$stems /ngineering &lan

S'/ Su!"ect 'atter /pert

S6A Scheule 6isk Assessment

T/'& Test an /#aluation 'aster &lan

T&' Technical &erformance 'easure

CS ork Creako%n Structure


AT2*/D;os.mil

@





A''endix C. De*initions

Conse3"en,e The outcome of a future occurrence epresse 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 potentialconsequence from occurring. t is the most !asic reason for the presence of a risk.

Iss"e 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.

Ris0 A measure of future uncertainties in achie#ing program performance goals %ithin efine

cost an scheule constraints. t has three components a future root cause, a likelihoo assesseat the present time of that future root cause occurring, an the consequence of that future

occurrence.

Ris0 An/sis The acti#it$ of eamining each ientifie risk to refine the escription of the risk,

isolate the cause, an etermine the effects an aiing in setting risk mitigation priorities. trefines each risk in terms of its likelihoo, its consequence, an its relationship to other risk areas

or processes.

Ris0 Identi*i,tion The acti#it$ that eamines each element of the program to ientif$ associate

future root causes, !egin their ocumentation, an set the stage for their successful management.6isk ientification !egins as earl$ as possi!le in successful programs an continues throughout the

life of the program.

Ris0 Mn#e)ent An o#erarching process that encompasses ientification, anal$sis, mitigation

planning, mitigation plan implementation, an tracking of future root causes an theirconsequence.

Ris0 Mn#e)ent +nnin# The acti#it$ of e#eloping an ocumenting an organize,comprehensi#e, an interacti#e strateg$ an methos for ientif$ing an tracking future root

causes, e#eloping risk*mitigation plans, performing continuous risk assessments to etermineho% risks an their root causes ha#e change, an assigning aequate resources.

Ris0 Miti#tion +n I)'e)enttion The acti#it$ of eecuting the risk mitigation plan to

ensure successful risk mitigation occurs. t etermines %hat planning, !uget, an requirements

an contractual changes are neee, pro#ies a coorination #ehicle %ith management an otherstakeholers, irects the teams to eecute 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# The acti#it$ that ientifies, e#aluates, an selects options to set risk at

accepta!le le#els gi#en program constraints an o!"ecti#es. t inclues the specifics of %hatshoul !e one, %hen it shoul !e accomplishe, %ho is responsi!le, an the funing require to

implement the risk mitigation plan.

Ris0 Tr,0in# 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#elopsfurther risk mitigation options or eecutes risk mitigation plans, as appropriate. t fees


AT2*/D;os.mil

@@





information !ack into the other risk management acti#ities of ientification, anal$sis, mitigation

planning, an mitigation plan implementation.