Cmmi For Development, Version 1.3

CMMI for Development, Version 1.
3
CMMI-DEV, V1.3
CMMI Product Team
Improving processes for developing better products and services

November 2010 TECHNICAL REPORT
CMU/SEI-2010-TR-033 E C-T!-"#1#-#33
Software E !" eer" ! Pro#e$$ Ma a!eme t Pro!ram

Unlimited distribution subject to the copyright.
$ttp%&&'''.sei.cmu.edu
This report was prepared for the SEI Administrative Agent ESC !"# $ Eglin Street %anscom A&'( )A *+,-+./+** The ideas and findings in this report should not be construed as an official 0o0 position. It is published in the interest of scientific and technical information e1change. This wor2 is sponsored by the U.S. 0epartment of 0efense. The Software Engineering Institute is a federally funded research and development center sponsored by the U.S. 0epartment of 0efense. Copyright /*+* Carnegie )ellon University. 34 5A66A3T7 T%IS CA63E8IE )E9943 U3I:E6SIT7 A30 S4&T5A6E E38I3EE6I38 I3STITUTE )ATE6IA9 IS &U63IS%E0 43 A3 ;AS.IS< 'ASIS. CA63E8IE )E9943 U3I:E6SIT7 )A#ES 34 5A66A3TIES 4& A37 #I30( EIT%E6 E!"6ESSE0 46 I)"9IE0( AS T4 A37 )ATTE6 I3C9U0I38( 'UT 34T 9I)ITE0 T4( 5A66A3T7 4& &IT3ESS &46 "U6"4SE 46 )E6C%A3TA'I9IT7( E!C9USI:IT7( 46 6ESU9TS 4'TAI3E0 &64) USE 4& T%E )ATE6IA9. CA63E8IE )E9943 U3I:E6SIT7 04ES 34T )A#E A37 5A66A3T7 4& A37 #I30 5IT% 6ES"ECT T4 &6EE04) &64) "ATE3T( T6A0E)A6#( 46 C4"76I8%T I3&6I38E)E3T. Use of any trademar2s in this report is not intended in any way to infringe on the rights of the trademar2 holder. Internal use. "ermission to reproduce this document and to prepare derivative wor2s from this document for internal use is granted( provided the copyright and ;3o 5arranty< statements are included with all reproductions and derivative wor2s.
E1ternal use. This document may be reproduced in its entirety( without modification( and freely distributed in written or electronic form without re=uesting formal permission. "ermission is re=uired for any other e1ternal and or commercial use. 6e=uests for permission should be directed to the Software Engineering Institute at permission>sei.cmu.edu.
This wor2 was created in the performance of &ederal 8overnment Contract 3umber &A?,/+.*$.C. ***- with Carnegie )ellon University for the operation of the Software Engineering Institute( a federally funded research and development center. The 8overnment of the United States has a royalty. free government.purpose license to use( duplicate( or disclose the wor2( in whole or in part and in any manner( and to have or permit others to do so( for government purposes pursuant to the copyright license under the clause at /$/.//,.,*+-. &or information about SEI publications( please visit the library on the SEI website @www.sei.cmu.edu libraryA. The following service mar2s and registered mar2s are used in this documentBCapability )aturity )odel Carnegie )ellon CE6T C)) C))I C)) Integration I0EA9S) SCA)"IS) C))I( C))( CE6T( C)) Integration( Carnegie )ellon( and Capability )aturity )odel are registered in the U.S. "atent and Trademar2 4ffice. SCA)"I and I0EA9 are service mar2s of Carnegie )ellon University.
CMMI for %eve&o'me t( )er$"o 1*3
Prefa#e
CMMI (Capa)ilit* Maturit* Model Inte+ration, models are collections of )est practices t$at $elp or+ani-ations to improve t$eir processes. T$ese models are developed )* product teams 'it$ mem)ers from industr*, +overnment, and t$e oft'are En+ineerin+ Institute ( EI,. T$is model, called CMMI for Development (CMMI-DEV,, provides a compre$ensive inte+rated set of +uidelines for developin+ products and services.
Purpose
T$e CMMI-DEV model provides +uidance for appl*in+ CMMI )est practices in a development or+ani-ation. .est practices in t$e model focus on activities for developin+ /ualit* products and services to meet t$e needs of customers and end users. T$e CMMI-DEV, V1.3 model is a collection of development )est practices from +overnment and industr* t$at is +enerated from t$e CMMI V1.3 0rc$itecture and 1rame'or2.1 CMMI-DEV is )ased on t$e CMMI Model 1oundation or CM1 (i.e., model components common to all CMMI models and constellations", and incorporates 'or2 )* development or+ani-ations to adapt CMMI for use in t$e development of products and services.
Acknowledgments
Man* talented people 'ere involved in t$e development of t$e V1.3 CMMI Product uite. T$ree primar* +roups 'ere t$e CMMI teerin+ 3roup, Product Team, and Confi+uration Control .oard (CC.,. T$e teerin+ 3roup +uided and approved t$e plans of t$e Product Team, provided consultation on si+nificant CMMI pro4ect issues, and ensured involvement from a variet* of interested communities. T$e teerin+ 3roup oversa' t$e development of t$e Development constellation reco+ni-in+ t$e importance of providin+ )est practices to development or+ani-ations. T$e Product Team 'rote, revie'ed, revised, discussed, and a+reed on t$e structure and tec$nical content of t$e CMMI Product uite, includin+ t$e
1
T$e CMMI 1rame'or2 is t$e )asic structure t$at or+ani-es CMMI components and com)ines t$em into CMMI constellations and models. 0 constellation is a collection of CMMI components t$at are used to construct models, trainin+ materials, and appraisal related documents for an area of interest (e.+., development, ac/uisition, services,.
"
Prefa#e
"
frame'or2, models, trainin+, and appraisal materials. Development activities 'ere )ased on multiple inputs. T$ese inputs included an 0pecification and +uidance specific to eac$ release provided )* t$e teerin+ 3roup, source models, c$an+e re/uests received from t$e user communit*, and input received from pilots and ot$er sta2e$olders. T$e CC. is t$e official mec$anism for controllin+ c$an+es to CMMI models, appraisal related documents, and Introduction to CMMI trainin+. 0s suc$, t$is +roup ensures inte+rit* over t$e life of t$e product suite )* revie'in+ all proposed c$an+es to t$e )aseline and approvin+ onl* t$ose c$an+es t$at satisf* identified issues and meet criteria for t$e upcomin+ release. Mem)ers of t$e +roups involved in developin+ CMMI-DEV, V1.3 are listed in 0ppendi5 C.
Audience
T$e audience for CMMI-DEV includes an*one interested in process improvement in a development environment. 6$et$er *ou are familiar 'it$ t$e concept of Capa)ilit* Maturit* Models or are see2in+ information to )e+in improvin+ *our development processes, CMMI-DEV 'ill )e useful to *ou. T$is model is also intended for or+ani-ations t$at 'ant to use a reference model for an appraisal of t$eir development related processes. 3
Organization of this Document
T$is document is or+ani-ed into t$ree main parts% Part 7ne% 0)out CMMI for Development Part T'o% 3eneric 3oals and 3eneric Practices, and t$e Process 0reas Part T$ree% T$e 0ppendices and 3lossar*
Part 7ne% 0)out CMMI for Development, consists of five c$apters% C$apter 1, Introduction, offers a )road vie' of CMMI and t$e CMMI for Development constellation, concepts of process improvement, and t$e $istor* of models used for process improvement and different process improvement approac$es. C$apter ", Process 0rea Components, descri)es all of t$e components of t$e CMMI for Development process areas.8 C$apter 3, T*in+ It 0ll To+et$er, assem)les t$e model components and e5plains t$e concepts of maturit* levels and capa)ilit* levels. C$apter 8, !elations$ips 0mon+ Process 0reas, provides insi+$t into t$e meanin+ and interactions amon+ t$e CMMI-DEV process areas.
0n appraisal is an e5amination of one or more processes )* a trained team of professionals usin+ a reference model (e.+., CMMI-DEV, as t$e )asis for determinin+ stren+t$s and 'ea2nesses. 0 process area is a cluster of related practices in an area t$at, '$en implemented collectivel*, satisfies a set of +oals considered important for ma2in+ improvement in t$at area. T$is concept is covered in detail in C$apter ".
""
Prefa#e
C$apter 9, :sin+ CMMI Models, descri)es pat$s to adoption and t$e use of CMMI for process improvement and )enc$mar2in+ of practices in a development or+ani-ation.
Part T'o% 3eneric 3oals and 3eneric Practices, and t$e Process 0reas, contains all of t$is CMMI model;s re/uired and e5pected components. It also contains related informative components, includin+ su)practices, notes, e5amples, and e5ample 'or2 products. Part T'o contains "3 sections. T$e first section contains t$e +eneric +oals and practices. T$e remainin+ "" sections eac$ represent one of t$e CMMIDEV process areas. To ma2e t$ese process areas eas* to find, t$e* are or+ani-ed alp$a)eticall* )* process area acron*m. Eac$ section contains descriptions of +oals, )est practices, and e5amples. Part T$ree% T$e 0ppendices and 3lossar*, consists of four sections% 0ppendi5 0% !eferences, contains references *ou can use to locate documented sources of information suc$ as reports, process improvement models, industr* standards, and )oo2s t$at are related to CMMI-DEV. 0ppendi5 .% 0cron*ms, defines t$e acron*ms used in t$e model. 0ppendi5 C% CMMI Version 1.3 Pro4ect Participants contains lists of team mem)ers '$o participated in t$e development of CMMI-DEV, V1.3. 0ppendi5 D% 3lossar*, defines man* of t$e terms used in CMMI-DEV.
How to Use this Document
6$et$er *ou are ne' to process improvement, ne' to CMMI, or alread* familiar 'it$ CMMI, Part 7ne can $elp *ou understand '$* CMMI-DEV is t$e model to use for improvin+ *our development processes.
Rea+er$ New to Pro#e$$ Im'roveme t
If *ou are ne' to process improvement or ne' to t$e Capa)ilit* Maturit* Model (CMM, concept, 'e su++est t$at *ou read C$apter 1 first. C$apter 1 contains an overvie' of process improvement t$at e5plains '$at CMMI is all a)out. <e5t, s2im Part T'o, includin+ +eneric +oals and practices and specific +oals and practices, to +et a feel for t$e scope of t$e )est practices contained in t$e model. Pa* close attention to t$e purpose and introductor* notes at t$e )e+innin+ of eac$ process area. In Part T$ree, loo2 t$rou+$ t$e references in 0ppendi5 0 and select additional sources *ou t$in2 'ould )e )eneficial to read )efore movin+ for'ard 'it$ usin+ CMMI-DEV. !ead t$rou+$ t$e acron*ms and +lossar* to )ecome familiar 'it$ t$e lan+ua+e of CMMI. T$en, +o )ac2 and read t$e details of Part T'o.
Prefa#e
"""
Rea+er$ E,'er"e #e+ w"t- Pro#e$$ Im'roveme t
If *ou are ne' to CMMI )ut $ave e5perience 'it$ ot$er process improvement models, suc$ as t$e oft'are CMM or t$e *stems En+ineerin+ Capa)ilit* Model (i.e., EI0 =31,, *ou 'ill immediatel* reco+ni-e man* similarities in t$eir structure and content >EI0 "##"a?. 6e recommend t$at *ou read Part 7ne to understand $o' CMMI is different from ot$er process improvement models. If *ou $ave e5perience 'it$ ot$er models, *ou ma* 'ant to select '$ic$ sections to read first. !ead Part T'o 'it$ an e*e for )est practices *ou reco+ni-e from t$e models t$at *ou $ave alread* used. .* identif*in+ familiar material, *ou 'ill +ain an understandin+ of '$at is ne', '$at $as )een carried over, and '$at is familiar from t$e models *ou alread* 2no'. <e5t, revie' t$e +lossar* to understand $o' some terminolo+* can differ from t$at used in t$e process improvement models *ou 2no'. Man* concepts are repeated, )ut t$e* ma* )e called somet$in+ different.
Rea+er$ .am"&"ar w"t- CMMI
If *ou $ave revie'ed or used a CMMI model )efore, *ou 'ill /uic2l* reco+ni-e t$e CMMI concepts discussed and t$e )est practices presented. 0s al'a*s, t$e improvements t$at t$e CMMI Product Team made to CMMI for t$e V1.3 release 'ere driven )* user input. C$an+e re/uests 'ere carefull* considered, anal*-ed, and implemented. ome si+nificant improvements *ou can e5pect in CMMI-DEV, V1.3 include t$e follo'in+% @i+$ maturit* process areas are si+nificantl* improved to reflect industr* )est practices, includin+ a ne' specific +oal and several ne' specific practices in t$e process area t$at 'as renamed from 7r+ani-ational Innovation and Deplo*ment (7ID, to 7r+ani-ational Performance Mana+ement (7PM,. Improvements 'ere made to t$e model arc$itecture t$at simplif* t$e use of multiple models. Informative material 'as improved, includin+ revisin+ t$e en+ineerin+ practices to reflect industr* )est practice and addin+ +uidance for or+ani-ations t$at use 0+ile met$ods. 3lossar* definitions and model terminolo+* 'ere improved to en$ance t$e clarit*, accurac*, and usa)ilit* of t$e model. Aevel 8 and 9 +eneric +oals and practices 'ere eliminated as 'ell as capa)ilit* levels 8 and 9 to appropriatel* focus $i+$ maturit* on t$e ac$ievement of )usiness o)4ectives, '$ic$ is accomplis$ed )* appl*in+ capa)ilit* level 1-3 to t$e $i+$ maturit* process areas (Causal 0nal*sis and !esolution, Buantitative Pro4ect Mana+ement, 7r+ani-ational Performance Mana+ement, and 7r+ani-ational Process Performance,.
1or a more complete and detailed list of improvements, see $ttp%&&'''.sei.cmu.edu&cmmi&tools&cmmiv1-3&.
"v
Prefa#e
Additional Information and Reader Feedback
Man* sources of information a)out CMMI are listed in 0ppendi5 0 and are also pu)lis$ed on t$e CMMI 'e)siteC$ttp%&&'''.sei.cmu.edu&cmmi&. Dour su++estions for improvin+ CMMI are 'elcome. 1or information on $o' to provide feed)ac2, see t$e CMMI 'e)site at $ttp%&&'''.sei.cmu.edu&cmmi&tools&cr&. If *ou $ave /uestions a)out CMMI, send email to cmmi-commentsEsei.cmu.edu.
Prefa#e
v"
Prefa#e
Tab&e of Co te t$
U &"m"te+ +"$tr"b/t"o $/b0e#t to t-e #o'1r"!-t* -tt'2//www*$e"*#m/*e+/

Preface Purpose 0c2no'led+ments 0udience 7r+ani-ation of t$is Document @o' to :se t$is Document !eaders <e' to Process Improvement !eaders E5perienced 'it$ Process Improvement !eaders 1amiliar 'it$ CMMI 0dditional Information and !eader 1eed)ac2
" "
i i i ii ii iii iii iv iv v
Part O e2 Abo/t CMMI for %eve&o'me t 1 I tro+/#t"o

0)out Process Improvement 0)out Capa)ilit* Maturit* Models Evolution of CMMI CMMI 1rame'or2 CMMI for Development
1 1 3
8 9 9 = =
2 Pro#e$$ Area Com'o e t$

Core Process 0reas and CMMI Models !e/uired, E5pected, and Informative Components !e/uired Components E5pected Components Informative Components Components 0ssociated 'it$ Part T'o Process 0reas Purpose tatements Introductor* <otes !elated Process 0reas pecific 3oals 3eneric 3oals pecific 3oal and Practice ummaries pecific Practices E5ample 6or2 Products u)practices 3eneric Practices 3eneric Practice Ela)orations 0dditions upportin+ Informative Components
3
F F F F 1# 1# 11 11 11 1" 1" 1" 1" 13 13 13 13 18 18 18
Tab&e of Co te t$
v""
<otes E5amples !eferences <um)erin+ c$eme T*po+rap$ical Conventions
18 18 19 19 1G
3 T1" ! It A&& To!et-er

:nderstandin+ Aevels tructures of t$e Continuous and ta+ed !epresentations :nderstandin+ Capa)ilit* Aevels Capa)ilit* Aevel #% Incomplete Capa)ilit* Aevel 1% Performed Capa)ilit* Aevel "% Mana+ed Capa)ilit* Aevel 3% Defined 0dvancin+ T$rou+$ Capa)ilit* Aevels :nderstandin+ Maturit* Aevels Maturit* Aevel 1% Initial Maturit* Aevel "% Mana+ed Maturit* Aevel 3% Defined Maturit* Aevel 8% Buantitativel* Mana+ed Maturit* Aevel 9% 7ptimi-in+ 0dvancin+ T$rou+$ Maturit* Aevels Process 0reas E/uivalent ta+in+ 0c$ievin+ @i+$ Maturit*
21
"1 "" "8 "8 "8 "9 "9 "9 "G "= "= "H "H "F "F 3# 38 3=
4 Re&at"o $-"'$ Amo ! Pro#e$$ Area$

Process Mana+ement .asic Process Mana+ement Process 0reas 0dvanced Process Mana+ement Process 0reas Pro4ect Mana+ement .asic Pro4ect Mana+ement Process 0reas 0dvanced Pro4ect Mana+ement Process 0reas En+ineerin+ !ecursion and Iteration of En+ineerin+ Processes upport .asic upport Process 0reas 0dvanced upport Process 0reas
33
3F 8# 81 83 83 89 8= 9# 9# 91 9"
5 U$" ! CMMI Mo+e&$

0doptin+ CMMI Dour Process Improvement Pro+ram elections t$at Influence Dour Pro+ram CMMI Models Interpretin+ CMMI 6$en :sin+ 0+ile 0pproac$es :sin+ CMMI 0ppraisals 0ppraisal !e/uirements for CMMI C0MPI 0ppraisal Met$ods 0ppraisal Considerations CMMI !elated Trainin+
55
99 9G 9G 9= 9H 9F 9F 9F G# G1
Part Two2
63
v"""
Tab&e of Co te t$
7e er"# 7oa&$ a + 7e er"# Pra#t"#e$( a + t-e Pro#e$$ Area$

Generic Goals and Generic Practices 7vervie' Process Institutionali-ation Performed Process Mana+ed Process Defined Process !elations$ips 0mon+ Processes 3eneric 3oals and 3eneric Practices 0ppl*in+ 3eneric Practices Process 0reas t$at upport 3eneric Practices Causal Analysis and Resolution Configuration Management Decision Analysis and Resolution ntegrated Pro!ect Management Measurement and Analysis $rgani%ational Process Definition $rgani%ational Process 'ocus $rgani%ational Performance Management $rgani%ational Process Performance $rgani%ational (raining Product ntegration Pro!ect Monitoring and Control Pro!ect Planning Process and Product )uality Assurance )uantitati*e Pro!ect Management Re+uirements De*elo,ment Re+uirements Management Ris- Management .u,,lier Agreement Management (ec/nical .olution 0alidation 0erification
63
65 G9 G9 G9 GG GG G= GH 1"# 1"1 127 137 150 15" 17# 1"& 206 220 23# 250 260 27& 2#& 305 311 32" 3&5 353 367 377 3"7 &05
Part T-ree2 T-e A''e +"#e$

A,,endi1 A2 References Information 0ssurance&Information ecurit* !elated ources A,,endi1 32 Acronyms A,,endi1 C2 CMM 0ersion 143 Pro!ect Partici,ants CMMI teerin+ 3roup
418 418
&1" 8"3 &25 &2" 8"F
Tab&e of Co te t$
",
teerin+ 3roup Mem)ers E5-7fficio teerin+ 3roup Mem)ers teerin+ 3roup upport CMMI for ervices 0dvisor* 3roup CMMI V1.3 Coordination Team CMMI V1.3 Confi+uration Control .oard CMMI V1.3 Core Model Team CMMI V1.3 Translation Team CMMI V1.3 @i+$ Maturit* Team CMMI V1.3 0c/uisition Mini Team CMMI V1.3 ervices Mini Team CMMI V1.3 C0MPI :p+rade Team CMMI Version 1.3 Trainin+ Teams 0CB and DEV Trainin+ Team VC Trainin+ Team CMMI V1.3 Bualit* Team A,,endi1 D2 Glossary
8"F 83# 83# 83# 831 831 83" 83" 833 833 833 838 838 838 839 839 &37
Tab&e of Co te t$
Part 7ne% Abo/t CMMI for %eve&o'me t
1 I tro+/#t"o
<o' more t$an ever, companies 'ant to deliver products and services )etter, faster, and c$eaper. 0t t$e same time, in t$e $i+$-tec$nolo+* environment of t$e t'ent*-first centur*, nearl* all or+ani-ations $ave found t$emselves )uildin+ increasin+l* comple5 products and services. It is unusual toda* for a sin+le or+ani-ation to develop all t$e components t$at compose a comple5 product or service. More commonl*, some components are )uilt in-$ouse and some are ac/uiredI t$en all t$e components are inte+rated into t$e final product or service. 7r+ani-ations must )e a)le to mana+e and control t$is comple5 development and maintenance process. T$e pro)lems t$ese or+ani-ations address toda* involve enterprise-'ide solutions t$at re/uire an inte+rated approac$. Effective mana+ement of or+ani-ational assets is critical to )usiness success. In essence, t$ese or+ani-ations are product and service developers t$at need a 'a* to mana+e t$eir development activities as part of ac$ievin+ t$eir )usiness o)4ectives. In t$e current mar2etplace, maturit* models, standards, met$odolo+ies, and +uidelines e5ist t$at can $elp an or+ani-ation improve t$e 'a* it does )usiness. @o'ever, most availa)le improvement approac$es focus on a specific part of t$e )usiness and do not ta2e a s*stemic approac$ to t$e pro)lems t$at most or+ani-ations are facin+. .* focusin+ on improvin+ one area of a )usiness, t$ese models $ave unfortunatel* perpetuated t$e stovepipes and )arriers t$at e5ist in or+ani-ations. CMMI for Development (CMMI-DEV, provides an opportunit* to avoid or eliminate t$ese stovepipes and )arriers. CMMI for Development consists of )est practices t$at address development activities applied to products and services. It addresses practices t$at cover t$e product;s lifec*cle from conception t$rou+$ deliver* and maintenance. T$e emp$asis is on t$e 'or2 necessar* to )uild and maintain t$e total product. CMMI-DEV contains "" process areas. 7f t$ose process areas, 1G are core process areas, 1 is a s$ared process area, and 9 are development specific process areas.9 0ll CMMI-DEV model practices focus on t$e activities of t$e developer or+ani-ation. 1ive process areas focus on practices specific to development% addressin+ re/uirements development, tec$nical solution, product inte+ration, verification, and validation.
0 core process area is a process area t$at is common to all CMMI models. 0 s$ared process area is s$ared )* at least t'o CMMI models, )ut not all of t$em.
I tro+/#t"o
About Process Impro ement
In its researc$ to $elp or+ani-ations to develop and maintain /ualit* products and services, t$e oft'are En+ineerin+ Institute ( EI, $as found several dimensions t$at an or+ani-ation can focus on to improve its )usiness. 1i+ure 1.1 illustrates t$e t$ree critical dimensions t$at or+ani-ations t*picall* focus on% people, procedures and met$ods, and tools and e/uipment.
Procedures and met$ods definin+ t$e relations$ip of tas2s
9 A C %
PROCESS
People 'it$ s2ills, trainin+, and motivation
Tools and e/uipment
Figure 1.1: The Three Critical Dimensions
6$at $olds ever*t$in+ to+et$erJ It is t$e processes used in *our or+ani-ation. Processes allo' *ou to ali+n t$e 'a* *ou do )usiness. T$e* allo' *ou to address scala)ilit* and provide a 'a* to incorporate 2no'led+e of $o' to do t$in+s )etter. Processes allo' *ou to levera+e *our resources and to e5amine )usiness trends. T$is is not to sa* t$at people and tec$nolo+* are not important. 6e are livin+ in a 'orld '$ere tec$nolo+* is c$an+in+ at an incredi)le speed. imilarl*, people t*picall* 'or2 for man* companies t$rou+$out t$eir careers. 6e live in a d*namic 'orld. 0 focus on process provides t$e infrastructure and sta)ilit* necessar* to deal 'it$ an ever-c$an+in+ 'orld and to ma5imi-e t$e productivit* of people and t$e use of tec$nolo+* to )e competitive. Manufacturin+ $as lon+ reco+ni-ed t$e importance of process effectiveness and efficienc*. Toda*, man* or+ani-ations in manufacturin+ and service industries reco+ni-e t$e importance of /ualit* processes. Process $elps an or+ani-ation;s 'or2force to meet )usiness o)4ectives )* $elpin+ t$em to 'or2 smarter, not $arder, and 'it$ improved consistenc*. Effective processes also provide a ve$icle for introducin+ and usin+ ne' tec$nolo+* in a 'a* t$at )est meets t$e )usiness o)4ectives of t$e or+ani-ation.
I tro+/#t"o
About !apabilit" #aturit" #odels
0 Capa)ilit* Maturit* Model (CMM,, includin+ CMMI, is a simplified representation of t$e 'orld. CMMs contain t$e essential elements of effective processes. T$ese elements are )ased on t$e concepts developed )* Cros)*, Demin+, Kuran, and @ump$re*. In t$e 1F3#s, 6alter $e'$art )e+an 'or2 in process improvement 'it$ $is principles of statistical /ualit* control > $e'$art 1F31?. T$ese principles 'ere refined )* 6. Ed'ards Demin+ >Demin+ 1FHG?, P$illip Cros)* >Cros)* 1F=F?, and Kosep$ Kuran >Kuran 1FHH?. 6atts @ump$re*, !on !adice, and ot$ers e5tended t$ese principles furt$er and )e+an appl*in+ t$em to soft'are in t$eir 'or2 at I.M (International .usiness Mac$ines, and t$e EI >@ump$re* 1FHF?. @ump$re*;s )oo2, Managing the Software Process, provides a description of t$e )asic principles and concepts on '$ic$ man* of t$e Capa)ilit* Maturit* Models (CMMs, are )ased. T$e EI $as ta2en t$e process mana+ement premise, Lt$e /ualit* of a s*stem or product is $i+$l* influenced )* t$e /ualit* of t$e process used to develop and maintain it,M and defined CMMs t$at em)od* t$is premise. T$e )elief in t$is premise is seen 'orld'ide in /ualit* movements, as evidenced )* t$e International 7r+ani-ation for tandardi-ation&International Electrotec$nical Commission (I 7&IEC, )od* of standards. CMMs focus on improvin+ processes in an or+ani-ation. T$e* contain t$e essential elements of effective processes for one or more disciplines and descri)e an evolutionar* improvement pat$ from ad $oc, immature processes to disciplined, mature processes 'it$ improved /ualit* and effectiveness. Ai2e ot$er CMMs, CMMI models provide +uidance to use '$en developin+ processes. CMMI models are not processes or process descriptions. T$e actual processes used in an or+ani-ation depend on man* factors, includin+ application domains and or+ani-ation structure and si-e. In particular, t$e process areas of a CMMI model t*picall* do not map one to one 'it$ t$e processes used in *our or+ani-ation. T$e EI created t$e first CMM desi+ned for soft'are or+ani-ations and pu)lis$ed it in a )oo2, The Capability Maturity Model: Guidelines for Improving the Software Process > EI 1FF9?. Toda*, CMMI is an application of t$e principles introduced almost a centur* a+o to t$is never-endin+ c*cle of process improvement. T$e value of t$is process improvement approac$ $as )een confirmed over time. 7r+ani-ations $ave e5perienced increased productivit* and /ualit*, improved c*cle time, and more accurate and predicta)le sc$edules and )ud+ets >3i)son "##G?.
$ olution of !##I
T$e CMM Inte+ration pro4ect 'as formed to sort out t$e pro)lem of usin+ multiple CMMs. T$e com)ination of selected models into a sin+le
I tro+/#t"o
improvement frame'or2 'as intended for use )* or+ani-ations in t$eir pursuit of enterprise-'ide process improvement. Developin+ a set of inte+rated models involved more t$an simpl* com)inin+ e5istin+ model materials. :sin+ processes t$at promote consensus, t$e CMMI Product Team )uilt a frame'or2 t$at accommodates multiple constellations. T$e first model to )e developed 'as t$e CMMI for Development model (t$en simpl* called LCMMIM,. 1i+ure 1." illustrates t$e models t$at led to CMMI Version 1.3.
H"$tor1 of CMM$
CMM for Software )1*1 :1333; S1$tem$ E !" eer" ! CMM )1*1 :1335;
INCOSE SECAM :1336;
Software CMM )2( +raft C :1338; Software A#=/"$"t"o CMM )1*03 :2002; EIA 831 SECM :133<; I te!rate+ Pro+/#t %eve&o'me t CMM :1338;
CMMI for A#=/"$"t"o )1*2 :2008;
)1*02 v1*02 :2000; )1*1 v1*1 :2002; :2002; CMMI for %eve&o'me t )1*2 :2006; CMMI for Serv"#e$ )1*2 :2003;
CMMI for A#=/"$"t"o )1*3 :2010;
CMMI for %eve&o'me t CMMI for Serv"#e$ )1*3 :2010; )1*3 :2010;
Figure 1.2: The History of CMMs6
Initiall*, CMMI 'as one model t$at com)ined t$ree source models% t$e Capability Maturity Model for Software ( 6-CMM, v".# draft C, t$e Systems Engineering Capability Model ( ECM, >EI0 "##"a?, and t$e Integrated Product evelopment Capability Maturity Model (IPD-CMM, v#.FH.
EI0 =31 ECM is t$e Electronic Industries 0lliance standard =31, or t$e *stems En+ineerin+ Capa)ilit* Model. I<C7 E EC0M is International Council on *stems En+ineerin+ *stems En+ineerin+ Capa)ilit* 0ssessment Model >EI0 "##"a?.
I tro+/#t"o
T$ese t$ree source models 'ere selected )ecause of t$eir successful adoption or promisin+ approac$ to improvin+ processes in an or+ani-ation. T$e first CMMI model (V1.#", 'as desi+ned for use )* development or+ani-ations in t$eir pursuit of enterprise-'ide process improvement. It 'as released in "###. T'o *ears later version 1.1 'as released and four *ears after t$at, version 1." 'as released. .* t$e time t$at version 1." 'as released, t'o ot$er CMMI models 'ere )ein+ planned. .ecause of t$is planned e5pansion, t$e name of t$e first CMMI model $ad to c$an+e to )ecome CMMI for Development and t$e concept of constellations 'as created. T$e CMMI for 0c/uisition model 'as released in "##=. ince it )uilt on t$e CMMI for Development Version 1." model, it also 'as named Version 1.". T'o *ears later t$e CMMI for ervices model 'as released. It )uilt on t$e ot$er t'o models and also 'as named Version 1.". In "##H plans 'ere dra'n to )e+in developin+ Version 1.3, '$ic$ 'ould ensure consistenc* amon+ all t$ree models and improve $i+$ maturit* material in all of t$e models. Version 1.3 of CMMI for 0c/uisition >3alla+$er "#11, EI "#1#)?, CMMI for Development >C$rissis "#11?, and CMMI for ervices >1orrester "#11, EI "#1#a? 'ere released in <ovem)er "#1#.
!##I Framework
T$e CMMI 1rame'or2 provides t$e structure needed to produce CMMI models, trainin+, and appraisal components. To allo' t$e use of multiple models 'it$in t$e CMMI 1rame'or2, model components are classified as eit$er common to all CMMI models or applica)le to a specific model. T$e common material is called t$e LCMMI Model 1oundationM or LCM1.M T$e components of t$e CM1 are part of ever* model +enerated from t$e CMMI 1rame'or2. T$ose components are com)ined 'it$ material applica)le to an area of interest (e.+., ac/uisition, development, services, to produce a model. 0 LconstellationM is defined as a collection of CMMI components t$at are used to construct models, trainin+ materials, and appraisal related documents for an area of interest (e.+., ac/uisition, development, services,. T$e Development constellation;s model is called LCMMI for DevelopmentM or LCMMI-DEV.M
!##I for De elopment
CMMI for Development is a reference model t$at covers activities for developin+ )ot$ products and services. 7r+ani-ations from man* industries, includin+ aerospace, )an2in+, computer $ard'are, soft'are, defense, automo)ile manufacturin+, and telecommunications, use CMMI for Development.
I tro+/#t"o
CMMI for Development contains practices t$at cover pro4ect mana+ement, process mana+ement, s*stems en+ineerin+, $ard'are en+ineerin+, soft'are en+ineerin+, and ot$er supportin+ processes used in development and maintenance. :se professional 4ud+ment and common sense to interpret t$e model for *our or+ani-ation. T$at is, alt$ou+$ t$e process areas descri)ed in t$is model depict )e$aviors considered )est practices for most users, process areas and practices s$ould )e interpreted usin+ an in-dept$ 2no'led+e of CMMI-DEV, *our or+ani-ational constraints, and *our )usiness environment.
<
I tro+/#t"o
2 Pro#e$$ Area Com'o e t$
T$is c$apter descri)es t$e components found in eac$ process area and in t$e +eneric +oals and +eneric practices. :nderstandin+ t$ese components is critical to usin+ t$e information in Part T'o effectivel*. If *ou are unfamiliar 'it$ Part T'o, *ou ma* 'ant to s2im t$e 3eneric 3oals and 3eneric Practices section and a couple of process area sections to +et a +eneral feel for t$e content and la*out )efore readin+ t$is c$apter.
!ore Process Areas and !##I #odels
0ll CMMI models are produced from t$e CMMI 1rame'or2. T$is frame'or2 contains all of t$e +oals and practices t$at are used to produce CMMI models t$at )elon+ to CMMI constellations. 0ll CMMI models contain 1G core process areas. T$ese process areas cover )asic concepts t$at are fundamental to process improvement in an* area of interest (i.e., ac/uisition, development, services,. ome of t$e material in t$e core process areas is t$e same in all constellations. 7t$er material ma* )e ad4usted to address a specific area of interest. Conse/uentl*, t$e material in t$e core process areas ma* not )e e5actl* t$e same.
Re%uired& $'pected& and Informati e !omponents
Model components are +rouped into t$ree cate+oriesCre/uired, e5pected, and informativeCt$at reflect $o' to interpret t$em.
Re=/"re+ Com'o e t$
!e/uired components are CMMI components t$at are essential to ac$ievin+ process improvement in a +iven process area. T$is ac$ievement must )e visi)l* implemented in an or+ani-ation;s processes. T$e re/uired components in CMMI are t$e specific and +eneric +oals. 3oal satisfaction is used in appraisals as t$e )asis for decidin+ '$et$er a process area $as )een satisfied.
E,'e#te+ Com'o e t$
E5pected components are CMMI components t$at descri)e t$e activities t$at are important in ac$ievin+ a re/uired CMMI component. E5pected components +uide t$ose '$o implement improvements or perform appraisals. T$e e5pected components in CMMI are t$e specific and +eneric practices.
Pro#e$$ Area Com'o e t$
.efore +oals can )e considered to )e satisfied, eit$er t$eir practices as descri)ed, or accepta)le alternatives to t$em, must )e present in t$e planned and implemented processes of t$e or+ani-ation.
I format"ve Com'o e t$
Informative components are CMMI components t$at $elp model users understand CMMI re/uired and e5pected components. T$ese components can )e e5ample )o5es, detailed e5planations, or ot$er $elpful information. u)practices, notes, references, +oal titles, practice titles, sources, e5ample 'or2 products, and +eneric practice ela)orations are informative model components. T$e informative material pla*s an important role in understandin+ t$e model. It is often impossi)le to ade/uatel* descri)e t$e )e$avior re/uired or e5pected of an or+ani-ation usin+ onl* a sin+le +oal or practice statement. T$e model;s informative material provides information necessar* to ac$ieve t$e correct understandin+ of +oals and practices and t$us cannot )e i+nored.
!omponents Associated with Part (wo
T$e model components associated 'it$ Part T'o are summari-ed in 1i+ure ".1 to illustrate t$eir relations$ips.
Figure 2.1: CMMI Model Components
T$e follo'in+ sections provide detailed descriptions of CMMI model components.
10
Pro#e$$ Area$
0 process area is a cluster of related practices in an area t$at, '$en implemented collectivel*, satisfies a set of +oals considered important for ma2in+ improvement in t$at area. ( ee t$e definition of Lprocess areaM in t$e +lossar*., T$e "" process areas are presented in alp$a)etical order )* acron*m% Causal 0nal*sis and !esolution (C0!, Confi+uration Mana+ement (CM, Decision 0nal*sis and !esolution (D0!, Inte+rated Pro4ect Mana+ement (IPM, Measurement and 0nal*sis (M0, 7r+ani-ational Process Definition (7PD, 7r+ani-ational Process 1ocus (7P1, 7r+ani-ational Performance Mana+ement (7PM, 7r+ani-ational Process Performance (7PP, 7r+ani-ational Trainin+ (7T, Product Inte+ration (PI, Pro4ect Monitorin+ and Control (PMC, Pro4ect Plannin+ (PP, Process and Product Bualit* 0ssurance (PPB0, Buantitative Pro4ect Mana+ement (BPM, !e/uirements Development (!D, !e/uirements Mana+ement (!EBM, !is2 Mana+ement (! NM, upplier 0+reement Mana+ement ( 0M, Tec$nical olution (T , Validation (V0A, Verification (VE!,
P/r'o$e Stateme t$
0 purpose statement descri)es t$e purpose of t$e process area and is an informative component. 1or e5ample, t$e purpose statement of t$e 7r+ani-ational Process Definition process area is LT$e purpose of 7r+ani-ational Process Definition (7PD, is to esta)lis$ and maintain a usa)le set of or+ani-ational process assets, 'or2 environment standards, and rules and +uidelines for teams.M
I tro+/#tor1 Note$
T$e introductor* notes section of t$e process area descri)es t$e ma4or concepts covered in t$e process area and is an informative component.
11
0n e5ample from t$e introductor* notes of t$e Pro4ect Monitorin+ and Control process area is L6$en actual status deviates si+nificantl* from e5pected values, corrective actions are ta2en as appropriate.M
Re&ate+ Pro#e$$ Area$
T$e !elated Process 0reas section lists references to related process areas and reflects t$e $i+$-level relations$ips amon+ t$e process areas. T$e !elated Process 0reas section is an informative component. 0n e5ample of a reference found in t$e !elated Process 0reas section of t$e Pro4ect Plannin+ process area is L!efer to t$e !is2 Mana+ement process area for more information a)out identif*in+ and anal*-in+ ris2s and miti+atin+ ris2s.M
S'e#"f"# 7oa&$
0 specific +oal descri)es t$e uni/ue c$aracteristics t$at must )e present to satisf* t$e process area. 0 specific +oal is a re/uired model component and is used in appraisals to $elp determine '$et$er a process area is satisfied. ( ee t$e definition of Lspecific +oalM in t$e +lossar*., 1or e5ample, a specific +oal from t$e Confi+uration Mana+ement process area is LInte+rit* of )aselines is esta)lis$ed and maintained.M 7nl* t$e statement of t$e specific +oal is a re/uired model component. T$e title of a specific +oal (preceded )* t$e +oal num)er, and notes associated 'it$ t$e +oal are considered informative model components.
7e er"# 7oa&$
3eneric +oals are called L+enericM )ecause t$e same +oal statement applies to multiple process areas. 0 +eneric +oal descri)es t$e c$aracteristics t$at must )e present to institutionali-e processes t$at implement a process area. 0 +eneric +oal is a re/uired model component and is used in appraisals to determine '$et$er a process area is satisfied. ( ee t$e 3eneric 3oals and 3eneric Practices section in Part T'o for a more detailed description of +eneric +oals. ee t$e definition of L+eneric +oalM in t$e +lossar*., 0n e5ample of a +eneric +oal is LT$e process is institutionali-ed as a defined process.M 7nl* t$e statement of t$e +eneric +oal is a re/uired model component. T$e title of a +eneric +oal (preceded )* t$e +oal num)er, and notes associated 'it$ t$e +oal are considered informative model components.
S'e#"f"# 7oa& a + Pra#t"#e S/mmar"e$
T$e specific +oal and practice summar* provides a $i+$-level summar* of t$e specific +oals and specific practices. T$e specific +oal and practice summar* is an informative component.
12
S'e#"f"# Pra#t"#e$
0 specific practice is t$e description of an activit* t$at is considered important in ac$ievin+ t$e associated specific +oal. T$e specific practices descri)e t$e activities t$at are e5pected to result in ac$ievement of t$e specific +oals of a process area. 0 specific practice is an e5pected model component. ( ee t$e definition of Lspecific practiceM in t$e +lossar*., 1or e5ample, a specific practice from t$e Pro4ect Monitorin+ and Control process area is LMonitor commitments a+ainst t$ose identified in t$e pro4ect plan.M 7nl* t$e statement of t$e specific practice is an e5pected model component. T$e title of a specific practice (preceded )* t$e practice num)er, and notes associated 'it$ t$e specific practice are considered informative model components.
E,am'&e >or? Pro+/#t$
T$e e5ample 'or2 products section lists sample outputs from a specific practice. 0n e5ample 'or2 product is an informative model component. ( ee t$e definition of Le5ample 'or2 productM in t$e +lossar*., 1or instance, an e5ample 'or2 product for t$e specific practice LMonitor Pro4ect Plannin+ ParametersM in t$e Pro4ect Monitorin+ and Control process area is L!ecords of si+nificant deviations.M
S/b'ra#t"#e$
0 su)practice is a detailed description t$at provides +uidance for interpretin+ and implementin+ a specific or +eneric practice. u)practices can )e 'orded as if prescriptive, )ut t$e* are actuall* an informative component meant onl* to provide ideas t$at ma* )e useful for process improvement. ( ee t$e definition of Lsu)practiceM in t$e +lossar*., 1or e5ample, a su)practice for t$e specific practice LTa2e Corrective 0ctionM in t$e Pro4ect Monitorin+ and Control process area is LDetermine and document t$e appropriate actions needed to address identified issues.M
7e er"# Pra#t"#e$
3eneric practices are called L+enericM )ecause t$e same practice applies to multiple process areas. T$e +eneric practices associated 'it$ a +eneric +oal descri)e t$e activities t$at are considered important in ac$ievin+ t$e +eneric +oal and contri)ute to t$e institutionali-ation of t$e processes associated 'it$ a process area. 0 +eneric practice is an e5pected model component. ( ee t$e definition of L+eneric practiceM in t$e +lossar*., 1or e5ample, a +eneric practice for t$e +eneric +oal LT$e process is institutionali-ed as a mana+ed processM is LProvide ade/uate resources for performin+ t$e process, developin+ t$e 'or2 products, and providin+ t$e services of t$e process.M 7nl* t$e statement of t$e +eneric practice is an e5pected model component. T$e title of a +eneric practice (preceded )* t$e practice
13
num)er, and notes associated 'it$ t$e practice are considered informative model components.
7e er"# Pra#t"#e E&aborat"o $
3eneric practice ela)orations appear after +eneric practices to provide +uidance on $o' t$e +eneric practices can )e applied uni/uel* to process areas. 0 +eneric practice ela)oration is an informative model component. ( ee t$e definition of L+eneric practice ela)orationM in t$e +lossar*., 1or e5ample, a +eneric practice ela)oration after t$e +eneric practice LEsta)lis$ and maintain an or+ani-ational polic* for plannin+ and performin+ t$e processM for t$e Pro4ect Plannin+ process area is LT$is polic* esta)lis$es or+ani-ational e5pectations for estimatin+ t$e plannin+ parameters, ma2in+ internal and e5ternal commitments, and developin+ t$e plan for mana+in+ t$e pro4ect.M
A++"t"o $
0dditions are clearl* mar2ed model components t$at contain information of interest to particular users. 0n addition can )e informative material, a specific practice, a specific +oal, or an entire process area t$at e5tends t$e scope of a model or emp$asi-es a particular aspect of its use. T$ere are no additions in t$e CMMI-DEV model.
)upporting Informati e !omponents
In man* places in t$e model, furt$er information is needed to descri)e a concept. T$is informative material is provided in t$e form of t$e follo'in+ components% <otes E5amples !eferences
Note$
0 note is te5t t$at can accompan* nearl* an* ot$er model component. It ma* provide detail, )ac2+round, or rationale. 0 note is an informative model component. 1or e5ample, a note t$at accompanies t$e specific practice LImplement 0ction ProposalsM in t$e Causal 0nal*sis and !esolution process area is L7nl* c$an+es t$at prove to )e of value s$ould )e considered for )road implementation.M
E,am'&e$
0n e5ample is a component comprisin+ te5t and often a list of items, usuall* in a )o5, t$at can accompan* nearl* an* ot$er component and provides one or more e5amples to clarif* a concept or descri)ed activit*. 0n e5ample is an informative model component.
14
T$e follo'in+ is an e5ample t$at accompanies t$e su)practice LDocument noncompliance issues '$en t$e* cannot )e resolved in t$e pro4ectM under t$e specific practice LCommunicate and Ensure t$e !esolution of <oncompliance IssuesM in t$e Process and Product Bualit* 0ssurance process area. Examples of ways to resolve noncompliance in the project include the following: Fixing the noncompliance Changing the process descriptions, standards, or procedures that were violated Obtaining a waiver to cover the noncompliance
Refere #e$
0 reference is a pointer to additional or more detailed information in related process areas and can accompan* nearl* an* ot$er model component. 0 reference is an informative model component. ( ee t$e definition of LreferenceM in t$e +lossar*., 1or e5ample, a reference t$at accompanies t$e specific practice LCompose t$e Defined ProcessM in t$e Buantitative Pro4ect Mana+ement process area is L!efer to t$e 7r+ani-ational Process Definition process area for more information a)out esta)lis$in+ or+ani-ational process assets.M
*umbering )cheme
pecific and +eneric +oals are num)ered se/uentiall*. Eac$ specific +oal )e+ins 'it$ t$e prefi5 L 3M (e.+., 3 1,. Eac$ +eneric +oal )e+ins 'it$ t$e prefi5 L33M (e.+., 33 ",. pecific and +eneric practices are also num)ered se/uentiall*. Eac$ specific practice )e+ins 'it$ t$e prefi5 L P,M follo'ed )* a num)er in t$e form L5.*M (e.+., P 1.1,. T$e 5 is t$e same num)er as t$e +oal to '$ic$ t$e specific practice maps. T$e * is t$e se/uence num)er of t$e specific practice under t$e specific +oal. 0n e5ample of specific practice num)erin+ is in t$e Pro4ect Plannin+ process area. T$e first specific practice is num)ered P 1.1 and t$e second is P 1.". Eac$ +eneric practice )e+ins 'it$ t$e prefi5 L3P,M follo'ed )* a num)er in t$e form L5.*M (e.+., 3P 1.1,. T$e 5 corresponds to t$e num)er of t$e +eneric +oal. T$e * is t$e se/uence num)er of t$e +eneric practice under t$e +eneric +oal. 1or e5ample, t$e first +eneric practice associated 'it$ 33 " is num)ered 3P ".1 and t$e second is 3P ".".
15
("pographical !on entions
T$e t*po+rap$ical conventions used in t$is model 'ere desi+ned to ena)le *ou to easil* identif* and select model components )* presentin+ t$em in formats t$at allo' *ou to find t$em /uic2l* on t$e pa+e. 1i+ures ".", ".3, and ".8 are sample pa+es from process areas in Part T'oI t$e* s$o' t$e different process area components, la)eled so t$at *ou can identif* t$em. <otice t$at components differ t*po+rap$icall* so t$at *ou can easil* identif* eac$ one.
16
Process Area Name Maturity Level Process Area Category
Purpose Statement
Introductory Notes
Figure 2.2: ample !age from Decision "nalysis and #esolution
18
Specific "oal
Specific Practice
Example or! Product
Example #ox
Reference
Subpractice
Figure 2.$: ample !age from Causal "nalysis and #esolution
1<
"eneric "oal "eneric Practice
"eneric Practice Elaboration
Figure 2.%: ample !age from the &eneric &oals and &eneric !ractices
13
20
3 T1" ! It A&& To!et-er
<o' t$at *ou $ave )een introduced to t$e components of CMMI models, *ou need to understand $o' t$e* fit to+et$er to meet *our process improvement needs. T$is c$apter introduces t$e concept of levels and s$o's $o' t$e process areas are or+ani-ed and used. CMMI-DEV does not specif* t$at a pro4ect or or+ani-ation must follo' a particular process flo' or t$at a certain num)er of products )e developed per da* or specific performance tar+ets )e ac$ieved. T$e model does specif* t$at a pro4ect or or+ani-ation s$ould $ave processes t$at address development related practices. To determine '$et$er t$ese processes are in place, a pro4ect or or+ani-ation maps its processes to t$e process areas in t$is model. T$e mappin+ of processes to process areas ena)les t$e or+ani-ation to trac2 its pro+ress a+ainst t$e CMMI-DEV model as it updates or creates processes. Do not e5pect t$at ever* CMMI-DEV process area 'ill map one to one 'it$ *our or+ani-ation;s or pro4ect;s processes.
Understanding +e els
Aevels are used in CMMI-DEV to descri)e an evolutionar* pat$ recommended for an or+ani-ation t$at 'ants to improve t$e processes it uses to develop products or services. Aevels can also )e t$e outcome of t$e ratin+ activit* in appraisals.= 0ppraisals can appl* to entire or+ani-ations or to smaller +roups suc$ as a +roup of pro4ects or a division. CMMI supports t'o improvement pat$s usin+ levels. 7ne pat$ ena)les or+ani-ations to incrementall* improve processes correspondin+ to an individual process area (or +roup of process areas, selected )* t$e or+ani-ation. T$e ot$er pat$ ena)les or+ani-ations to improve a set of related processes )* incrementall* addressin+ successive sets of process areas. T$ese t'o improvement pat$s are associated 'it$ t$e t'o t*pes of levels% capa)ilit* levels and maturit* levels. T$ese levels correspond to t'o approac$es to process improvement called Lrepresentations.M T$e t'o representations are called LcontinuousM and Lsta+ed.M :sin+ t$e continuous representation ena)les *ou to ac$ieve Lcapa)ilit* levels.M :sin+ t$e sta+ed representation ena)les *ou to ac$ieve Lmaturit* levels.M
1or more information a)out appraisals, refer to 0ppraisal !e/uirements for CMMI and t$e tandard CMMI 0ppraisal Met$od for Process Improvement Met$od Definition Document > EI "#11a, EI "#11)?.
T1" ! It A&& To!et-er
21
To reac$ a particular level, an or+ani-ation must satisf* all of t$e +oals of t$e process area or set of process areas t$at are tar+eted for improvement, re+ardless of '$et$er it is a capa)ilit* or a maturit* level. .ot$ representations provide 'a*s to improve *our processes to ac$ieve )usiness o)4ectives, and )ot$ provide t$e same essential content and use t$e same model components.
)tructures of the !ontinuous and )taged Representations
1i+ure 3.1 illustrates t$e structures of t$e continuous and sta+ed representations. T$e differences )et'een t$e structures are su)tle )ut si+nificant. T$e sta+ed representation uses maturit* levels to c$aracteri-e t$e overall state of t$e or+ani-ation;s processes relative to t$e model as a '$ole, '$ereas t$e continuous representation uses capa)ilit* levels to c$aracteri-e t$e state of t$e or+ani-ation;s processes relative to an individual process area.
Continuous !epresentation
Pro#e$$ Area$
S'e#"f"# 7oa&$
7e er"# 7oa&$
Ca'ab"&"t1 Leve&$
S'e#"f"# Pra#t"#e$
7e er"# Pra#t"#e$
ta+ed !epresentation
Mat/r"t1 Leve&$ Pro#e$$ Area$
S'e#"f"# 7oa&$
7e er"# 7oa&$
S'e#"f"# Pra#t"#e$
7e er"# Pra#t"#e$
Figure $.1: tructure of the Continuous and taged #epresentations
22
6$at ma* stri2e *ou as *ou compare t$ese t'o representations is t$eir similarit*. .ot$ $ave man* of t$e same components (e.+., process areas, specific +oals, specific practices,, and t$ese components $ave t$e same $ierarc$* and confi+uration. 6$at is not readil* apparent from t$e $i+$-level vie' in 1i+ure 3.1 is t$at t$e continuous representation focuses on process area capa)ilit* as measured )* capa)ilit* levels and t$e sta+ed representation focuses on overall maturit* as measured )* maturit* levels. T$is dimension (t$e capa)ilit*&maturit* dimension, of CMMI is used for )enc$mar2in+ and appraisal activities, as 'ell as +uidin+ an or+ani-ation;s improvement efforts. Capa)ilit* levels appl* to an or+ani-ation;s process improvement ac$ievement in individual process areas. T$ese levels are a means for incrementall* improvin+ t$e processes correspondin+ to a +iven process area. T$e four capa)ilit* levels are num)ered # t$rou+$ 3. Maturit* levels appl* to an or+ani-ation;s process improvement ac$ievement across multiple process areas. T$ese levels are a means of improvin+ t$e processes correspondin+ to a +iven set of process areas (i.e., maturit* level,. T$e five maturit* levels are num)ered 1 t$rou+$ 9. Ta)le 3.1 compares t$e four capa)ilit* levels to t$e five maturit* levels. <otice t$at t$e names of t'o of t$e levels are t$e same in )ot$ representations (i.e., Mana+ed and Defined,. T$e differences are t$at t$ere is no maturit* level #I t$ere are no capa)ilit* levels 8 and 9I and at level 1, t$e names used for capa)ilit* level 1 and maturit* level 1 are different.
Ta'le $.1 Comparison of Capa'ility and Maturity (e)els !evel Continuous "epresentation Capability !evels Incomplete Performed Mana+ed Defined Initial Mana+ed Defined Buantitativel* Mana+ed 7ptimi-in+ Staged "epresentation Maturity !evels
Aevel # Aevel 1 Aevel " Aevel 3 Aevel 8 Aevel 9
T$e continuous representation is concerned 'it$ selectin+ )ot$ a particular process area to improve and t$e desired capa)ilit* level for t$at process area. In t$is conte5t, '$et$er a process is performed or incomplete is important. T$erefore, t$e name LIncompleteM is +iven to t$e continuous representation startin+ point.
23
T$e sta+ed representation is concerned 'it$ selectin+ multiple process areas to improve 'it$in a maturit* levelI '$et$er individual processes are performed or incomplete is not t$e primar* focus. T$erefore, t$e name LInitialM is +iven to t$e sta+ed representation startin+ point. .ot$ capa)ilit* levels and maturit* levels provide a 'a* to improve t$e processes of an or+ani-ation and measure $o' 'ell or+ani-ations can and do improve t$eir processes. @o'ever, t$e associated approac$ to process improvement is different.
Understanding !apabilit" +e els
To support t$ose '$o use t$e continuous representation, all CMMI models reflect capa)ilit* levels in t$eir desi+n and content. T$e four capa)ilit* levels, eac$ a la*er in t$e foundation for on+oin+ process improvement, are desi+nated )* t$e num)ers # t$rou+$ 3% #. 1. ". 3. Incomplete Performed Mana+ed Defined
0 capa)ilit* level for a process area is ac$ieved '$en all of t$e +eneric +oals are satisfied up to t$at level. T$e fact t$at capa)ilit* levels " and 3 use t$e same terms as +eneric +oals " and 3 is intentional )ecause eac$ of t$ese +eneric +oals and practices reflects t$e meanin+ of t$e capa)ilit* levels of t$e +oals and practices. ( ee t$e 3eneric 3oals and 3eneric Practices section in Part T'o for more information a)out +eneric +oals and practices., 0 s$ort description of eac$ capa)ilit* level follo's.
Ca'ab"&"t1 Leve& 02 I #om'&ete
0n incomplete process is a process t$at eit$er is not performed or is partiall* performed. 7ne or more of t$e specific +oals of t$e process area are not satisfied and no +eneric +oals e5ist for t$is level since t$ere is no reason to institutionali-e a partiall* performed process.
Ca'ab"&"t1 Leve& 12 Performe+
0 capa)ilit* level 1 process is c$aracteri-ed as a performed process. 0 performed process is a process t$at accomplis$es t$e needed 'or2 to produce 'or2 productsI t$e specific +oals of t$e process area are satisfied. 0lt$ou+$ capa)ilit* level 1 results in important improvements, t$ose improvements can )e lost over time if t$e* are not institutionali-ed. T$e application of institutionali-ation (t$e CMMI +eneric practices at capa)ilit* levels " and 3, $elps to ensure t$at improvements are maintained.
24
Ca'ab"&"t1 Leve& 22 Ma a!e+
0 capa)ilit* level " process is c$aracteri-ed as a managed process. 0 mana+ed process is a performed process t$at is planned and e5ecuted in accordance 'it$ polic*I emplo*s s2illed people $avin+ ade/uate resources to produce controlled outputsI involves relevant sta2e$oldersI is monitored, controlled, and revie'edI and is evaluated for ad$erence to its process description. T$e process discipline reflected )* capa)ilit* level " $elps to ensure t$at e5istin+ practices are retained durin+ times of stress.
Ca'ab"&"t1 Leve& 32 %ef" e+
0 capa)ilit* level 3 process is c$aracteri-ed as a defined process. 0 defined process is a mana+ed process t$at is tailored from t$e or+ani-ation;s set of standard processes accordin+ to t$e or+ani-ation;s tailorin+ +uidelinesI $as a maintained process descriptionI and contri)utes process related e5periences to t$e or+ani-ational process assets. 0 critical distinction )et'een capa)ilit* levels " and 3 is t$e scope of standards, process descriptions, and procedures. 0t capa)ilit* level ", t$e standards, process descriptions, and procedures can )e /uite different in eac$ specific instance of t$e process (e.+., on a particular pro4ect,. 0t capa)ilit* level 3, t$e standards, process descriptions, and procedures for a pro4ect are tailored from t$e or+ani-ation;s set of standard processes to suit a particular pro4ect or or+ani-ational unit and t$erefore are more consistent, e5cept for t$e differences allo'ed )* t$e tailorin+ +uidelines. 0not$er critical distinction is t$at at capa)ilit* level 3 processes are t*picall* descri)ed more ri+orousl* t$an at capa)ilit* level ". 0 defined process clearl* states t$e purpose, inputs, entr* criteria, activities, roles, measures, verification steps, outputs, and e5it criteria. 0t capa)ilit* level 3, processes are mana+ed more proactivel* usin+ an understandin+ of t$e interrelations$ips of t$e process activities and detailed measures of t$e process and its 'or2 products.
A+va #" ! T-ro/!- Ca'ab"&"t1 Leve&$
T$e capa)ilit* levels of a process area are ac$ieved t$rou+$ t$e application of +eneric practices or suita)le alternatives to t$e processes associated 'it$ t$at process area. !eac$in+ capa)ilit* level 1 for a process area is e/uivalent to sa*in+ t$at t$e processes associated 'it$ t$at process area are performed processes. !eac$in+ capa)ilit* level " for a process area is e/uivalent to sa*in+ t$at t$ere is a polic* t$at indicates *ou 'ill perform t$e process. T$ere is a plan for performin+ it, resources are provided, responsi)ilities are assi+ned, trainin+ to perform it is provided, selected 'or2 products related to performin+ t$e process are controlled, and so on. In ot$er 'ords, a capa)ilit* level " process can )e planned and monitored 4ust li2e an* pro4ect or support activit*.
25
!eac$in+ capa)ilit* level 3 for a process area is e/uivalent to sa*in+ t$at an or+ani-ational standard process e5ists associated 'it$ t$at process area, '$ic$ can )e tailored to t$e needs of t$e pro4ect. T$e processes in t$e or+ani-ation are no' more consistentl* defined and applied )ecause t$e* are )ased on or+ani-ational standard processes. 0fter an or+ani-ation $as reac$ed capa)ilit* level 3 in t$e process areas it $as selected for improvement, it can continue its improvement 4ourne* )* addressin+ $i+$ maturit* process areas (7r+ani-ational Process Performance, Buantitative Pro4ect Mana+ement, Causal 0nal*sis and !esolution, and 7r+ani-ational Performance Mana+ement,. T$e $i+$ maturit* process areas focus on improvin+ t$e performance of t$ose processes alread* implemented. T$e $i+$ maturit* process areas descri)e t$e use of statistical and ot$er /uantitative tec$ni/ues to improve or+ani-ational and pro4ect processes to )etter ac$ieve )usiness o)4ectives. 6$en continuin+ its improvement 4ourne* in t$is 'a*, an or+ani-ation can derive t$e most )enefit )* first selectin+ t$e 7PP and BPM process areas, and )rin+in+ t$ose process areas to capa)ilit* levels 1, ", and 3. In doin+ so, pro4ects and or+ani-ations ali+n t$e selection and anal*ses of processes more closel* 'it$ t$eir )usiness o)4ectives. 0fter t$e or+ani-ation attains capa)ilit* level 3 in t$e 7PP and BPM process areas, t$e or+ani-ation can continue its improvement pat$ )* selectin+ t$e C0! and 7PM process areas. In doin+ so, t$e or+ani-ation anal*-es t$e )usiness performance usin+ statistical and ot$er /uantitative tec$ni/ues to determine performance s$ortfalls, and identifies and deplo*s process and tec$nolo+* improvements t$at contri)ute to meetin+ /ualit* and process performance o)4ectives. Pro4ects and t$e or+ani-ation use causal anal*sis to identif* and resolve issues affectin+ performance and promote t$e dissemination of )est practices.
Understanding #aturit" +e els
To support t$ose '$o use t$e sta+ed representation, all CMMI models reflect maturit* levels in t$eir desi+n and content. 0 maturit* level consists of related specific and +eneric practices for a predefined set of process areas t$at improve t$e or+ani-ation;s overall performance. T$e maturit* level of an or+ani-ation provides a 'a* to c$aracteri-e its performance. E5perience $as s$o'n t$at or+ani-ations do t$eir )est '$en t$e* focus t$eir process improvement efforts on a mana+ea)le num)er of process areas at a time and t$at t$ose areas re/uire increasin+ sop$istication as t$e or+ani-ation improves. 0 maturit* level is a defined evolutionar* plateau for or+ani-ational process improvement. Eac$ maturit* level matures an important su)set of t$e or+ani-ation;s processes, preparin+ it to move to t$e ne5t maturit* level. T$e maturit* levels are measured )* t$e ac$ievement of t$e specific and +eneric +oals associated 'it$ eac$ predefined set of process areas.
26
T$e five maturit* levels, eac$ a la*er in t$e foundation for on+oin+ process improvement, are desi+nated )* t$e num)ers 1 t$rou+$ 9% 1. ". 3. 8. 9. Initial Mana+ed Defined Buantitativel* Mana+ed 7ptimi-in+
!emem)er t$at maturit* levels " and 3 use t$e same terms as capa)ilit* levels " and 3. T$is consistenc* of terminolo+* 'as intentional )ecause t$e concepts of maturit* levels and capa)ilit* levels are complementar*. Maturit* levels are used to c$aracteri-e or+ani-ational improvement relative to a set of process areas, and capa)ilit* levels c$aracteri-e or+ani-ational improvement relative to an individual process area.
Mat/r"t1 Leve& 12 I "t"a&
0t maturit* level 1, processes are usuall* ad $oc and c$aotic. T$e or+ani-ation usuall* does not provide a sta)le environment to support processes. uccess in t$ese or+ani-ations depends on t$e competence and $eroics of t$e people in t$e or+ani-ation and not on t$e use of proven processes. In spite of t$is c$aos, maturit* level 1 or+ani-ations often produce products and services t$at 'or2, )ut t$e* fre/uentl* e5ceed t$e )ud+et and sc$edule documented in t$eir plans. Maturit* level 1 or+ani-ations are c$aracteri-ed )* a tendenc* to overcommit, a)andon t$eir processes in a time of crisis, and )e una)le to repeat t$eir successes.
Mat/r"t1 Leve& 22 Ma a!e+
0t maturit* level ", t$e pro4ects $ave ensured t$at processes are planned and e5ecuted in accordance 'it$ polic*I t$e pro4ects emplo* s2illed people '$o $ave ade/uate resources to produce controlled outputsI involve relevant sta2e$oldersI are monitored, controlled, and revie'edI and are evaluated for ad$erence to t$eir process descriptions. T$e process discipline reflected )* maturit* level " $elps to ensure t$at e5istin+ practices are retained durin+ times of stress. 6$en t$ese practices are in place, pro4ects are performed and mana+ed accordin+ to t$eir documented plans. 0lso at maturit* level ", t$e status of t$e 'or2 products are visi)le to mana+ement at defined points (e.+., at ma4or milestones, at t$e completion of ma4or tas2s,. Commitments are esta)lis$ed amon+ relevant sta2e$olders and are revised as needed. 6or2 products are appropriatel* controlled. T$e 'or2 products and services satisf* t$eir specified process descriptions, standards, and procedures.
28
Mat/r"t1 Leve& 32 %ef" e+
0t maturit* level 3, processes are 'ell c$aracteri-ed and understood, and are descri)ed in standards, procedures, tools, and met$ods. T$e or+ani-ation;s set of standard processes, '$ic$ is t$e )asis for maturit* level 3, is esta)lis$ed and improved over time. T$ese standard processes are used to esta)lis$ consistenc* across t$e or+ani-ation. Pro4ects esta)lis$ t$eir defined processes )* tailorin+ t$e or+ani-ation;s set of standard processes accordin+ to tailorin+ +uidelines. ( ee t$e definition of Lor+ani-ation;s set of standard processesM in t$e +lossar*., 0 critical distinction )et'een maturit* levels " and 3 is t$e scope of standards, process descriptions, and procedures. 0t maturit* level ", t$e standards, process descriptions, and procedures can )e /uite different in eac$ specific instance of t$e process (e.+., on a particular pro4ect,. 0t maturit* level 3, t$e standards, process descriptions, and procedures for a pro4ect are tailored from t$e or+ani-ation;s set of standard processes to suit a particular pro4ect or or+ani-ational unit and t$erefore are more consistent e5cept for t$e differences allo'ed )* t$e tailorin+ +uidelines. 0not$er critical distinction is t$at at maturit* level 3, processes are t*picall* descri)ed more ri+orousl* t$an at maturit* level ". 0 defined process clearl* states t$e purpose, inputs, entr* criteria, activities, roles, measures, verification steps, outputs, and e5it criteria. 0t maturit* level 3, processes are mana+ed more proactivel* usin+ an understandin+ of t$e interrelations$ips of process activities and detailed measures of t$e process, its 'or2 products, and its services. 0t maturit* level 3, t$e or+ani-ation furt$er improves its processes t$at are related to t$e maturit* level " process areas. 3eneric practices associated 'it$ +eneric +oal 3 t$at 'ere not addressed at maturit* level " are applied to ac$ieve maturit* level 3.
Mat/r"t1 Leve& 42 @/a t"tat"ve&1 Ma a!e+
0t maturit* level 8, t$e or+ani-ation and pro4ects esta)lis$ /uantitative o)4ectives for /ualit* and process performance and use t$em as criteria in mana+in+ pro4ects. Buantitative o)4ectives are )ased on t$e needs of t$e customer, end users, or+ani-ation, and process implementers. Bualit* and process performance is understood in statistical terms and is mana+ed t$rou+$out t$e life of pro4ects. 1or selected su)processes, specific measures of process performance are collected and statisticall* anal*-ed. 6$en selectin+ su)processes for anal*ses, it is critical to understand t$e relations$ips )et'een different su)processes and t$eir impact on ac$ievin+ t$e o)4ectives for /ualit* and process performance. uc$ an approac$ $elps to ensure t$at su)process monitorin+ usin+ statistical and ot$er /uantitative tec$ni/ues is applied to '$ere it $as t$e most overall value to t$e )usiness. Process performance )aselines and models can )e used to $elp set /ualit* and process performance o)4ectives t$at $elp ac$ieve )usiness o)4ectives.
2<
0 critical distinction )et'een maturit* levels 3 and 8 is t$e predicta)ilit* of process performance. 0t maturit* level 8, t$e performance of pro4ects and selected su)processes is controlled usin+ statistical and ot$er /uantitative tec$ni/ues, and predictions are )ased, in part, on a statistical anal*sis of fine-+rained process data.
Mat/r"t1 Leve& 52 O't"m"A" !
0t maturit* level 9, an or+ani-ation continuall* improves its processes )ased on a /uantitative understandin+ of its )usiness o)4ectives and performance needs. T$e or+ani-ation uses a /uantitative approac$ to understand t$e variation in$erent in t$e process and t$e causes of process outcomes. Maturit* level 9 focuses on continuall* improvin+ process performance t$rou+$ incremental and innovative process and tec$nolo+ical improvements. T$e or+ani-ation;s /ualit* and process performance o)4ectives are esta)lis$ed, continuall* revised to reflect c$an+in+ )usiness o)4ectives and or+ani-ational performance, and used as criteria in mana+in+ process improvement. T$e effects of deplo*ed process improvements are measured usin+ statistical and ot$er /uantitative tec$ni/ues and compared to /ualit* and process performance o)4ectives. T$e pro4ect;s defined processes, t$e or+ani-ation;s set of standard processes, and supportin+ tec$nolo+* are tar+ets of measura)le improvement activities. 0 critical distinction )et'een maturit* levels 8 and 9 is t$e focus on mana+in+ and improvin+ or+ani-ational performance. 0t maturit* level 8, t$e or+ani-ation and pro4ects focus on understandin+ and controllin+ performance at t$e su)process level and usin+ t$e results to mana+e pro4ects. 0t maturit* level 9, t$e or+ani-ation is concerned 'it$ overall or+ani-ational performance usin+ data collected from multiple pro4ects. 0nal*sis of t$e data identifies s$ortfalls or +aps in performance. T$ese +aps are used to drive or+ani-ational process improvement t$at +enerates measurea)le improvement in performance.
A+va #" ! T-ro/!- Mat/r"t1 Leve&$
7r+ani-ations can ac$ieve pro+ressive improvements in t$eir maturit* )* ac$ievin+ control first at t$e pro4ect level and continuin+ to t$e most advanced levelCor+ani-ation-'ide performance mana+ement and continuous process improvementCusin+ )ot$ /ualitative and /uantitative data to ma2e decisions. ince improved or+ani-ational maturit* is associated 'it$ improvement in t$e ran+e of e5pected results t$at can )e ac$ieved )* an or+ani-ation, maturit* is one 'a* of predictin+ +eneral outcomes of t$e or+ani-ation;s ne5t pro4ect. 1or instance, at maturit* level ", t$e or+ani-ation $as )een elevated from ad $oc to disciplined )* esta)lis$in+ sound pro4ect mana+ement. 0s t$e or+ani-ation ac$ieves +eneric and specific +oals for t$e set of process areas in a maturit* level, it increases its or+ani-ational maturit* and reaps t$e )enefits of process improvement. .ecause eac$
23
maturit* level forms a necessar* foundation for t$e ne5t level, tr*in+ to s2ip maturit* levels is usuall* counterproductive. 0t t$e same time, reco+ni-e t$at process improvement efforts s$ould focus on t$e needs of t$e or+ani-ation in t$e conte5t of its )usiness environment and t$at process areas at $i+$er maturit* levels can address t$e current and future needs of an or+ani-ation or pro4ect. 1or e5ample, or+ani-ations see2in+ to move from maturit* level 1 to maturit* level " are fre/uentl* encoura+ed to esta)lis$ a process +roup, '$ic$ is addressed )* t$e 7r+ani-ational Process 1ocus process area at maturit* level 3. 0lt$ou+$ a process +roup is not a necessar* c$aracteristic of a maturit* level " or+ani-ation, it can )e a useful part of t$e or+ani-ation;s approac$ to ac$ievin+ maturit* level ". T$is situation is sometimes c$aracteri-ed as esta)lis$in+ a maturit* level 1 process +roup to )ootstrap t$e maturit* level 1 or+ani-ation to maturit* level ". Maturit* level 1 process improvement activities ma* depend primaril* on t$e insi+$t and competence of t$e process +roup until an infrastructure to support more disciplined and 'idespread improvement is in place. 7r+ani-ations can institute process improvements an*time t$e* c$oose, even )efore t$e* are prepared to advance to t$e maturit* level at '$ic$ t$e specific practice is recommended. In suc$ situations, $o'ever, or+ani-ations s$ould understand t$at t$e success of t$ese improvements is at ris2 )ecause t$e foundation for t$eir successful institutionali-ation $as not )een completed. Processes 'it$out t$e proper foundation can fail at t$e point t$e* are needed mostCunder stress. 0 defined process t$at is c$aracteristic of a maturit* level 3 or+ani-ation can )e placed at +reat ris2 if maturit* level " mana+ement practices are deficient. 1or e5ample, mana+ement ma* commit to a poorl* planned sc$edule or fail to control c$an+es to )aselined re/uirements. imilarl*, man* or+ani-ations prematurel* collect t$e detailed data c$aracteristic of maturit* level 8 onl* to find t$e data uninterpreta)le )ecause of inconsistencies in processes and measurement definitions. 0not$er e5ample of usin+ processes associated 'it$ $i+$er maturit* level process areas is in t$e )uildin+ of products. Certainl*, 'e 'ould e5pect maturit* level 1 or+ani-ations to perform re/uirements anal*sis, desi+n, product inte+ration, and verification. @o'ever, t$ese activities are not descri)ed until maturit* level 3, '$ere t$e* are defined as co$erent, 'ellinte+rated en+ineerin+ processes. T$e maturit* level 3 en+ineerin+ process complements a maturin+ pro4ect mana+ement capa)ilit* put in place so t$at t$e en+ineerin+ improvements are not lost )* an ad $oc mana+ement process.
Process Areas
Process areas are vie'ed differentl* in t$e t'o representations. 1i+ure 3." compares vie's of $o' process areas are used in t$e continuous representation and t$e sta+ed representation.
30
Co t " /o/$
Tar+et Profile
Process 0rea 1
Process 0rea "
Process 0rea 3
Process 0rea 8
a 0 s o r P d t c l e
Process 0rea < CA1 CA" CA3
Tar+eted Capa)ilit* Aevels
Sta!e+
elected Maturit* Aevel
Mat/r"t1 Leve& 5 Mat/r"t1 Leve& 4 Mat/r"t1 Leve& 3 Mat/r"t1 Leve& 2
SAM RE@M PP@A PP PMC MA CM
= roups of process areas chosen for process improvement to achieve maturity level !
Figure $.2: !rocess "reas in the Continuous and taged #epresentations
T$e continuous representation ena)les t$e or+ani-ation to c$oose t$e focus of its process improvement efforts )* c$oosin+ t$ose process areas, or sets of interrelated process areas, t$at )est )enefit t$e or+ani-ation and its )usiness o)4ectives. 0lt$ou+$ t$ere are some limits on '$at an or+ani-ation can c$oose )ecause of t$e dependencies amon+ process areas, t$e or+ani-ation $as considera)le freedom in its selection.
31
To support t$ose '$o use t$e continuous representation, process areas are or+ani-ed into four cate+ories% Process Mana+ement, Pro4ect Mana+ement, En+ineerin+, and upport. T$ese cate+ories emp$asi-e some of t$e 2e* relations$ips t$at e5ist amon+ t$e process areas. ometimes an informal +roupin+ of process areas is mentioned% $i+$ maturit* process areas. T$e four $i+$ maturit* process areas are% 7r+ani-ational Process Performance, Buantitative Pro4ect Mana+ement, 7r+ani-ational Performance Mana+ement, and Causal 0nal*sis and !esolution. T$ese process areas focus on improvin+ t$e performance of implemented processes t$at most closel* relate to t$e or+ani-ation;s )usiness o)4ectives. 7nce *ou select process areas, *ou must also select $o' muc$ *ou 'ould li2e to mature processes associated 'it$ t$ose process areas (i.e., select t$e appropriate capa)ilit* level,. Capa)ilit* levels and +eneric +oals and practices support t$e improvement of processes associated 'it$ individual process areas. 1or e5ample, an or+ani-ation ma* 'is$ to reac$ capa)ilit* level " in one process area and capa)ilit* level 3 in anot$er. 0s t$e or+ani-ation reac$es a capa)ilit* level, it sets its si+$ts on t$e ne5t capa)ilit* level for one of t$ese same process areas or decides to 'iden its vie' and address a lar+er num)er of process areas. 7nce it reac$es capa)ilit* level 3 in most of t$e process areas, t$e or+ani-ation can s$ift its attention to t$e $i+$ maturit* process areas and can trac2 t$e capa)ilit* of eac$ t$rou+$ capa)ilit* level 3. T$e selection of a com)ination of process areas and capa)ilit* levels is t*picall* descri)ed in a Ltar+et profile.M 0 tar+et profile defines all of t$e process areas to )e addressed and t$e tar+eted capa)ilit* level for eac$. T$is profile +overns '$ic$ +oals and practices t$e or+ani-ation 'ill address in its process improvement efforts. Most or+ani-ations, at minimum, tar+et capa)ilit* level 1 for t$e process areas t$e* select, '$ic$ re/uires t$at all of t$ese process areas; specific +oals )e ac$ieved. @o'ever, or+ani-ations t$at tar+et capa)ilit* levels $i+$er t$an 1 concentrate on t$e institutionali-ation of selected processes in t$e or+ani-ation )* implementin+ +eneric +oals and practices. T$e sta+ed representation provides a pat$ of improvement from maturit* level 1 to maturit* level 9 t$at involves ac$ievin+ t$e +oals of t$e process areas at eac$ maturit* level. To support t$ose '$o use t$e sta+ed representation, process areas are +rouped )* maturit* level, indicatin+ '$ic$ process areas to implement to ac$ieve eac$ maturit* level. 1or e5ample, at maturit* level ", t$ere is a set of process areas t$at an or+ani-ation 'ould use to +uide its process improvement until it could ac$ieve all t$e +oals of all t$ese process areas. 7nce maturit* level " is ac$ieved, t$e or+ani-ation focuses its efforts on maturit* level 3 process areas, and so on. T$e +eneric +oals t$at appl* to eac$ process area are also predetermined. 3eneric +oal " applies to maturit* level " and +eneric +oal 3 applies to maturit* levels 3 t$rou+$ 9.
32
Ta)le 3." provides a list of CMMI-DEV process areas and t$eir associated cate+ories and maturit* levels.
Ta'le $.2 !rocess "reas* Categories* and Maturity (e)els !rocess "rea Causal 0nal*sis and !esolution (C0!, Confi+uration Mana+ement (CM, Decision 0nal*sis and !esolution (D0!, Inte+rated Pro4ect Mana+ement (IPM, Measurement and 0nal*sis (M0, 7r+ani-ational Process Definition (7PD, 7r+ani-ational Process 1ocus (7P1, 7r+ani-ational Performance Mana+ement (7PM, 7r+ani-ational Process Performance (7PP, 7r+ani-ational Trainin+ (7T, Product Inte+ration (PI, Pro4ect Monitorin+ and Control (PMC, Pro4ect Plannin+ (PP, Process and Product Bualit* 0ssurance (PPB0, Buantitative Pro4ect Mana+ement (BPM, !e/uirements Development (!D, !e/uirements Mana+ement (!EBM, !is2 Mana+ement (! NM, upplier 0+reement Mana+ement ( 0M, Category upport upport upport Pro4ect Mana+ement upport Process Mana+ement Process Mana+ement Process Mana+ement Process Mana+ement Process Mana+ement En+ineerin+ Pro4ect Mana+ement Pro4ect Mana+ement upport Pro4ect Mana+ement En+ineerin+ Pro4ect Mana+ement Pro4ect Mana+ement Pro4ect Mana+ement Maturity (e)el 9 " 3 3 " 3 3 9 8 3 3 " " " 8 3 " 3 "
33
Tec$nical olution (T , Validation (V0A, Verification (VE!,
En+ineerin+ En+ineerin+ En+ineerin+
3 3 3
$%ui alent )taging
E/uivalent sta+in+ is a 'a* to compare results from usin+ t$e continuous representation to results from usin+ t$e sta+ed representation. In essence, if *ou measure improvement relative to selected process areas usin+ capa)ilit* levels in t$e continuous representation, $o' do *ou translate t$at 'or2 into maturit* levelsJ Is t$is translation possi)leJ :p to t$is point, 'e $ave not discussed process appraisals in muc$ detail. T$e C0MPI M met$odH is used to appraise or+ani-ations usin+ CMMI, and one result of an appraisal is a ratin+ > EI "#11a, 0$ern "##9?. If t$e continuous representation is used for an appraisal, t$e ratin+ is a Lcapa)ilit* level profile.M If t$e sta+ed representation is used for an appraisal, t$e ratin+ is a Lmaturit* level ratin+M (e.+., maturit* level 3,. 0 capa)ilit* level profile is a list of process areas and t$e correspondin+ capa)ilit* level ac$ieved for eac$. T$is profile ena)les an or+ani-ation to trac2 its capa)ilit* level )* process area. T$e profile is called an Lac$ievement profileM '$en it represents t$e or+ani-ation;s actual pro+ress for eac$ process area. 0lternativel*, t$e profile is called a Ltar+et profileM '$en it represents t$e or+ani-ation;s planned process improvement o)4ectives. 1i+ure 3.3 illustrates a com)ined tar+et and ac$ievement profile. T$e +ra* portion of eac$ )ar represents '$at $as )een ac$ieved. T$e uns$aded portion represents '$at remains to )e accomplis$ed to meet t$e tar+et profile.
T$e tandard CMMI 0ppraisal Met$od for Process Improvement ( C0MPI, met$od is descri)ed in C$apter 9.
34
!e/uirements Mana+ement
Pro4ect Plannin+ Pro4ect Monitorin+ and Control
upplier 0+reement Mana+ement Measurement and 0nal*sis Process and Product Bualit* 0ssurance Confi+uration Mana+ement
Capa)ilit* Aevel 1
Capa)ilit* Aevel "
Capa)ilit* Aevel 3
Figure $.$: +,ample Com'ined Target and "chie)ement !rofile
0n ac$ievement profile, '$en compared 'it$ a tar+et profile, ena)les an or+ani-ation to plan and trac2 its pro+ress for eac$ selected process area. Maintainin+ capa)ilit* level profiles is advisa)le '$en usin+ t$e continuous representation. Tar+et sta+in+ is a se/uence of tar+et profiles t$at descri)es t$e pat$ of process improvement to )e follo'ed )* t$e or+ani-ation. 6$en )uildin+ tar+et profiles, t$e or+ani-ation s$ould pa* attention to t$e dependencies )et'een +eneric practices and process areas. If a +eneric practice depends on a process area, eit$er to carr* out t$e +eneric practice or to provide a prere/uisite 'or2 product, t$e +eneric practice can )e muc$ less effective '$en t$e process area is not implemented. F 0lt$ou+$ t$e reasons to use t$e continuous representation are man*, ratin+s consistin+ of capa)ilit* level profiles are limited in t$eir a)ilit* to provide or+ani-ations 'it$ a 'a* to +enerall* compare t$emselves 'it$ ot$er or+ani-ations. Capa)ilit* level profiles can )e used if eac$ or+ani-ation selects t$e same process areasI $o'ever, maturit* levels $ave )een used to compare or+ani-ations for *ears and alread* provide predefined sets of process areas. .ecause of t$is situation, e/uivalent sta+in+ 'as created. E/uivalent sta+in+ ena)les an or+ani-ation usin+ t$e continuous representation to convert a capa)ilit* level profile to t$e associated maturit* level ratin+. T$e most effective 'a* to depict e/uivalent sta+in+ is to provide a se/uence of tar+et profiles, eac$ of '$ic$ is e/uivalent to a maturit* level
F
ee Ta)le G." in t$e 3eneric 3oals and 3eneric Practices section of Part T'o for more information a)out t$e dependencies )et'een +eneric practices and process areas.
35
ratin+ of t$e sta+ed representation reflected in t$e process areas listed in t$e tar+et profile. T$e result is a tar+et sta+in+ t$at is e/uivalent to t$e maturit* levels of t$e sta+ed representation. 1i+ure 3.8 s$o's a summar* of t$e tar+et profiles t$at must )e ac$ieved '$en usin+ t$e continuous representation to )e e/uivalent to maturit* levels " t$rou+$ 9. Eac$ s$aded area in t$e capa)ilit* level columns represents a tar+et profile t$at is e/uivalent to a maturit* level.
#ame Confi+uration Mana+ement Measurement and 0nal*sis Pro4ect Monitorin+ and Control Pro4ect Plannin+ Process and Product Bualit* 0ssurance !e/uirements Mana+ement upplier 0+reement Mana+ement Decision 0nal*sis and !esolution Inte+rated Pro4ect Mana+ement 7r+ani-ational Process Definition 7r+ani-ational Process 1ocus 7r+ani-ational Trainin+ Product Inte+ration !e/uirements Development !is2 Mana+ement Tec$nical olution Validation Verification 7r+ani-ational Process Performance Buantitative Pro4ect Mana+ement Causal 0nal*sis and !esolution 7r+ani-ational Performance Mana+ement $bbr% CM M0 PMC PP PPB0 !EBM 0M D0! IPM 7PD 7P1 7T PI !D ! NM T V0A VE! 7PP BPM C0! 7PM M! " " " " " " " 3 3 3 3 3 3 3 3 3 3 3 8 8 9 9 C! & C!' C!(
Tar!et Prof"&e 2
Tar!et Prof"&e 3
Tar!et Prof"&e 4 Tar!et Prof"&e 5
Figure $.%: Target !rofiles and +-ui)alent taging
T$e follo'in+ rules summari-e e/uivalent sta+in+% To ac$ieve maturit* level ", all process areas assi+ned to maturit* level " must ac$ieve capa)ilit* level " or 3. To ac$ieve maturit* level 3, all process areas assi+ned to maturit* levels " and 3 must ac$ieve capa)ilit* level 3. To ac$ieve maturit* level 8, all process areas assi+ned to maturit* levels ", 3, and 8 must ac$ieve capa)ilit* level 3. To ac$ieve maturit* level 9, all process areas must ac$ieve capa)ilit* level 3.
36
Achie ing High #aturit"
6$en usin+ t$e sta+ed representation, *ou attain $i+$ maturit* '$en *ou ac$ieve maturit* level 8 or 9. 0c$ievin+ maturit* level 8 involves implementin+ all process areas for maturit* levels ", 3, and 8. Ai2e'ise, ac$ievin+ maturit* level 9 involves implementin+ all process areas for maturit* levels ", 3, 8, and 9. 6$en usin+ t$e continuous representation, *ou attain $i+$ maturit* usin+ t$e e/uivalent sta+in+ concept. @i+$ maturit* t$at is e/uivalent to sta+ed maturit* level 8 usin+ e/uivalent sta+in+ is attained '$en *ou ac$ieve capa)ilit* level 3 for all process areas e5cept for 7r+ani-ational Performance Mana+ement (7PM, and Causal 0nal*sis and !esolution (C0!,. @i+$ maturit* t$at is e/uivalent to sta+ed maturit* level 9 usin+ e/uivalent sta+in+ is attained '$en *ou ac$ieve capa)ilit* level 3 for all process areas.
38
3<
4 Re&at"o $-"'$ Amo ! Pro#e$$ Area$
In t$is c$apter 'e descri)e t$e 2e* relations$ips amon+ process areas to $elp *ou see t$e or+ani-ation;s vie' of process improvement and $o' process areas depend on t$e implementation of ot$er process areas. T$e relations$ips amon+ multiple process areas, includin+ t$e information and artifacts t$at flo' from one process area to anot$erCillustrated )* t$e fi+ures and descriptions in t$is c$apterC$elp *ou to see a lar+er vie' of process implementation and improvement. uccessful process improvement initiatives must )e driven )* t$e )usiness o)4ectives of t$e or+ani-ation. 1or e5ample, a common )usiness o)4ective is to reduce t$e time it ta2es to +et a product to mar2et. T$e process improvement o)4ective derived from t$at mi+$t )e to improve t$e pro4ect mana+ement processes to ensure on-time deliver*I t$ose improvements rel* on )est practices in t$e Pro4ect Plannin+ and Pro4ect Monitorin+ and Control process areas. 0lt$ou+$ 'e +roup process areas in t$is c$apter to simplif* t$e discussion of t$eir relations$ips, process areas often interact and $ave an effect on one anot$er re+ardless of t$eir +roup, cate+or*, or level. 1or e5ample, t$e Decision 0nal*sis and !esolution process area (a upport process area at maturit* level 3, contains specific practices t$at address t$e formal evaluation process used in t$e Tec$nical olution process area for selectin+ a tec$nical solution from alternative solutions. .ein+ a'are of t$e 2e* relations$ips t$at e5ist amon+ CMMI process areas 'ill $elp *ou appl* CMMI in a useful and productive 'a*. !elations$ips amon+ process areas are descri)ed in more detail in t$e references of eac$ process area and specificall* in t$e !elated Process 0reas section of eac$ process area in Part T'o. !efer to C$apter " for more information a)out references.
Process #anagement
Process Mana+ement process areas contain t$e cross-pro4ect activities related to definin+, plannin+, deplo*in+, implementin+, monitorin+, controllin+, appraisin+, measurin+, and improvin+ processes. T$e five Process Mana+ement process areas in CMMI-DEV are as follo's% 7r+ani-ational Process Definition (7PD, 7r+ani-ational Process 1ocus (7P1, 7r+ani-ational Performance Mana+ement (7PM,
Re&at"o $-"'$ Amo ! Pro#e$$ Area$
33
7r+ani-ational Process Performance (7PP, 7r+ani-ational Trainin+ (7T,
9a$"# Pro#e$$ Ma a!eme t Pro#e$$ Area$
T$e .asic Process Mana+ement process areas provide t$e or+ani-ation 'it$ a capa)ilit* to document and s$are )est practices, or+ani-ational process assets, and learnin+ across t$e or+ani-ation. 1i+ure 8.1 provides a )ird;s-e*e vie' of t$e interactions amon+ t$e .asic Process Mana+ement process areas and 'it$ ot$er process area cate+ories. 0s illustrated in 1i+ure 8.1, t$e 7r+ani-ational Process 1ocus process area $elps t$e or+ani-ation to plan, implement, and deplo* or+ani-ational process improvements )ased on an understandin+ of t$e current stren+t$s and 'ea2nesses of t$e or+ani-ation;s processes and process assets.
Figure %.1: .asic !rocess Management !rocess "reas
Candidate improvements to t$e or+ani-ation;s processes are o)tained t$rou+$ various sources. T$ese activities include process improvement proposals, measurement of t$e processes, lessons learned in implementin+ t$e processes, and results of process appraisal and product evaluation activities.
40
T$e 7r+ani-ational Process Definition process area esta)lis$es and maintains t$e or+ani-ation;s set of standard processes, 'or2 environment standards, and ot$er assets )ased on t$e process needs and o)4ectives of t$e or+ani-ation. T$ese ot$er assets include descriptions of lifec*cle models, process tailorin+ +uidelines, and process related documentation and data. Pro4ects tailor t$e or+ani-ation;s set of standard processes to create t$eir defined processes. T$e ot$er assets support tailorin+ as 'ell as implementation of t$e defined processes. E5periences and 'or2 products from performin+ t$ese defined processes, includin+ measurement data, process descriptions, process artifacts, and lessons learned, are incorporated as appropriate into t$e or+ani-ation;s set of standard processes and ot$er assets. T$e 7r+ani-ational Trainin+ process area identifies t$e strate+ic trainin+ needs of t$e or+ani-ation as 'ell as t$e tactical trainin+ needs t$at are common across pro4ects and support +roups. In particular, trainin+ is developed or o)tained to develop t$e s2ills re/uired to perform t$e or+ani-ation;s set of standard processes. T$e main components of trainin+ include a mana+ed trainin+ development pro+ram, documented plans, staff 'it$ appropriate 2no'led+e, and mec$anisms for measurin+ t$e effectiveness of t$e trainin+ pro+ram.
A+va #e+ Pro#e$$ Ma a!eme t Pro#e$$ Area$
T$e 0dvanced Process Mana+ement process areas provide t$e or+ani-ation 'it$ an improved capa)ilit* to ac$ieve its /uantitative o)4ectives for /ualit* and process performance. 1i+ure 8." provides a )ird;s-e*e vie' of t$e interactions amon+ t$e 0dvanced Process Mana+ement process areas and 'it$ ot$er process area cate+ories. Eac$ of t$e 0dvanced Process Mana+ement process areas depends on t$e a)ilit* to develop and deplo* processes and supportin+ assets. T$e .asic Process Mana+ement process areas provide t$is a)ilit*.
41
Figure %.2: "d)anced !rocess Management !rocess "reas 0s illustrated in 1i+ure 8.", t$e 7r+ani-ational Process Performance process area derives /uantitative o)4ectives for /ualit* and process performance from t$e or+ani-ation;s )usiness o)4ectives. T$e or+ani-ation provides pro4ects and support +roups 'it$ common measures, process performance )aselines, and process performance models. T$ese additional or+ani-ational assets support composin+ a defined process t$at can ac$ieve t$e pro4ect;s /ualit* and process performance o)4ectives and support /uantitative mana+ement. T$e or+ani-ation anal*-es t$e process performance data collected from t$ese defined processes to develop a /uantitative understandin+ of product /ualit*, service /ualit*, and process performance of t$e or+ani-ation;s set of standard processes. In 7r+ani-ational Performance Mana+ement, process performance )aselines and models are anal*-ed to understand t$e or+ani-ation;s a)ilit* to meet its )usiness o)4ectives and to derive /ualit* and process performance o)4ectives. .ased on t$is understandin+, t$e or+ani-ation proactivel* selects and deplo*s incremental and innovative improvements t$at measura)l* improve t$e or+ani-ation;s performance. T$e selection of improvements to deplo* is )ased on a /uantitative understandin+ of t$e li2el* )enefits and predicted costs of deplo*in+
42
candidate improvements. T$e or+ani-ation can also ad4ust )usiness o)4ectives and /ualit* and process performance o)4ectives as appropriate.
Pro,ect #anagement
Pro4ect Mana+ement process areas cover t$e pro4ect mana+ement activities related to plannin+, monitorin+, and controllin+ t$e pro4ect. T$e seven Pro4ect Mana+ement process areas in CMMI-DEV are as follo's% Inte+rated Pro4ect Mana+ement (IPM, Pro4ect Monitorin+ and Control (PMC, Pro4ect Plannin+ (PP, Buantitative Pro4ect Mana+ement (BPM, !e/uirements Mana+ement (!EBM, !is2 Mana+ement (! NM, upplier 0+reement Mana+ement ( 0M,
9a$"# Pro0e#t Ma a!eme t Pro#e$$ Area$
T$e .asic Pro4ect Mana+ement process areas address t$e activities related to esta)lis$in+ and maintainin+ t$e pro4ect plan, esta)lis$in+ and maintainin+ commitments, monitorin+ pro+ress a+ainst t$e plan, ta2in+ corrective action, and mana+in+ supplier a+reements. 1i+ure 8.3 provides a )ird;s-e*e vie' of t$e interactions amon+ t$e .asic Pro4ect Mana+ement process areas and 'it$ ot$er process area cate+ories. 0s illustrated in 1i+ure 8.3, t$e Pro4ect Plannin+ process area includes developin+ t$e pro4ect plan, involvin+ relevant sta2e$olders, o)tainin+ commitment to t$e plan, and maintainin+ t$e plan.
43
Figure %.$: .asic !ro/ect Management !rocess "reas Plannin+ )e+ins 'it$ re/uirements t$at define t$e product and pro4ect (L6$at to .uildM in 1i+ure 8.3,. T$e pro4ect plan covers t$e various pro4ect mana+ement and development activities performed )* t$e pro4ect. T$e pro4ect revie's ot$er plans t$at affect t$e pro4ect from various relevant sta2e$olders and esta)lis$es commitments 'it$ t$ose sta2e$olders for t$eir contri)utions to t$e pro4ect. 1or e5ample, t$ese plans cover confi+uration mana+ement, verification, and measurement and anal*sis. T$e Pro4ect Monitorin+ and Control process area contains practices for monitorin+ and controllin+ activities and ta2in+ corrective action. T$e pro4ect plan specifies t$e fre/uenc* of pro+ress revie's and t$e measures used to monitor pro+ress. Pro+ress is determined primaril* )* comparin+ pro4ect status to t$e plan. 6$en t$e actual status deviates si+nificantl* from t$e e5pected values, corrective actions are ta2en as appropriate. T$ese actions can include replannin+, '$ic$ re/uires usin+ Pro4ect Plannin+ practices. T$e !e/uirements Mana+ement process area maintains t$e re/uirements. It descri)es activities for o)tainin+ and controllin+ re/uirement c$an+es and ensurin+ t$at ot$er relevant plans and data are 2ept current. It provides
44
tracea)ilit* of re/uirements from customer re/uirements to product re/uirements to product component re/uirements. !e/uirements Mana+ement ensures t$at c$an+es to re/uirements are reflected in pro4ect plans, activities, and 'or2 products. T$is c*cle of c$an+es can affect t$e En+ineerin+ process areasI t$us, re/uirements mana+ement is a d*namic and often recursive se/uence of events. T$e !e/uirements Mana+ement process area is fundamental to a controlled and disciplined en+ineerin+ process. T$e upplier 0+reement Mana+ement process area addresses t$e need of t$e pro4ect to ac/uire t$ose portions of 'or2 t$at are produced )* suppliers. ources of products t$at can )e used to satisf* pro4ect re/uirements are proactivel* identified. T$e supplier is selected, and a supplier a+reement is esta)lis$ed to mana+e t$e supplier. T$e supplier;s pro+ress and performance are trac2ed as specified in t$e supplier a+reement, and t$e supplier a+reement is revised as appropriate. 0cceptance revie's and tests are conducted on t$e supplier-produced product component.
A+va #e+ Pro0e#t Ma a!eme t Pro#e$$ Area$
T$e 0dvanced Pro4ect Mana+ement process areas address activities suc$ as esta)lis$in+ a defined process t$at is tailored from t$e or+ani-ation;s set of standard processes, esta)lis$in+ t$e pro4ect 'or2 environment from t$e or+ani-ation;s 'or2 environment standards, coordinatin+ and colla)oratin+ 'it$ relevant sta2e$olders, formin+ and sustainin+ teams for t$e conduct of pro4ects, /uantitativel* mana+in+ t$e pro4ect, and mana+in+ ris2. 1i+ure 8.8 provides a )ird;s-e*e vie' of t$e interactions amon+ t$e 0dvanced Pro4ect Mana+ement process areas and 'it$ ot$er process area cate+ories. Eac$ 0dvanced Pro4ect Mana+ement process area depends on t$e a)ilit* to plan, monitor, and control t$e pro4ect. T$e .asic Pro4ect Mana+ement process areas provide t$is a)ilit*.
45
tatistical mana+ement data Buantitative o)4ectives, su)processes to statisticall* mana+e, pro4ect;s composed and defined process 7r+ani-ation;s standard processes , 'or2 environment standards, and supportin+ assets IPM Process Mana+ement process areas
BPM
!is2 e5posure due to unsta)le processes
! NM
Product arc$itecture for structurin+ teams
Pro4ect;s defined process and 'or2 environment Coordination, commitments , and issues to resolve Teams for performin+ en+ineerin+ and support processes
!is2 ta5onomies and parameters, ris2 status, ris2 miti+ation plans, and corrective action
En+ineerin+ and upport process areas
.asic Pro4ect Mana+ement process areas
IPMO Inte+rated Pro4ect Mana+ement

BPM O Buantitative Pro4ect Mana+ement
! NM O !is2 Mana+ement
Figure %.%: "d)anced !ro/ect Management !rocess "reas T$e Inte+rated Pro4ect Mana+ement process area esta)lis$es and maintains t$e pro4ect;s defined process t$at is tailored from t$e or+ani-ation;s set of standard processes (7r+ani-ational Process Definition,. T$e pro4ect is mana+ed usin+ t$e pro4ect;s defined process. T$e pro4ect uses and contri)utes to t$e or+ani-ational process assets, t$e pro4ect;s 'or2 environment is esta)lis$ed and maintained from t$e or+ani-ation;s 'or2 environment standards, and teams are esta)lis$ed usin+ t$e or+ani-ation;s rules and +uidelines. T$e pro4ect;s relevant sta2e$olders coordinate t$eir efforts in a timel* manner t$rou+$ t$e identification, ne+otiation, and trac2in+ of critical dependencies and t$e resolution of coordination issues. 0lt$ou+$ ris2 identification and monitorin+ are covered in t$e Pro4ect Plannin+ and Pro4ect Monitorin+ and Control process areas, t$e !is2 Mana+ement process area ta2es a continuin+, for'ard-loo2in+ approac$ to mana+in+ ris2s 'it$ activities t$at include identification of ris2 parameters, ris2 assessments, and ris2 miti+ation.
46
T$e Buantitative Pro4ect Mana+ement process area esta)lis$es o)4ectives for /ualit* and process performance, composes a defined process t$at can $elp ac$ieve t$ose o)4ectives, and /uantitativel* mana+es t$e pro4ect. T$e pro4ect;s /ualit* and process performance o)4ectives are )ased on t$e o)4ectives esta)lis$ed )* t$e or+ani-ation and t$e customer. T$e pro4ect;s defined process is composed usin+ statistical and ot$er /uantitative tec$ni/ues. uc$ an anal*sis ena)les t$e pro4ect to predict '$et$er it 'ill ac$ieve its /ualit* and process performance o)4ectives. .ased on t$e prediction, t$e pro4ect can ad4ust t$e defined process or can ne+otiate c$an+es to /ualit* and process performance o)4ectives. 0s t$e pro4ect pro+resses, t$e performance of selected su)processes is carefull* monitored to $elp evaluate '$et$er t$e pro4ect is on trac2 to ac$ievin+ its o)4ectives.
$ngineering
En+ineerin+ process areas cover t$e development and maintenance activities t$at are s$ared across en+ineerin+ disciplines. T$e En+ineerin+ process areas 'ere 'ritten usin+ +eneral en+ineerin+ terminolo+* so t$at an* tec$nical discipline involved in t$e product development process (e.+., soft'are en+ineerin+, mec$anical en+ineerin+, can use t$em for process improvement. T$e En+ineerin+ process areas also inte+rate t$e processes associated 'it$ different en+ineerin+ disciplines into a sin+le product development process, supportin+ a product oriented process improvement strate+*. uc$ a strate+* tar+ets essential )usiness o)4ectives rat$er t$an specific tec$nical disciplines. T$is approac$ to processes effectivel* avoids t$e tendenc* to'ard an or+ani-ational LstovepipeM mentalit*. T$e En+ineerin+ process areas appl* to t$e development of an* product or service in t$e development domain (e.+., soft'are products, $ard'are products, services, processes,. T$e five En+ineerin+ process areas in CMMI-DEV are as follo's% Product Inte+ration (PI, !e/uirements Development (!D, Tec$nical olution (T , Validation (V0A, Verification (VE!,
1i+ure 8.9 provides a )ird;s-e*e vie' of t$e interactions amon+ t$e si5 En+ineerin+ process areas.
48
Figure %.0: +ngineering !rocess "reas T$e !e/uirements Development process area identifies customer needs and translates t$ese needs into product re/uirements. T$e set of product re/uirements is anal*-ed to produce a $i+$-level conceptual solution. T$is set of re/uirements is t$en allocated to esta)lis$ an initial set of product component re/uirements. 7t$er re/uirements t$at $elp define t$e product are derived and allocated to product components. T$is set of product and product component re/uirements clearl* descri)es t$e product;s performance, /ualit* attri)utes, desi+n features, verification re/uirements, etc., in terms t$e developer understands and uses. T$e !e/uirements Development process area supplies re/uirements to t$e Tec$nical olution process area, '$ere t$e re/uirements are converted into t$e product arc$itecture, product component desi+ns, and product components (e.+., )* codin+, fa)rication,. !e/uirements are also supplied to t$e Product Inte+ration process area, '$ere product components are com)ined and interfaces are verified to ensure t$at t$e* meet t$e interface re/uirements supplied )* !e/uirements Development.
4<
T$e Tec$nical olution process area develops tec$nical data pac2a+es for product components to )e used )* t$e Product Inte+ration or upplier 0+reement Mana+ement process area. 0lternative solutions are e5amined to select t$e optimum desi+n )ased on esta)lis$ed criteria. T$ese criteria can )e si+nificantl* different across products, dependin+ on product t*pe, operational environment, performance re/uirements, support re/uirements, and cost or deliver* sc$edules. T$e tas2 of selectin+ t$e final solution ma2es use of t$e specific practices in t$e Decision 0nal*sis and !esolution process area. T$e Tec$nical olution process area relies on t$e specific practices in t$e Verification process area to perform desi+n verification and peer revie's durin+ desi+n and prior to final )uild. T$e Verification process area ensures t$at selected 'or2 products meet t$e specified re/uirements. T$e Verification process area selects 'or2 products and verification met$ods t$at 'ill )e used to verif* 'or2 products a+ainst specified re/uirements. Verification is +enerall* an incremental process, startin+ 'it$ product component verification and usuall* concludin+ 'it$ verification of full* assem)led products. Verification also addresses peer revie's. Peer revie's are a proven met$od for removin+ defects earl* and provide valua)le insi+$t into t$e 'or2 products and product components )ein+ developed and maintained. T$e Validation process area incrementall* validates products a+ainst t$e customer;s needs. Validation can )e performed in t$e operational environment or in a simulated operational environment. Coordination 'it$ t$e customer on validation re/uirements is an important element of t$is process area. T$e scope of t$e Validation process area includes validation of products, product components, selected intermediate 'or2 products, and processes. T$ese validated elements can often re/uire reverification and revalidation. Issues discovered durin+ validation are usuall* resolved in t$e !e/uirements Development or Tec$nical olution process area. T$e Product Inte+ration process area contains t$e specific practices associated 'it$ +eneratin+ an inte+ration strate+*, inte+ratin+ product components, and deliverin+ t$e product to t$e customer. Product Inte+ration uses t$e specific practices of )ot$ Verification and Validation in implementin+ t$e product inte+ration process. Verification practices verif* t$e interfaces and interface re/uirements of product components prior to product inte+ration. Interface verification is an essential event in t$e inte+ration process. Durin+ product inte+ration in t$e operational environment, t$e specific practices of t$e Validation process area are used.
43
Recursion and Iteration of $ngineering Processes
Most process standards a+ree t$at t$ere are t'o 'a*s t$at processes can )e applied. T$ese t'o 'a*s are called recursion and iteration. !ecursion occurs '$en a process is applied to successive levels of s*stem elements 'it$in a s*stem structure. T$e outcomes of one application are used as inputs to t$e ne5t level in t$e s*stem structure. 1or e5ample, t$e verification process is desi+ned to appl* to t$e entire assem)led product, t$e ma4or product components, and even components of components. @o' far into t$e product *ou appl* t$e verification process depends entirel* on t$e si-e and comple5it* of t$e end product. Iteration occurs '$en processes are repeated at t$e same s*stem level. <e' information is created )* t$e implementation of one process t$at feeds t$at information )ac2 into a related process. T$is ne' information t*picall* raises /uestions t$at must )e resolved )efore completin+ t$e processes. 1or e5ample, iteration 'ill most li2el* occur )et'een re/uirements development and tec$nical solution. !eapplication of t$e processes can resolve t$e /uestions t$at are raised. Iteration can ensure /ualit* prior to appl*in+ t$e ne5t process. En+ineerin+ processes (e.+., re/uirements development, verification, are implemented repeatedl* on a product to ensure t$at t$ese en+ineerin+ processes $ave )een ade/uatel* addressed )efore deliver* to t$e customer. 1urt$er, en+ineerin+ processes are applied to components of t$e product. 1or e5ample, some /uestions t$at are raised )* processes associated 'it$ t$e Verification and Validation process areas can )e resolved )* processes associated 'it$ t$e !e/uirements Development or Product Inte+ration process area. !ecursion and iteration of t$ese processes ena)le t$e pro4ect to ensure /ualit* in all components of t$e product )efore it is delivered to t$e customer. T$e pro4ect mana+ement process areas can li2e'ise )e recursive )ecause sometimes pro4ects are nested 'it$in pro4ects.
)upport
upport process areas cover t$e activities t$at support product development and maintenance. T$e upport process areas address processes t$at are used in t$e conte5t of performin+ ot$er processes. In +eneral, t$e upport process areas address processes t$at are tar+eted to'ard t$e pro4ect and can address processes t$at appl* more +enerall* to t$e or+ani-ation. 1or e5ample, Process and Product Bualit* 0ssurance can )e used 'it$ all t$e process areas to provide an o)4ective evaluation of t$e processes and 'or2 products descri)ed in all t$e process areas. T$e five upport process areas in CMMI-DEV are as follo's%
50
Causal 0nal*sis and !esolution (C0!, Confi+uration Mana+ement (CM, Decision 0nal*sis and !esolution (D0!, Measurement and 0nal*sis (M0, Process and Product Bualit* 0ssurance (PPB0,
9a$"# S/''ort Pro#e$$ Area$
T$e .asic upport process areas address fundamental support functions t$at are used )* all process areas. 0lt$ou+$ all upport process areas rel* on t$e ot$er process areas for input, t$e .asic upport process areas provide support functions t$at also $elp implement several +eneric practices. 1i+ure 8.G provides a )ird;s-e*e vie' of t$e interactions amon+ t$e .asic upport process areas and 'it$ all ot$er process areas.
Figure %.6: .asic upport !rocess "reas T$e Measurement and 0nal*sis process area supports all process areas )* providin+ specific practices t$at +uide pro4ects and or+ani-ations in ali+nin+ measurement needs and o)4ectives 'it$ a measurement approac$ t$at is used to support mana+ement information needs. T$e results can )e used in ma2in+ informed decisions and ta2in+ appropriate corrective actions. T$e Process and Product Bualit* 0ssurance process area supports all process areas )* providin+ specific practices for o)4ectivel* evaluatin+ performed processes, 'or2 products, and services a+ainst t$e applica)le
51
process descriptions, standards, and procedures, and ensurin+ t$at an* issues arisin+ from t$ese revie's are addressed. Process and Product Bualit* 0ssurance supports t$e deliver* of $i+$ /ualit* products and services )* providin+ t$e pro4ect staff and all levels of mana+ement 'it$ appropriate visi)ilit* into, and feed)ac2 on, t$e processes and associated 'or2 products t$rou+$out t$e life of t$e pro4ect. T$e Confi+uration Mana+ement process area supports all process areas )* esta)lis$in+ and maintainin+ t$e inte+rit* of 'or2 products usin+ confi+uration identification, confi+uration control, confi+uration status accountin+, and confi+uration audits. T$e 'or2 products placed under confi+uration mana+ement include t$e products t$at are delivered to t$e customer, desi+nated internal 'or2 products, ac/uired products, tools, and ot$er items t$at are used in creatin+ and descri)in+ t$ese 'or2 products. E5amples of 'or2 products t$at can )e placed under confi+uration mana+ement include plans, process descriptions, re/uirements, desi+n data, dra'in+s, product specifications, code, compilers, product data files, and product tec$nical pu)lications.
A+va #e+ S/''ort Pro#e$$ Area$
T$e 0dvanced upport process areas provide t$e pro4ects and or+ani-ation 'it$ an improved support capa)ilit*. Eac$ of t$ese process areas relies on specific inputs or practices from ot$er process areas. 1i+ure 8.= provides a )ird;s-e*e vie' of t$e interactions amon+ t$e 0dvanced upport process areas and 'it$ all ot$er process areas.
52
C0!
Process improvement proposals
Defects, ot$er pro)lems, and successes
0ll process areas
elected issues
1ormal evaluations
C0! O Causal 0nal*sis and !esolution D0! O Decision 0nal*sis and !esolution
D0!
Figure %.1: "d)anced upport !rocess "reas :sin+ t$e Causal 0nal*sis and !esolution process area, pro4ect mem)ers identif* causes of selected outcomes and ta2e action to prevent ne+ative outcomes from occurrin+ in t$e future or to levera+e positive outcomes. 6$ile t$e pro4ect;s defined processes are t$e initial tar+ets for root cause anal*sis and action plans, effective process c$an+es can result in process improvement proposals su)mitted to t$e or+ani-ation;s set of standard processes. T$e Decision 0nal*sis and !esolution process area supports all t$e process areas )* determinin+ '$ic$ issues s$ould )e su)4ected to a formal evaluation process and t$en appl*in+ a formal evaluation process to t$em.
53
54
5 U$" ! CMMI Mo+e&$
T$e comple5it* of products toda* demands an inte+rated vie' of $o' or+ani-ations do )usiness. CMMI can reduce t$e cost of process improvement across enterprises t$at depend on multiple functions or +roups to ac$ieve t$eir o)4ectives. To ac$ieve t$is inte+rated vie', t$e CMMI 1rame'or2 includes common terminolo+*, common model components, common appraisal met$ods, and common trainin+ materials. T$is c$apter descri)es $o' or+ani-ations can use t$e CMMI Product uite not onl* to improve t$eir /ualit*, reduce t$eir costs, and optimi-e t$eir sc$edules, )ut also to +au+e $o' 'ell t$eir process improvement pro+ram is 'or2in+.
Adopting !##I
!esearc$ $as s$o'n t$at t$e most po'erful initial step to process improvement is to )uild or+ani-ational support t$rou+$ stron+ senior mana+ement sponsors$ip. To +ain t$e sponsors$ip of senior mana+ement, it is often )eneficial to e5pose t$em to t$e performance results e5perienced )* ot$ers '$o $ave used CMMI to improve t$eir processes >3i)son "##G?. 1or more information a)out CMMI performance results, see t$e EI 'e)site at $ttp%&&'''.sei.cmu.edu&cmmi&researc$&results&. T$e senior mana+er, once committed as t$e process improvement sponsor, must )e activel* involved in t$e CMMI-)ased process improvement effort. 0ctivities performed )* t$e senior mana+ement sponsor include )ut are not limited to t$e follo'in+% Influence t$e or+ani-ation to adopt CMMI C$oose t$e )est people to mana+e t$e process improvement effort Monitor t$e process improvement effort personall* .e a visi)le advocate and spo2esperson for t$e process improvement effort Ensure t$at ade/uate resources are availa)le to ena)le t$e process improvement effort to )e successful
3iven sufficient senior mana+ement sponsors$ip, t$e ne5t step is esta)lis$in+ a stron+, tec$nicall* competent process +roup t$at represents relevant sta2e$olders to +uide process improvement efforts >0$ern "##H, D*mond "##9?. 1or an or+ani-ation 'it$ a mission to develop soft'are-intensive s*stems, t$e process +roup mi+$t include t$ose '$o represent different disciplines
U$" ! CMMI Mo+e&$
55
across t$e or+ani-ation and ot$er selected mem)ers )ased on t$e )usiness needs drivin+ improvement. 1or e5ample, a s*stems administrator ma* focus on information tec$nolo+* support, '$ereas a mar2etin+ representative ma* focus on inte+ratin+ customers; needs. .ot$ mem)ers could ma2e po'erful contri)utions to t$e process +roup. 7nce *our or+ani-ation decides to adopt CMMI, plannin+ can )e+in 'it$ an improvement approac$ suc$ as t$e IDE0A M (Initiatin+, Dia+nosin+, Esta)lis$in+, 0ctin+, and Aearnin+, model >Mc1eele* 1FFG?. 1or more information a)out t$e IDE0A model, see t$e EI 'e)site at $ttp%&&'''.sei.cmu.edu&li)rar*&a)stracts&reports&FG$)##1.cfm.
-our Process Impro ement Program
:se t$e CMMI Product uite to $elp esta)lis$ *our or+ani-ation;s process improvement pro+ram. :sin+ t$e product suite for t$is purpose can )e a relativel* informal process t$at involves understandin+ and appl*in+ CMMI )est practices to *our or+ani-ation. 7r, it can )e a formal process t$at involves e5tensive trainin+, creation of a process improvement infrastructure, appraisals, and more.
)elections that Influence -our Program
Dou must ma2e t$ree selections to appl* CMMI to *our or+ani-ation for process improvement% 1. ". 3. elect a part of t$e or+ani-ation. elect a model. elect a representation.
electin+ t$e pro4ects to )e involved in *our process improvement pro+ram is critical. If *ou select a +roup t$at is too lar+e, it ma* )e too muc$ for t$e initial improvement effort. T$e selection s$ould also consider or+ani-ational, product, and 'or2 $omo+eneit* (i.e., '$et$er t$e +roup;s mem)ers all are e5perts in t$e same discipline, '$et$er t$e* all 'or2 on t$e same product or )usiness line, and so on,. electin+ an appropriate model is also essential to a successful process improvement pro+ram. T$e CMMI-DEV model focuses on activities for developin+ /ualit* products and services. T$e CMMI-0CB model focuses on activities for initiatin+ and mana+in+ t$e ac/uisition of products and services. T$e CMMI- VC model focuses on activities for providin+ /ualit* services to t$e customer and end users. 6$en selectin+ a model, appropriate consideration s$ould )e +iven to t$e primar* focus of t$e or+ani-ation and pro4ects, as 'ell as to t$e processes necessar* to satisf* )usiness o)4ectives. T$e lifec*cle processes (e.+., conception, desi+n, manufacture, deplo*ment, operations, maintenance, disposal, on '$ic$ an or+ani-ation concentrates s$ould also )e considered '$en selectin+ an appropriate model.
56
U$" ! CMMI Mo+e&$
elect t$e representation (capa)ilit* or maturit* levels, t$at fits *our concept of process improvement. !e+ardless of '$ic$ *ou c$oose, *ou can select nearl* an* process area or +roup of process areas to +uide improvement, alt$ou+$ dependencies amon+ process areas s$ould )e considered '$en ma2in+ suc$ a selection. 0s process improvement plans and activities pro+ress, ot$er important selections must )e made, includin+ '$et$er to use an appraisal, '$ic$ appraisal met$od s$ould )e used, '$ic$ pro4ects s$ould )e appraised, $o' trainin+ for staff s$ould )e secured, and '$ic$ staff mem)ers s$ould )e trained.
!##I #odels
CMMI models descri)e )est practices t$at or+ani-ations $ave found to )e productive and useful to ac$ievin+ t$eir )usiness o)4ectives. !e+ardless of *our or+ani-ation, *ou must use professional 4ud+ment '$en interpretin+ CMMI )est practices for *our situation, needs, and )usiness o)4ectives. T$is use of 4ud+ment is reinforced '$en *ou see 'ords suc$ as Lade/uate,M Lappropriate,M or Las neededM in a +oal or practice. T$ese 'ords are used for activities t$at ma* not )e e/uall* relevant in all situations. Interpret t$ese +oals and practices in 'a*s t$at 'or2 for *our or+ani-ation. 0lt$ou+$ process areas depict t$e c$aracteristics of an or+ani-ation committed to process improvement, *ou must interpret t$e process areas usin+ an in-dept$ 2no'led+e of CMMI, *our or+ani-ation, t$e )usiness environment, and t$e specific circumstances involved. 0s *ou )e+in usin+ a CMMI model to improve *our or+ani-ation;s processes, map *our real 'orld processes to CMMI process areas. T$is mappin+ ena)les *ou to initiall* 4ud+e and later trac2 *our or+ani-ation;s level of conformance to t$e CMMI model *ou are usin+ and to identif* opportunities for improvement. To interpret practices, it is important to consider t$e overall conte5t in '$ic$ t$ese practices are used and to determine $o' 'ell t$e practices satisf* t$e +oals of a process area in t$at conte5t. CMMI models do not prescri)e nor impl* processes t$at are ri+$t for an* or+ani-ation or pro4ect. Instead, CMMI descri)es minimal criteria necessar* to plan and implement processes selected )* t$e or+ani-ation for improvement )ased on )usiness o)4ectives. CMMI practices purposel* use nonspecific p$rases suc$ as Lrelevant sta2e$olders,M Las appropriate,M and Las necessar*M to accommodate t$e needs of different or+ani-ations and pro4ects. T$e specific needs of a pro4ect can also differ at various points in its life.
U$" ! CMMI Mo+e&$
58
Interpreting !##I .hen Using Agile Approaches
CMMI practices are desi+ned to provide value across a ran+e of different situations and t$us are stated in +eneral terms. .ecause CMMI does not endorse an* particular approac$ to development, little information t$at is approac$-specific is provided. T$erefore, t$ose '$o don;t $ave prior e5perience implementin+ CMMI in situations similar to t$e one t$e* are no' in ma* find interpretation non-intuitive. To $elp t$ose '$o use 0+ile met$ods to interpret CMMI practices in t$eir environments, notes $ave )een added to selected process areas. T$ese notes are added, usuall* in t$e introductor* notes, to t$e follo'in+ process areas in CMMI-DEV% CM, PI, PMC, PP, PPB0, !D, !EBM, ! NM, T , and VE!. 0ll of t$e notes )e+in 'it$ t$e 'ords, LIn 0+ile environmentsM and are in e5ample )o5es to $elp *ou to easil* reco+ni-e t$em and remind *ou t$at t$ese notes are e5amples of $o' to interpret practices and t$erefore are neit$er necessar* nor sufficient for implementin+ t$e process area. Multiple 0+ile approac$es e5ist. T$e p$rases L0+ile environmentM and L0+ile met$odM are s$ort$and for an* development or mana+ement approac$ t$at ad$eres to t$e Manifesto for $gile evelopment >.ec2 "##1?. uc$ approac$es are c$aracteri-ed )* t$e follo'in+% Direct involvement of t$e customer in product development :se of multiple development iterations to learn a)out and evolve t$e product Customer 'illin+ness to s$are in t$e responsi)ilit* for decisions and ris2
Man* development and mana+ement approac$es can s$are one or more of t$ese c$aracteristics and *et not )e called L0+ile.M 1or e5ample, some teams are ar+ua)l* L0+ileM even t$ou+$ t$e term 0+ile is not used. Even if *ou are not usin+ an 0+ile approac$, *ou mi+$t still find value in t$ese notes. .e cautious '$en usin+ t$ese notes. Dour ultimate interpretation of t$e process area s$ould fit t$e specifics of *our situation, includin+ *our or+ani-ation;s )usiness, pro4ect, 'or2 +roup, or team o)4ectives, '$ile full* meetin+ a CMMI process area;s +oals and practices. 0s mentioned earlier, t$e notes s$ould )e ta2en as e5amples and are neit$er necessar* nor sufficient to implementin+ t$e process area. ome +eneral )ac2+round and motivation for t$e +uidance +iven on 0+ile development approac$es are found in t$e EI tec$nical note CMMI or $gile: )hy #ot Embrace *oth+ >3la-er "##H?.
5<
U$" ! CMMI Mo+e&$
Using !##I Appraisals
Man* or+ani-ations find value in measurin+ t$eir pro+ress )* conductin+ an appraisal and earnin+ a maturit* level ratin+ or a capa)ilit* level ac$ievement profile. T$ese t*pes of appraisals are t*picall* conducted for one or more of t$e follo'in+ reasons% To determine $o' 'ell t$e or+ani-ation;s processes compare to CMMI )est practices and identif* areas '$ere improvement can )e made To inform e5ternal customers and suppliers a)out $o' 'ell t$e or+ani-ation;s processes compare to CMMI )est practices To meet t$e contractual re/uirements of one or more customers
0ppraisals of or+ani-ations usin+ a CMMI model must conform to t$e re/uirements defined in t$e $ppraisal "e,uirements for CMMI (0!C, > EI "#11)? document. 0ppraisals focus on identif*in+ improvement opportunities and comparin+ t$e or+ani-ation;s processes to CMMI )est practices. 0ppraisal teams use a CMMI model and 0!C-conformant appraisal met$od to +uide t$eir evaluation of t$e or+ani-ation and t$eir reportin+ of conclusions. T$e appraisal results are used (e.+., )* a process +roup, to plan improvements for t$e or+ani-ation.
Appraisal Re%uirements for !##I
T$e $ppraisal "e,uirements for CMMI (0!C, document descri)es t$e re/uirements for several t*pes of appraisals. 0 full )enc$mar2in+ appraisal is defined as a Class $ appraisal met$od. Aess formal met$ods are defined as Class * or Class C met$ods. T$e 0!C document 'as desi+ned to $elp improve consistenc* across appraisal met$ods and to $elp appraisal met$od developers, sponsors, and users understand t$e tradeoffs associated 'it$ various met$ods. Dependin+ on t$e purpose of t$e appraisal and t$e nature of t$e circumstances, one class ma* )e preferred over t$e ot$ers. ometimes self assessments, initial appraisals, /uic2-loo2 or mini appraisals, or e5ternal appraisals are appropriateI at ot$er times a formal )enc$mar2in+ appraisal is appropriate. 0 particular appraisal met$od is declared an 0!C Class 0, ., or C appraisal met$od )ased on t$e sets of 0!C re/uirements t$at t$e met$od developer addressed '$en desi+nin+ t$e met$od. More information a)out t$e 0!C is availa)le on t$e EI 'e)site at $ttp%&&'''.sei.cmu.edu&cmmi&tools&appraisals&.
)!A#PI Appraisal #ethods
T$e C0MPI 0 appraisal met$od is t$e +enerall* accepted met$od used for conductin+ 0!C Class 0 appraisals usin+ CMMI models. T$e SC$MPI $
U$" ! CMMI Mo+e&$
53
Method efinition ocument (MDD, defines rules for ensurin+ t$e consistenc* of C0MPI 0 appraisal ratin+s > EI "#11a?. 1or )enc$mar2in+ a+ainst ot$er or+ani-ations, appraisals must ensure consistent ratin+s. T$e ac$ievement of a specific maturit* level or t$e satisfaction of a process area must mean t$e same t$in+ for different appraised or+ani-ations. T$e C0MPI famil* of appraisals includes Class 0, ., and C appraisal met$ods. T$e C0MPI 0 appraisal met$od is t$e officiall* reco+ni-ed and most ri+orous met$od. It is t$e onl* met$od t$at can result in )enc$mar2 /ualit* ratin+s. C0MPI . and C appraisal met$ods provide or+ani-ations 'it$ improvement information t$at is less formal t$an t$e results of a C0MPI 0 appraisal, )ut nonet$eless $elps t$e or+ani-ation to identif* improvement opportunities. More information a)out C0MPI met$ods is availa)le on t$e EI 'e)site at $ttp%&&'''.sei.cmu.edu&cmmi&tools&appraisals&.
Appraisal !onsiderations
C$oices t$at affect a CMMI-)ased appraisal include t$e follo'in+% CMMI model 0ppraisal scope, includin+ t$e or+ani-ational unit to )e appraised, t$e CMMI process areas to )e investi+ated, and t$e maturit* level or capa)ilit* levels to )e appraised 0ppraisal met$od 0ppraisal team leader and team mem)ers 0ppraisal participants selected from t$e appraisal entities to )e intervie'ed 0ppraisal outputs (e.+., ratin+s, instantiation-specific findin+s, 0ppraisal constraints (e.+., time spent on site,
T$e C0MPI MDD allo's t$e selection of predefined options for use in an appraisal. T$ese appraisal options are desi+ned to $elp or+ani-ations ali+n CMMI 'it$ t$eir )usiness needs and o)4ectives. CMMI appraisal plans and results s$ould al'a*s include a description of t$e appraisal options, model scope, and or+ani-ational scope selected. T$is documentation confirms '$et$er an appraisal meets t$e re/uirements for )enc$mar2in+. 1or or+ani-ations t$at 'is$ to appraise multiple functions or +roups, t$e inte+rated approac$ of CMMI ena)les some econom* of scale in model and appraisal trainin+. 7ne appraisal met$od can provide separate or com)ined results for multiple functions. T$e follo'in+ appraisal principles for CMMI are t$e same as t$ose principles used in appraisals for ot$er process improvement models%
1#
enior mana+ement sponsors$ip1#
E5perience $as s$o'n t$at t$e most critical factor influencin+ successful process improvement and appraisals is senior mana+ement sponsors$ip.
60
U$" ! CMMI Mo+e&$

!##I Related (raining
0 focus on t$e or+ani-ation;s )usiness o)4ectives Confidentialit* for intervie'ees :se of a documented appraisal met$od :se of a process reference model (e.+., a CMMI model, 0 colla)orative team approac$ 0 focus on actions for process improvement
6$et$er *our or+ani-ation is ne' to process improvement or is alread* familiar 'it$ process improvement models, trainin+ is a 2e* element in t$e a)ilit* of or+ani-ations to adopt CMMI. 0n initial set of courses is provided )* t$e EI and its Partner <et'or2, )ut *our or+ani-ation ma* 'is$ to supplement t$ese courses 'it$ its o'n instruction. T$is approac$ allo's *our or+ani-ation to focus on areas t$at provide t$e +reatest )usiness value. T$e EI and its Partner <et'or2 offer t$e introductor* course, Introduction to CMMI for evelopment. T$e EI also offers advanced trainin+ to t$ose '$o plan to )ecome more deepl* involved in CMMI adoption or appraisalC for e5ample, t$ose '$o 'ill +uide improvement as part of a process +roup, t$ose '$o 'ill lead C0MPI appraisals, and t$ose '$o 'ill teac$ t$e Introduction to CMMI for evelopment course. Current information a)out CMMI related trainin+ is availa)le on t$e EI 'e)site at $ttp%&&'''.sei.cmu.edu&trainin+&.
U$" ! CMMI Mo+e&$
61
62
U$" ! CMMI Mo+e&$
Part T'o% 7e er"# 7oa&$ a + 7e er"# Pra#t"#e$( a + t-e Pro#e$$ Area$
63
64
/$*$RI! /OA+) A*D /$*$RI! PRA!(I!$) O er iew
T$is section descri)es in detail all t$e +eneric +oals and +eneric practices of CMMICmodel components t$at directl* address process institutionali-ation. 0s *ou address eac$ process area, refer to t$is section for t$e details of all +eneric practices. 3eneric practice ela)orations appear after +eneric practices to provide +uidance on $o' t$e +eneric practice can )e applied uni/uel* to process areas.
Process Institutionalization
Institutionali-ation is an important concept in process improvement. 6$en mentioned in t$e +eneric +oal and +eneric practice descriptions, institutionali-ation implies t$at t$e process is in+rained in t$e 'a* t$e 'or2 is performed and t$ere is commitment and consistenc* to performin+ (i.e., e5ecutin+, t$e process. 0n institutionali-ed process is more li2el* to )e retained durin+ times of stress. 6$en t$e re/uirements and o)4ectives for t$e process c$an+e, $o'ever, t$e implementation of t$e process ma* also need to c$an+e to ensure t$at it remains effective. T$e +eneric practices descri)e activities t$at address t$ese aspects of institutionali-ation. T$e de+ree of institutionali-ation is em)odied in t$e +eneric +oals and e5pressed in t$e names of t$e processes associated 'it$ eac$ +oal as indicated in Ta)le G.1.
Ta'le 6.1 &eneric &oals and !rocess 2ames Generic Goal 33 1 33 " 33 3 Progression of Processes Performed process Mana+ed process Defined process
T$e pro+ression of process institutionali-ation is c$aracteri-ed in t$e follo'in+ descriptions of eac$ process.
Performe+ Pro#e$$
0 performed process is a process t$at accomplis$es t$e 'or2 necessar* to satisf* t$e specific +oals of a process area.
7e er"# 7oa&$ a + 7e er"# Pra#t"#e$
65
Ma a!e+ Pro#e$$
0 managed process is a performed process t$at is planned and e5ecuted in accordance 'it$ polic*I emplo*s s2illed people $avin+ ade/uate resources to produce controlled outputsI involves relevant sta2e$oldersI is monitored, controlled, and revie'edI and is evaluated for ad$erence to its process description. T$e process can )e instantiated )* a pro4ect, +roup, or or+ani-ational function. Mana+ement of t$e process is concerned 'it$ institutionali-ation and t$e ac$ievement of ot$er specific o)4ectives esta)lis$ed for t$e process, suc$ as cost, sc$edule, and /ualit* o)4ectives. T$e control provided )* a mana+ed process $elps to ensure t$at t$e esta)lis$ed process is retained durin+ times of stress. T$e re/uirements and o)4ectives for t$e process are esta)lis$ed )* t$e or+ani-ation. T$e status of t$e 'or2 products and services are visi)le to mana+ement at defined points (e.+., at ma4or milestones, on completion of ma4or tas2s,. Commitments are esta)lis$ed amon+ t$ose '$o perform t$e 'or2 and t$e relevant sta2e$olders and are revised as necessar*. 6or2 products are revie'ed 'it$ relevant sta2e$olders and are controlled. T$e 'or2 products and services satisf* t$eir specified re/uirements. 0 critical distinction )et'een a performed process and a managed process is t$e e5tent to '$ic$ t$e process is mana+ed. 0 mana+ed process is planned (t$e plan can )e part of a more encompassin+ plan, and t$e e5ecution of t$e process is mana+ed a+ainst t$e plan. Corrective actions are ta2en '$en t$e actual results and e5ecution deviate si+nificantl* from t$e plan. 0 managed process ac$ieves t$e o)4ectives of t$e plan and is institutionali-ed for consistent e5ecution.
%ef" e+ Pro#e$$
0 defined process is a managed process t$at is tailored from t$e or+ani-ation;s set of standard processes accordin+ to t$e or+ani-ation;s tailorin+ +uidelinesI $as a maintained process descriptionI and contri)utes process related e5periences to t$e or+ani-ational process assets. 7r+ani-ational process assets are artifacts t$at relate to descri)in+, implementin+, and improvin+ processes. T$ese artifacts are assets )ecause t$e* are developed or ac/uired to meet t$e )usiness o)4ectives of t$e or+ani-ation and t$e* represent investments )* t$e or+ani-ation t$at are e5pected to provide current and future )usiness value. T$e or+ani-ation;s set of standard processes, '$ic$ are t$e )asis of t$e defined process, are esta)lis$ed and improved over time. tandard processes descri)e t$e fundamental process elements t$at are e5pected in t$e defined processes. tandard processes also descri)e t$e relations$ips (e.+., t$e orderin+, t$e interfaces, amon+ t$ese process elements. T$e or+ani-ation-level infrastructure to support current and future use of t$e or+ani-ation;s set of standard processes is esta)lis$ed and improved over time. ( ee t$e definition of Lstandard processM in t$e +lossar*.,
66
0 pro4ect;s defined process provides a )asis for plannin+, performin+, and improvin+ t$e pro4ect;s tas2s and activities. 0 pro4ect can $ave more t$an one defined process (e.+., one for developin+ t$e product and anot$er for testin+ t$e product,. 0 defined process clearl* states t$e follo'in+% Purpose Inputs Entr* criteria 0ctivities !oles Measures Verification steps 7utputs E5it criteria
0 critical distinction )et'een a managed process and a defined process is t$e scope of application of t$e process descriptions, standards, and procedures. 1or a managed process, t$e process descriptions, standards, and procedures are applica)le to a particular pro4ect, +roup, or or+ani-ational function. 0s a result, t$e mana+ed processes of t'o pro4ects in one or+ani-ation can )e different. 0not$er critical distinction is t$at a defined process is descri)ed in more detail and is performed more ri+orousl* t$an a managed process. T$is distinction means t$at improvement information is easier to understand, anal*-e, and use. 1inall*, mana+ement of t$e defined process is )ased on t$e additional insi+$t provided )* an understandin+ of t$e interrelations$ips of t$e process activities and detailed measures of t$e process, its 'or2 products, and its services.
Re&at"o $-"'$ Amo ! Pro#e$$e$
T$e +eneric +oals evolve so t$at eac$ +oal provides a foundation for t$e ne5t. T$erefore, t$e follo'in+ conclusions can )e made% 0 managed process is a performed process. 0 defined process is a managed process.
T$us, applied se/uentiall* and in order, t$e +eneric +oals descri)e a process t$at is increasin+l* institutionali-ed from a performed process to a defined process. 0c$ievin+ 33 1 for a process area is e/uivalent to sa*in+ *ou ac$ieve t$e specific +oals of t$e process area. 0c$ievin+ 33 " for a process area is e/uivalent to sa*in+ *ou mana+e t$e e5ecution of processes associated 'it$ t$e process area. T$ere is a polic* t$at indicates *ou 'ill perform t$e process. T$ere is a plan for performin+ it. T$ere are resources provided, responsi)ilities assi+ned, trainin+ on $o' to perform it, selected 'or2 products from performin+ t$e process are
68
controlled, and so on. In ot$er 'ords, t$e process is planned and monitored 4ust li2e an* pro4ect or support activit*. 0c$ievin+ 33 3 for a process area is e/uivalent to sa*in+ t$at an or+ani-ational standard process e5ists t$at can )e tailored to result in t$e process *ou 'ill use. Tailorin+ mi+$t result in ma2in+ no c$an+es to t$e standard process. In ot$er 'ords, t$e process used and t$e standard process can )e identical. :sin+ t$e standard process Las isM is tailorin+ )ecause t$e c$oice is made t$at no modification is re/uired. Eac$ process area descri)es multiple activities, some of '$ic$ are repeatedl* performed. Dou ma* need to tailor t$e 'a* one of t$ese activities is performed to account for ne' capa)ilities or circumstances. 1or e5ample, *ou ma* $ave a standard for developin+ or o)tainin+ or+ani-ational trainin+ t$at does not consider 'e)-)ased trainin+. 6$en preparin+ to develop or o)tain a 'e)-)ased course, *ou ma* need to tailor t$e standard process to account for t$e particular c$allen+es and )enefits of 'e)-)ased trainin+.
/eneric /oals and /eneric Practices
T$is section descri)es all of t$e +eneric +oals and +eneric practices, as 'ell as t$eir associated su)practices, notes, e5amples, and references. T$e +eneric +oals are or+ani-ed in numerical order, 33 1 t$rou+$ 33 3. T$e +eneric practices are also or+ani-ed in numerical order under t$e +eneric +oal t$e* support.
77 1 A#-"eve S'e#"f"# 7oa&$
The specific goals of the process area are supported 'y the process 'y transforming identifia'le input 3or4 products into identifia'le output 3or4 products.
7P 1*1 Perform S'e#"f"# Pra#t"#e$
!erform the specific practices of the process area to de)elop 3or4 products and pro)ide ser)ices to achie)e the specific goals of the process area.
T$e purpose of t$is +eneric practice is to produce t$e 'or2 products and deliver t$e services t$at are e5pected )* performin+ (i.e., e5ecutin+, t$e process. T$ese practices can )e done informall* 'it$out follo'in+ a documented process description or plan. T$e ri+or 'it$ '$ic$ t$ese practices are performed depends on t$e individuals mana+in+ and performin+ t$e 'or2 and can var* considera)l*.
6<
77 2
I $t"t/t"o a&"Ae a Ma a!e+ Pro#e$$
The process is institutionali5ed as a managed process.

7P 2*1 E$tab&"$- a Or!a "Aat"o a& Po&"#1
+sta'lish and maintain an organi5ational policy for planning and performing the process.
T$e purpose of t$is +eneric practice is to define t$e or+ani-ational e5pectations for t$e process and ma2e t$ese e5pectations visi)le to t$ose mem)ers of t$e or+ani-ation '$o are affected. In +eneral, senior mana+ement is responsi)le for esta)lis$in+ and communicatin+ +uidin+ principles, direction, and e5pectations for t$e or+ani-ation. <ot all direction from senior mana+ement 'ill )ear t$e la)el Lpolic*.M T$e e5istence of appropriate or+ani-ational direction is t$e e5pectation of t$is +eneric practice, re+ardless of '$at it is called or $o' it is imparted. C"# Elaboration T$is polic* esta)lis$es or+ani-ational e5pectations for identif*in+ and s*stematicall* addressin+ causal anal*sis of selected outcomes. C$ Elaboration T$is polic* esta)lis$es or+ani-ational e5pectations for esta)lis$in+ and maintainin+ )aselines, trac2in+ and controllin+ c$an+es to 'or2 products (under confi+uration mana+ement,, and esta)lis$in+ and maintainin+ inte+rit* of t$e )aselines. %"# Elaboration T$is polic* esta)lis$es or+ani-ational e5pectations for selectivel* anal*-in+ possi)le decisions usin+ a formal evaluation process t$at evaluates identified alternatives a+ainst esta)lis$ed criteria. T$e polic* s$ould also provide +uidance on '$ic$ decisions re/uire a formal evaluation process. &'$ Elaboration T$is polic* esta)lis$es or+ani-ational e5pectations for esta)lis$in+ and maintainin+ t$e pro4ect;s defined process from pro4ect startup t$rou+$ t$e life of t$e pro4ect, usin+ t$e pro4ect;s defined process in mana+in+ t$e pro4ect, and coordinatin+ and colla)oratin+ 'it$ relevant sta2e$olders. $" Elaboration T$is polic* esta)lis$es or+ani-ational e5pectations for ali+nin+ measurement o)4ectives and activities 'it$ identified information needs and pro4ect, or+ani-ational, or )usiness o)4ectives and for providin+ measurement results. O'% Elaboration T$is polic* esta)lis$es or+ani-ational e5pectations for esta)lis$in+ and maintainin+ a set of standard processes for use )* t$e or+ani-ation, ma2in+ or+ani-ational process assets availa)le across t$e or+ani-ation, and esta)lis$in+ rules and +uidelines for teams.
63
O'F Elaboration T$is polic* esta)lis$es or+ani-ational e5pectations for determinin+ process improvement opportunities for t$e processes )ein+ used and for plannin+, implementin+, and deplo*in+ process improvements across t$e or+ani-ation. O'$ Elaboration T$is polic* esta)lis$es or+ani-ational e5pectations for anal*-in+ t$e or+ani-ation;s )usiness performance usin+ statistical and ot$er /uantitative tec$ni/ues to determine performance s$ortfalls, and identif*in+ and deplo*in+ process and tec$nolo+* improvements t$at contri)ute to meetin+ /ualit* and process performance o)4ectives. O'' Elaboration T$is polic* esta)lis$es or+ani-ational e5pectations for esta)lis$in+ and maintainin+ process performance )aselines and process performance models for t$e or+ani-ation;s set of standard processes. O( Elaboration T$is polic* esta)lis$es or+ani-ational e5pectations for identif*in+ t$e strate+ic trainin+ needs of t$e or+ani-ation and providin+ t$at trainin+. '& Elaboration T$is polic* esta)lis$es or+ani-ational e5pectations for developin+ product inte+ration strate+ies, procedures, and an environmentI ensurin+ interface compati)ilit* amon+ product componentsI assem)lin+ t$e product componentsI and deliverin+ t$e product and product components. '$C Elaboration T$is polic* esta)lis$es or+ani-ational e5pectations for monitorin+ pro4ect pro+ress and performance a+ainst t$e pro4ect plan and mana+in+ corrective action to closure '$en actual or results deviate si+nificantl* from t$e plan. '' Elaboration T$is polic* esta)lis$es or+ani-ational e5pectations for estimatin+ t$e plannin+ parameters, ma2in+ internal and e5ternal commitments, and developin+ t$e plan for mana+in+ t$e pro4ect. '')" Elaboration T$is polic* esta)lis$es or+ani-ational e5pectations for o)4ectivel* evaluatin+ '$et$er processes and associated 'or2 products ad$ere to applica)le process descriptions, standards, and proceduresI and ensurin+ t$at noncompliance is addressed. T$is polic* also esta)lis$es or+ani-ational e5pectations for process and product /ualit* assurance )ein+ in place for all pro4ects. Process and product /ualit* assurance must possess sufficient independence from pro4ect mana+ement to provide o)4ectivit* in identif*in+ and reportin+ noncompliance issues.
80
)'$ Elaboration T$is polic* esta)lis$es or+ani-ational e5pectations for usin+ statistical and ot$er /uantitative tec$ni/ues and $istorical data '$en% esta)lis$in+ /ualit* and process performance o)4ectives, composin+ t$e pro4ect;s defined process, selectin+ su)process attri)utes critical to understandin+ process performance, monitorin+ su)process and pro4ect performance, and performin+ root cause anal*sis to address process performance deficiencies. In particular, t$is polic* esta)lis$es or+ani-ational e5pectations for use of process performance measures, )aselines, and models. #% Elaboration T$is polic* esta)lis$es or+ani-ational e5pectations for collectin+ sta2e$older needs, formulatin+ product and product component re/uirements, and anal*-in+ and validatin+ t$ose re/uirements. #E)$ Elaboration T$is polic* esta)lis$es or+ani-ational e5pectations for mana+in+ re/uirements and identif*in+ inconsistencies )et'een t$e re/uirements and t$e pro4ect plans and 'or2 products. #*+$ Elaboration T$is polic* esta)lis$es or+ani-ational e5pectations for definin+ a ris2 mana+ement strate+* and identif*in+, anal*-in+, and miti+atin+ ris2s. *"$ Elaboration T$is polic* esta)lis$es or+ani-ational e5pectations for esta)lis$in+, maintainin+, and satisf*in+ supplier a+reements. (* Elaboration T$is polic* esta)lis$es or+ani-ational e5pectations for addressin+ t$e iterative c*cle in '$ic$ product or product component solutions are selected, desi+ns are developed, and desi+ns are implemented. ,"- Elaboration T$is polic* esta)lis$es or+ani-ational e5pectations for selectin+ products and product components for validationI for selectin+ validation met$odsI and for esta)lis$in+ and maintainin+ validation procedures, criteria, and environments t$at ensure t$e products and product components satisf* end user needs in t$eir intended operatin+ environment. ,E# Elaboration T$is polic* esta)lis$es or+ani-ational e5pectations for esta)lis$in+ and maintainin+ verification met$ods, procedures, criteria, and t$e verification environment, as 'ell as for performin+ peer revie's and verif*in+ selected 'or2 products.
81
7P 2*2
P&a t-e Pro#e$$
+sta'lish and maintain the plan for performing the process.

T$e purpose of t$is +eneric practice is to determine '$at is needed to perform t$e process and to ac$ieve t$e esta)lis$ed o)4ectives, to prepare a plan for performin+ t$e process, to prepare a process description, and to +et a+reement on t$e plan from relevant sta2e$olders. T$e practical implications of appl*in+ a +eneric practice var* for eac$ process area. For example, the planning described by this generic practice as applied to the 'roject $onitoring and Control process area can be carried out in full by the processes associated with the 'roject 'lanning process area. /owever, this generic practice, when applied to the 'roject 'lanning process area, sets an expectation that the project planning process itself be planned. T$erefore, t$is +eneric practice can eit$er reinforce e5pectations set else'$ere in CMMI or set ne' e5pectations t$at s$ould )e addressed. "efer to the Pro.ect Planning process area for more information about establishing and maintaining plans that define pro.ect activities% Esta)lis$in+ a plan includes documentin+ t$e plan and a process description. Maintainin+ t$e plan includes updatin+ it to reflect corrective actions or c$an+es in re/uirements or o)4ectives. (he plan for performing the process typically includes the following: 'rocess description *tandards and re0uirements for the wor1 products and services of the process *pecific objectives for the execution of the process and its results 2e.g., 0uality, time scale, cycle time, use of resources3 %ependencies among the activities, wor1 products, and services of the process #esources 2e.g., funding, people, tools3 needed to perform the process "ssignment of responsibility and authority (raining needed for performing and supporting the process 4or1 products to be controlled and the level of control to be applied $easurement re0uirements to provide insight into the execution of the process, its wor1 products, and its services &nvolvement of relevant sta1eholders "ctivities for monitoring and controlling the process Objective evaluation activities of the process $anagement review activities for the process and the wor1 products
S/b'ra#t"#e$
1.
Define and document t$e plan for performin+ t$e process.
82
(his plan can be a stand5alone document, embedded in a more comprehensive document, or distributed among multiple documents. &n the case of the plan being distributed among multiple documents, ensure that a coherent picture of who does what is preserved. %ocuments can be hardcopy or softcopy. ". Define and document t$e process description. (he process description, which includes relevant standards and procedures, can be included as part of the plan for performing the process or can be included in the plan by reference. 3. !evie' t$e plan 'it$ relevant sta2e$olders and +et t$eir a+reement. (his review of the plan includes reviewing that the planned process satisfies the applicable policies, plans, re0uirements, and standards to provide assurance to relevant sta1eholders. 8. !evise t$e plan as necessar*. C"# Elaboration T$is plan for performin+ t$e causal anal*sis and resolution process can )e included in (or referenced )*, t$e pro4ect plan, '$ic$ is descri)ed in t$e Pro4ect Plannin+ process area. T$is plan differs from t$e action proposals and associated action plans descri)ed in several specific practices in t$is process area. T$e plan called for in t$is +eneric practice 'ould address t$e pro4ect;s overall causal anal*sis and resolution process (per$aps tailored from a standard process maintained )* t$e or+ani-ation,. In contrast, t$e process action proposals and associated action items address t$e activities needed to address a specific root cause under stud*. C$ Elaboration T$is plan for performin+ t$e confi+uration mana+ement process can )e included in (or referenced )*, t$e pro4ect plan, '$ic$ is descri)ed in t$e Pro4ect Plannin+ process area. %"# Elaboration T$is plan for performin+ t$e decision anal*sis and resolution process can )e included in (or referenced )*, t$e pro4ect plan, '$ic$ is descri)ed in t$e Pro4ect Plannin+ process area. &'$ Elaboration T$is plan for t$e inte+rated pro4ect mana+ement process unites t$e plannin+ for t$e pro4ect plannin+ and monitor and control processes. T$e plannin+ for performin+ t$e plannin+ related practices in Inte+rated Pro4ect Mana+ement is addressed as part of plannin+ t$e pro4ect plannin+ process. T$is plan for performin+ t$e monitor-and-control related practices in Inte+rated Pro4ect Mana+ement can )e included in (or referenced )*, t$e pro4ect plan, '$ic$ is descri)ed in t$e Pro4ect Plannin+ process area.
83
$" Elaboration T$is plan for performin+ t$e measurement and anal*sis process can )e included in (or referenced )*, t$e pro4ect plan, '$ic$ is descri)ed in t$e Pro4ect Plannin+ process area. O'% Elaboration T$is plan for performin+ t$e or+ani-ational process definition process can )e part of (or referenced )*, t$e or+ani-ation;s process improvement plan. O'F Elaboration T$is plan for performin+ t$e or+ani-ational process focus process, '$ic$ is often called Lt$e process improvement plan,M differs from t$e process action plans descri)ed in specific practices in t$is process area. T$e plan called for in t$is +eneric practice addresses t$e compre$ensive plannin+ for all of t$e specific practices in t$is process area, from esta)lis$in+ or+ani-ational process needs t$rou+$ incorporatin+ process related e5periences into or+ani-ational process assets. O'$ Elaboration T$is plan for performin+ t$e or+ani-ational performance mana+ement process differs from t$e deplo*ment plans descri)ed in a specific practice in t$is process area. T$e plan called for in t$is +eneric practice addresses t$e compre$ensive plannin+ for all of t$e specific practices in t$is process area, from maintainin+ )usiness o)4ectives to evaluatin+ improvement effects. In contrast, t$e deplo*ment plans called for in t$e specific practice 'ould address t$e plannin+ needed for t$e deplo*ment of selected improvements. O'' Elaboration T$is plan for performin+ t$e or+ani-ational process performance process can )e included in (or referenced )*, t$e or+ani-ation;s process improvement plan, '$ic$ is descri)ed in t$e 7r+ani-ational Process 1ocus process area. 7r it ma* )e documented in a separate plan t$at descri)es onl* t$e plan for t$e or+ani-ational process performance process. O( Elaboration T$is plan for performin+ t$e or+ani-ational trainin+ process differs from t$e tactical plan for or+ani-ational trainin+ descri)ed in a specific practice in t$is process area. T$e plan called for in t$is +eneric practice addresses t$e compre$ensive plannin+ for all of t$e specific practices in t$is process area, from esta)lis$in+ strate+ic trainin+ needs t$rou+$ assessin+ t$e effectiveness of or+ani-ational trainin+. In contrast, t$e or+ani-ational trainin+ tactical plan called for in t$e specific practice of t$is process area addresses t$e periodic plannin+ for t$e deliver* of trainin+ offerin+s. '& Elaboration T$is plan for performin+ t$e product inte+ration process addresses t$e compre$ensive plannin+ for all of t$e specific practices in t$is process area, from t$e preparation for product inte+ration all t$e 'a* t$rou+$ to t$e deliver* of t$e final product.
84
T$is plan for performin+ t$e product inte+ration process can )e part of (or referenced )*, t$e pro4ect plan as descri)ed in t$e Pro4ect Plannin+ process area. '$C Elaboration T$is plan for performin+ t$e pro4ect monitorin+ and control process can )e part of (or referenced )*, t$e pro4ect plan, as descri)ed in t$e Pro4ect Plannin+ process area. '' Elaboration "efer to Table /%' in Generic Goals and Generic Practices for more information about the relationship between generic practice '%' and the Pro.ect Planning process area% '')" Elaboration T$is plan for performin+ t$e process and product /ualit* assurance process can )e included in (or referenced )*, t$e pro4ect plan, '$ic$ is descri)ed in t$e Pro4ect Plannin+ process area. )'$ Elaboration T$is plan for performin+ t$e /uantitative pro4ect mana+ement process can )e included in (or referenced )*, t$e pro4ect plan, '$ic$ is descri)ed in t$e Pro4ect Plannin+ process area. #% Elaboration T$is plan for performin+ t$e re/uirements development process can )e part of (or referenced )*, t$e pro4ect plan as descri)ed in t$e Pro4ect Plannin+ process area. #E)$ Elaboration T$is plan for performin+ t$e re/uirements mana+ement process can )e part of (or referenced )*, t$e pro4ect plan as descri)ed in t$e Pro4ect Plannin+ process area. #*+$ Elaboration T$is plan for performin+ t$e ris2 mana+ement process can )e included in (or referenced )*, t$e pro4ect plan, '$ic$ is descri)ed in t$e Pro4ect Plannin+ process area. T$e plan called for in t$is +eneric practice addresses t$e compre$ensive plannin+ for all of t$e specific practices in t$is process area. In particular, t$is plan provides t$e overall approac$ for ris2 miti+ation, )ut is distinct from miti+ation plans (includin+ contin+enc* plans, for specific ris2s. In contrast, t$e ris2 miti+ation plans called for in t$e specific practices of t$is process area addresses more focused items suc$ as t$e levels t$at tri++er ris2 $andlin+ activities. *"$ Elaboration Portions of t$is plan for performin+ t$e supplier a+reement mana+ement process can )e part of (or referenced )*, t$e pro4ect plan as descri)ed in t$e Pro4ect Plannin+ process area. 7ften, $o'ever, some portions of t$e
85
plan reside outside of t$e pro4ect 'it$ a +roup suc$ as contract mana+ement. (* Elaboration T$is plan for performin+ t$e tec$nical solution process can )e part of (or referenced )*, t$e pro4ect plan as descri)ed in t$e Pro4ect Plannin+ process area. ,"- Elaboration T$is plan for performin+ t$e validation process can )e included in (or referenced )*, t$e pro4ect plan, '$ic$ is descri)ed in t$e Pro4ect Plannin+ process area. ,E# Elaboration T$is plan for performin+ t$e verification process can )e included in (or referenced )*, t$e pro4ect plan, '$ic$ is descri)ed in t$e Pro4ect Plannin+ process area.
7P 2*3 Prov"+e Re$o/r#e$
!ro)ide ade-uate resources for performing the process* de)eloping the 3or4 products* and pro)iding the ser)ices of the process.
T$e purpose of t$is +eneric practice is to ensure t$at t$e resources necessar* to perform t$e process as defined )* t$e plan are availa)le '$en t$e* are needed. !esources include ade/uate fundin+, appropriate p$*sical facilities, s2illed people, and appropriate tools. T$e interpretation of t$e term Lade/uateM depends on man* factors and can c$an+e over time. Inade/uate resources ma* )e addressed )* increasin+ resources or )* removin+ re/uirements, constraints, and commitments. C"# Elaboration Examples of resources provided include the following: %atabase management systems 'rocess modeling tools *tatistical analysis pac1ages
C$ Elaboration Examples of resources provided include the following: Configuration management tools %ata management tools "rchiving and reproduction tools %atabase management systems
86
%"# Elaboration Examples of resources provided include the following: *imulators and modeling tools 'rototyping tools (ools for conducting surveys
&'$ Elaboration Examples of resources provided include the following: 'roblem trac1ing and trouble reporting pac1ages roupware ,ideo conferencing &ntegrated decision database &ntegrated product support environments
$" Elaboration taff 'it$ appropriate e5pertise provide support for measurement and anal*sis activities. 0 measurement +roup 'it$ suc$ a role ma* e5ist. Examples of resources provided include the following: *tatistical pac1ages 'ac1ages that support data collection over networ1s
O'% Elaboration 0 process +roup t*picall* mana+es or+ani-ational process definition activities. T$is +roup t*picall* is staffed )* a core of professionals '$ose primar* responsi)ilit* is coordinatin+ or+ani-ational process improvement. (his group is supported by process owners and people with expertise in various disciplines such as the following: 'roject management (he appropriate engineering disciplines Configuration management )uality assurance
Examples of resources provided include the following: %atabase management systems 'rocess modeling tools 4eb page builders and browsers
88
O'F Elaboration Examples of resources provided include the following: %atabase management systems 'rocess improvement tools 4eb page builders and browsers roupware )uality improvement tools 2e.g., cause5and5effect diagrams, affinity diagrams, 'areto charts3
O'$ Elaboration Examples of resources provided include the following: *imulation pac1ages 'rototyping tools *tatistical pac1ages %ynamic systems modeling *ubscriptions to online technology databases and publications 'rocess modeling tools
O'' Elaboration pecial e5pertise in statistical and ot$er /uantitative tec$ni/ues ma* )e needed to esta)lis$ process performance )aselines for t$e or+ani-ation;s set of standard processes. Examples of resources provided include the following: %atabase management systems *ystem dynamics models 'rocess modeling tools *tatistical analysis pac1ages 'roblem trac1ing pac1ages
O( Elaboration Examples of resources provided include the following: *ubject matter experts Curriculum designers &nstructional designers &nstructors (raining administrators
pecial facilities ma* )e re/uired for trainin+. 6$en necessar*, t$e facilities re/uired for t$e activities in t$e 7r+ani-ational Trainin+ process area are developed or purc$ased.
8<
Examples of resources provided include the following: &nstruments for analy6ing training needs 4or1stations to be used for training &nstructional design tools 'ac1ages for developing presentation materials
'& Elaboration Product component interface coordination can )e accomplis$ed 'it$ an Interface Control 6or2in+ 3roup consistin+ of people '$o represent e5ternal and internal interfaces. uc$ +roups can )e used to elicit needs for interface re/uirements development. pecial facilities ma* )e re/uired for assem)lin+ and deliverin+ t$e product. 6$en necessar*, t$e facilities re/uired for t$e activities in t$e Product Inte+ration process area are developed or purc$ased. Examples of resources provided include the following: 'rototyping tools "nalysis tools *imulation tools &nterface management tools "ssembly tools 2e.g., compilers, ma1e files, joining tools, jigs, fixtures3
'$C Elaboration Examples of resources provided include the following: Cost trac1ing systems Effort reporting systems "ction item trac1ing systems 'roject management and scheduling programs
'' Elaboration pecial e5pertise, e/uipment, and facilities in pro4ect plannin+ ma* )e re/uired. *pecial expertise in project planning can include the following: Experienced estimators *chedulers (echnical experts in applicable areas 2e.g., product domain, technology3
83
Examples of resources provided include the following: *preadsheet programs Estimating models 'roject planning and scheduling pac1ages
'')" Elaboration Examples of resources provided include the following: Evaluation tools 7oncompliance trac1ing tools
)'$ Elaboration pecial e5pertise in statistics and its use in anal*-in+ process performance ma* )e needed to define t$e anal*tic tec$ni/ues used in /uantitative mana+ement. pecial e5pertise in statistics can also )e needed for anal*-in+ and interpretin+ t$e measures resultin+ from statistical anal*sesI $o'ever, teams need sufficient e5pertise to support a )asic understandin+ of t$eir process performance as t$e* perform t$eir dail* 'or2. Examples of resources provided include the following: *tatistical analysis pac1ages *tatistical process and 0uality control pac1ages *cripts and tools that assist teams in analy6ing their own process performance with minimal need for additional expert assistance
#% Elaboration pecial e5pertise in t$e application domain, met$ods for elicitin+ sta2e$older needs, and met$ods and tools for specif*in+ and anal*-in+ customer, product, and product component re/uirements ma* )e re/uired. Examples of resources provided include the following: #e0uirements specification tools *imulators and modeling tools 'rototyping tools *cenario definition and management tools #e0uirements trac1ing tools
#E)$ Elaboration Examples of resources provided include the following: #e0uirements trac1ing tools (raceability tools
<0
#*+$ Elaboration Examples of resources provided include the following: #is1 management databases #is1 mitigation tools 'rototyping tools $odeling and simulation tools
*"$ Elaboration Examples of resources provided include the following: 'referred supplier lists #e0uirements trac1ing tools 'roject management and scheduling programs
(* Elaboration pecial facilities ma* )e re/uired for developin+, desi+nin+, and implementin+ solutions to re/uirements. 6$en necessar*, t$e facilities re/uired for t$e activities in t$e Tec$nical olution process area are developed or purc$ased. Examples of resources provided include the following: %esign specification tools *imulators and modeling tools 'rototyping tools *cenario definition and management tools #e0uirements trac1ing tools &nteractive documentation tools
,"- Elaboration pecial facilities ma* )e re/uired for validatin+ t$e product or product components. 6$en necessar*, t$e facilities re/uired for validation are developed or purc$ased. Examples of resources provided include the following: (est management tools (est case generators (est coverage analy6ers *imulators -oad, stress, and performance testing tools
<1
,E# Elaboration pecial facilities ma* )e re/uired for verif*in+ selected 'or2 products. 6$en necessar*, t$e facilities re/uired for t$e activities in t$e Verification process area are developed or purc$ased. Certain verification met$ods can re/uire special tools, e/uipment, facilities, and trainin+ (e.+., peer revie's can re/uire meetin+ rooms and trained moderatorsI certain verification tests can re/uire special test e/uipment and people s2illed in t$e use of t$e e/uipment,. Examples of resources provided include the following:
7P 2*4
(est management tools (est case generators (est coverage analy6ers *imulators
A$$"! Re$'o $"b"&"t1
"ssign responsi'ility and authority for performing the process* de)eloping the 3or4 products* and pro)iding the ser)ices of the process.
T$e purpose of t$is +eneric practice is to ensure t$at t$ere is accounta)ilit* for performin+ t$e process and ac$ievin+ t$e specified results t$rou+$out t$e life of t$e process. T$e people assi+ned must $ave t$e appropriate aut$orit* to perform t$e assi+ned responsi)ilities. !esponsi)ilit* can )e assi+ned usin+ detailed 4o) descriptions or in livin+ documents, suc$ as t$e plan for performin+ t$e process. D*namic assi+nment of responsi)ilit* is anot$er le+itimate 'a* to implement t$is +eneric practice, as lon+ as t$e assi+nment and acceptance of responsi)ilit* are ensured t$rou+$out t$e life of t$e process.
S/b'ra#t"#e$
1. ". 3.
0ssi+n overall responsi)ilit* and aut$orit* for performin+ t$e process. 0ssi+n responsi)ilit* and aut$orit* for performin+ t$e specific tas2s of t$e process. Confirm t$at t$e people assi+ned to t$e responsi)ilities and aut$orities understand and accept t$em.
O'F Elaboration T'o +roups are t*picall* esta)lis$ed and assi+ned responsi)ilit* for process improvement% (1, a mana+ement steerin+ committee for process improvement to provide senior mana+ement sponsors$ip, and (", a process +roup to facilitate and mana+e t$e process improvement activities.
<2
'')" Elaboration !esponsi)ilit* is assi+ned to t$ose '$o can perform process and product /ualit* assurance evaluations 'it$ sufficient independence and o)4ectivit* to +uard a+ainst su)4ectivit* or )ias. (* Elaboration 0ppointin+ a lead or c$ief arc$itect t$at oversees t$e tec$nical solution and $as aut$orit* over desi+n decisions $elps to maintain consistenc* in product desi+n and evolution.
7P 2*5 Tra" Peo'&e
Train the people performing or supporting the process as needed.

T$e purpose of t$is +eneric practice is to ensure t$at people $ave t$e necessar* s2ills and e5pertise to perform or support t$e process. 0ppropriate trainin+ is provided to t$ose '$o 'ill )e performin+ t$e 'or2. 7vervie' trainin+ is provided to orient people '$o interact 'it$ t$ose '$o perform t$e 'or2. Examples of methods for providing training include self study8 self5directed training8 self5 paced, programmed instruction8 formali6ed on5the5job training8 mentoring8 and formal and classroom training. Trainin+ supports t$e successful e5ecution of t$e process )* esta)lis$in+ a common understandin+ of t$e process and )* impartin+ t$e s2ills and 2no'led+e needed to perform t$e process. "efer to the 0rgani-ational Training process area for more information about developing s1ills and 1nowledge of people so they can perform their roles effectively and efficiently% C"# Elaboration Examples of training topics include the following: )uality management methods 2e.g., root cause analysis3
C$ Elaboration Examples of training topics include the following: #oles, responsibilities, and authority of the configuration management staff Configuration management standards, procedures, and methods Configuration library system
%"# Elaboration Examples of training topics include the following: Formal decision analysis $ethods for evaluating alternative solutions against criteria
<3
&'$ Elaboration Examples of training topics include the following: (ailoring the organi6ation9s set of standard processes to meet the needs of the project $anaging the project based on the project9s defined process :sing the organi6ation9s measurement repository :sing the organi6ational process assets &ntegrated management &ntergroup coordination roup problem solving
$" Elaboration Examples of training topics include the following: *tatistical techni0ues %ata collection, analysis, and reporting processes %evelopment of goal related measurements 2e.g., oal )uestion $etric3
O'% Elaboration Examples of training topics include the following: C$$& and other process and process improvement reference models 'lanning, managing, and monitoring processes 'rocess modeling and definition %eveloping a tailorable standard process %eveloping wor1 environment standards Ergonomics
O'F Elaboration Examples of training topics include the following: C$$& and other process improvement reference models 'lanning and managing process improvement (ools, methods, and analysis techni0ues 'rocess modeling Facilitation techni0ues Change management
<4
O'$ Elaboration Examples of training topics include the following: Cost benefit analysis 'lanning, designing, and conducting pilots (echnology transition Change management
O'' Elaboration Examples of training topics include the following: 'rocess and process improvement modeling *tatistical and other 0uantitative methods 2e.g., estimating models, 'areto analysis, control charts3
O( Elaboration Examples of training topics include the following: +nowledge and s1ills needs analysis &nstructional design &nstructional techni0ues 2e.g., train the trainer3 #efresher training on subject matter
'& Elaboration Examples of training topics include the following: "pplication domain 'roduct integration procedures and criteria Organi6ation9s facilities for integration and assembly "ssembly methods 'ac1aging standards
'$C Elaboration Examples of training topics include the following: $onitoring and control of projects #is1 management %ata management
<5
'' Elaboration Examples of training topics include the following: Estimating ;udgeting 7egotiating &dentifying and analy6ing ris1s $anaging data 'lanning *cheduling
'')" Elaboration Examples of training topics include the following: "pplication domain Customer relations 'rocess descriptions, standards, procedures, and methods for the project )uality assurance objectives, process descriptions, standards, procedures, methods, and tools
)'$ Elaboration Examples of training topics include the following: ;asic 0uantitative 2including statistical3 analyses that help in analy6ing process performance, using historical data, and identifying when corrective action is warranted 'rocess modeling and analysis 'rocess measurement data selection, definition, and collection
#% Elaboration Examples of training topics include the following: "pplication domain #e0uirements definition and analysis #e0uirements elicitation #e0uirements specification and modeling #e0uirements trac1ing
<6
#E)$ Elaboration Examples of training topics include the following: "pplication domain #e0uirements definition, analysis, review, and management #e0uirements management tools Configuration management 7egotiation and conflict resolution
#*+$ Elaboration Examples of training topics include the following: #is1 management concepts and activities 2e.g., ris1 identification, evaluation, monitoring, mitigation3 $easure selection for ris1 mitigation
*"$ Elaboration Examples of training topics include the following: #egulations and business practices related to negotiating and wor1ing with suppliers "c0uisition planning and preparation Commercial off5the5shelf products ac0uisition *upplier evaluation and selection 7egotiation and conflict resolution *upplier management (esting and transition of ac0uired products #eceiving, storing, using, and maintaining ac0uired products
(* Elaboration Examples of training topics include the following: "pplication domain of the product and product components %esign methods "rchitecture methods &nterface design :nit testing techni0ues *tandards 2e.g., product, safety, human factors, environmental3
<8
,"- Elaboration Examples of training topics include the following: "pplication domain ,alidation principles, standards, and methods &ntended5use environment
,E# Elaboration Examples of training topics include the following:

7P 2*6
"pplication or service domain ,erification principles, standards, and methods 2e.g., analysis, demonstration, inspection, test3 ,erification tools and facilities 'eer review preparation and procedures $eeting facilitation
Co tro& >or? Pro+/#t$
!lace selected 3or4 products of the process under appropriate le)els of control.
T$e purpose of t$is +eneric practice is to esta)lis$ and maintain t$e inte+rit* of t$e selected 'or2 products of t$e process (or t$eir descriptions, t$rou+$out t$eir useful life. T$e selected 'or2 products are specificall* identified in t$e plan for performin+ t$e process, alon+ 'it$ a specification of t$e appropriate level of control. Different levels of control are appropriate for different 'or2 products and for different points in time. 1or some 'or2 products, it ma* )e sufficient to maintain version control so t$at t$e version of t$e 'or2 product in use at a +iven time, past or present, is 2no'n and c$an+es are incorporated in a controlled manner. Version control is usuall* under t$e sole control of t$e 'or2 product o'ner ('$ic$ can )e an individual, +roup, or team,. ometimes, it can )e critical t$at 'or2 products )e placed under formal or )aseline confi+uration mana+ement. T$is t*pe of control includes definin+ and esta)lis$in+ )aselines at predetermined points. T$ese )aselines are formall* revie'ed and approved, and serve as t$e )asis for furt$er development of t$e desi+nated 'or2 products. "efer to the Configuration Management process area for more information about establishing and maintaining the integrity of wor1 products using configuration identification2 configuration control2 configuration status accounting2 and configuration audits% 0dditional levels of control )et'een version control and formal confi+uration mana+ement are possi)le. 0n identified 'or2 product can )e under various levels of control at different points in time.
<<
C"# Elaboration Examples of wor1 products placed under control include the following: "ction proposals "ction plans Causal analysis and resolution records
C$ Elaboration Examples of wor1 products placed under control include the following: "ccess lists Change status reports Change re0uest database CC; meeting minutes "rchived baselines
%"# Elaboration Examples of wor1 products placed under control include the following: uidelines for when to apply a formal evaluation process Evaluation reports containing recommended solutions
&'$ Elaboration Examples of wor1 products placed under control include the following: (he project9s defined process 'roject plans Other plans that affect the project &ntegrated plans "ctual process and product measurements collected from the project 'roject9s shared vision (eam structure (eam charters
$" Elaboration Examples of wor1 products placed under control include the following: $easurement objectives *pecifications of base and derived measures %ata collection and storage procedures ;ase and derived measurement data sets "nalysis results and draft reports %ata analysis tools
<3
O'% Elaboration Examples of wor1 products placed under control include the following: Organi6ation9s set of standard processes %escriptions of lifecycle models (ailoring guidelines for the organi6ation9s set of standard processes %efinitions of the common set of product and process measures Organi6ation9s measurement data #ules and guidelines for structuring and forming teams
O'F Elaboration Examples of wor1 products placed under control include the following: 'rocess improvement proposals Organi6ation9s approved process action plans (raining materials used for deploying organi6ational process assets uidelines for deploying the organi6ation9s set of standard processes on new projects 'lans for the organi6ation9s process appraisals
O'$ Elaboration Examples of wor1 products placed under control include the following: %ocumented lessons learned from improvement validation %eployment plans #evised improvement measures, objectives, priorities :pdated process documentation and training material
O'' Elaboration Examples of wor1 products placed under control include the following: Organi6ation9s 0uality and process performance objectives %efinitions of the selected measures of process performance ;aseline data on the organi6ation9s process performance 'rocess performance models
O( Elaboration Examples of wor1 products placed under control include the following: Organi6ational training tactical plan (raining records (raining materials and supporting artifacts &nstructor evaluation forms
30
'& Elaboration Examples of wor1 products placed under control include the following: "cceptance documents for the received product components Evaluated assembled product and product components 'roduct integration strategy 'roduct integration procedures and criteria :pdated interface description or agreement
'$C Elaboration Examples of wor1 products placed under control include the following: 'roject schedules with status 'roject measurement data and analysis Earned value reports
'' Elaboration Examples of wor1 products placed under control include the following: 4or1 brea1down structure 'roject plan %ata management plan *ta1eholder involvement plan
'')" Elaboration Examples of wor1 products placed under control include the following: 7oncompliance reports Evaluation logs and reports
)'$ Elaboration Examples of wor1 products placed under control include the following: *ubprocesses to be included in the project9s defined process Operational definitions of the measures, their collection points in the subprocesses, and how the integrity of the measures will be determined Collected measurements
31
#% Elaboration Examples of wor1 products placed under control include the following: Customer functional and 0uality attribute re0uirements %efinition of re0uired functionality and 0uality attributes 'roduct and product component re0uirements &nterface re0uirements
#E)$ Elaboration Examples of wor1 products placed under control include the following: #e0uirements #e0uirements traceability matrix
#*+$ Elaboration Examples of wor1 products placed under control include the following: #is1 management strategy &dentified ris1 items #is1 mitigation plans
*"$ Elaboration Examples of wor1 products placed under control include the following: *tatements of wor1 *upplier agreements $emoranda of agreement *ubcontracts 'referred supplier lists
(* Elaboration Examples of wor1 products placed under control include the following: 'roduct, product component, and interface designs (echnical data pac1ages &nterface design documents Criteria for design and product component reuse &mplemented designs 2e.g., software code, fabricated product components3 :ser, installation, operation, and maintenance documentation
32
,"- Elaboration Examples of wor1 products placed under control include the following: -ists of products and product components selected for validation ,alidation methods, procedures, and criteria ,alidation reports
,E# Elaboration Examples of wor1 products placed under control include the following:
7P 2*8
,erification procedures and criteria 'eer review training material 'eer review data ,erification reports
I+e t"f1 a + I vo&ve Re&eva t Sta?e-o&+er$
Identify and in)ol)e the rele)ant sta4eholders of the process as planned.

T$e purpose of t$is +eneric practice is to esta)lis$ and maintain t$e e5pected involvement of relevant sta2e$olders durin+ t$e e5ecution of t$e process. Involve relevant sta2e$olders as descri)ed in an appropriate plan for sta2e$older involvement. Involve sta2e$olders appropriatel* in activities suc$ as t$e follo'in+% Plannin+ Decisions Commitments Communications Coordination !evie's 0ppraisals !e/uirements definitions !esolution of pro)lems and issues
"efer to the Pro.ect Planning process area for more information about planning sta1eholder involvement% T$e o)4ective of plannin+ sta2e$older involvement is to ensure t$at interactions necessar* to t$e process are accomplis$ed, '$ile not allo'in+ e5cessive num)ers of affected +roups and individuals to impede process e5ecution.
33
Examples of sta1eholders that might serve as relevant sta1eholders for specific tas1s, depending on context, include individuals, teams, management, customers, suppliers, end users, operations and support staff, other projects, and government regulators.
S/b'ra#t"#e$
1.
Identif* sta2e$olders relevant to t$is process and t$eir appropriate involvement. #elevant sta1eholders are identified among the suppliers of inputs to, the users of outputs from, and the performers of the activities in the process. Once the relevant sta1eholders are identified, the appropriate level of their involvement in process activities is planned.
". 3.
$are t$ese identifications 'it$ pro4ect planners or ot$er planners as appropriate. Involve relevant sta2e$olders as planned.
C"# Elaboration Examples of activities for sta1eholder involvement include the following: Conducting causal analysis "ssessing action proposals
C$ Elaboration Examples of activities for sta1eholder involvement include the following: Establishing baselines #eviewing configuration management system reports and resolving issues "ssessing the impact of changes for configuration items 'erforming configuration audits #eviewing results of configuration management audits
%"# Elaboration Examples of activities for sta1eholder involvement include the following: Establishing guidelines for which issues are subject to a formal evaluation process %efining the issue to be addressed Establishing evaluation criteria &dentifying and evaluating alternatives *electing evaluation methods *electing solutions
34
&'$ Elaboration Examples of activities for sta1eholder involvement include the following: #esolving issues about the tailoring of organi6ational process assets #esolving issues among the project plan and other plans that affect the project #eviewing project progress and performance to align with current and projected needs, objectives, and re0uirements Creating the project9s shared vision %efining the team structure for the project 'opulating teams
$" Elaboration Examples of activities for sta1eholder involvement include the following: Establishing measurement objectives and procedures "ssessing measurement data 'roviding meaningful feedbac1 to those who are responsible for providing the raw data on which the analysis and results depend
O'% Elaboration Examples of activities for sta1eholder involvement include the following: #eviewing the organi6ation9s set of standard processes #eviewing the organi6ation9s lifecycle models #esolving issues related to the tailoring guidelines "ssessing definitions of the common set of process and product measures #eviewing wor1 environment standards Establishing and maintaining empowerment mechanisms Establishing and maintaining organi6ational rules and guidelines for structuring and forming teams
35
O'F Elaboration Examples of activities for sta1eholder involvement include the following: Coordinating and collaborating on process improvement activities with process owners, those who are or will be performing the process, and support organi6ations 2e.g., training staff, 0uality assurance representatives3 Establishing the organi6ational process needs and objectives "ppraising the organi6ation9s processes &mplementing process action plans Coordinating and collaborating on the execution of pilots to test selected improvements %eploying organi6ational process assets and changes to organi6ational process assets Communicating the plans, status, activities, and results related to planning, implementing, and deploying process improvements
O'$ Elaboration Examples of activities for sta1eholder involvement include the following: #eviewing improvement proposals that could contribute to meeting business objectives 'roviding feedbac1 to the organi6ation on the readiness, status, and results of the improvement deployment activities
(he feedbac1 typically involves the following: &nforming the people who submit improvement proposals about the disposition of their proposals #egularly communicating the results of comparing business performance against the business objectives #egularly informing relevant sta1eholders about the plans and status for selecting and deploying improvements 'reparing and distributing a summary of improvement selection and deployment activities
O'' Elaboration Examples of activities for sta1eholder involvement include the following: Establishing the organi6ation9s 0uality and process performance objectives and their priorities #eviewing and resolving issues on the organi6ation9s process performance baselines #eviewing and resolving issues on the organi6ation9s process performance models
36
O( Elaboration Examples of activities for sta1eholder involvement include the following: Establishing a collaborative environment for discussion of training needs and training effectiveness to ensure that the organi6ation9s training needs are met &dentifying training needs #eviewing the organi6ational training tactical plan "ssessing training effectiveness
'& Elaboration Examples of activities for sta1eholder involvement include the following: Establishing the product integration strategy #eviewing interface descriptions for completeness Establishing the product integration procedures and criteria "ssembling and delivering the product and product components Communicating the results after evaluation Communicating new, effective product integration processes to give affected people the opportunity to improve their process performance
'$C Elaboration Examples of activities for sta1eholder involvement include the following: "ssessing the project against the plan #eviewing commitments and resolving issues #eviewing project ris1s #eviewing data management activities #eviewing project progress $anaging corrective actions to closure
'' Elaboration Examples of activities for sta1eholder involvement include the following: Establishing estimates #eviewing and resolving issues on the completeness and correctness of the project ris1s #eviewing data management plans Establishing project plans #eviewing project plans and resolving issues on wor1 and resource issues
38
'')" Elaboration Examples of activities for sta1eholder involvement include the following: Establishing criteria for the objective evaluations of processes and wor1 products Evaluating processes and wor1 products #esolving noncompliance issues (rac1ing noncompliance issues to closure
)'$ Elaboration Examples of activities for sta1eholder involvement include the following: Establishing project objectives #esolving issues among the project9s 0uality and process performance objectives *electing analytic techni0ues to be used Evaluating the process performance of selected subprocesses &dentifying and managing the ris1s in achieving the project9s 0uality and process performance objectives &dentifying what corrective action should be ta1en
#% Elaboration Examples of activities for sta1eholder involvement include the following: #eviewing the ade0uacy of re0uirements in meeting needs, expectations, constraints, and interfaces Establishing operational concepts and operational, sustainment, and development scenarios "ssessing the ade0uacy of re0uirements 'rioriti6ing customer re0uirements Establishing product and product component functional and 0uality attribute re0uirements "ssessing product cost, schedule, and ris1
#E)$ Elaboration Examples of activities for sta1eholder involvement include the following: #esolving issues on the understanding of re0uirements "ssessing the impact of re0uirements changes Communicating bidirectional traceability &dentifying inconsistencies among re0uirements, project plans, and wor1 products
3<
#*+$ Elaboration Examples of activities for sta1eholder involvement include the following: Establishing a collaborative environment for free and open discussion of ris1 #eviewing the ris1 management strategy and ris1 mitigation plans 'articipating in ris1 identification, analysis, and mitigation activities Communicating and reporting ris1 management status
*"$ Elaboration Examples of activities for sta1eholder involvement include the following: Establishing criteria for evaluation of potential suppliers #eviewing potential suppliers Establishing supplier agreements #esolving issues with suppliers #eviewing supplier performance
(* Elaboration Examples of activities for sta1eholder involvement include the following: %eveloping alternative solutions and selection criteria Obtaining approval on external interface specifications and design descriptions %eveloping the technical data pac1age "ssessing the ma1e, buy, or reuse alternatives for product components &mplementing the design
,"- Elaboration Examples of activities for sta1eholder involvement include the following: *electing the products and product components to be validated Establishing the validation methods, procedures, and criteria #eviewing results of product and product component validation and resolving issues #esolving issues with the customers or end users
&ssues with the customers or end users are resolved particularly when there are significant deviations from their baseline needs. Examples of resolutions include the following: 4aivers on the contract or agreement 2what, when, and for which products3 "dditional in5depth studies, trials, tests, or evaluations 'ossible changes in the contracts or agreements
33
,E# Elaboration Examples of activities for sta1eholder involvement include the following:
7P 2*<
*electing wor1 products and methods for verification Establishing verification procedures and criteria Conducting peer reviews "ssessing verification results and identifying corrective action
Mo "tor a + Co tro& t-e Pro#e$$
Monitor and control the process against the plan for performing the process and ta4e appropriate correcti)e action.
T$e purpose of t$is +eneric practice is to perform t$e direct da*-to-da* monitorin+ and controllin+ of t$e process. 0ppropriate visi)ilit* into t$e process is maintained so t$at appropriate corrective action can )e ta2en '$en necessar*. Monitorin+ and controllin+ t$e process can involve measurin+ appropriate attri)utes of t$e process or 'or2 products produced )* t$e process. "efer to the Measurement and $nalysis process area for more information about developing and sustaining a measurement capability used to support management information needs% "efer to the Pro.ect Monitoring and Control process area for more information about providing an understanding of the pro.ect3s progress so that appropriate corrective actions can be ta1en when the pro.ect3s performance deviates significantly from the plan%
S/b'ra#t"#e$
1.
Evaluate actual pro+ress and performance a+ainst t$e plan for performin+ t$e process. (he evaluations are of the process, its wor1 products, and its services.
". 3.
!evie' accomplis$ments and results of t$e process a+ainst t$e plan for performin+ t$e process. !evie' activities, status, and results of t$e process 'it$ t$e immediate level of mana+ement responsi)le for t$e process and identif* issues. (hese reviews are intended to provide the immediate level of management with appropriate visibility into the process based on the day5to5day monitoring and controlling of the process, and are supplemented by periodic and event5driven reviews with higher level management as described in ' <.=>.
8. 9.
Identif* and evaluate t$e effects of si+nificant deviations from t$e plan for performin+ t$e process. Identif* pro)lems in t$e plan for performin+ t$e process and in t$e e5ecution of t$e process.
100
G.
Ta2e corrective action '$en re/uirements and o)4ectives are not )ein+ satisfied, '$en issues are identified, or '$en pro+ress differs si+nificantl* from t$e plan for performin+ t$e process. &nherent ris1s should be considered before any corrective action is ta1en. Corrective action can include the following:
(a1ing remedial action to repair defective wor1 products or services Changing the plan for performing the process "djusting resources, including people, tools, and other resources 7egotiating changes to the established commitments *ecuring change to the re0uirements and objectives that must be satisfied (erminating the effort
=.
Trac2 corrective action to closure.
C"# Elaboration Examples of measures and wor1 products used in monitoring and controlling include the following: 7umber of outcomes analy6ed Change in 0uality or process performance per instance of the causal analysis and resolution process *chedule of activities for implementing a selected action proposal
C$ Elaboration Examples of measures and wor1 products used in monitoring and controlling include the following: 7umber of changes to configuration items 7umber of configuration audits conducted *chedule of CC; or audit activities
%"# Elaboration Examples of measures and wor1 products used in monitoring and controlling include the following: Cost5to5benefit ratio of using formal evaluation processes *chedule for the execution of a trade study
101
&'$ Elaboration Examples of measures and wor1 products used in monitoring and controlling include the following: 7umber of changes to the project9s defined process *chedule and effort to tailor the organi6ation9s set of standard processes &nterface coordination issue trends 2i.e., number identified and number closed3 *chedule for project tailoring activities 'roject?s shared vision usage and effectiveness (eam structure usage and effectiveness (eam charters usage and effectiveness
$" Elaboration Examples of measures and wor1 products used in monitoring and controlling include the following: 'ercentage of projects using progress and performance measures 'ercentage of measurement objectives addressed *chedule for collection and review of measurement data
O'% Elaboration Examples of measures and wor1 products used in monitoring and controlling include the following: 'ercentage of projects using the process architectures and process elements of the organi6ation9s set of standard processes %efect density of each process element of the organi6ation9s set of standard processes *chedule for development of a process or process change
O'F Elaboration Examples of measures and wor1 products used in monitoring and controlling include the following: 7umber of process improvement proposals submitted, accepted, or implemented C$$& maturity level or capability level earned *chedule for deployment of an organi6ational process asset 'ercentage of projects using the current organi6ation9s set of standard processes 2or tailored version of the current set3 &ssue trends associated with implementing the organi6ation9s set of standard processes 2i.e., number of issues identified, number closed3 'rogress toward achievement of process needs and objectives
102
O'$ Elaboration Examples of measures and wor1 products used in monitoring and controlling include the following: Change in 0uality and process performance related to business objectives *chedule for implementing and validating an improvement *chedule for activities to deploy a selected improvement
O'' Elaboration Examples of measures and wor1 products used in monitoring and controlling include the following: (rends in the organi6ation9s process performance with respect to changes in wor1 products and tas1 attributes 2e.g., si6e growth, effort, schedule, 0uality3 *chedule for collecting and reviewing measures to be used for establishing a process performance baseline
O( Elaboration Examples of measures and wor1 products used in monitoring and controlling include the following: 7umber of training courses delivered 2e.g., planned versus actual3 'ost5training evaluation ratings (raining program 0uality survey ratings *chedule for delivery of training *chedule for development of a course
'& Elaboration Examples of measures and wor1 products used in monitoring and controlling include the following: 'roduct component integration profile 2e.g., product component assemblies planned and performed, number of exceptions found3 &ntegration evaluation problem report trends 2e.g., number written and number closed3 &ntegration evaluation problem report aging 2i.e., how long each problem report has been open3 *chedule for conduct of specific integration activities
103
'$C Elaboration Examples of measures and wor1 products used in monitoring and controlling include the following: 7umber of open and closed corrective actions *chedule with status for monthly financial data collection, analysis, and reporting 7umber and types of reviews performed #eview schedule 2planned versus actual and slipped target dates3 *chedule for collection and analysis of monitoring data
'' Elaboration Examples of measures and wor1 products used in monitoring and controlling include the following: 7umber of revisions to the plan Cost, schedule, and effort variance per plan revision *chedule for development and maintenance of program plans
'')" Elaboration Examples of measures and wor1 products used in monitoring and controlling include the following: ,ariance of objective process evaluations planned and performed ,ariance of objective wor1 product evaluations planned and performed *chedule for objective evaluations
)'$ Elaboration Examples of measures and wor1 products used in monitoring and controlling include the following: 'rofile of subprocess attributes whose process performance provide insight about the ris1 to, or are 1ey contributors to, achieving project objectives 2e.g., number selected for monitoring through statistical techni0ues, number currently being monitored, number whose process performance is stable3 7umber of special causes of variation identified *chedule of data collection, analysis, and reporting activities in a measurement and analysis cycle as it relates to 0uantitative management activities
#% Elaboration Examples of measures and wor1 products used in monitoring and controlling include the following: Cost, schedule, and effort expended for rewor1 %efect density of re0uirements specifications *chedule for activities to develop a set of re0uirements
104
#E)$ Elaboration Examples of measures and wor1 products used in monitoring and controlling include the following: #e0uirements volatility 2percentage of re0uirements changed3 *chedule for coordination of re0uirements *chedule for analysis of a proposed re0uirements change
#*+$ Elaboration Examples of measures and wor1 products used in monitoring and controlling include the following: 7umber of ris1s identified, managed, trac1ed, and controlled #is1 exposure and changes to the ris1 exposure for each assessed ris1, and as a summary percentage of management reserve Change activity for ris1 mitigation plans 2e.g., processes, schedule, funding3 Occurrence of unanticipated ris1s #is1 categori6ation volatility Comparison of estimated versus actual ris1 mitigation effort and impact *chedule for ris1 analysis activities *chedule of actions for a specific mitigation
*"$ Elaboration Examples of measures and wor1 products used in monitoring and controlling include the following: 7umber of changes made to the re0uirements for the supplier Cost and schedule variance in accordance with the supplier agreement *chedule for selecting a supplier and establishing an agreement
(* Elaboration Examples of measures and wor1 products used in monitoring and controlling include the following: Cost, schedule, and effort expended for rewor1 'ercentage of re0uirements addressed in the product or product component design *i6e and complexity of the product, product components, interfaces, and documentation %efect density of technical solutions wor1 products *chedule for design activities
105
,"- Elaboration Examples of measures and wor1 products used in monitoring and controlling include the following: 7umber of validation activities completed 2planned versus actual3 ,alidation problem report trends 2e.g., number written, number closed3 ,alidation problem report aging 2i.e., how long each problem report has been open3 *chedule for a specific validation activity
,E# Elaboration Examples of measures and wor1 products used in monitoring and controlling include the following:
7P 2*3
,erification profile 2e.g., the number of verifications planned and performed, and the defects found8 or defects categori6ed by verification method or type3 7umber of defects detected by defect category ,erification problem report trends 2e.g., number written, number closed3 ,erification problem report status 2i.e., how long each problem report has been open3 *chedule for a specific verification activity 'eer review effectiveness
Ob0e#t"ve&1 Eva&/ate A+-ere #e
6'/ecti)ely e)aluate adherence of the process and selected 3or4 products against the process description* standards* and procedures* and address noncompliance.
T$e purpose of t$is +eneric practice is to provide credi)le assurance t$at t$e process and selected 'or2 products are implemented as planned and ad$ere to t$e process description, standards, and procedures. ( ee t$e definition of Lo)4ectivel* evaluateM in t$e +lossar*., "efer to the Process and Product 4uality $ssurance process area for more information about ob.ectively evaluating processes and wor1 products% People not directl* responsi)le for mana+in+ or performin+ t$e activities of t$e process t*picall* evaluate ad$erence. In man* cases, ad$erence is evaluated )* people in t$e or+ani-ation, )ut e5ternal to t$e process or pro4ect, or )* people e5ternal to t$e or+ani-ation. 0s a result, credi)le assurance of ad$erence can )e provided even durin+ times '$en t$e process is under stress (e.+., '$en t$e effort is )e$ind sc$edule, '$en t$e effort is over )ud+et,. C"# Elaboration Examples of activities reviewed include the following: %etermining causes of outcomes Evaluating results of action plans
106
Examples of wor1 products reviewed include the following: "ction proposals selected for implementation Causal analysis and resolution records
C$ Elaboration Examples of activities reviewed include the following: Establishing baselines (rac1ing and controlling changes Establishing and maintaining the integrity of baselines
Examples of wor1 products reviewed include the following: "rchives of baselines Change re0uest database
%"# Elaboration Examples of activities reviewed include the following: Evaluating alternatives using established criteria and methods
Examples of wor1 products reviewed include the following: uidelines for when to apply a formal evaluation process Evaluation reports containing recommended solutions
&'$ Elaboration Examples of activities reviewed include the following: Establishing, maintaining, and using the project9s defined process Coordinating and collaborating with relevant sta1eholders :sing the project?s shared vision Organi6ing teams
Examples of wor1 products reviewed include the following: 'roject9s defined process 'roject plans Other plans that affect the project 4or1 environment standards *hared vision statements (eam structure (eam charters
108
$" Elaboration Examples of activities reviewed include the following: "ligning measurement and analysis activities 'roviding measurement results
Examples of wor1 products reviewed include the following: *pecifications of base and derived measures %ata collection and storage procedures "nalysis results and draft reports
O'% Elaboration Examples of activities reviewed include the following: Establishing organi6ational process assets %etermining rules and guidelines for structuring and forming teams
Examples of wor1 products reviewed include the following: Organi6ation9s set of standard processes %escriptions of lifecycle models (ailoring guidelines for the organi6ation9s set of standard processes Organi6ation9s measurement data Empowerment rules and guidelines for people and teams Organi6ational process documentation
O'F Elaboration Examples of activities reviewed include the following: %etermining process improvement opportunities 'lanning and coordinating process improvement activities %eploying the organi6ation9s set of standard processes on projects at their startup
Examples of wor1 products reviewed include the following: 'rocess improvement plans 'rocess action plans 'rocess deployment plans 'lans for the organi6ation9s process appraisals
10<
O'$ Elaboration Examples of activities reviewed include the following: "naly6ing process performance data to determine the organi6ation9s ability to meet identified business objectives *electing improvements using 0uantitative analysis %eploying improvements $easuring effectiveness of the deployed improvements using statistical and other 0uantitative techni0ues
Examples of wor1 products reviewed include the following: &mprovement proposals %eployment plans #evised improvement measures, objectives, priorities, and deployment plans :pdated process documentation and training material
O'' Elaboration Examples of activities reviewed include the following: Establishing process performance baselines and models
Examples of wor1 products reviewed include the following: 'rocess performance baselines Organi6ation9s 0uality and process performance objectives %efinitions of the selected measures of process performance
O( Elaboration Examples of activities reviewed include the following: &dentifying training needs and ma1ing training available 'roviding necessary training
Examples of wor1 products reviewed include the following: Organi6ational training tactical plan (raining materials and supporting artifacts &nstructor evaluation forms
103
'& Elaboration Examples of activities reviewed include the following: Establishing and maintaining a product integration strategy Ensuring interface compatibility "ssembling product components and delivering the product
Examples of wor1 products reviewed include the following: 'roduct integration strategy 'roduct integration procedures and criteria "cceptance documents for the received product components "ssembled product and product components
'$C Elaboration Examples of activities reviewed include the following: $onitoring project progress and performance against the project plan $anaging corrective actions to closure
Examples of wor1 products reviewed include the following: #ecords of project progress and performance 'roject review results
'' Elaboration Examples of activities reviewed include the following: Establishing estimates %eveloping the project plan Obtaining commitments to the project plan
Examples of wor1 products reviewed include the following: 4;* 'roject plan %ata management plan *ta1eholder involvement plan
'')" Elaboration Examples of activities reviewed include the following: Objectively evaluating processes and wor1 products (rac1ing and communicating noncompliance issues
110
Examples of wor1 products reviewed include the following: 7oncompliance reports Evaluation logs and reports
)'$ Elaboration Examples of activities reviewed include the following: $anaging the project using 0uality and process performance objectives $anaging selected subprocesses using statistical and other 0uantitative techni0ues
Examples of wor1 products reviewed include the following: Compositions of the project9s defined process Operational definitions of the measures 'rocess performance analyses reports Collected measurements
#% Elaboration Examples of activities reviewed include the following: Collecting sta1eholder needs Formulating product and product component functional and 0uality attribute re0uirements Formulating architectural re0uirements that specify how product components are organi6ed and designed to achieve particular end5to5end functional and 0uality attribute re0uirements "naly6ing and validating product and product component re0uirements
Examples of wor1 products reviewed include the following: 'roduct re0uirements 'roduct component re0uirements &nterface re0uirements %efinition of re0uired functionality and 0uality attributes "rchitecturally significant 0uality attribute re0uirements
#E)$ Elaboration Examples of activities reviewed include the following: $anaging re0uirements Ensuring alignment among project plans, wor1 products, and re0uirements
111
Examples of wor1 products reviewed include the following: #e0uirements #e0uirements traceability matrix
#*+$ Elaboration Examples of activities reviewed include the following: Establishing and maintaining a ris1 management strategy &dentifying and analy6ing ris1s $itigating ris1s
Examples of wor1 products reviewed include the following: #is1 management strategy #is1 mitigation plans
*"$ Elaboration Examples of activities reviewed include the following: Establishing and maintaining supplier agreements *atisfying supplier agreements
Examples of wor1 products reviewed include the following: 'lan for supplier agreement management *upplier agreements
(* Elaboration Examples of activities reviewed include the following: *electing product component solutions %eveloping product and product component designs &mplementing product component designs
Examples of wor1 products reviewed include the following: (echnical data pac1ages 'roduct, product component, and interface designs &mplemented designs 2e.g., software code, fabricated product components3 :ser, installation, operation, and maintenance documentation
112
,"- Elaboration Examples of activities reviewed include the following: *electing the products and product components to be validated Establishing and maintaining validation methods, procedures, and criteria ,alidating products or product components
Examples of wor1 products reviewed include the following: ,alidation methods ,alidation procedures ,alidation criteria
,E# Elaboration Examples of activities reviewed include the following: *electing wor1 products for verification Establishing and maintaining verification procedures and criteria 'erforming peer reviews ,erifying selected wor1 products
Examples of wor1 products reviewed include the following:

7P 2*10
,erification procedures and criteria 'eer review chec1lists ,erification reports
Rev"ew Stat/$ w"t- H"!-er Leve& Ma a!eme t
#e)ie3 the acti)ities* status* and results of the process 3ith higher le)el management and resol)e issues.
T$e purpose of t$is +eneric practice is to provide $i+$er level mana+ement 'it$ t$e appropriate visi)ilit* into t$e process. @i+$er level mana+ement includes t$ose levels of mana+ement in t$e or+ani-ation a)ove t$e immediate level of mana+ement responsi)le for t$e process. In particular, $i+$er level mana+ement can include senior mana+ement. T$ese revie's are for mana+ers '$o provide t$e polic* and overall +uidance for t$e process and not for t$ose '$o perform t$e direct da*-to-da* monitorin+ and controllin+ of t$e process. Different mana+ers $ave different needs for information a)out t$e process. T$ese revie's $elp ensure t$at informed decisions on t$e plannin+ and performin+ of t$e process can )e made. T$erefore, t$ese revie's are e5pected to )e )ot$ periodic and event driven.
113
O'F Elaboration T$ese revie's are t*picall* in t$e form of a )riefin+ presented to t$e mana+ement steerin+ committee )* t$e process +roup and t$e process action teams. Examples of presentation topics include the following: *tatus of improvements being developed by process action teams #esults of pilots #esults of deployments *chedule status for achieving significant milestones 2e.g., readiness for an appraisal, progress toward achieving a targeted organi6ational maturity level or capability level profile3
O'$ Elaboration T$ese revie's are t*picall* in t$e form of a )riefin+ presented to $i+$er level mana+ement )* t$ose responsi)le for performance improvement. Examples of presentation topics include the following: &mprovement areas identified from analysis of current performance compared to business objectives #esults of process improvement elicitation and analysis activities #esults from validation activities 2e.g., pilots3 compared to expected benefits 'erformance data after deployment of improvements %eployment cost, schedule, and ris1 #is1s of not achieving business objectives
#E)$ Elaboration Proposed c$an+es to commitments to )e made e5ternal to t$e or+ani-ation are revie'ed 'it$ $i+$er level mana+ement to ensure t$at all commitments can )e accomplis$ed. #*+$ Elaboration !evie's of t$e pro4ect ris2 status are $eld on a periodic and event driven )asis, 'it$ appropriate levels of mana+ement, to provide visi)ilit* into t$e potential for pro4ect ris2 e5posure and appropriate corrective action. T*picall*, t$ese revie's include a summar* of t$e most critical ris2s, 2e* ris2 parameters (suc$ as li2eli$ood and conse/uence of t$e ris2s,, and t$e status of ris2 miti+ation efforts.
114
77 3
I $t"t/t"o a&"Ae a %ef" e+ Pro#e$$
The process is institutionali5ed as a defined process.

7P 3*1 E$tab&"$- a %ef" e+ Pro#e$$
+sta'lish and maintain the description of a defined process.

T$e purpose of t$is +eneric practice is to esta)lis$ and maintain a description of t$e process t$at is tailored from t$e or+ani-ation;s set of standard processes to address t$e needs of a specific instantiation. T$e or+ani-ation s$ould $ave standard processes t$at cover t$e process area, as 'ell as $ave +uidelines for tailorin+ t$ese standard processes to meet t$e needs of a pro4ect or or+ani-ational function. 6it$ a defined process, varia)ilit* in $o' t$e processes are performed across t$e or+ani-ation is reduced and process assets, data, and learnin+ can )e effectivel* s$ared. "efer to the Integrated Pro.ect Management process area for more information about establishing the pro.ect3s defined process% "efer to the 0rgani-ational Process efinition process area for more information about establishing standard processes and establishing tailoring criteria and guidelines% T$e descriptions of t$e defined processes provide t$e )asis for plannin+, performin+, and mana+in+ t$e activities, 'or2 products, and services associated 'it$ t$e process.
S/b'ra#t"#e$
1.
elect from t$e or+ani-ation;s set of standard processes t$ose processes t$at cover t$e process area and )est meet t$e needs of t$e pro4ect or or+ani-ational function. Esta)lis$ t$e defined process )* tailorin+ t$e selected processes accordin+ to t$e or+ani-ation;s tailorin+ +uidelines. Ensure t$at t$e or+ani-ation;s process o)4ectives are appropriatel* addressed in t$e defined process. Document t$e defined process and t$e records of t$e tailorin+. !evise t$e description of t$e defined process as necessar*.
". 3. 8. 9.
7P 3*2
Co&&e#t Pro#e$$ Re&ate+ E,'er"e #e$
Collect process related e,periences deri)ed from planning and performing the process to support the future use and impro)ement of the organi5ation7s processes and process assets.
T$e purpose of t$is +eneric practice is to collect process related e5periences, includin+ information and artifacts derived from plannin+ and performin+ t$e process. E5amples of process related e5periences include 'or2 products, measures, measurement results, lessons learned, and process improvement su++estions. T$e information and artifacts are collected so t$at t$e* can )e included in t$e or+ani-ational process assets and made availa)le to t$ose '$o are (or '$o 'ill )e, plannin+ and
115
performin+ t$e same or similar processes. T$e information and artifacts are stored in t$e or+ani-ation;s measurement repositor* and t$e or+ani-ation;s process asset li)rar*. Examples of relevant information include the effort expended for the various activities, defects injected or removed in a particular activity, and lessons learned. "efer to the Integrated Pro.ect Management process area for more information about contributing to organi-ational process assets% "efer to the 0rgani-ational Process efinition process area for more information about establishing organi-ational process assets%
S/b'ra#t"#e$
1.
tore process and product measures in t$e or+ani-ation;s measurement repositor*. (he process and product measures are primarily those measures that are defined in the common set of measures for the organi6ation9s set of standard processes.
". 3. 8.
u)mit documentation for inclusion in t$e or+ani-ation;s process asset li)rar*. Document lessons learned from t$e process for inclusion in t$e or+ani-ation;s process asset li)rar*. Propose improvements to t$e or+ani-ational process assets.
C"# Elaboration Examples of process related experiences include the following: "ction proposals 7umber of action plans that are open and for how long "ction plan status reports
C$ Elaboration Examples of process related experiences include the following: (rends in the status of configuration items Configuration audit results Change re0uest aging reports
%"# Elaboration Examples process related experiences include the following: 7umber of alternatives considered Evaluation results #ecommended solutions to address significant issues
116
&'$ Elaboration Examples of process related experiences include the following: 'roject9s defined process 7umber of tailoring options exercised by the project to create its defined process &nterface coordination issue trends 2i.e., number identified, number closed3 7umber of times the process asset library is accessed for assets related to project planning by project members #ecords of expenses related to holding face5to5face meetings versus holding meetings using collaborative e0uipment such as teleconferencing and videoconferencing 'roject shared vision (eam charters
$" Elaboration Examples of process related experiences include the following: %ata currency status #esults of data integrity tests %ata analysis reports
O'% Elaboration Examples of process related experiences include the following: *ubmission of lessons learned to the organi6ation?s process asset library *ubmission of measurement data to the organi6ation?s measurement repository *tatus of the change re0uests submitted to modify the organi6ation?s standard process #ecord of non5standard tailoring re0uests
O'F Elaboration Examples of process related experiences include the following: Criteria used to prioriti6e candidate process improvements "ppraisal findings that address strengths and wea1nesses of the organi6ation?s processes *tatus of improvement activities against the schedule #ecords of tailoring the organi6ation9s set of standard processes and implementing them on identified projects
118
O'$ Elaboration Examples of process related experiences include the following: -essons learned captured from analysis of process performance data compared to business objectives %ocumented measures of the costs and benefits resulting from implementing and deploying improvements #eport of a comparison of similar development processes to identify the potential for improving efficiency
O'' Elaboration Examples of process related experiences include the following: 'rocess performance baselines 'ercentage of measurement data that is rejected because of inconsistencies with the process performance measurement definitions
O( Elaboration Examples of process related experiences include the following: #esults of training effectiveness surveys (raining program performance assessment results Course evaluations (raining re0uirements from an advisory group
'& Elaboration Examples of process related experiences include the following: #ecords of the receipt of product components, exception reports, confirmation of configuration status, and results of readiness chec1ing 'ercentage of total development effort spent in product integration 2actual to date plus estimate to complete3 %efects found in the product and test environment during product integration 'roblem reports resulting from product integration
'$C Elaboration Examples of process related experiences include the following: #ecords of significant deviations Criteria for what constitutes a deviation Corrective action results
11<
'' Elaboration Examples of process related experiences include the following: 'roject data library structure 'roject attribute estimates #is1 impacts and probability of occurrence
'')" Elaboration Examples of process related experiences include the following: Evaluation logs )uality trends 7oncompliance reports *tatus reports of corrective actions Cost of 0uality reports for the project
)'$ Elaboration Examples of process related experiences include the following: #ecords of 0uantitative management data from the project, including results from the periodic review of the process performance of the subprocesses selected for management against established interim objectives of the project *uggested improvements to process performance models
#% Elaboration Examples of process related experiences include the following: -ist of the re0uirements for a product that are found to be ambiguous 7umber of re0uirements introduced at each phase of the project lifecycle -essons learned from the re0uirements allocation process
#E)$ Elaboration Examples of process related experiences include the following: #e0uirements traceability matrix 7umber of unfunded re0uirements changes after baselining -essons learned in resolving ambiguous re0uirements
#*+$ Elaboration Examples of process related experiences include the following: #is1 parameters #is1 categories #is1 status reports
113
*"$ Elaboration Examples of process related experiences include the following: #esults of supplier reviews (rade studies used to select suppliers #evision history of supplier agreements *upplier performance reports
(* Elaboration Examples of process related experiences include the following: #esults of the ma1e, buy, or reuse analysis %esign defect density #esults of applying new methods and tools
,"- Elaboration Examples of process related experiences include the following: 'roduct component prototype 'ercentage of time the validation environment is available 7umber of product defects found through validation per development phase ,alidation analysis report
,E# Elaboration Examples of process related experiences include the following: 'eer review records that include conduct time and average preparation time 7umber of product defects found through verification per development phase ,erification and analysis report
Appl"ing /eneric Practices
3eneric practices are components t$at can )e applied to all process areas. T$in2 of +eneric practices as reminders. T$e* serve t$e purpose of remindin+ *ou to do t$in+s ri+$t and are e5pected model components. 1or e5ample, consider t$e +eneric practice, LEsta)lis$ and maintain t$e plan for performin+ t$e processM (3P ".",. 6$en applied to t$e Pro4ect Plannin+ process area, t$is +eneric practice reminds *ou to plan t$e activities involved in creatin+ t$e plan for t$e pro4ect. 6$en applied to t$e 7r+ani-ational Trainin+ process area, t$is same +eneric practice reminds *ou to plan t$e activities involved in developin+ t$e s2ills and 2no'led+e of people in t$e or+ani-ation.
120
Process Areas that )upport /eneric Practices
6$ile +eneric +oals and +eneric practices are t$e model components t$at directl* address t$e institutionali-ation of a process across t$e or+ani-ation, man* process areas li2e'ise address institutionali-ation )* supportin+ t$e implementation of t$e +eneric practices. Nno'in+ t$ese relations$ips 'ill $elp *ou effectivel* implement t$e +eneric practices. uc$ process areas contain one or more specific practices t$at '$en implemented can also full* implement a +eneric practice or +enerate a 'or2 product t$at is used in t$e implementation of a +eneric practice. 0n e5ample is t$e Confi+uration Mana+ement process area and 3P ".G, LPlace selected 'or2 products of t$e process under appropriate levels of control.M To implement t$e +eneric practice for one or more process areas, *ou mi+$t c$oose to implement t$e Confi+uration Mana+ement process area, all or in part, to implement t$e +eneric practice. 0not$er e5ample is t$e 7r+ani-ational Process Definition process area and 3P 3.1, LEsta)lis$ and maintain t$e description of a defined process.M To implement t$is +eneric practice for one or more process areas, *ou s$ould first implement t$e 7r+ani-ational Process Definition process area, all or in part, to esta)lis$ t$e or+ani-ational process assets t$at are needed to implement t$e +eneric practice. Ta)le G." descri)es (1, t$e process areas t$at support t$e implementation of +eneric practices and (", t$e recursive relations$ips )et'een +eneric practices and t$eir closel* related process areas. .ot$ t*pes of relations$ips are important to remem)er durin+ process improvement to ta2e advanta+e of t$e natural s*ner+ies t$at e5ist )et'een t$e +eneric practices and t$eir related process areas.
121
Ta'le 6.2 &eneric !ractice and !rocess "rea #elationships Generic Practice 3P "." Plan t$e Process 3P ".3 Provide !esources 3P ".8 0ssi+n !esponsi)ilit* "oles of Process $reas in Implementation of the Generic Practice Pro0e#t P&a " !2 T$e pro4ect plannin+ process can implement 3P "." in full for all pro4ect related process areas (e5cept for Pro4ect Plannin+ itself,. Pro0e#t P&a " !2 T$e part of t$e pro4ect plannin+ process t$at implements Pro4ect Plannin+ P ".8, LPlan t$e Pro4ect;s !esources,M supports t$e implementation of 3P ".3 and 3P ".8 for all pro4ect related process areas (e5cept per$aps initiall* for Pro4ect Plannin+ itself, )* identif*in+ needed processes, roles, and responsi)ilities to ensure t$e proper staffin+, facilities, e/uipment, and ot$er assets needed )* t$e pro4ect are secured. Or!a "Aat"o a& Tra" " !2 T$e or+ani-ational trainin+ process supports t$e implementation of 3P ".9 as applied to all process areas )* ma2in+ t$e trainin+ t$at addresses strate+ic or or+ani-ation-'ide trainin+ needs availa)le to t$ose '$o 'ill perform or support t$e process. Pro0e#t P&a " !2 T$e part of t$e pro4ect plannin+ process t$at implements Pro4ect Plannin+ P ".9, LPlan <eeded Nno'led+e and 2ills,M and t$e or+ani-ational trainin+ process, supports t$e implementation of 3P ".9 in full for all pro4ect related process areas. 3P ".G Control 6or2 Products Co f"!/rat"o Ma a!eme t2 T$e confi+uration mana+ement process can implement 3P ".G in full for all pro4ect related process areas as 'ell as some of t$e or+ani-ational process areas. 3P ".G applied to t$e confi+uration mana+ement process covers c$an+e and version control for t$e 'or2 products produced )* confi+uration mana+ement activities. 3P ".9 applied to t$e or+ani-ational trainin+ process covers trainin+ for performin+ t$e or+ani-ational trainin+ activities, '$ic$ addresses t$e s2ills re/uired to mana+e, create, and accomplis$ t$e trainin+. 5ow the Generic Practice "ecursively $pplies to its "elated Process $rea6s711 3P "." applied to t$e pro4ect plannin+ process can )e c$aracteri-ed as Lplan t$e planM and covers plannin+ pro4ect plannin+ activities.
3P ".9 Train People
11
6$en t$e relations$ip )et'een a +eneric practice and a process area is less direct, t$e ris2 of confusion is reducedI t$erefore, 'e do not descri)e all recursive relations$ips in t$e ta)le (e.+., for +eneric practices ".3, ".8, and ".1#,.
122
Generic Practice 3P ".= Identif* and Involve !elevant ta2e$olders
"oles of Process $reas in Implementation of the Generic Practice Pro0e#t P&a " !2 T$e part of t$e pro4ect plannin+ process t$at implements Pro4ect Plannin+ P ".G, LPlan ta2e$older Involvement,M can implement t$e sta2e$older identification part (first t'o su)practices, of 3P ".= in full for all pro4ect related process areas. Pro0e#t Mo "tor" ! a + Co tro&2 T$e part of t$e pro4ect monitorin+ and control process t$at implements Pro4ect Monitorin+ and Control P 1.9, LMonitor ta2e$older Involvement,M can aid in implementin+ t$e t$ird su)practice of 3P ".= for all pro4ect related process areas. I te!rate+ Pro0e#t Ma a!eme t2 T$e part of t$e inte+rated pro4ect mana+ement process t$at implements Inte+rated Pro4ect Mana+ement P ".1, LMana+e ta2e$older Involvement,M can aid in implementin+ t$e t$ird su)practice of 3P ".= for all pro4ect related process areas.
5ow the Generic Practice "ecursively $pplies to its "elated Process $rea6s7 3P ".= applied to t$e pro4ect plannin+ process covers t$e involvement of relevant sta2e$olders in pro4ect plannin+ activities. 3P ".= applied to t$e pro4ect monitorin+ and control process covers t$e involvement of relevant sta2e$olders in pro4ect monitorin+ and control activities. 3P ".= applied to t$e inte+rated pro4ect mana+ement process covers t$e involvement of relevant sta2e$olders in inte+rated pro4ect mana+ement activities.
3P ".H Monitor and Control t$e Process
Pro0e#t Mo "tor" ! a + Co tro&2 T$e pro4ect monitorin+ and control process can implement 3P ".H in full for all pro4ect related process areas. Mea$/reme t a + A a&1$"$2 1or all processes, not 4ust pro4ect related processes, t$e Measurement and 0nal*sis process area provides +eneral +uidance a)out measurin+, anal*-in+, and recordin+ information t$at can )e used in esta)lis$in+ measures for monitorin+ performance of t$e process.
3P ".H applied to t$e pro4ect monitorin+ and control process covers t$e monitorin+ and controllin+ of t$e pro4ect;s monitor and control activities.
3P ".F 7)4ectivel* Evaluate 0d$erence
Pro#e$$ a + Pro+/#t @/a&"t1 A$$/ra #e2 T$e process and product /ualit* assurance process can implement 3P ".F in full for all process areas (e5cept per$aps for Process and Product Bualit* 0ssurance itself,.
3P ".F applied to t$e process and product /ualit* assurance process covers t$e o)4ective evaluation of /ualit* assurance activities and selected 'or2 products.
123
Generic Practice 3P ".1# !evie' tatus 'it$ @i+$er Aevel Mana+ement
"oles of Process $reas in Implementation of the Generic Practice Pro0e#t Mo "tor" ! a + Co tro&2 T$e part of t$e pro4ect monitorin+ and control process t$at implements Pro4ect Monitorin+ and Control P 1.G, LConduct Pro+ress !evie's,M and P 1.=, LConduct Milestone !evie's,M supports t$e implementation of 3P ".1# for all pro4ect related process areas, per$aps in full, dependin+ on $i+$er level mana+ement involvement in t$ese revie's. I te!rate+ Pro0e#t Ma a!eme t2 T$e part of t$e inte+rated pro4ect mana+ement process t$at implements Inte+rated Pro4ect Mana+ement P 1.1, LEsta)lis$ t$e Pro4ect;s Defined Process,M can implement 3P 3.1 in full for all pro4ect related process areas. Or!a "Aat"o a& Pro#e$$ %ef" "t"o 2 1or all processes, not 4ust pro4ect related processes, t$e or+ani-ational process definition process esta)lis$es t$e or+ani-ational process assets needed to implement 3P 3.1.
5ow the Generic Practice "ecursively $pplies to its "elated Process $rea6s7
3P 3.1 Esta)lis$ a Defined Process
3P 3.1 applied to t$e inte+rated pro4ect mana+ement process covers esta)lis$in+ defined processes for inte+rated pro4ect mana+ement activities.
3P 3." Collect Process !elated E5periences
I te!rate+ Pro0e#t Ma a!eme t2 T$e part of t$e inte+rated pro4ect mana+ement process t$at implements Inte+rated Pro4ect Mana+ement P 1.=, LContri)ute to 7r+ani-ational Process 0ssets,M can implement 3P 3." in part or in full for all pro4ect related process areas. Or!a "Aat"o a& Pro#e$$ .o#/$2 T$e part of t$e or+ani-ational process focus process t$at implements 7r+ani-ational Process 1ocus P 3.8, LIncorporate E5periences into 7r+ani-ational Process 0ssets,M can implement 3P 3." in part or in full for all process areas. Or!a "Aat"o a& Pro#e$$ %ef" "t"o 2 1or all processes, t$e or+ani-ational process definition process esta)lis$es t$e or+ani-ational process assets needed to implement 3P 3.".
3P 3." applied to t$e inte+rated pro4ect mana+ement process covers collectin+ process related e5periences derived from plannin+ and performin+ inte+rated pro4ect mana+ement activities.
124
3iven t$e dependencies t$at +eneric practices $ave on t$ese process areas, and +iven t$e more $olistic vie' t$at man* of t$ese process areas provide, t$ese process areas are often implemented earl*, in '$ole or in part, )efore or concurrent 'it$ implementin+ t$e associated +eneric practices. T$ere are also a fe' situations '$ere t$e result of appl*in+ a +eneric practice to a particular process area 'ould seem to ma2e a '$ole process area redundant, )ut, in fact, it does not. It can )e natural to t$in2 t$at appl*in+ 3P 3.1, LEsta)lis$ a Defined Process,M to t$e Pro4ect Plannin+ and Pro4ect Monitorin+ and Control process areas +ives t$e same effect as t$e first specific +oal of Inte+rated Pro4ect Mana+ement, L:se t$e Pro4ect;s Defined Process.M 0lt$ou+$ it is true t$at t$ere is some overlap, t$e application of t$e +eneric practice to t$ese t'o process areas provides defined processes coverin+ pro4ect plannin+ and pro4ect monitorin+ and control activities. T$ese defined processes do not necessaril* cover support activities (e.+., confi+uration mana+ement,, ot$er pro4ect mana+ement processes (e.+., inte+rated pro4ect mana+ement,, or ot$er processes. In contrast, t$e pro4ect;s defined process, provided )* t$e Inte+rated Pro4ect Mana+ement process area, covers all appropriate processes.
125
126
!AU)A+ A*A+-)I) A*D R$)O+U(IO*

A Support Process Area at Maturity Level 5
Purpose
T$e purpose of Causal 0nal*sis and !esolution (C0!, is to identif* causes of selected outcomes and ta2e action to improve process performance.
Introductor" *otes
Causal anal*sis and resolution improves /ualit* and productivit* )* preventin+ t$e introduction of defects or pro)lems and )* identif*in+ and appropriatel* incorporatin+ t$e causes of superior process performance. T$e Causal 0nal*sis and !esolution process area involves t$e follo'in+ activities% Identif*in+ and anal*-in+ causes of selected outcomes. T$e selected outcomes can represent defects and pro)lems t$at can )e prevented from $appenin+ in t$e future or successes t$at can )e implemented in pro4ects or t$e or+ani-ation. Ta2in+ actions to complete t$e follo'in+% o !emove causes and prevent t$e recurrence of t$ose t*pes of defects and pro)lems in t$e future o Proactivel* anal*-e data to identif* potential pro)lems and prevent t$em from occurrin+ o Incorporate t$e causes of successes into t$e process to improve future process performance !eliance on detectin+ defects and pro)lems after t$e* $ave )een introduced is not cost effective. It is more effective to prevent defects and pro)lems )* inte+ratin+ Causal 0nal*sis and !esolution activities into eac$ p$ase of t$e pro4ect. ince similar outcomes ma* $ave )een previousl* encountered in ot$er pro4ects or in earlier p$ases or tas2s of t$e current pro4ect, Causal 0nal*sis and !esolution activities are mec$anisms for communicatin+ lessons learned amon+ pro4ects. T*pes of outcomes encountered are anal*-ed to identif* trends. .ased on an understandin+ of t$e defined process and $o' it is implemented, root causes of t$ese outcomes and future implications of t$em are determined. ince it is impractical to perform causal anal*sis on all outcomes, tar+ets are selected )* tradeoffs on estimated investments and estimated returns of /ualit*, productivit*, and c*cle time. Measurement and anal*sis processes s$ould alread* )e in place. E5istin+ defined measures can )e used, t$ou+$ in some instances ne'
Ca/$a& A a&1$"$ a + Re$o&/t"o :CAR;
128
measurement definitions, redefinitions, or clarified definitions ma* )e needed to anal*-e t$e effects of a process c$an+e. "efer to the Measurement and $nalysis process area for more information about aligning measurement and analysis activities and providing measurement results% Causal 0nal*sis and !esolution activities provide a mec$anism for pro4ects to evaluate t$eir processes at t$e local level and loo2 for improvements t$at can )e implemented. 6$en improvements are 4ud+ed to )e effective, t$e information is su)mitted to t$e or+ani-ational level for potential deplo*ment in t$e or+ani-ational processes. T$e specific practices of t$is process area appl* to a process t$at is selected for /uantitative mana+ement. :se of t$e specific practices of t$is process area can add value in ot$er situations, )ut t$e results ma* not provide t$e same de+ree of impact to t$e or+ani-ation;s /ualit* and process performance o)4ectives.
Related Process Areas
"efer to the Measurement and $nalysis process area for more information about aligning measurement and analysis activities and providing measurement results% "efer to the 0rgani-ational Performance Management process area for more information about selecting and implementing improvements for deployment% "efer to the 4uantitative Pro.ect Management process area for more information about ,uantitatively managing the pro.ect to achieve the pro.ect3s established ,uality and process performance ob.ectives%
)pecific /oal and Practice )ummar"
3 1 Determine Causes of elected 7utcomes P 1.1 P 1." P ".1 P "." P ".3 elect 7utcomes for 0nal*sis 0nal*-e Causes Implement 0ction Proposals Evaluate t$e Effect of Implemented 0ctions !ecord Causal 0nal*sis Data
3 " 0ddress Causes of elected 7utcomes
)pecific Practices b" /oal S7 1 %eterm" e Ca/$e$ of Se&e#te+ O/t#ome$
#oot causes of selected outcomes are systematically determined.

0 root cause is an initiatin+ element in a causal c$ain '$ic$ leads to an outcome of interest.
12<
SP 1*1
Se&e#t O/t#ome$ for A a&1$"$
elect outcomes for analysis.

T$is activit* could )e tri++ered )* an event (reactive, or could )e planned periodicall*, suc$ as at t$e )e+innin+ of a ne' p$ase or tas2 (proactive,.
1. ". 3. 1.
Data to )e used in t$e initial anal*sis Initial anal*sis results data 7utcomes selected for furt$er anal*sis 3at$er relevant data. Examples of relevant data include the following:
%efects reported by customers or end users %efects found in peer reviews or testing 'roductivity measures that are higher than expected 'roject management problem reports re0uiring corrective action 'rocess capability problems Earned value measurements by process 2e.g., cost performance index3 #esource throughput, utili6ation, or response time measurements *ervice fulfillment or service satisfaction problems
S/b'ra#t"#e$
".
Determine '$ic$ outcomes to anal*-e furt$er. 4hen determining which outcomes to analy6e further, consider their source, impact, fre0uency of occurrence, similarity, the cost of analysis, the time and resources needed, safety considerations, etc. Examples of methods for selecting outcomes include the following:
'areto analysis /istograms ;ox and whis1er plots for attributes Failure mode and effects analysis 2F$E"3 'rocess capability analysis
3.
1ormall* define t$e scope of t$e anal*sis, includin+ a clear definition of t$e improvement needed or e5pected, sta2e$olders affected, tar+et affected, etc. "efer to the ecision $nalysis and "esolution process area for more information about analy-ing possible decisions using a formal evaluation process that evaluates identified alternatives against established criteria%
123
SP 1*2
A a&1Ae Ca/$e$
!erform causal analysis of selected outcomes and propose actions to address them.
T$e purpose of t$is anal*sis is to define actions t$at 'ill address selected outcomes )* anal*-in+ relevant outcome data and producin+ action proposals for implementation.
1. ". 1.
!oot cause anal*sis results 0ction proposal Conduct causal anal*sis 'it$ t$ose '$o are responsi)le for performin+ t$e tas2. Causal analysis is performed, typically in meetings, with those who understand the selected outcome under study. (hose who have the best understanding of the selected outcome are typically those who are responsible for performing the tas1. (he analysis is most effective when applied to real time data, as close as possible to the event which triggered the outcome. Examples of when to perform causal analysis include the following:
4hen a stable subprocess does not meet its specified 0uality and process performance objectives, or when a subprocess needs to be stabili6ed %uring the tas1, if and when problems warrant a causal analysis meeting 4hen a wor1 product exhibits an unexpected deviation from its re0uirements 4hen more defects than anticipated escape from earlier phases to the current phase 4hen process performance exceeds expectations "t the start of a new phase or tas1
S/b'ra#t"#e$
"efer to the 4uantitative Pro.ect Management process area for more information about performing root cause analysis% ". 0nal*-e selected outcomes to determine t$eir root causes. "nalysis of process performance baselines and models can aid in the identification of potential root causes. %epending on the type and number of outcomes, it can be beneficial to loo1 at the outcomes in several ways to ensure all potential root causes are investigated. Consider loo1ing at individual outcomes as well as grouping the outcomes. Examples of methods to determine root causes include the following:
Cause5and5effect 2fishbone3 diagrams Chec1 sheets
3.
Com)ine selected outcomes into +roups )ased on t$eir root causes. &n some cases, outcomes can be influenced by multiple root causes.
130
Examples of cause groups or categories include the following:

&nade0uate training and s1ills ;rea1down of communication 7ot accounting for all details of a tas1 $a1ing mista1es in manual procedures 2e.g., 1eyboard entry3 'rocess deficiency
4here appropriate, loo1 for trends or symptoms in or across groupings. 8. Create an action proposal t$at documents actions to )e ta2en to prevent t$e future occurrence of similar outcomes or to incorporate )est practices into processes. 'rocess performance models can support cost benefit analysis of action proposals through prediction of impacts and return on investment. Examples of proposed preventative actions include changes to the following:
(he process in 0uestion (raining (ools $ethods 4or1 products
Examples of incorporating best practices include the following:

Creating activity chec1lists, which reinforce training or communications related to common problems and techni0ues for preventing them Changing a process so that error5prone steps do not occur "utomating all or part of a process #eordering process activities "dding process steps, such as tas1 1ic1off meetings to review common problems as well as actions to prevent them
131
"n action proposal usually documents the following:

Originator of the action proposal %escription of the outcome to be addressed %escription of the cause Cause category 'hase identified %escription of the action (ime, cost, and other resources re0uired to implement the action proposal Expected benefits from implementing the action proposal Estimated cost of not fixing the problem "ction proposal category
S7 2
A++re$$ Ca/$e$ of Se&e#te+ O/t#ome$
#oot causes of selected outcomes are systematically addressed.

Pro4ects operatin+ accordin+ to a 'ell-defined process s*stematicall* anal*-e '$ere improvements are needed and implement process c$an+es to address root causes of selected outcomes.
SP 2*1 Im'&eme t A#t"o Pro'o$a&$
Implement selected action proposals de)eloped in causal analysis.

0ction proposals descri)e tas2s necessar* to address root causes of anal*-ed outcomes to prevent or reduce t$e occurrence or recurrence of ne+ative outcomes, or incorporate reali-ed successes. 0ction plans are developed and implemented for selected action proposals. 7nl* c$an+es t$at prove to )e of value s$ould )e considered for )road implementation.
1. ". 1.
0ction proposals selected for implementation 0ction plans 0nal*-e action proposals and determine t$eir priorities. Criteria for prioriti6ing action proposals include the following:
&mplications of not addressing the outcome Cost to implement process improvements to address the outcome Expected impact on 0uality
S/b'ra#t"#e$
'rocess performance models can be used to help identify interactions among multiple action proposals. ". elect action proposals to )e implemented. "efer to the ecision $nalysis and "esolution process area for more information about analy-ing possible decisions using a formal
132
evaluation process that evaluates identified alternatives against established criteria% 3. Create action plans for implementin+ t$e selected action proposals. Examples of information provided in an action plan include the following:
'erson responsible for implementation %etailed description of the improvement %escription of the affected areas 'eople who are to be 1ept informed of status *chedule Cost expended 7ext date that status will be reviewed #ationale for 1ey decisions %escription of implementation actions
8.
Implement action plans. (o implement action plans, the following tas1s should be performed:
$a1e assignments. Coordinate the people doing the wor1. #eview the results. (rac1 action items to closure.
Experiments may be conducted for particularly complex changes. Examples of experiments include the following:
:sing a temporarily modified process :sing a new tool
"ctions may be assigned to members of the causal analysis team, members of the project team, or other members of the organi6ation. 9. Aoo2 for similar causes t$at ma* e5ist in ot$er processes and 'or2 products and ta2e action as appropriate.
SP 2*2
Eva&/ate t-e Effe#t of Im'&eme te+ A#t"o $
+)aluate the effect of implemented actions on process performance.

"efer to the 4uantitative Pro.ect Management process area for more information about selecting measures and analytic techni,ues% 7nce t$e c$an+ed process is deplo*ed across t$e pro4ect, t$e effect of c$an+es is evaluated to verif* t$at t$e process c$an+e $as improved process performance.
1.
0nal*sis of process performance and c$an+e in process performance
133
S/b'ra#t"#e$
1.
Measure and anal*-e t$e c$an+e in process performance of t$e pro4ect;s affected processes or su)processes. (his subpractice determines whether the selected change has positively influenced process performance and by how much. "n example of a change in the process performance of the project9s defined design process would be a change in the predicted ability of the design to meet the 0uality and process performance objectives. "nother example would be a change in the defect density of the design documentation, as statistically measured through peer reviews before and after the improvement has been made. On a statistical process control chart, this change in process performance would be represented by an improvement in the mean, a reduction in variation, or both. *tatistical and other 0uantitative techni0ues 2e.g., hypothesis testing3 can be used to compare the before and after baselines to assess the statistical significance of the change.
".
Determine t$e impact of t$e c$an+e on ac$ievin+ t$e pro4ect;s /ualit* and process performance o)4ectives. (his subpractice determines whether the selected change has positively influenced the ability of the project to meet its 0uality and process performance objectives by understanding how changes in the process performance data have affected the objectives. 'rocess performance models can aid in the evaluation through prediction of impacts and return on investment.
3.
Determine and document appropriate actions if t$e process or su)process improvements did not result in e5pected pro4ect )enefits.
SP 2*3
Re#or+ Ca/$a& A a&1$"$ %ata
#ecord causal analysis and resolution data for use across pro/ects and the organi5ation.
1. ". 1.
Causal anal*sis and resolution records 7r+ani-ational improvement proposals !ecord causal anal*sis data and ma2e t$e data availa)le so t$at ot$er pro4ects can ma2e appropriate process c$an+es and ac$ieve similar results. #ecord the following:
%ata on outcomes that were analy6ed #ationale for decisions "ction proposals from causal analysis meetings "ction plans resulting from action proposals
S/b'ra#t"#e$
134
Cost of analysis and resolution activities $easures of changes to the process performance of the defined process resulting from resolutions
".
u)mit process improvement proposals for t$e or+ani-ation '$en t$e implemented actions are effective for t$e pro4ect as appropriate. 4hen improvements are judged to be effective, the information can be submitted to the organi6ational level for potential inclusion in the organi6ational processes. "efer to the 0rgani-ational Performance Management process area for more information about selecting improvements%
135
136
!O*FI/URA(IO* #A*A/$#$*(
Purpose
T$e purpose of Confi+uration Mana+ement (CM, is to esta)lis$ and maintain t$e inte+rit* of 'or2 products usin+ confi+uration identification, confi+uration control, confi+uration status accountin+, and confi+uration audits.
Introductor" *otes
T$e Confi+uration Mana+ement process area involves t$e follo'in+ activities% Identif*in+ t$e confi+uration of selected 'or2 products t$at compose )aselines at +iven points in time Controllin+ c$an+es to confi+uration items .uildin+ or providin+ specifications to )uild 'or2 products from t$e confi+uration mana+ement s*stem Maintainin+ t$e inte+rit* of )aselines Providin+ accurate status and current confi+uration data to developers, end users, and customers
T$e 'or2 products placed under confi+uration mana+ement include t$e products t$at are delivered to t$e customer, desi+nated internal 'or2 products, ac/uired products, tools, and ot$er items used in creatin+ and descri)in+ t$ese 'or2 products. ( ee t$e definition of Lconfi+uration mana+ementM in t$e +lossar*.,
Co f"!/rat"o Ma a!eme t :CM;
138
Examples of wor1 products that can be placed under configuration management include the following: /ardware and e0uipment %rawings 'roduct specifications (ool configurations Code and libraries Compilers (est tools and test scripts &nstallation logs 'roduct data files 'roduct technical publications 'lans :ser stories &teration bac1logs 'rocess descriptions #e0uirements "rchitecture documentation and design data 'roduct line plans, processes, and core assets
0c/uired products ma* need to )e placed under confi+uration mana+ement )* )ot$ t$e supplier and t$e pro4ect. Provisions for conductin+ confi+uration mana+ement s$ould )e esta)lis$ed in supplier a+reements. Met$ods to ensure t$at data are complete and consistent s$ould )e esta)lis$ed and maintained. "efer to the Supplier $greement Management process area for more information about establishing supplier agreements% Confi+uration mana+ement of 'or2 products can )e performed at several levels of +ranularit*. Confi+uration items can )e decomposed into confi+uration components and confi+uration units. 7nl* t$e term Lconfi+uration itemM is used in t$is process area. T$erefore, in t$ese practices, Lconfi+uration itemM ma* )e interpreted as Lconfi+uration componentM or Lconfi+uration unitM as appropriate. ( ee t$e definition of Lconfi+uration itemM in t$e +lossar*., .aselines provide a sta)le )asis for t$e continuin+ evolution of confi+uration items. "n example of a baseline is an approved description of a product that includes internally consistent versions of re0uirements, re0uirement traceability matrices, design, discipline5 specific items, and end5user documentation. .aselines are added to t$e confi+uration mana+ement s*stem as t$e* are developed. C$an+es to )aselines and t$e release of 'or2 products )uilt
13<
from t$e confi+uration mana+ement s*stem are s*stematicall* controlled and monitored via t$e confi+uration control, c$an+e mana+ement, and confi+uration auditin+ functions of confi+uration mana+ement. T$is process area applies not onl* to confi+uration mana+ement on pro4ects )ut also to confi+uration mana+ement of or+ani-ational 'or2 products suc$ as standards, procedures, reuse li)raries, and ot$er s$ared supportin+ assets. Confi+uration mana+ement is focused on t$e ri+orous control of t$e mana+erial and tec$nical aspects of 'or2 products, includin+ t$e delivered product or service. T$is process area covers t$e practices for performin+ t$e confi+uration mana+ement function and is applica)le to all 'or2 products t$at are placed under confi+uration mana+ement. 1or product lines, confi+uration mana+ement involves additional considerations due to t$e s$arin+ of core assets across t$e products in t$e product line and across multiple versions of core assets and products. ( ee t$e definition of Lproduct lineM in t$e +lossar*., &n "gile environments, configuration management 2C$3 is important because of the need to support fre0uent change, fre0uent builds 2typically daily3, multiple baselines, and multiple C$ supported wor1spaces 2e.g., for individuals, teams, and even for pair5programming3. "gile teams may get bogged down if the organi6ation doesn9t: =3 automate C$ 2e.g., build scripts, status accounting, integrity chec1ing3 and <3 implement C$ as a single set of standard services. "t its start, an "gile team should identify the individual who will be responsible to ensure C$ is implemented correctly. "t the start of each iteration, C$ support needs are re5confirmed. C$ is carefully integrated into the rhythms of each team with a focus on minimi6ing team distraction to get the job done. 2*ee @&nterpreting C$$& 4hen :sing "gile "pproachesA in 'art &.3
"efer to the Pro.ect Monitoring and Control process area for more information about monitoring the pro.ect against the plan and managing corrective action to closure% "efer to the Pro.ect Planning process area for more information about developing a pro.ect plan%
133

3 1 Esta)lis$ .aselines P 1.1 P 1." P 1.3 P ".1 P "." P 3.1 P 3." Identif* Confi+uration Items Esta)lis$ a Confi+uration Mana+ement *stem Create or !elease .aselines Trac2 C$an+e !e/uests Control Confi+uration Items Esta)lis$ Confi+uration Mana+ement !ecords Perform Confi+uration 0udits
3 " Trac2 and Control C$an+es
3 3 Esta)lis$ Inte+rit*
)pecific Practices b" /oal S7 1 E$tab&"$- 9a$e&" e$
.aselines of identified 3or4 products are esta'lished.

pecific practices to esta)lis$ )aselines are covered )* t$is specific +oal. T$e specific practices under t$e Trac2 and Control C$an+es specific +oal serve to maintain t$e )aselines. T$e specific practices of t$e Esta)lis$ Inte+rit* specific +oal document and audit t$e inte+rit* of t$e )aselines.
SP 1*1 I+e t"f1 Co f"!/rat"o Item$
Identify configuration items* components* and related 3or4 products to 'e placed under configuration management.
Confi+uration identification is t$e selection and specification of t$e follo'in+% Products delivered to t$e customer Desi+nated internal 'or2 products 0c/uired products Tools and ot$er capital assets of t$e pro4ect;s 'or2 environment 7t$er items used in creatin+ and descri)in+ t$ese 'or2 products
Confi+uration items can include $ard'are, e/uipment, and tan+i)le assets as 'ell as soft'are and documentation. Documentation can include re/uirements specifications and interface documents. 7t$er documents t$at serve to identif* t$e confi+uration of t$e product or service, suc$ as test results, ma* also )e included. 0 Lconfi+uration itemM is an entit* desi+nated for confi+uration mana+ement, '$ic$ ma* consist of multiple related 'or2 products t$at form a )aseline. T$is lo+ical +roupin+ provides ease of identification and controlled access. T$e selection of 'or2 products for confi+uration mana+ement s$ould )e )ased on criteria esta)lis$ed durin+ plannin+.
1.
Identified confi+uration items
140
S/b'ra#t"#e$
1.
elect confi+uration items and 'or2 products t$at compose t$em )ased on documented criteria. Example criteria for selecting configuration items at the appropriate wor1 product level include the following:
4or1 products that can be used by two or more groups 4or1 products that are expected to change over time either because of errors or changes in re0uirements 4or1 products that are dependent on each other 2i.e., a change in one mandates a change in the others3 4or1 products critical to project success
Examples of wor1 products that may be part of a configuration item include the following:
%esign (est plans and procedures (est results &nterface descriptions %rawings *ource code :ser stories or story cards (he declared business case, logic, or value (ools 2e.g., compilers3 'rocess descriptions #e0uirements
". 3.
0ssi+n uni/ue identifiers to confi+uration items. pecif* t$e important c$aracteristics of eac$ confi+uration item. Example characteristics of configuration items include author, document or file type, programming language for software code files, minimum mar1etable features, and the purpose the configuration item serves.
8.
pecif* '$en eac$ confi+uration item is placed under confi+uration mana+ement.
141
Example criteria for determining when to place wor1 products under configuration management include the following:
4hen the wor1 product is ready for test *tage of the project lifecycle %egree of control desired on the wor1 product Cost and schedule limitations *ta1eholder re0uirements
9. G.
Identif* t$e o'ner responsi)le for eac$ confi+uration item. pecif* relations$ips amon+ confi+uration items. &ncorporating the types of relationships 2e.g., parent5child, dependency3 that exist among configuration items into the configuration management structure 2e.g., configuration management database3 assists in managing the effects and impacts of changes.
SP 1*2
E$tab&"$- a Co f"!/rat"o Ma a!eme t S1$tem
+sta'lish and maintain a configuration management and change management system for controlling 3or4 products.
0 confi+uration mana+ement s*stem includes t$e stora+e media, procedures, and tools for accessin+ t$e s*stem. 0 confi+uration mana+ement s*stem can consist of multiple su)s*stems 'it$ different implementations t$at are appropriate for eac$ confi+uration mana+ement environment. 0 c$an+e mana+ement s*stem includes t$e stora+e media, procedures, and tools for recordin+ and accessin+ c$an+e re/uests.
1. ". 3. 1.
Confi+uration mana+ement s*stem 'it$ controlled 'or2 products Confi+uration mana+ement s*stem access control procedures C$an+e re/uest data)ase Esta)lis$ a mec$anism to mana+e multiple levels of control. (he level of control is typically selected based on project objectives, ris1, and resources. Control levels can vary in relation to the project lifecycle, type of system under development, and specific project re0uirements. Example levels of control include the following:
:ncontrolled: "nyone can ma1e changes. 4or15in5progress: "uthors control changes. #eleased: " designated authority authori6es and controls changes and relevant sta1eholders are notified when changes are made.
S/b'ra#t"#e$
142
-evels of control can range from informal control that simply trac1s changes made when configuration items are being developed to formal configuration control using baselines that can only be changed as part of a formal configuration management process. ". 3. 8. 9. G. =. H. Provide access control to ensure aut$ori-ed access to t$e confi+uration mana+ement s*stem. tore and retrieve confi+uration items in a confi+uration mana+ement s*stem. $are and transfer confi+uration items )et'een control levels in t$e confi+uration mana+ement s*stem. tore and recover arc$ived versions of confi+uration items. tore, update, and retrieve confi+uration mana+ement records. Create confi+uration mana+ement reports from t$e confi+uration mana+ement s*stem. Preserve t$e contents of t$e confi+uration mana+ement s*stem. Examples of preservation functions of the configuration management system include the following:
;ac1up and restoration of configuration management files "rchive of configuration management files #ecovery from configuration management errors
F.
SP 1*3
!evise t$e confi+uration mana+ement structure as necessar*.
Create or Re&ea$e 9a$e&" e$
Create or release 'aselines for internal use and for deli)ery to the customer.
0 )aseline is represented )* t$e assi+nment of an identifier to a confi+uration item or a collection of confi+uration items and associated entities at a distinct point in time. 0s a product or service evolves, multiple )aselines can )e used to control development and testin+. ( ee t$e definition of L)aselineM in t$e +lossar*., @ard'are products as 'ell as soft'are and documentation s$ould also )e included in )aselines for infrastructure related confi+urations (e.+., soft'are, $ard'are, and in preparation for s*stem tests t$at include interfacin+ $ard'are and soft'are. 7ne common set of )aselines includes t$e s*stem level re/uirements, s*stem element level desi+n re/uirements, and t$e product definition at t$e end of development&)e+innin+ of production. T$ese )aselines are t*picall* referred to respectivel* as t$e Lfunctional )aseline,M Lallocated )aseline,M and Lproduct )aseline.M
143
0 soft'are )aseline can )e a set of re/uirements, desi+n, source code files and t$e associated e5ecuta)le code, )uild files, and user documentation (associated entities, t$at $ave )een assi+ned a uni/ue identifier.
1. ". 1. ". 3. 8.
S7 2
.aselines Description of )aselines 7)tain aut$ori-ation from t$e CC. )efore creatin+ or releasin+ )aselines of confi+uration items. Create or release )aselines onl* from confi+uration items in t$e confi+uration mana+ement s*stem. Document t$e set of confi+uration items t$at are contained in a )aseline. Ma2e t$e current set of )aselines readil* availa)le.
S/b'ra#t"#e$
Tra#? a + Co tro& C-a !e$
Changes to the 3or4 products under configuration management are trac4ed and controlled.
T$e specific practices under t$is specific +oal serve to maintain )aselines after t$e* are esta)lis$ed )* specific practices under t$e Esta)lis$ .aselines specific +oal.
SP 2*1 Tra#? C-a !e Re=/e$t$
Trac4 change re-uests for configuration items.

C$an+e re/uests address not onl* ne' or c$an+ed re/uirements )ut also failures and defects in 'or2 products. C$an+e re/uests are anal*-ed to determine t$e impact t$at t$e c$an+e 'ill $ave on t$e 'or2 product, related 'or2 products, t$e )ud+et, and t$e sc$edule.
1. 1. ".
C$an+e re/uests Initiate and record c$an+e re/uests in t$e c$an+e re/uest data)ase. 0nal*-e t$e impact of c$an+es and fi5es proposed in c$an+e re/uests. Changes are evaluated through activities that ensure that they are consistent with all technical and project re0uirements. Changes are evaluated for their impact beyond immediate project or contract re0uirements. Changes to an item used in multiple products can resolve an immediate issue while causing a problem in other applications. Changes are evaluated for their impact on release plans.
S/b'ra#t"#e$
144
3.
Cate+ori-e and prioriti-e c$an+e re/uests. Emergency re0uests are identified and referred to an emergency authority if appropriate. Changes are allocated to future baselines.
8.
!evie' c$an+e re/uests to )e addressed in t$e ne5t )aseline 'it$ relevant sta2e$olders and +et t$eir a+reement. Conduct the change re0uest review with appropriate participants. #ecord the disposition of each change re0uest and the rationale for the decision, including success criteria, a brief action plan if appropriate, and needs met or unmet by the change. 'erform the actions re0uired in the disposition and report results to relevant sta1eholders.
9.
Trac2 t$e status of c$an+e re/uests to closure. Change re0uests brought into the system should be handled in an efficient and timely manner. Once a change re0uest has been processed, it is critical to close the re0uest with the appropriate approved action as soon as it is practical. "ctions left open result in larger than necessary status lists, which in turn result in added costs and confusion.
SP 2*2
Co tro& Co f"!/rat"o Item$
Control changes to configuration items.

Control is maintained over t$e confi+uration of t$e 'or2 product )aseline. T$is control includes trac2in+ t$e confi+uration of eac$ confi+uration item, approvin+ a ne' confi+uration if necessar*, and updatin+ t$e )aseline.
1. ". 1. ".
!evision $istor* of confi+uration items 0rc$ives of )aselines Control c$an+es to confi+uration items t$rou+$out t$e life of t$e product or service. 7)tain appropriate aut$ori-ation )efore c$an+ed confi+uration items are entered into t$e confi+uration mana+ement s*stem. For example, authori6ation can come from the CC;, the project manager, product owner, or the customer.
S/b'ra#t"#e$
3.
C$ec2 in and c$ec2 out confi+uration items in t$e confi+uration mana+ement s*stem for incorporation of c$an+es in a manner t$at maintains t$e correctness and inte+rit* of confi+uration items.
145
Examples of chec15in and chec15out steps include the following:

Confirming that the revisions are authori6ed :pdating the configuration items "rchiving the replaced baseline and retrieving the new baseline Commenting on the changes made to the item (ying changes to related wor1 products such as re0uirements, user stories, and tests
8.
Perform revie's to ensure t$at c$an+es $ave not caused unintended effects on t$e )aselines (e.+., ensure t$at c$an+es $ave not compromised t$e safet* or securit* of t$e s*stem,. !ecord c$an+es to confi+uration items and reasons for c$an+es as appropriate. &f a proposed change to the wor1 product is accepted, a schedule is identified for incorporating the change into the wor1 product and other affected areas. Configuration control mechanisms can be tailored to categories of changes. For example, the approval considerations could be less stringent for component changes that do not affect other components. Changed configuration items are released after review and approval of configuration changes. Changes are not official until they are released.
9.
S7 3
E$tab&"$- I te!r"t1
Integrity of 'aselines is esta'lished and maintained.

T$e inte+rit* of )aselines, esta)lis$ed )* processes associated 'it$ t$e Esta)lis$ .aselines specific +oal, and maintained )* processes associated 'it$ t$e Trac2 and Control C$an+es specific +oal, is addressed )* t$e specific practices under t$is specific +oal.
SP 3*1 E$tab&"$- Co f"!/rat"o Ma a!eme t Re#or+$
+sta'lish and maintain records descri'ing configuration items.

1. ". 3. 8. 9. 1.
!evision $istor* of confi+uration items C$an+e lo+ C$an+e re/uest records tatus of confi+uration items Differences )et'een )aselines !ecord confi+uration mana+ement actions in sufficient detail so t$e content and status of eac$ confi+uration item is 2no'n and previous versions can )e recovered. Ensure t$at relevant sta2e$olders $ave access to and 2no'led+e of t$e confi+uration status of confi+uration items.
S/b'ra#t"#e$
".
146
Examples of activities for communicating configuration status include the following:

'roviding access permissions to authori6ed end users $a1ing baseline copies readily available to authori6ed end users "utomatically alerting relevant sta1eholders when items are chec1ed in or out or changed, or of decisions made regarding change re0uests
3. 8. 9. G.
pecif* t$e latest version of )aselines. Identif* t$e version of confi+uration items t$at constitute a particular )aseline. Descri)e differences )et'een successive )aselines. !evise t$e status and $istor* (i.e., c$an+es, ot$er actions, of eac$ confi+uration item as necessar*.
SP 3*2
Perform Co f"!/rat"o A/+"t$
!erform configuration audits to maintain the integrity of configuration 'aselines.

Confi+uration audits confirm t$at t$e resultin+ )aselines and documentation conform to a specified standard or re/uirement. Confi+uration item related records can e5ist in multiple data)ases or confi+uration mana+ement s*stems. In suc$ instances, confi+uration audits s$ould e5tend to t$ese ot$er data)ases as appropriate to ensure accurac*, consistenc*, and completeness of confi+uration item information. ( ee t$e definition of Lconfi+uration auditM in t$e +lossar*., Examples of audit types include the following: Functional configuration audits 2FC"s3: "udits conducted to verify that the development of a configuration item has been completed satisfactorily, that the item has achieved the functional and 0uality attribute characteristics specified in the functional or allocated baseline, and that its operational and support documents are complete and satisfactory. 'hysical configuration audits 2'C"s3: "udits conducted to verify that a configuration item, as built, conforms to the technical documentation that defines and describes it. Configuration management audits: "udits conducted to confirm that configuration management records and configuration items are complete, consistent, and accurate.
1. ". 1. ". 3.
Confi+uration audit results 0ction items 0ssess t$e inte+rit* of )aselines. Confirm t$at confi+uration mana+ement records correctl* identif* confi+uration items. !evie' t$e structure and inte+rit* of items in t$e confi+uration mana+ement s*stem.
S/b'ra#t"#e$
148
8.
Confirm t$e completeness, correctness, and consistenc* of items in t$e confi+uration mana+ement s*stem. Completeness, correctness, and consistency of the configuration management system9s content are based on re0uirements as stated in the plan and the disposition of approved change re0uests.
9. G.
Confirm compliance 'it$ applica)le confi+uration mana+ement standards and procedures. Trac2 action items from t$e audit to closure.
14<
143
D$!I)IO* A*A+-)I) A*D R$)O+U(IO*

Purpose
T$e purpose of Decision 0nal*sis and !esolution (D0!, is to anal*-e possi)le decisions usin+ a formal evaluation process t$at evaluates identified alternatives a+ainst esta)lis$ed criteria.
Introductor" *otes
T$e Decision 0nal*sis and !esolution process area involves esta)lis$in+ +uidelines to determine '$ic$ issues s$ould )e su)4ect to a formal evaluation process and appl*in+ formal evaluation processes to t$ese issues. 0 formal evaluation process is a structured approac$ to evaluatin+ alternative solutions a+ainst esta)lis$ed criteria to determine a recommended solution. 0 formal evaluation process involves t$e follo'in+ actions% Esta)lis$in+ t$e criteria for evaluatin+ alternatives Identif*in+ alternative solutions electin+ met$ods for evaluatin+ alternatives Evaluatin+ alternative solutions usin+ esta)lis$ed criteria and met$ods electin+ recommended solutions from alternatives )ased on evaluation criteria
!at$er t$an usin+ t$e p$rase Lalternative solutions to address issuesM eac$ time, in t$is process area, one of t'o s$orter p$rases are used% Lalternative solutionsM or Lalternatives.M 0 formal evaluation process reduces t$e su)4ective nature of a decision and provides a $i+$er pro)a)ilit* of selectin+ a solution t$at meets multiple demands of relevant sta2e$olders. 6$ile t$e primar* application of t$is process area is to tec$nical concerns, formal evaluation processes can )e applied to man* nontec$nical issues, particularl* '$en a pro4ect is )ein+ planned. Issues t$at $ave multiple alternative solutions and evaluation criteria lend t$emselves to a formal evaluation process. (rade studies of e0uipment or software are typical examples of formal evaluation processes. Durin+ plannin+, specific issues re/uirin+ a formal evaluation process are identified. T*pical issues include selection amon+ arc$itectural or desi+n alternatives, use of reusa)le or commercial off-t$e-s$elf (C7T ,
150
%e#"$"o A a&1$"$ a + Re$o&/t"o :%AR;
components, supplier selection, en+ineerin+ support environments or associated tools, test environments, deliver* alternatives, and lo+istics and production. 0 formal evaluation process can also )e used to address a ma2e-or-)u* decision, t$e development of manufacturin+ processes, t$e selection of distri)ution locations, and ot$er decisions. 3uidelines are created for decidin+ '$en to use formal evaluation processes to address unplanned issues. 3uidelines often su++est usin+ formal evaluation processes '$en issues are associated 'it$ medium-to$i+$-impact ris2s or '$en issues affect t$e a)ilit* to ac$ieve pro4ect o)4ectives. Definin+ an issue 'ell $elps to define t$e scope of alternatives to )e considered. T$e ri+$t scope (i.e., not too )road, not too narro', 'ill aid in ma2in+ an appropriate decision for resolvin+ t$e defined issue. 1ormal evaluation processes can var* in formalit*, t*pe of criteria, and met$ods emplo*ed. Aess formal decisions can )e anal*-ed in a fe' $ours, use fe' criteria (e.+., effectiveness, cost to implement,, and result in a oneor t'o-pa+e report. More formal decisions can re/uire separate plans, mont$s of effort, meetin+s to develop and approve criteria, simulations, protot*pes, pilotin+, and e5tensive documentation. .ot$ numeric and non-numeric criteria can )e used in a formal evaluation process. <umeric criteria use 'ei+$ts to reflect t$e relative importance of criteria. <on-numeric criteria use a su)4ective ran2in+ scale (e.+., $i+$, medium, lo',. More formal decisions can re/uire a full trade stud*. 0 formal evaluation process identifies and evaluates alternative solutions. T$e eventual selection of a solution can involve iterative activities of identification and evaluation. Portions of identified alternatives can )e com)ined, emer+in+ tec$nolo+ies can c$an+e alternatives, and t$e )usiness situation of suppliers can c$an+e durin+ t$e evaluation period. 0 recommended alternative is accompanied )* documentation of selected met$ods, criteria, alternatives, and rationale for t$e recommendation. T$e documentation is distri)uted to relevant sta2e$oldersI it provides a record of t$e formal evaluation process and rationale, '$ic$ are useful to ot$er pro4ects t$at encounter a similar issue. 6$ile some of t$e decisions made t$rou+$out t$e life of t$e pro4ect involve t$e use of a formal evaluation process, ot$ers do not. 0s mentioned earlier, +uidelines s$ould )e esta)lis$ed to determine '$ic$ issues s$ould )e su)4ect to a formal evaluation process.
"efer to the Integrated Pro.ect Management process area for more information about establishing the pro.ect3s defined process% "efer to the "is1 Management process area for more information about identifying and analy-ing ris1s and mitigating ris1s%
%e#"$"o A a&1$"$ a + Re$o&/t"o :%AR;
151

3 1 Evaluate 0lternatives P 1.1 P 1." P 1.3 P 1.8 P 1.9 P 1.G Esta)lis$ 3uidelines for Decision 0nal*sis Esta)lis$ Evaluation Criteria Identif* 0lternative olutions elect Evaluation Met$ods Evaluate 0lternative olutions elect olutions
)pecific Practices b" /oal S7 1 Eva&/ate A&ter at"ve$
Decisions are 'ased on an e)aluation of alternati)es using esta'lished criteria.

Issues re/uirin+ a formal evaluation process can )e identified at an* time. T$e o)4ective s$ould )e to identif* issues as earl* as possi)le to ma5imi-e t$e time availa)le to resolve t$em.
SP 1*1 E$tab&"$- 7/"+e&" e$ for %e#"$"o A a&1$"$
+sta'lish and maintain guidelines to determine 3hich issues are su'/ect to a formal e)aluation process.
<ot ever* decision is si+nificant enou+$ to re/uire a formal evaluation process. T$e c$oice )et'een t$e trivial and t$e trul* important is unclear 'it$out e5plicit +uidance. 6$et$er a decision is si+nificant or not is dependent on t$e pro4ect and circumstances and is determined )* esta)lis$ed +uidelines. (ypical guidelines for determining when to re0uire a formal evaluation process include the following: " decision is directly related to issues that are medium5to5high5impact ris1. " decision is related to changing wor1 products under configuration management. " decision would cause schedule delays over a certain percentage or amount of time. " decision affects the ability of the project to achieve its objectives. (he costs of the formal evaluation process are reasonable when compared to the decision9s impact. " legal obligation exists during a solicitation. 4hen competing 0uality attribute re0uirements would result in significantly different alternative architectures.
"efer to the "is1 Management process area for more information about evaluating2 categori-ing2 and prioriti-ing ris1s%
152
%e#"$"o A a&1$"$ a + Re$o&/t"o :%AR;
Examples of activities for which you may use a formal evaluation process include the following: $a1ing decisions involving the procurement of material when <> percent of the material parts constitute B> percent of the total material costs $a1ing design5implementation decisions when technical performance failure can cause a catastrophic failure 2e.g., safety5of5flight item3 $a1ing decisions with the potential to significantly reduce design ris1, engineering changes, cycle time, response time, and production costs 2e.g., to use lithography models to assess form and fit capability before releasing engineering drawings and production builds3
1. 1. ".
3uidelines for '$en to appl* a formal evaluation process Esta)lis$ +uidelines for '$en to use a formal evaluation process. Incorporate t$e use of +uidelines into t$e defined process as appropriate. "efer to the Integrated Pro.ect Management process area for more information about establishing the pro.ect3s defined process%
S/b'ra#t"#e$
SP 1*2
E$tab&"$- Eva&/at"o Cr"ter"a
+sta'lish and maintain criteria for e)aluating alternati)es and the relati)e ran4ing of these criteria.
Evaluation criteria provide t$e )asis for evaluatin+ alternative solutions. Criteria are ran2ed so t$at t$e $i+$est ran2ed criteria e5ert t$e most influence on t$e evaluation. T$is process area is referenced )* man* ot$er process areas in t$e model, and man* conte5ts in '$ic$ a formal evaluation process can )e used. T$erefore, in some situations *ou ma* find t$at criteria $ave alread* )een defined as part of anot$er process. T$is specific practice does not su++est t$at a second development of criteria )e conducted. 0 'ell-defined statement of t$e issue to )e addressed and t$e decision to )e made focuses t$e anal*sis to )e performed. uc$ a statement also aids in definin+ evaluation criteria t$at minimi-e t$e possi)ilit* t$at decisions 'ill )e second +uessed or t$at t$e reason for ma2in+ t$e decision 'ill )e for+otten. Decisions )ased on criteria t$at are e5plicitl* defined and esta)lis$ed remove )arriers to sta2e$older )u*-in.
1. ". 1.
Documented evaluation criteria !an2in+s of criteria importance Define t$e criteria for evaluatin+ alternative solutions.
S/b'ra#t"#e$
%e#"$"o A a&1$"$ a + Re$o&/t"o :%AR;
153
Criteria should be traceable to re0uirements, scenarios, business case assumptions, business objectives, or other documented sources. (ypes of criteria to consider include the following:
(echnology limitations Environmental impact #is1s ;usiness value &mpact on priorities (otal ownership and lifecycle costs
".
Define t$e ran+e and scale for ran2in+ t$e evaluation criteria. *cales of relative importance for evaluation criteria can be established with non5 numeric values or with formulas that relate the evaluation parameter to a numeric weight.
3.
!an2 t$e criteria. (he criteria are ran1ed according to the defined range and scale to reflect the needs, objectives, and priorities of the relevant sta1eholders.
8. 9. G.
0ssess t$e criteria and t$eir relative importance. Evolve t$e evaluation criteria to improve t$eir validit*. Document t$e rationale for t$e selection and re4ection of evaluation criteria. %ocumentation of selection criteria and rationale may be needed to justify solutions or for future reference and use.
SP 1*3
I+e t"f1 A&ter at"ve So&/t"o $
Identify alternati)e solutions to address issues.

0 'ider ran+e of alternatives can surface )* solicitin+ as man* sta2e$olders as practical for input. Input from sta2e$olders 'it$ diverse s2ills and )ac2+rounds can $elp teams identif* and address assumptions, constraints, and )iases. .rainstormin+ sessions can stimulate innovative alternatives t$rou+$ rapid interaction and feed)ac2. ufficient candidate solutions ma* not )e furnis$ed for anal*sis. 0s t$e anal*sis proceeds, ot$er alternatives s$ould )e added to t$e list of potential candidate solutions. T$e +eneration and consideration of multiple alternatives earl* in a decision anal*sis and resolution process increases t$e li2eli$ood t$at an accepta)le decision 'ill )e made and t$at conse/uences of t$e decision 'ill )e understood.
1. 1.
Identified alternatives Perform a literature searc$.
S/b'ra#t"#e$
154
%e#"$"o A a&1$"$ a + Re$o&/t"o :%AR;
" literature search can uncover what others have done both inside and outside the organi6ation. *uch a search can provide a deeper understanding of the problem, alternatives to consider, barriers to implementation, existing trade studies, and lessons learned from similar decisions. ". Identif* alternatives for consideration in addition to t$e alternatives t$at ma* )e provided 'it$ t$e issue. Evaluation criteria are an effective starting point for identifying alternatives. Evaluation criteria identify priorities of relevant sta1eholders and the importance of technical, logistical, or other challenges. Combining 1ey attributes of existing alternatives can generate additional and sometimes stronger alternatives. *olicit alternatives from relevant sta1eholders. ;rainstorming sessions, interviews, and wor1ing groups can be used effectively to uncover alternatives. 3.
SP 1*4
Document proposed alternatives.
Se&e#t Eva&/at"o Met-o+$
elect e)aluation methods.

Met$ods for evaluatin+ alternative solutions a+ainst esta)lis$ed criteria can ran+e from simulations to t$e use of pro)a)ilistic models and decision t$eor*. T$ese met$ods s$ould )e carefull* selected. T$e level of detail of a met$od s$ould )e commensurate 'it$ cost, sc$edule, performance, and ris2 impacts. 6$ile man* pro)lems ma* re/uire onl* one evaluation met$od, some pro)lems ma* re/uire multiple met$ods. 1or e5ample, simulations ma* au+ment a trade stud* to determine '$ic$ desi+n alternative )est meets a +iven criterion.
1. 1.
elected evaluation met$ods elect met$ods )ased on t$e purpose for anal*-in+ a decision and on t$e availa)ilit* of t$e information used to support t$e met$od. For example, the methods used for evaluating a solution when re0uirements are wea1ly defined may be different from the methods used when the re0uirements are well defined.
S/b'ra#t"#e$
%e#"$"o A a&1$"$ a + Re$o&/t"o :%AR;
155
(ypical evaluation methods include the following:

(esting $odeling and simulation Engineering studies $anufacturing studies Cost studies ;usiness opportunity studies *urveys Extrapolations based on field experience and prototypes End5user review and comment Cudgment provided by an expert or group of experts 2e.g., %elphi method3
".
elect evaluation met$ods )ased on t$eir a)ilit* to focus on t$e issues at $and 'it$out )ein+ overl* influenced )* side issues. #esults of simulations can be s1ewed by random activities in the solution that are not directly related to the issues at hand.
3.
Determine t$e measures needed to support t$e evaluation met$od. Consider the impact on cost, schedule, performance, and ris1s.
SP 1*5
Eva&/ate A&ter at"ve So&/t"o $
+)aluate alternati)e solutions using esta'lished criteria and methods.

Evaluatin+ alternative solutions involves anal*sis, discussion, and revie'. Iterative c*cles of anal*sis are sometimes necessar*. upportin+ anal*ses, e5perimentation, protot*pin+, pilotin+, or simulations ma* )e needed to su)stantiate scorin+ and conclusions. 7ften, t$e relative importance of criteria is imprecise and t$e total effect on a solution is not apparent until after t$e anal*sis is performed. In cases '$ere t$e resultin+ scores differ )* relativel* small amounts, t$e )est selection amon+ alternative solutions ma* not )e clear. C$allen+es to criteria and assumptions s$ould )e encoura+ed.
1. 1. ". 3.
Evaluation results Evaluate proposed alternative solutions usin+ t$e esta)lis$ed evaluation criteria and selected met$ods. Evaluate assumptions related to t$e evaluation criteria and t$e evidence t$at supports t$e assumptions. Evaluate '$et$er uncertaint* in t$e values for alternative solutions affects t$e evaluation and address t$ese uncertainties as appropriate.
S/b'ra#t"#e$
156
%e#"$"o A a&1$"$ a + Re$o&/t"o :%AR;
For instance, if the score varies between two values, is the difference significant enough to ma1e a difference in the final solution setD %oes the variation in score represent a high5impact ris1D (o address these concerns, simulations may be run, further studies may be performed, or evaluation criteria may be modified, among other things. 8. Perform simulations, modelin+, protot*pes, and pilots as necessar* to e5ercise t$e evaluation criteria, met$ods, and alternative solutions. :ntested criteria, their relative importance, and supporting data or functions can cause the validity of solutions to be 0uestioned. Criteria and their relative priorities and scales can be tested with trial runs against a set of alternatives. (hese trial runs of a select set of criteria allow for the evaluation of the cumulative impact of criteria on a solution. &f trials reveal problems, different criteria or alternatives might be considered to avoid biases. 9. Consider ne' alternative solutions, criteria, or met$ods if proposed alternatives do not test 'ellI repeat evaluations until alternatives do test 'ell. Document t$e results of t$e evaluation. %ocument the rationale for the addition of new alternatives or methods and changes to criteria, as well as the results of interim evaluations.
SP 1*6 Se&e#t So&/t"o $
G.
elect solutions from alternati)es 'ased on e)aluation criteria.

electin+ solutions involves 'ei+$in+ results from t$e evaluation of alternatives. !is2s associated 'it$ t$e implementation of solutions s$ould )e assessed.
1. 1.
!ecommended solutions to address si+nificant issues 0ssess t$e ris2s associated 'it$ implementin+ t$e recommended solution. "efer to the "is1 Management process area for more information about identifying and analy-ing ris1s and mitigating ris1s% %ecisions must often be made with incomplete information. (here can be substantial ris1 associated with the decision because of having incomplete information. 4hen decisions must be made according to a specific schedule, time and resources may not be available for gathering complete information. Conse0uently, ris1y decisions made with incomplete information can re0uire re5analysis later. &dentified ris1s should be monitored.
S/b'ra#t"#e$
".
Document and communicate to relevant sta2e$olders t$e results and rationale for t$e recommended solution. &t is important to record both why a solution is selected and why another solution was rejected.
%e#"$"o A a&1$"$ a + Re$o&/t"o :%AR;
158
15<
%e#"$"o A a&1$"$ a + Re$o&/t"o :%AR;
I*($/RA($D PRO0$!( #A*A/$#$*(

A Project Management Process Area at Maturity Level 3
Purpose
T$e purpose of Inte+rated Pro4ect Mana+ement (IPM, is to esta)lis$ and mana+e t$e pro4ect and t$e involvement of relevant sta2e$olders accordin+ to an inte+rated and defined process t$at is tailored from t$e or+ani-ation;s set of standard processes.
Introductor" *otes
Inte+rated Pro4ect Mana+ement involves t$e follo'in+ activities% Esta)lis$in+ t$e pro4ect;s defined process at pro4ect startup )* tailorin+ t$e or+ani-ation;s set of standard processes Mana+in+ t$e pro4ect usin+ t$e pro4ect;s defined process Esta)lis$in+ t$e 'or2 environment for t$e pro4ect )ased on t$e or+ani-ation;s 'or2 environment standards Esta)lis$in+ teams t$at are tas2ed to accomplis$ pro4ect o)4ectives :sin+ and contri)utin+ to or+ani-ational process assets Ena)lin+ relevant sta2e$olders; concerns to )e identified, considered, and, '$en appropriate, addressed durin+ t$e pro4ect Ensurin+ t$at relevant sta2e$olders (1, perform t$eir tas2s in a coordinated and timel* mannerI (", address pro4ect re/uirements, plans, o)4ectives, pro)lems, and ris2sI (3, fulfill t$eir commitmentsI and (8, identif*, trac2, and resolve coordination issues
T$e inte+rated and defined process t$at is tailored from t$e or+ani-ation;s set of standard processes is called t$e pro4ect;s defined process. ( ee t$e definition of Lpro4ectM in t$e +lossar*., Mana+in+ t$e pro4ect;s effort, cost, sc$edule, staffin+, ris2s, and ot$er factors is tied to t$e tas2s of t$e pro4ect;s defined process. T$e implementation and mana+ement of t$e pro4ect;s defined process are t*picall* descri)ed in t$e pro4ect plan. Certain activities ma* )e covered in ot$er plans t$at affect t$e pro4ect, suc$ as t$e /ualit* assurance plan, ris2 mana+ement strate+*, and t$e confi+uration mana+ement plan. ince t$e defined process for eac$ pro4ect is tailored from t$e or+ani-ation;s set of standard processes, varia)ilit* amon+ pro4ects is t*picall* reduced and pro4ects can easil* s$are process assets, data, and lessons learned.
I te!rate+ Pro0e#t Ma a!eme t :IPM;
153
(his process area also addresses the coordination of all activities associated with the project such as the following: %evelopment activities 2e.g., re0uirements development, design, verification3 *ervice activities 2e.g., delivery, help des1, operations, customer contact3 "c0uisition activities 2e.g., solicitation, agreement monitoring, transition to operations3 *upport activities 2e.g., configuration management, documentation, mar1eting, training3
T$e 'or2in+ interfaces and interactions amon+ relevant sta2e$olders internal and e5ternal to t$e pro4ect are planned and mana+ed to ensure t$e /ualit* and inte+rit* of t$e overall endeavor. !elevant sta2e$olders participate as appropriate in definin+ t$e pro4ect;s defined process and t$e pro4ect plan. !evie's and e5c$an+es are re+ularl* conducted 'it$ relevant sta2e$olders to ensure t$at coordination issues receive appropriate attention and ever*one involved 'it$ t$e pro4ect is appropriatel* a'are of status, plans, and activities. ( ee t$e definition of Lrelevant sta2e$olderM in t$e +lossar*., In definin+ t$e pro4ect;s defined process, formal interfaces are created as necessar* to ensure t$at appropriate coordination and colla)oration occurs. T$is process area applies in an* or+ani-ational structure, includin+ pro4ects t$at are structured as line or+ani-ations, matri5 or+ani-ations, or teams. T$e terminolo+* s$ould )e appropriatel* interpreted for t$e or+ani-ational structure in place.
"efer to the 8erification process area for more information about performing peer reviews% "efer to the Measurement and $nalysis process area for more information about aligning measurement and analysis activities and providing measurement results% "efer to the 0rgani-ational Process efinition process area for more information about establishing and maintaining a usable set of organi-ational process assets2 wor1 environment standards2 and rules and guidelines for teams% "efer to the Pro.ect Monitoring and Control process area for more information about monitoring the pro.ect against the plan% "efer to the Pro.ect Planning process area for more information about developing a pro.ect plan%
160

3 1 :se t$e Pro4ect;s Defined Process P 1.1 P 1." P 1.3 P 1.8 P 1.9 P 1.G P 1.= P ".1 P "." P ".3 Esta)lis$ t$e Pro4ect;s Defined Process :se 7r+ani-ational Process 0ssets for Plannin+ Pro4ect 0ctivities Esta)lis$ t$e Pro4ect;s 6or2 Environment Inte+rate Plans Mana+e t$e Pro4ect :sin+ Inte+rated Plans Esta)lis$ Teams Contri)ute to 7r+ani-ational Process 0ssets Mana+e ta2e$older Involvement Mana+e Dependencies !esolve Coordination Issues
3 " Coordinate and Colla)orate 'it$ !elevant ta2e$olders
)pecific Practices b" /oal S7 1 U$e t-e Pro0e#tB$ %ef" e+ Pro#e$$
The pro/ect is conducted using a defined process tailored from the organi5ation7s set of standard processes.
T$e pro4ect;s defined process includes t$ose processes from t$e or+ani-ation;s set of standard processes t$at address all processes necessar* to ac/uire, develop, maintain, or deliver t$e product. T$e product related lifec*cle processes, suc$ as manufacturin+ and support processes, are developed concurrentl* 'it$ t$e product.
SP 1*1 E$tab&"$- t-e Pro0e#tB$ %ef" e+ Pro#e$$
+sta'lish and maintain the pro/ect7s defined process from pro/ect startup through the life of the pro/ect.
"efer to the 0rgani-ational Process efinition process area for more information about establishing organi-ational process assets and establishing the organi-ation3s measurement repository% "efer to the 0rgani-ational Process 9ocus process area for more information about deploying organi-ational process assets and deploying standard processes% T$e pro4ect;s defined process consists of defined processes t$at form an inte+rated, co$erent lifec*cle for t$e pro4ect. T$e pro4ect;s defined process s$ould satisf* t$e pro4ect;s contractual re/uirements, operational needs, opportunities, and constraints. It is desi+ned to provide a )est fit for pro4ect needs. 0 pro4ect;s defined process is )ased on t$e follo'in+ factors% ta2e$older re/uirements Commitments 7r+ani-ational process needs and o)4ectives T$e or+ani-ation;s set of standard processes and tailorin+ +uidelines
161
T$e operational environment T$e )usiness environment
Esta)lis$in+ t$e pro4ect;s defined process at pro4ect startup $elps to ensure t$at pro4ect staff and relevant sta2e$olders implement a set of activities needed to efficientl* esta)lis$ an initial set of re/uirements and plans for t$e pro4ect. 0s t$e pro4ect pro+resses, t$e description of t$e pro4ect;s defined process is ela)orated and revised to )etter meet pro4ect re/uirements and t$e or+ani-ation;s process needs and o)4ectives. 0lso, as t$e or+ani-ation;s set of standard processes c$an+es, t$e pro4ect;s defined process ma* need to )e revised.
1. 1.
T$e pro4ect;s defined process elect a lifec*cle model from t$e ones availa)le in or+ani-ational process assets. Examples of project characteristics that could affect the selection of lifecycle models include the following:
*i6e or complexity of the project 'roject strategy Experience and familiarity of staff with implementing the process Constraints such as cycle time and acceptable defect levels "vailability of customers to answer 0uestions and provide feedbac1 on increments Clarity of re0uirements Customer expectations
S/b'ra#t"#e$
". 3.
elect standard processes from t$e or+ani-ation;s set of standard processes t$at )est fit t$e needs of t$e pro4ect. Tailor t$e or+ani-ation;s set of standard processes and ot$er or+ani-ational process assets accordin+ to tailorin+ +uidelines to produce t$e pro4ect;s defined process. *ometimes the available lifecycle models and standard processes are inade0uate to meet project needs. &n such circumstances, the project should see1 approval to deviate from what is re0uired by the organi6ation. 4aivers are provided for this purpose. (ailoring can include adapting the organi6ation9s common measures and specifying additional measures to meet the information needs of the project.
8.
:se ot$er artifacts from t$e or+ani-ation;s process asset li)rar* as appropriate.
162
Other artifacts can include the following:

-essons learned documents (emplates Example documents Estimating models
9.
Document t$e pro4ect;s defined process. (he project9s defined process covers all of the activities for the project and its interfaces to relevant sta1eholders. Examples of project activities include the following:
'roject planning 'roject monitoring *upplier management )uality assurance #is1 management %ecision analysis and resolution #e0uirements development #e0uirements management Configuration management 'roduct development and support Code review *olicitation
G.
Conduct peer revie's of t$e pro4ect;s defined process. "efer to the 8erification process area for more information about performing peer reviews%
=.
SP 1*2
!evise t$e pro4ect;s defined process as necessar*.

" ! Pro0e#t A#t"v"t"e$
U$e Or!a "Aat"o a& Pro#e$$ A$$et$ for P&a
8se organi5ational process assets and the measurement repository for estimating and planning pro/ect acti)ities.
"efer to the 0rgani-ational Process efinition process area for more information about establishing organi-ational process assets% 6$en availa)le, use results of previous plannin+ and e5ecution activities as predictors of t$e relative scope and ris2 of t$e effort )ein+ estimated.
1. ".
Pro4ect estimates Pro4ect plans
163
S/b'ra#t"#e$
1.
:se t$e tas2s and 'or2 products of t$e pro4ect;s defined process as a )asis for estimatin+ and plannin+ pro4ect activities. "n understanding of the relationships among tas1s and wor1 products of the project9s defined process, and of the roles to be performed by relevant sta1eholders, is a basis for developing a realistic plan.
".
:se t$e or+ani-ation;s measurement repositor* in estimatin+ t$e pro4ect;s plannin+ parameters. (his estimate typically includes the following:
"ppropriate historical data from this project or similar projects *imilarities and differences between the current project and those projects whose historical data will be used ,alidated historical data #easoning, assumptions, and rationale used to select the historical data #easoning of a broad base of experienced project participants
Examples of parameters that are considered for similarities and differences include the following:
4or1 product and tas1 attributes "pplication domain Experience of the people %esign and development approaches Operational environment
Examples of data contained in the organi6ation9s measurement repository include the following:
*i6e of wor1 products or other wor1 product attributes Effort Cost *chedule *taffing #esponse time *ervice capacity *upplier performance %efects SP 1*3 E$tab&"$- t-e Pro0e#tB$ >or? E v"ro me t
+sta'lish and maintain the pro/ect7s 3or4 en)ironment 'ased on the organi5ation7s 3or4 en)ironment standards.
0n appropriate 'or2 environment for a pro4ect comprises an infrastructure of facilities, tools, and e/uipment t$at people need to perform t$eir 4o)s
164
effectivel* in support of )usiness and pro4ect o)4ectives. T$e 'or2 environment and its components are maintained at a level of 'or2 environment performance and relia)ilit* indicated )* or+ani-ational 'or2 environment standards. 0s re/uired, t$e pro4ect;s 'or2 environment or some of its components can )e developed internall* or ac/uired from e5ternal sources. T$e pro4ect;s 'or2 environment mi+$t encompass environments for product inte+ration, verification, and validation or t$e* mi+$t )e separate environments. "efer to the Establish the Product Integration Environment specific practice in the Product Integration process area for more information about establishing and maintaining the product integration environment for the pro.ect% "efer to the Establish the 8alidation Environment specific practice in the 8alidation process area for more information about establishing and maintaining the validation environment for the pro.ect% "efer to the Establish the 8erification Environment specific practice in the 8erification process area for more information about establishing and maintaining the verification environment for the pro.ect% "efer to the Establish )or1 Environment Standards specific practice in the 0rgani-ational Process efinition process area for more information about wor1 environment standards%
1. ". 3. 8. 9. 1.
E/uipment and tools for t$e pro4ect Installation, operation, and maintenance manuals for t$e pro4ect 'or2 environment :ser surve*s and results :se, performance, and maintenance records upport services for t$e pro4ect;s 'or2 environment Plan, desi+n, and install a 'or2 environment for t$e pro4ect. (he critical aspects of the project wor1 environment are, li1e any other product, re0uirements driven. Functionality and 0uality attributes of the wor1 environment are explored with the same rigor as is done for any other product development project.
S/b'ra#t"#e$
165
&t may be necessary to ma1e tradeoffs among 0uality attributes, costs, and ris1s. (he following are examples of each:
)uality attribute considerations can include timely communication, safety, security, and maintainability. Costs can include capital outlays, training, a support structure8 disassembly and disposal of existing environments8 and the operation and maintenance of the environment. #is1s can include wor1flow and project disruptions.
Examples of e0uipment and tools include the following:

Office software %ecision support software 'roject management tools (est and evaluation e0uipment #e0uirements management tools and design tools Configuration management tools Evaluation tools &ntegration tools "utomated test tools
".
Provide on+oin+ maintenance and operational support for t$e pro4ect;s 'or2 environment. $aintenance and support of the wor1 environment can be accomplished either with capabilities found inside the organi6ation or hired from outside the organi6ation. Examples of maintenance and support approaches include the following:
/iring people to perform maintenance and support (raining people to perform maintenance and support Contracting maintenance and support %eveloping expert users for selected tools
3.
Maintain t$e /ualification of components of t$e pro4ect;s 'or2 environment. Components include software, databases, hardware, tools, test e0uipment, and appropriate documentation. )ualification of software includes appropriate certifications. /ardware and test e0uipment 0ualification includes calibration and adjustment records and traceability to calibration standards.
8.
Periodicall* revie' $o' 'ell t$e 'or2 environment is meetin+ pro4ect needs and supportin+ colla)oration, and ta2e action as appropriate. Examples of actions that might be ta1en include the following:
"dding new tools "c0uiring additional networ1s, e0uipment, training, and support
166
SP 1*4
I te!rate P&a $
Integrate the pro/ect plan and other plans that affect the pro/ect to descri'e the pro/ect7s defined process.
"efer to the 0rgani-ational Process efinition process area for more information about establishing organi-ational process assets and2 in particular2 establishing the organi-ation3s measurement repository% "efer to the 0rgani-ational Process 9ocus process area for more information about establishing organi-ational process needs and determining process improvement opportunities% "efer to the Pro.ect Planning process area for more information about developing a pro.ect plan% T$is specific practice e5tends t$e specific practices for esta)lis$in+ and maintainin+ a pro4ect plan to address additional plannin+ activities suc$ as incorporatin+ t$e pro4ect;s defined process, coordinatin+ 'it$ relevant sta2e$olders, usin+ or+ani-ational process assets, incorporatin+ plans for peer revie's, and esta)lis$in+ o)4ective entr* and e5it criteria for tas2s. T$e development of t$e pro4ect plan s$ould account for current and pro4ected needs, o)4ectives, and re/uirements of t$e or+ani-ation, customer, suppliers, and end users as appropriate.
1. 1.
Inte+rated plans Inte+rate ot$er plans t$at affect t$e pro4ect 'it$ t$e pro4ect plan. Other plans that affect the project plan can include the following:
)uality assurance plans #is1 management strategy ,erification and validation plans (ransition to operations and support plans Configuration management plans %ocumentation plans *taff training plans Facilities and logistics plans
S/b'ra#t"#e$
".
Incorporate into t$e pro4ect plan t$e definitions of measures and measurement activities for mana+in+ t$e pro4ect. Examples of measures that would be incorporated include the following:
Organi6ation9s common set of measures "dditional project specific measures
168
"efer to the Measurement and $nalysis process area for more information about developing and sustaining a measurement capability used to support management information needs% 3. Identif* and anal*-e product and pro4ect interface ris2s. "efer to the "is1 Management process area for more information about identifying and analy-ing ris1s% Examples of product and project interface ris1s include the following:
&ncomplete interface descriptions :navailability of tools, suppliers, or test e0uipment :navailability of CO(* components &nade0uate or ineffective team interfaces
8.
c$edule tas2s in a se/uence t$at accounts for critical development and deliver* factors and pro4ect ris2s. Examples of factors considered in scheduling include the following:
*i6e and complexity of tas1s 7eeds of the customer and end users "vailability of critical resources "vailability of 1ey staff &ntegration and test issues
9.
Incorporate plans for performin+ peer revie's on 'or2 products of t$e pro4ect;s defined process. "efer to the 8erification process area for more information about performing peer reviews%
G.
Incorporate t$e trainin+ needed to perform t$e pro4ect;s defined process in t$e pro4ect;s trainin+ plans. (his tas1 typically includes negotiating with the organi6ational training group on the support they will provide.
=.
Esta)lis$ o)4ective entr* and e5it criteria to aut$ori-e t$e initiation and completion of tas2s descri)ed in t$e 'or2 )rea2do'n structure (6. ,. "efer to the Pro.ect Planning process area for more information about estimating the scope of the pro.ect%
H.
Ensure t$at t$e pro4ect plan is appropriatel* compati)le 'it$ t$e plans of relevant sta2e$olders. (ypically the plan and changes to the plan will be reviewed for compatibility.
F.
Identif* $o' conflicts 'ill )e resolved t$at arise amon+ relevant sta2e$olders.
16<
SP 1*5
Ma a!e t-e Pro0e#t U$" ! I te!rate+ P&a $
Manage the pro/ect using the pro/ect plan* other plans that affect the pro/ect* and the pro/ect7s defined process.
"efer to the 0rgani-ational Process efinition process area for more information about establishing organi-ational process assets% "efer to the 0rgani-ational Process 9ocus process area for more information about establishing organi-ational process needs2 deploying organi-ational process assets2 and deploying standard processes% "efer to the Pro.ect Monitoring and Control process area for more information about providing an understanding of the pro.ect3s progress so that appropriate corrective actions can be ta1en when the pro.ect3s performance deviates significantly from the plan% "efer to the "is1 Management process area for more information about identifying and analy-ing ris1s and mitigating ris1s%
1. ". 3. 8. 1.
6or2 products created )* performin+ t$e pro4ect;s defined process Collected measures (i.e., actuals, and status records or reports !evised re/uirements, plans, and commitments Inte+rated plans Implement t$e pro4ect;s defined process usin+ t$e or+ani-ation;s process asset li)rar*. (his tas1 typically includes the following activities:
&ncorporating artifacts from the organi6ation9s process asset library into the project as appropriate :sing lessons learned from the organi6ation9s process asset library to manage the project
S/b'ra#t"#e$
".
Monitor and control t$e pro4ect;s activities and 'or2 products usin+ t$e pro4ect;s defined process, pro4ect plan, and ot$er plans t$at affect t$e pro4ect. (his tas1 typically includes the following activities:
:sing the defined entry and exit criteria to authori6e the initiation and determine the completion of tas1s $onitoring activities that could significantly affect actual values of the project9s planning parameters (rac1ing project planning parameters using measurable thresholds that will trigger investigation and appropriate actions $onitoring product and project interface ris1s $anaging external and internal commitments based on plans for tas1s and wor1 products of the project9s defined process
163
"n understanding of the relationships among tas1s and wor1 products of the project9s defined process and of the roles to be performed by relevant sta1eholders, along with well5defined control mechanisms 2e.g., peer reviews3, achieves better visibility into project performance and better control of the project. 3. 7)tain and anal*-e selected measurements to mana+e t$e pro4ect and support or+ani-ation needs. "efer to the Measurement and $nalysis process area for more information about obtaining measurement data and analy-ing measurement data% 8. Periodicall* revie' and ali+n t$e pro4ect;s performance 'it$ current and anticipated needs, o)4ectives, and re/uirements of t$e or+ani-ation, customer, and end users as appropriate. (his review includes alignment with organi6ational process needs and objectives. Examples of actions that achieve alignment include the following:
Changing the schedule with appropriate adjustments to other planning parameters and project ris1s Changing re0uirements or commitments in response to a change in mar1et opportunities or customer and end5user needs (erminating the project, iteration, or release
9.
0ddress causes of selected issues t$at can affect pro4ect o)4ectives. &ssues that re0uire corrective action are determined and analy6ed as in the "naly6e &ssues and (a1e Corrective "ctions specific practices of the 'roject $onitoring and Control process area. "s appropriate, the project may periodically review issues previously encountered on other projects or in earlier phases of the project, and conduct causal analysis of selected issues to determine how to prevent recurrence for issues which can significantly affect project objectives. 'roject process changes implemented as a result of causal analysis activities should be evaluated for effectiveness to ensure that the process change has prevented recurrence and improved performance.
SP 1*6
E$tab&"$- Team$
+sta'lish and maintain teams.

T$e pro4ect is mana+ed usin+ teams t$at reflect t$e or+ani-ational rules and +uidelines for team structurin+, formation, and operation. ( ee t$e definition of LteamM in t$e +lossar*., T$e pro4ect;s s$ared vision is esta)lis$ed prior to esta)lis$in+ t$e team structure, '$ic$ can )e )ased on t$e 6. . 1or small or+ani-ations, t$e '$ole or+ani-ation and relevant e5ternal sta2e$olders can )e treated as a team. "efer to the Establish "ules and Guidelines for Teams specific practice in the 0rgani-ational Process efinition process area for more information about establishing and maintaining organi-ational rules and guidelines for the structure2 formation2 and operation of teams%
180
7ne of t$e )est 'a*s to ensure coordination and colla)oration 'it$ relevant sta2e$olders is to include t$em on t$e team. In a customer environment t$at re/uires coordination amon+ multiple product or service development or+ani-ations, it is important to esta)lis$ a team 'it$ representation from all parties t$at affect overall success. uc$ representation $elps to ensure effective colla)oration across t$ese or+ani-ations, includin+ t$e timel* resolution of coordination issues.
1. ". 3. 8. 1.
Documented s$ared vision Aist of mem)ers assi+ned to eac$ team Team c$arters Periodic team status reports Esta)lis$ and maintain t$e pro4ect;s s$ared vision. 4hen creating a shared vision, it is critical to understand the interfaces between the project and sta1eholders external to the project. (he vision should be shared among relevant sta1eholders to obtain their agreement and commitment.
S/b'ra#t"#e$
".
Esta)lis$ and maintain t$e team structure. (he project 4;*, cost, schedule, project ris1s, resources, interfaces, the project9s defined process, and organi6ational guidelines are evaluated to establish an appropriate team structure, including team responsibilities, authorities, and interrelationships.
3.
Esta)lis$ and maintain eac$ team. Establishing and maintaining teams encompasses choosing team leaders and team members and establishing team charters for each team. &t also involves providing resources re0uired to accomplish tas1s assigned to the team.
8.
Periodicall* evaluate t$e team structure and composition. (eams should be monitored to detect misalignment of wor1 across different teams, mismanaged interfaces, and mismatches of tas1s to team members. (a1e corrective action when team or project performance does not meet expectations.
SP 1*8
Co tr"b/te to Or!a "Aat"o a& Pro#e$$ A$$et$
Contri'ute process related e,periences to organi5ational process assets.

"efer to the 0rgani-ational Process efinition process area for more information about establishing organi-ational process assets2 establishing the organi-ation3s measurement repository2 and establishing the organi-ation3s process asset library% "efer to the 0rgani-ational Process 9ocus process area for more information about incorporating e:periences into organi-ational process assets%
181
T$is specific practice addresses contri)utin+ information from processes in t$e pro4ect;s defined process to or+ani-ational process assets.
1. ". 3. 8.
Proposed improvements to or+ani-ational process assets 0ctual process and product measures collected from t$e pro4ect Documentation (e.+., e5emplar* process descriptions, plans, trainin+ modules, c$ec2lists, lessons learned, Process artifacts associated 'it$ tailorin+ and implementin+ t$e or+ani-ation;s set of standard processes on t$e pro4ect Propose improvements to t$e or+ani-ational process assets. tore process and product measures in t$e or+ani-ation;s measurement repositor*. "efer to the Measurement and $nalysis process area for more information about obtaining measurement data% "efer to the Pro.ect Monitoring and Control process area for more information about monitoring pro.ect planning parameters% "efer to the Pro.ect Planning process area for more information about planning data management% (hese process and product measures typically include the following:
'lanning data #eplanning data
S/b'ra#t"#e$
1. ".
Examples of data recorded by the project include the following:

(as1 descriptions "ssumptions Estimates #evised estimates %efinitions of recorded data and measures $easures Context information that relates the measures to the activities performed and wor1 products produced "ssociated information needed to reconstruct the estimates, assess their reasonableness, and derive estimates for new wor1
3.
u)mit documentation for possi)le inclusion in t$e or+ani-ation;s process asset li)rar*.
182
Examples of documentation include the following:

Exemplary process descriptions (raining modules Exemplary plans Chec1lists and templates 'roject repository shells (ool configurations
8. 9.
Document lessons learned from t$e pro4ect for inclusion in t$e or+ani-ation;s process asset li)rar*. Provide process artifacts associated 'it$ tailorin+ and implementin+ t$e or+ani-ation;s set of standard processes in support of t$e or+ani-ation;s process monitorin+ activities. "efer to the Monitor the Implementation specific practice in the 0rgani-ational Process 9ocus process area for more information about the organi-ation3s activities to understand the e:tent of deployment of standard processes on new and e:isting pro.ects%
S7 2
Coor+" ate a + Co&&aborate w"t- Re&eva t Sta?e-o&+er$
Coordination and colla'oration 'et3een the pro/ect and rele)ant sta4eholders are conducted.
SP 2*1 Ma a!e Sta?e-o&+er I vo&veme t
Manage the in)ol)ement of rele)ant sta4eholders in the pro/ect.

ta2e$older involvement is mana+ed accordin+ to t$e pro4ect;s inte+rated plan and defined process. "efer to the Pro.ect Planning process area for more information about planning sta1eholder involvement and obtaining plan commitment%
1. ". 3.
0+endas and sc$edules for colla)orative activities !ecommendations for resolvin+ relevant sta2e$older issues Documented issues (e.+., issues 'it$ sta2e$older re/uirements, product and product component re/uirements, product arc$itecture, product desi+n, Coordinate 'it$ relevant sta2e$olders '$o s$ould participate in pro4ect activities. (he relevant sta1eholders should already be identified in the project plan.
S/b'ra#t"#e$
1.
".
Ensure 'or2 products t$at are produced to satisf* commitments meet t$e re/uirements of t$e recipients.
183
"efer to the 8erification process area for more information about verifying selected wor1 products% (he wor1 products produced to satisfy commitments can be services. (his tas1 typically includes the following:
#eviewing, demonstrating, or testing, as appropriate, each wor1 product produced by relevant sta1eholders #eviewing, demonstrating, or testing, as appropriate, each wor1 product produced by the project for other projects with representatives of the projects receiving the wor1 product #esolving issues related to the acceptance of the wor1 products
3.
Develop recommendations and coordinate actions to resolve misunderstandin+s and pro)lems 'it$ re/uirements.
SP 2*2
Ma a!e %e'e +e #"e$
!articipate 3ith rele)ant sta4eholders to identify* negotiate* and trac4 critical dependencies.
1. ". 3. 8. 1. ". 3. 8.
Defects, issues, and action items resultin+ from revie's 'it$ relevant sta2e$olders Critical dependencies Commitments to address critical dependencies tatus of critical dependencies Conduct revie's 'it$ relevant sta2e$olders. Identif* eac$ critical dependenc*. Esta)lis$ need dates and plan dates for eac$ critical dependenc* )ased on t$e pro4ect sc$edule. !evie' and +et a+reement on commitments to address eac$ critical dependenc* 'it$ t$ose '$o are responsi)le for providin+ or receivin+ t$e 'or2 product. Document critical dependencies and commitments. %ocumentation of commitments typically includes the following:
%escribing the commitment &dentifying who made the commitment &dentifying who is responsible for satisfying the commitment *pecifying when the commitment will be satisfied *pecifying the criteria for determining if the commitment has been satisfied
S/b'ra#t"#e$
9.
G.
Trac2 t$e critical dependencies and commitments and ta2e corrective action as appropriate.
184
"efer to the Pro.ect Monitoring and Control process area for more information about monitoring commitments% (rac1ing critical dependencies typically includes the following:
Evaluating the effects of late and early completion for impacts on future activities and milestones #esolving actual and potential problems with responsible parties whenever possible Escalating to the appropriate party the actual and potential problems not resolvable by the responsible individual or group
185
SP 2*3
Re$o&ve Coor+" at"o I$$/e$
#esol)e issues 3ith rele)ant sta4eholders.

Examples of coordination issues include the following: 'roduct and product component re0uirements and design defects -ate critical dependencies and commitments 'roduct level problems :navailability of critical resources or staff
1. ". 1. ". 3. 8. 9. G.
!elevant sta2e$older coordination issues tatus of relevant sta2e$older coordination issues Identif* and document issues. Communicate issues to relevant sta2e$olders. !esolve issues 'it$ relevant sta2e$olders. Escalate to appropriate mana+ers t$e issues not resolva)le 'it$ relevant sta2e$olders. Trac2 issues to closure. Communicate 'it$ relevant sta2e$olders on t$e status and resolution of issues.
S/b'ra#t"#e$
186
188
#$A)UR$#$*( A*D A*A+-)I)

Purpose
T$e purpose of Measurement and 0nal*sis (M0, is to develop and sustain a measurement capa)ilit* used to support mana+ement information needs.
Introductor" *otes
T$e Measurement and 0nal*sis process area involves t$e follo'in+ activities% pecif*in+ o)4ectives of measurement and anal*sis so t$at t$e* are ali+ned 'it$ identified information needs and pro4ect, or+ani-ational, or )usiness o)4ectives pecif*in+ measures, anal*sis tec$ni/ues, and mec$anisms for data collection, data stora+e, reportin+, and feed)ac2 Implementin+ t$e anal*sis tec$ni/ues and mec$anisms for data collection, data reportin+, and feed)ac2 Providin+ o)4ective results t$at can )e used in ma2in+ informed decisions and ta2in+ appropriate corrective action
T$e inte+ration of measurement and anal*sis activities into t$e processes of t$e pro4ect supports t$e follo'in+% 7)4ective plannin+ and estimatin+ Trac2in+ actual pro+ress and performance a+ainst esta)lis$ed plans and o)4ectives Identif*in+ and resolvin+ process related issues Providin+ a )asis for incorporatin+ measurement into additional processes in t$e future
T$e staff re/uired to implement a measurement capa)ilit* ma* or ma* not )e emplo*ed in a separate or+ani-ation-'ide pro+ram. Measurement capa)ilit* ma* )e inte+rated into individual pro4ects or ot$er or+ani-ational functions (e.+., /ualit* assurance,. T$e initial focus for measurement activities is at t$e pro4ect level. @o'ever, a measurement capa)ilit* can prove useful for addressin+ or+ani-ationand enterprise-'ide information needs. To support t$is capa)ilit*, measurement activities s$ould support information needs at multiple levels, includin+ t$e )usiness, or+ani-ational unit, and pro4ect to minimi-e re-'or2 as t$e or+ani-ation matures. Pro4ects can store pro4ect specific data and results in a pro4ect specific repositor*, )ut '$en data are to )e used 'idel* or are to )e anal*-ed in
18<
Mea$/reme t a + A a&1$"$ :MA;
support of determinin+ data trends or )enc$mar2s, data ma* reside in t$e or+ani-ation;s measurement repositor*. Measurement and anal*sis of product components provided )* suppliers is essential for effective mana+ement of t$e /ualit* and costs of t$e pro4ect. It is possi)le, 'it$ careful mana+ement of supplier a+reements, to provide insi+$t into data t$at support supplier performance anal*sis. Measurement o)4ectives are derived from information needs t$at come from pro4ect, or+ani-ational, or )usiness o)4ectives. In t$is process area, '$en t$e term Lo)4ectivesM is used 'it$out t$e LmeasurementM /ualifier, it indicates eit$er pro4ect, or+ani-ational, or )usiness o)4ectives.
"efer to the "e,uirements evelopment process area for more information about eliciting2 analy-ing2 and establishing customer2 product2 and product component re,uirements% "efer to the Configuration Management process area for more information about establishing and maintaining the integrity of wor1 products using configuration identification2 configuration control2 configuration status accounting2 and configuration audits% "efer to the 0rgani-ational Process efinition process area for more information about establishing the organi-ation3s measurement repository% "efer to the Pro.ect Monitoring and Control process area for more information about monitoring pro.ect planning parameters% "efer to the Pro.ect Planning process area for more information about establishing estimates% "efer to the 4uantitative Pro.ect Management process area for more information about ,uantitatively managing the pro.ect% "efer to the "e,uirements Management process area for more information about maintaining bidirectional traceability of re,uirements%
3 1 0li+n Measurement and 0nal*sis 0ctivities P 1.1 P 1." P 1.3 P 1.8 P ".1 P "." P ".3 P ".8 Esta)lis$ Measurement 7)4ectives pecif* Measures pecif* Data Collection and tora+e Procedures pecif* 0nal*sis Procedures 7)tain Measurement Data 0nal*-e Measurement Data tore Data and !esults Communicate !esults
3 " Provide Measurement !esults
183
)pecific Practices b" /oal S7 1 A&"! Mea$/reme t a + A a&1$"$ A#t"v"t"e$
Measurement o'/ecti)es and acti)ities are aligned 3ith identified information needs and o'/ecti)es.
T$e specific practices under t$is specific +oal can )e addressed concurrentl* or in an* order. 6$en esta)lis$in+ measurement o)4ectives, e5perts often t$in2 a$ead a)out necessar* criteria for specif*in+ measures and anal*sis procedures. T$e* also t$in2 concurrentl* a)out t$e constraints imposed )* data collection and stora+e procedures. 7ften it is important to specif* t$e essential anal*ses to )e conducted )efore attendin+ to details of measurement specification, data collection, or stora+e.
SP 1*1 E$tab&"$- Mea$/reme t Ob0e#t"ve$
+sta'lish and maintain measurement o'/ecti)es deri)ed from identified information needs and o'/ecti)es.
Measurement o)4ectives document t$e purposes for '$ic$ measurement and anal*sis are done and specif* t$e 2inds of actions t$at can )e ta2en )ased on results of data anal*ses. Measurement o)4ectives can also identif* t$e c$an+e in )e$avior desired as a result of implementin+ a measurement and anal*sis activit*. Measurement o)4ectives ma* )e constrained )* e5istin+ processes, availa)le resources, or ot$er measurement considerations. Kud+ments ma* need to )e made a)out '$et$er t$e value of t$e result is commensurate 'it$ resources devoted to doin+ t$e 'or2. Modifications to identified information needs and o)4ectives can, in turn, )e indicated as a conse/uence of t$e process and results of measurement and anal*sis. *ources of information needs and objectives can include the following: 'roject plans 'roject performance monitoring &nterviews with managers and others who have information needs Established management objectives *trategic plans ;usiness plans Formal re0uirements or contractual obligations #ecurring or other troublesome management or technical problems Experiences of other projects or organi6ational entities External industry benchmar1s 'rocess improvement plans
1<0
Example measurement objectives include the following: 'rovide insight into schedule fluctuations and progress 'rovide insight into actual si6e compared to plan &dentify unplanned growth Evaluate the effectiveness of defect detection throughout the product development lifecycle %etermine the cost of correcting defects 'rovide insight into actual costs compared to plan Evaluate supplier progress against the plan Evaluate the effectiveness of mitigating information system vulnerabilities
"efer to the "e,uirements evelopment process area for more information about eliciting2 analy-ing2 and establishing customer2 product2 and product component re,uirements% "efer to the Pro.ect Monitoring and Control process area for more information about monitoring pro.ect planning parameters% "efer to the Pro.ect Planning process area for more information about establishing estimates% "efer to the "e,uirements Management process area for more information about maintaining bidirectional traceability of re,uirements%
1. 1. ".
Measurement o)4ectives Document information needs and o)4ectives. Prioriti-e information needs and o)4ectives. &t can be neither possible nor desirable to subject all initially identified information needs to measurement and analysis. 'riorities may also need to be set within the limits of available resources.
S/b'ra#t"#e$
3.
Document, revie', and update measurement o)4ectives. Carefully consider the purposes and intended uses of measurement and analysis. (he measurement objectives are documented, reviewed by management and other relevant sta1eholders, and updated as necessary. %oing so enables traceability to subse0uent measurement and analysis activities, and helps to ensure that analyses will properly address identified information needs and objectives. &t is important that users of measurement and analysis results be involved in setting measurement objectives and deciding on plans of action. &t may also be appropriate to involve those who provide the measurement data.
8.
Provide feed)ac2 for refinin+ and clarif*in+ information needs and o)4ectives as necessar*.
1<1
&dentified information needs and objectives can be refined and clarified as a result of setting measurement objectives. &nitial descriptions of information needs may be ambiguous. Conflicts can arise between existing needs and objectives. 'recise targets on an already existing measure may be unrealistic. 9. Maintain tracea)ilit* of measurement o)4ectives to identified information needs and o)4ectives. (here should always be a good answer to the 0uestion, @4hy are we measuring thisDA Of course, measurement objectives can also change to reflect evolving information needs and objectives.
SP 1*2 S'e#"f1 Mea$/re$
pecify measures to address measurement o'/ecti)es.

Measurement o)4ectives are refined into precise, /uantifia)le measures. Measurement of pro4ect and or+ani-ational 'or2 can t*picall* )e traced to one or more measurement information cate+ories. T$ese cate+ories include t$e follo'in+% sc$edule and pro+ress, effort and cost, si-e and sta)ilit*, and /ualit*. Measures can )e eit$er base or derived. Data for )ase measures are o)tained )* direct measurement. Data for derived measures come from ot$er data, t*picall* )* com)inin+ t'o or more )ase measures. Examples of commonly used base measures include the following: Estimates and actual measures of wor1 product si6e 2e.g., number of pages3 Estimates and actual measures of effort and cost 2e.g., number of person hours3 )uality measures 2e.g., number of defects by severity3 &nformation security measures 2e.g., number of system vulnerabilities identified3 Customer satisfaction survey scores
Examples of commonly used derived measures include the following: Earned value *chedule performance index %efect density 'eer review coverage (est or verification coverage #eliability measures 2e.g., mean time to failure3 )uality measures 2e.g., number of defects by severityEtotal number of defects3 &nformation security measures 2e.g., percentage of system vulnerabilities mitigated3 Customer satisfaction trends
Derived measures t*picall* are e5pressed as ratios, composite indices, or ot$er a++re+ate summar* measures. T$e* are often more /uantitativel*
1<2
relia)le and meanin+full* interpreta)le t$an t$e )ase measures used to +enerate t$em. T$ere are direct relations$ips amon+ information needs, measurement o)4ectives, measurement cate+ories, )ase measures, and derived measures. T$is direct relations$ip is depicted usin+ some common e5amples in Ta)le M0.1.
1<3
Ta'le M".1: +,ample Measurement #elationships
Example Pro$ect% &rgani'ational% or #usiness &b$ectives *horten time to delivery ;e first to mar1et the product
Information Need
Measurement &b$ective
Measurement Information Categories
Example #ase Measures
Example (erived Measures
4hat is the estimated delivery timeD
'rovide insight into schedule fluctuations and progress
*chedule and progress
Estimated and actual start and end dates by tas1
$ilestone performance 'ercentage of project on time *chedule estimation accuracy
&ncrease mar1et share by reducing costs of products and services %eliver specified functionality
/ow accurate are the si6e and cost estimatesD /as scope or project si6e grownD
'rovide insight into actual si6e and costs compared to plan 'rovide insight into actual si6e compared to plan, identify unplanned growth
*i6e and effort
Estimated and actual effort and si6e Estimated and actual cost #e0uirements count
'roductivity Cost performance Cost variance #e0uirements volatility *i6e estimation accuracy
Effort and cost *i6e and stability
Function point count -ines of code count 7umber of defects inserted and detected by lifecycle phase 'roduct si6e Cost 7umber of defects inserted and detected by lifecycle phase Effort hours to correct defects -abor rates
Estimated vs. actual function points "mount of new, modified, and reused code %efect containment by lifecycle phase %efect density
#educe defects in products delivered to the customer by =>F without affecting cost
4here are defects being inserted and detected prior to deliveryD 4hat is the cost of rewor1D
Evaluate the effectiveness of defect detection throughout the product lifecycle %etermine the cost of correcting defects
)uality
#ewor1 costs
#educe information system vulnerabilities
4hat is the magnitude of open system vulnerabilitiesD
Evaluate the effectiveness of mitigating system vulnerabilities
&nformation "ssurance
7umber of system vulnerabilities identified and number of system vulnerabilities mitigated
'ercentage of system vulnerabilities mitigated
1<4
1. 1.
pecifications of )ase and derived measures Identif* candidate measures )ased on documented measurement o)4ectives. $easurement objectives are refined into measures. &dentified candidate measures are categori6ed and specified by name and unit of measure.
S/b'ra#t"#e$
".
Maintain tracea)ilit* of measures to measurement o)4ectives. &nterdependencies among candidate measures are identified to enable later data validation and candidate analyses in support of measurement objectives.
3.
Identif* e5istin+ measures t$at alread* address measurement o)4ectives. *pecifications for measures may already exist, perhaps established for other purposes earlier or elsewhere in the organi6ation.
8.
pecif* operational definitions for measures. Operational definitions are stated in precise and unambiguous terms. (hey address two important criteria:
Communication: 4hat has been measured, how was it measured, what are the units of measure, and what has been included or excludedD #epeatability: Can the measurement be repeated, given the same definition, to get the same resultsD
9.
Prioriti-e, revie', and update measures. 'roposed specifications of measures are reviewed for their appropriateness with potential end users and other relevant sta1eholders. 'riorities are set or changed, and specifications of measures are updated as necessary.
SP 1*3
S'e#"f1 %ata Co&&e#t"o a + Stora!e Pro#e+/re$
pecify ho3 measurement data are o'tained and stored.

E5plicit specification of collection met$ods $elps to ensure t$at t$e ri+$t data are collected properl*. T$is specification can also $elp furt$er clarif* information needs and measurement o)4ectives. Proper attention to stora+e and retrieval procedures $elps to ensure t$at data are availa)le and accessi)le for future use.
1. ". 1.
Data collection and stora+e procedures Data collection tools Identif* e5istin+ sources of data t$at are +enerated from current 'or2 products, processes, or transactions.
S/b'ra#t"#e$
1<5
Existing sources of data may have been identified when specifying the measures. "ppropriate collection mechanisms may exist whether or not pertinent data have already been collected. ". 3. Identif* measures for '$ic$ data are needed )ut are not currentl* availa)le. pecif* $o' to collect and store t$e data for eac$ re/uired measure. Explicit specifications are made of what, how, where, and when data will be collected and stored to ensure its validity and to support later use for analysis and documentation purposes. )uestions to be considered typically include the following:
/ave the fre0uency of collection and the points in the process where measurements will be made been determinedD /as the timeline that is re0uired to move measurement results from points of collection to repositories, other databases, or end users been establishedD 4ho is responsible for obtaining dataD 4ho is responsible for data storage, retrieval, and securityD /ave necessary supporting tools been developed or ac0uiredD
8.
Create data collection mec$anisms and process +uidance. %ata collection and storage mechanisms are well integrated with other normal wor1 processes. %ata collection mechanisms can include manual or automated forms and templates. Clear, concise guidance on correct procedures is available to those who are responsible for doing the wor1. (raining is provided as needed to clarify processes re0uired for the collection of complete and accurate data and to minimi6e the burden on those who provide and record data.
9.
upport automatic collection of data as appropriate and feasi)le. Examples of such automated support include the following:
(ime stamped activity logs *tatic or dynamic analyses of artifacts
G.
Prioriti-e, revie', and update data collection and stora+e procedures. 'roposed procedures are reviewed for their appropriateness and feasibility with those who are responsible for providing, collecting, and storing data. (hey also may have useful insights about how to improve existing processes or may be able to suggest other useful measures or analyses.
=.
SP 1*4
:pdate measures and measurement o)4ectives as necessar*.
S'e#"f1 A a&1$"$ Pro#e+/re$
pecify ho3 measurement data are analy5ed and communicated.

pecif*in+ anal*sis procedures in advance ensures t$at appropriate anal*ses 'ill )e conducted and reported to address documented measurement o)4ectives (and t$ere)* t$e information needs and o)4ectives
1<6
on '$ic$ t$e* are )ased,. T$is approac$ also provides a c$ec2 t$at necessar* data 'ill, in fact, )e collected. 0nal*sis procedures s$ould account for t$e /ualit* (e.+., a+e, relia)ilit*, of all data t$at enter into an anal*sis ('$et$er from t$e pro4ect, or+ani-ation;s measurement repositor*, or ot$er source,. T$e /ualit* of data s$ould )e considered to $elp select t$e appropriate anal*sis procedure and evaluate t$e results of t$e anal*sis.
1. ". 1.
0nal*sis specifications and procedures Data anal*sis tools pecif* and prioriti-e t$e anal*ses to )e conducted and t$e reports to )e prepared. Early on, pay attention to the analyses to be conducted and to the manner in which results will be reported. (hese analyses and reports should meet the following criteria:
(he analyses explicitly address the documented measurement objectives. 'resentation of results is clearly understandable by the audiences to whom the results are addressed.
S/b'ra#t"#e$
'riorities may have to be set for available resources. ". elect appropriate data anal*sis met$ods and tools. &ssues to be considered typically include the following:
Choice of visual display and other presentation techni0ues 2e.g., pie charts, bar charts, histograms, radar charts, line graphs, scatter plots, tables3 Choice of appropriate descriptive statistics 2e.g., arithmetic mean, median, mode3 %ecisions about statistical sampling criteria when it is impossible or unnecessary to examine every data element %ecisions about how to handle analysis in the presence of missing data elements *election of appropriate analysis tools
%escriptive statistics are typically used in data analysis to do the following:

Examine distributions of specified measures 2e.g., central tendency, extent of variation, data points exhibiting unusual variation3 Examine interrelationships among specified measures 2e.g., comparisons of defects by phase of the product9s lifecycle, comparisons of defects by product component3 %isplay changes over time
"efer to the Select Measures and $nalytic Techni,ues specific practice and Monitor the Performance of Selected Subprocesses specific practice in the 4uantitative Pro.ect Management process area for more information about the appropriate use of statistical techni,ues and understanding variation% 3. pecif* administrative procedures for anal*-in+ data and communicatin+ results.
1<8
&ssues to be considered typically include the following:

&dentifying the persons and groups responsible for analy6ing the data and presenting the results %etermining the timeline to analy6e the data and present the results %etermining the venues for communicating the results 2e.g., progress reports, transmittal memos, written reports, staff meetings3
8.
!evie' and update t$e proposed content and format of specified anal*ses and reports. "ll of the proposed content and format are subject to review and revision, including analytic methods and tools, administrative procedures, and priorities. #elevant sta1eholders consulted should include end users, sponsors, data analysts, and data providers.
9.
:pdate measures and measurement o)4ectives as necessar*. Cust as measurement needs drive data analysis, clarification of analysis criteria can affect measurement. *pecifications for some measures may be refined further based on specifications established for data analysis procedures. Other measures may prove unnecessary or a need for additional measures may be recogni6ed. *pecifying how measures will be analy6ed and reported can also suggest the need for refining measurement objectives themselves.
G.
pecif* criteria for evaluatin+ t$e utilit* of anal*sis results and for evaluatin+ t$e conduct of measurement and anal*sis activities. Criteria for evaluating the utility of the analysis might address the extent to which the following apply:
(he results are provided in a timely manner, understandable, and used for decision ma1ing. (he wor1 does not cost more to perform than is justified by the benefits it provides.
Criteria for evaluating the conduct of the measurement and analysis might include the extent to which the following apply:
(he amount of missing data or the number of flagged inconsistencies is beyond specified thresholds. (here is selection bias in sampling 2e.g., only satisfied end users are surveyed to evaluate end5user satisfaction, only unsuccessful projects are evaluated to determine overall productivity3. $easurement data are repeatable 2e.g., statistically reliable3. *tatistical assumptions have been satisfied 2e.g., about the distribution of data, about appropriate measurement scales3.
1<<
S7 2
Prov"+e Mea$/reme t Re$/&t$
Measurement results* 3hich address identified information needs and o'/ecti)es* are pro)ided.
T$e primar* reason for conductin+ measurement and anal*sis is to address identified information needs derived from pro4ect, or+ani-ational, and )usiness o)4ectives. Measurement results )ased on o)4ective evidence can $elp to monitor pro+ress and performance, fulfill o)li+ations documented in a supplier a+reement, ma2e informed mana+ement and tec$nical decisions, and ena)le corrective actions to )e ta2en.
SP 2*1 Obta" Mea$/reme t %ata
6'tain specified measurement data.

T$e data necessar* for anal*sis are o)tained and c$ec2ed for completeness and inte+rit*.
1. ". 1.
.ase and derived measurement data sets !esults of data inte+rit* tests 7)tain data for )ase measures. %ata are collected as necessary for previously used and newly specified base measures. Existing data are gathered from project records or elsewhere in the organi6ation.
S/b'ra#t"#e$
".
3enerate data for derived measures. ,alues are newly calculated for all derived measures.
3.
Perform data inte+rit* c$ec2s as close to t$e source of data as possi)le. "ll measurements are subject to error in specifying or recording data. &t is always better to identify these errors and sources of missing data early in the measurement and analysis cycle. Chec1s can include scans for missing data, out5of5bounds data values, and unusual patterns and correlation across measures. &t is particularly important to do the following:
(est and correct for inconsistency of classifications made by human judgment 2i.e., to determine how fre0uently people ma1e differing classification decisions based on the same information, otherwise 1nown as @inter5coder reliabilityA3. Empirically examine the relationships among measures that are used to calculate additional derived measures. %oing so can ensure that important distinctions are not overloo1ed and that derived measures convey their intended meanings 2otherwise 1nown as @criterion validityA3.
1<3
SP 2*2
A a&1Ae Mea$/reme t %ata
"naly5e and interpret measurement data.

Measurement data are anal*-ed as planned, additional anal*ses are conducted as necessar*, results are revie'ed 'it$ relevant sta2e$olders, and necessar* revisions for future anal*ses are noted.
1. 1.
0nal*sis results and draft reports Conduct initial anal*ses, interpret results, and dra' preliminar* conclusions. (he results of data analyses are rarely self evident. Criteria for interpreting results and drawing conclusions should be stated explicitly.
S/b'ra#t"#e$
".
Conduct additional measurement and anal*sis as necessar* and prepare results for presentation. #esults of planned analyses can suggest 2or re0uire3 additional, unanticipated analyses. &n addition, these analyses can identify needs to refine existing measures, to calculate additional derived measures, or even to collect data for additional base measures to properly complete the planned analysis. *imilarly, preparing initial results for presentation can identify the need for additional, unanticipated analyses.
3.
!evie' initial results 'it$ relevant sta2e$olders. &t may be appropriate to review initial interpretations of results and the way in which these results are presented before disseminating and communicating them widely. #eviewing the initial results before their release can prevent needless misunderstandings and lead to improvements in the data analysis and presentation. #elevant sta1eholders with whom reviews may be conducted include intended end users, sponsors, data analysts, and data providers.
8.
!efine criteria for future anal*ses. -essons that can improve future efforts are often learned from conducting data analyses and preparing results. *imilarly, ways to improve measurement specifications and data collection procedures can become apparent as can ideas for refining identified information needs and objectives.
SP 2*3
Store %ata a + Re$/&t$
Manage and store measurement data* measurement specifications* and analysis results.
torin+ measurement related information ena)les its timel* and cost effective use as $istorical data and results. T$e information also is needed to provide sufficient conte5t for interpretation of data, measurement criteria, and anal*sis results.
130
&nformation stored typically includes the following: $easurement plans *pecifications of measures *ets of data that were collected "nalysis reports and presentations #etention period for data stored
tored information contains or refers to ot$er information needed to understand and interpret t$e measures and to assess t$em for reasona)leness and applica)ilit* (e.+., measurement specifications used on different pro4ects '$en comparin+ across pro4ects,. T*picall*, data sets for derived measures can )e recalculated and need not )e stored. @o'ever, it ma* )e appropriate to store summaries )ased on derived measures (e.+., c$arts, ta)les of results, report te5t,. Interim anal*sis results need not )e stored separatel* if t$e* can )e efficientl* reconstructed. Pro4ects can c$oose to store pro4ect specific data and results in a pro4ect specific repositor*. 6$en data are s$ared across pro4ects, t$e data can reside in t$e or+ani-ation;s measurement repositor*. "efer to the Configuration Management process area for more information about establishing a configuration management system% "efer to the Establish the 0rgani-ation3s Measurement "epository specific practice in the 0rgani-ational Process efinition process area for more information about establishing the organi-ation3s measurement repository%
1. 1. ". 3. 8.
tored data inventor* !evie' data to ensure t$eir completeness, inte+rit*, accurac*, and currenc*. tore data accordin+ to data stora+e procedures. Ma2e stored contents availa)le for use onl* to appropriate +roups and staff mem)ers. Prevent stored information from )ein+ used inappropriatel*. Examples of ways to prevent the inappropriate use of data and related information include controlling access to data and educating people on the appropriate use of data.
S/b'ra#t"#e$
131
Examples of the inappropriate use of data include the following:

%isclosure of information provided in confidence Faulty interpretations based on incomplete, out5of5context, or otherwise misleading information $easures used to improperly evaluate the performance of people or to ran1 projects &mpugning the integrity of individuals SP 2*4 Comm/ "#ate Re$/&t$
Communicate results of measurement and analysis acti)ities to all rele)ant sta4eholders.

T$e results of t$e measurement and anal*sis process are communicated to relevant sta2e$olders in a timel* and usa)le fas$ion to support decision ma2in+ and assist in ta2in+ corrective action. !elevant sta2e$olders include intended end users, sponsors, data anal*sts, and data providers.
1. ". 1.
Delivered reports and related anal*sis results Conte5tual information or +uidance to $elp interpret anal*sis results Neep relevant sta2e$olders informed of measurement results in a timel* manner. (o the extent possible and as part of the normal way they do business, users of measurement results are 1ept personally involved in setting objectives and deciding on plans of action for measurement and analysis. :sers are regularly 1ept informed of progress and interim results. "efer to the Pro.ect Monitoring and Control process area for more information about conducting progress reviews%
S/b'ra#t"#e$
".
0ssist relevant sta2e$olders in understandin+ results. #esults are communicated in a clear and concise manner appropriate to relevant sta1eholders. #esults are understandable, easily interpretable, and clearly tied to identified information needs and objectives. (he data analy6ed are often not self evident to practitioners who are not measurement experts. (he communication of results should be clear about the following:
/ow and why base and derived measures were specified /ow data were obtained /ow to interpret results based on the data analysis methods used /ow results address information needs
132
Examples of actions ta1en to help others to understand results include the following:
%iscussing the results with relevant sta1eholders 'roviding bac1ground and explanation in a document ;riefing users on results 'roviding training on the appropriate use and understanding of measurement results
133
OR/A*I1A(IO*A+ PRO!$)) D$FI*I(IO*

A Process Management Process Area at Maturity Level 3
Purpose
T$e purpose of 7r+ani-ational Process Definition (7PD, is to esta)lis$ and maintain a usa)le set of or+ani-ational process assets, 'or2 environment standards, and rules and +uidelines for teams.
Introductor" *otes
7r+ani-ational process assets ena)le consistent process e5ecution across t$e or+ani-ation and provide a )asis for cumulative, lon+-term )enefits to t$e or+ani-ation. ( ee t$e definition of Lor+ani-ational process assetsM in t$e +lossar*., T$e or+ani-ation;s process asset li)rar* supports or+ani-ational learnin+ and process improvement )* allo'in+ t$e s$arin+ of )est practices and lessons learned across t$e or+ani-ation. ( ee t$e definition of Lor+ani-ational process assetsM in t$e +lossar*., T$e or+ani-ation;s set of standard processes also descri)es standard interactions 'it$ suppliers. upplier interactions are c$aracteri-ed )* t$e follo'in+ t*pical items% delivera)les e5pected from suppliers, acceptance criteria applica)le to t$ose delivera)les, standards (e.+., arc$itecture and tec$nolo+* standards,, and standard milestone and pro+ress revie's. T$e or+ani-ation;s Lset of standard processesM is tailored )* pro4ects to create t$eir defined processes. 7t$er or+ani-ational process assets are used to support tailorin+ and implementin+ defined processes. 6or2 environment standards are used to +uide t$e creation of pro4ect 'or2 environments. !ules and +uidelines for teams are used to aid in t$eir structurin+, formation, and operation. 0 Lstandard processM is composed of ot$er processes (i.e., su)processes, or process elements. 0 Lprocess elementM is t$e fundamental (i.e., atomic, unit of process definition t$at descri)es activities and tas2s to consistentl* perform 'or2. T$e process arc$itecture provides rules for connectin+ t$e process elements of a standard process. T$e or+ani-ation;s set of standard processes can include multiple process arc$itectures. ( ee t$e definitions of Lstandard process,M Lprocess arc$itecture,M Lsu)process,M and Lprocess elementM in t$e +lossar*.,
134
Or!a "Aat"o a& Pro#e$$ %ef" "t"o :OP%;
Organi6ational process assets can be organi6ed in many ways, depending on the implementation of the Organi6ational 'rocess %efinition process area. Examples include the following: %escriptions of lifecycle models can be part of the organi6ation9s set of standard processes or they can be documented separately. (he organi6ation9s set of standard processes can be stored in the organi6ation9s process asset library or it can be stored separately. " single repository can contain both measurements and process related documentation, or they can be stored separately.
"efer to the 0rgani-ational Process 9ocus process area for more information about deploying organi-ational process assets%
3 1 Esta)lis$ 7r+ani-ational Process 0ssets P 1.1 P 1." P 1.3 P 1.8 P 1.9 P 1.G P 1.= Esta)lis$ tandard Processes Esta)lis$ Aifec*cle Model Descriptions Esta)lis$ Tailorin+ Criteria and 3uidelines Esta)lis$ t$e 7r+ani-ation;s Measurement !epositor* Esta)lis$ t$e 7r+ani-ation;s Process 0sset Ai)rar* Esta)lis$ 6or2 Environment tandards Esta)lis$ !ules and 3uidelines for Teams
)pecific Practices b" /oal S7 1 E$tab&"$- Or!a "Aat"o a& Pro#e$$ A$$et$
" set of organi5ational process assets is esta'lished and maintained.

SP 1*1 E$tab&"$- Sta +ar+ Pro#e$$e$
+sta'lish and maintain the organi5ation7s set of standard processes.

tandard processes can )e defined at multiple levels in an enterprise and t$e* can )e related $ierarc$icall*. 1or e5ample, an enterprise can $ave a set of standard processes t$at is tailored )* individual or+ani-ations (e.+., a division, a site, in t$e enterprise to esta)lis$ t$eir set of standard processes. T$e set of standard processes can also )e tailored for eac$ of t$e or+ani-ation;s )usiness areas, product lines, or standard services. T$us t$e organi-ation3s set of standard processes can refer to t$e standard processes esta)lis$ed at t$e or+ani-ation level and standard processes t$at ma* )e esta)lis$ed at lo'er levels, alt$ou+$ some or+ani-ations ma* $ave onl* one level of standard processes. ( ee t$e definitions of Lstandard processM and Lor+ani-ation;s set of standard processesM in t$e +lossar*., Multiple standard processes ma* )e needed to address t$e needs of different application domains, lifec*cle models, met$odolo+ies, and tools.
135
T$e or+ani-ation;s set of standard processes contains process elements (e.+., a 'or2 product si-e estimatin+ element, t$at ma* )e interconnected accordin+ to one or more process arc$itectures t$at descri)e relations$ips amon+ process elements. T$e or+ani-ation;s set of standard processes t*picall* includes tec$nical, mana+ement, administrative, support, and or+ani-ational processes. T$e or+ani-ation;s set of standard processes s$ould collectivel* cover all processes needed )* t$e or+ani-ation and pro4ects, includin+ t$ose processes addressed )* t$e process areas at maturit* level ".
1. 1.
7r+ani-ation;s set of standard processes Decompose eac$ standard process into constituent process elements to t$e detail needed to understand and descri)e t$e process. Each process element covers a closely related set of activities. (he descriptions of process elements may be templates to be filled in, fragments to be completed, abstractions to be refined, or complete descriptions to be tailored or used unmodified. (hese elements are described in such detail that the process, when fully defined, can be consistently performed by appropriately trained and s1illed people. Examples of process elements include the following:
(emplate for generating wor1 product si6e estimates %escription of wor1 product design methodology (ailorable peer review methodology (emplate for conducting management reviews (emplates or tas1 flows embedded in wor1flow tools %escription of methods for pre0ualifying suppliers as preferred suppliers
S/b'ra#t"#e$
".
pecif* t$e critical attri)utes of eac$ process element. Examples of critical attributes include the following:
'rocess roles "pplicable standards "pplicable procedures, methods, tools, and resources 'rocess performance objectives Entry criteria &nputs ,erification points 2e.g., peer reviews3 Outputs &nterfaces Exit criteria 'roduct and process measures
136
3.
pecif* relations$ips amon+ process elements. Examples of relationships include the following:
Order of the process elements &nterfaces among process elements &nterfaces with external processes &nterdependencies among process elements
(he rules for describing relationships among process elements are referred to as the @process architecture.A (he process architecture covers essential re0uirements and guidelines. %etailed specifications of these relationships are covered in descriptions of defined processes that are tailored from the organi6ation9s set of standard processes. 8. Ensure t$at t$e or+ani-ation;s set of standard processes ad$eres to applica)le policies, standards, and models. "dherence to applicable process standards and models is typically demonstrated by developing a mapping from the organi6ation9s set of standard processes to relevant process standards and models. (his mapping is a useful input to future appraisals. 9. Ensure t$at t$e or+ani-ation;s set of standard processes satisfies process needs and o)4ectives of t$e or+ani-ation. "efer to the 0rgani-ational Process 9ocus process area for more information about establishing organi-ational process needs% G. =. H. Ensure t$at t$ere is appropriate inte+ration amon+ processes t$at are included in t$e or+ani-ation;s set of standard processes. Document t$e or+ani-ation;s set of standard processes. Conduct peer revie's on t$e or+ani-ation;s set of standard processes. "efer to the 8erification process area for more information about performing peer reviews% F. !evise t$e or+ani-ation;s set of standard processes as necessar*. Examples of when the organi6ation?s set of standard processes may need to be revised include the following:
4hen improvements to the process are identified 4hen causal analysis and resolution data indicate that a process change is needed 4hen process improvement proposals are selected for deployment across the organi6ation 4hen the organi6ation9s process needs and objectives are updated SP 1*2 E$tab&"$- L"fe#1#&e Mo+e& %e$#r"'t"o $
+sta'lish and maintain descriptions of lifecycle models appro)ed for use in the organi5ation.
Aifec*cle models can )e developed for a variet* of customers or in a variet* of situations, since one lifec*cle model ma* not )e appropriate for all
138
situations. Aifec*cle models are often used to define p$ases of t$e pro4ect. 0lso, t$e or+ani-ation can define different lifec*cle models for eac$ t*pe of product and service it delivers.
1. 1.
Descriptions of lifec*cle models elect lifec*cle models )ased on t$e needs of pro4ects and t$e or+ani-ation. Examples of project lifecycle models include the following:
4aterfall or *erial *piral Evolutionary &ncremental &terative
S/b'ra#t"#e$
".
Document descriptions of lifec*cle models. -ifecycle models can be documented as part of the organi6ation9s standard process descriptions or they can be documented separately.
3.
Conduct peer revie's on lifec*cle models. "efer to the 8erification process area for more information about performing peer reviews%
8.
SP 1*3
!evise t$e descriptions of lifec*cle models as necessar*.
E$tab&"$- Ta"&or" ! Cr"ter"a a + 7/"+e&" e$
+sta'lish and maintain tailoring criteria and guidelines for the organi5ation7s set of standard processes.
Tailorin+ criteria and +uidelines descri)e t$e follo'in+% @o' t$e or+ani-ation;s set of standard processes and or+ani-ational process assets are used to create defined processes !e/uirements t$at must )e satisfied )* defined processes (e.+., t$e su)set of or+ani-ational process assets t$at are essential for an* defined process, 7ptions t$at can )e e5ercised and criteria for selectin+ amon+ options Procedures t$at must )e follo'ed in performin+ and documentin+ process tailorin+
Examples of reasons for tailoring include the following: "dapting the process to a new product line or wor1 environment Elaborating the process description so that the resulting defined process can be performed Customi6ing the process for an application or class of similar applications
13<
1le5i)ilit* in tailorin+ and definin+ processes is )alanced 'it$ ensurin+ appropriate consistenc* of processes across t$e or+ani-ation. 1le5i)ilit* is needed to address conte5tual varia)les suc$ as t$e domainI t$e nature of t$e customerI cost, sc$edule, and /ualit* tradeoffsI t$e tec$nical difficult* of t$e 'or2I and t$e e5perience of t$e people implementin+ t$e process. Consistenc* across t$e or+ani-ation is needed so t$at or+ani-ational standards, o)4ectives, and strate+ies are appropriatel* addressed, and process data and lessons learned can )e s$ared. Tailorin+ is a critical activit* t$at allo's controlled c$an+es to processes due to t$e specific needs of a pro4ect or a part of t$e or+ani-ation. Processes and process elements t$at are directl* related to critical )usiness o)4ectives s$ould usuall* )e defined as mandator*, )ut processes and process elements t$at are less critical or onl* indirectl* affect )usiness o)4ectives ma* allo' for more tailorin+. T$e amount of tailorin+ could also depend on t$e pro4ect;s lifec*cle model, t$e use of suppliers, and ot$er factors. Tailorin+ criteria and +uidelines can allo' for usin+ a standard process Las is,M 'it$ no tailorin+.
1. 1.
Tailorin+ +uidelines for t$e or+ani-ation;s set of standard processes pecif* selection criteria and procedures for tailorin+ t$e or+ani-ation;s set of standard processes. Examples of criteria and procedures include the following:
Criteria for selecting lifecycle models from the ones approved by the organi6ation Criteria for selecting process elements from the organi6ation9s set of standard processes 'rocedures for tailoring selected lifecycle models and process elements to accommodate process characteristics and needs 'rocedures for adapting the organi6ation9s common measures to address information needs
S/b'ra#t"#e$
Examples of tailoring include the following:

$odifying a lifecycle model Combining elements of different lifecycle models $odifying process elements #eplacing process elements #eordering process elements
". 3.
pecif* t$e standards used for documentin+ defined processes. pecif* t$e procedures used for su)mittin+ and o)tainin+ approval of 'aivers from t$e or+ani-ation;s set of standard processes.
133
8. 9.
Document tailorin+ +uidelines for t$e or+ani-ation;s set of standard processes. Conduct peer revie's on t$e tailorin+ +uidelines. "efer to the 8erification process area for more information about performing peer reviews%
G.
SP 1*4
!evise tailorin+ +uidelines as necessar*.
E$tab&"$- t-e Or!a "Aat"o B$ Mea$/reme t Re'o$"tor1
+sta'lish and maintain the organi5ation7s measurement repository.

"efer to the ;se 0rgani-ational Process $ssets for Planning Pro.ect $ctivities specific practice in the Integrated Pro.ect Management process area for more information about the use of the organi-ation3s measurement repository in planning pro.ect activities% T$e repositor* contains )ot$ product and process measures t$at are related to t$e or+ani-ation;s set of standard processes. It also contains or refers to information needed to understand and interpret measures and to assess t$em for reasona)leness and applica)ilit*. 1or e5ample, t$e definitions of measures are used to compare similar measures from different processes.
1. ". 3. 8. 1. ".
Definition of t$e common set of product and process measures for t$e or+ani-ation;s set of standard processes Desi+n of t$e or+ani-ation;s measurement repositor* 7r+ani-ation;s measurement repositor* (i.e., t$e repositor* structure, support environment, 7r+ani-ation;s measurement data Determine t$e or+ani-ation;s needs for storin+, retrievin+, and anal*-in+ measurements. Define a common set of process and product measures for t$e or+ani-ation;s set of standard processes. $easures in the common set are selected for their ability to provide visibility into processes critical to achieving business objectives and to focus on process elements significantly impacting cost, schedule, and performance within a project and across the organi6ation. (he common set of measures can vary for different standard processes. $easures defined include the ones related to agreement management, some of which may need to be collected from suppliers. Operational definitions for measures specify procedures for collecting valid data and the point in the process where data will be collected.
S/b'ra#t"#e$
200
Examples of classes of commonly used measures include the following:

Estimates of wor1 product si6e 2e.g., pages3 Estimates of effort and cost 2e.g., person hours3 "ctual measures of si6e, effort, and cost (est coverage #eliability measures 2e.g., mean time to failure3 )uality measures 2e.g., number of defects found, severity of defects3 'eer review coverage
3.
Desi+n and implement t$e measurement repositor*. Functions of the measurement repository include the following: *upporting effective comparison and interpretation of measurement data among projects 'roviding sufficient context to allow a new project to 0uic1ly identify and access data in the repository for similar projects Enabling projects to improve the accuracy of their estimates by using their own and other projects9 historical data "iding in the understanding of process performance *upporting potential statistical management of processes or subprocesses, as needed
8.
pecif* procedures for storin+, updatin+, and retrievin+ measures. "efer to the Measurement and $nalysis process area for more information about specifying data collection and storage procedures%
9.
Conduct peer revie's on definitions of t$e common set of measures and procedures for storin+, updatin+, and retrievin+ measures. "efer to the 8erification process area for more information about performing peer reviews%
G.
Enter specified measures into t$e repositor*. "efer to the Measurement and $nalysis process area for more information about specifying measures%
=. H.
Ma2e t$e contents of t$e measurement repositor* availa)le for use )* t$e or+ani-ation and pro4ects as appropriate. !evise t$e measurement repositor*, t$e common set of measures, and procedures as t$e or+ani-ation;s needs c$an+e.
201
Examples of when the common set of measures may need to be revised include the following:
7ew processes are added 'rocesses are revised and new measures are needed Finer granularity of data is re0uired reater visibility into the process is re0uired $easures are retired SP 1*5 E$tab&"$- t-e Or!a "Aat"o B$ Pro#e$$ A$$et L"brar1
+sta'lish and maintain the organi5ation7s process asset li'rary.

Examples of items to be stored in the organi6ation9s process asset library include the following: Organi6ational policies 'rocess descriptions 'rocedures 2e.g., estimating procedure3 %evelopment plans "c0uisition plans )uality assurance plans (raining materials 'rocess aids 2e.g., chec1lists3 -essons learned reports
1. ". 3. 8. 1. ".
Desi+n of t$e or+ani-ation;s process asset li)rar* T$e or+ani-ation;s process asset li)rar* elected items to )e included in t$e or+ani-ation;s process asset li)rar* T$e catalo+ of items in t$e or+ani-ation;s process asset li)rar* Desi+n and implement t$e or+ani-ation;s process asset li)rar*, includin+ t$e li)rar* structure and support environment. pecif* criteria for includin+ items in t$e li)rar*. &tems are selected based primarily on their relationship to the organi6ation9s set of standard processes.
S/b'ra#t"#e$
3. 8. 9.
pecif* procedures for storin+, updatin+, and retrievin+ items. Enter selected items into t$e li)rar* and catalo+ t$em for eas* reference and retrieval. Ma2e items availa)le for use )* pro4ects.
202
G. =.
Periodicall* revie' t$e use of eac$ item. !evise t$e or+ani-ation;s process asset li)rar* as necessar*. Examples of when the library may need to be revised include the following:
7ew items are added &tems are retired Current versions of items are changed
SP 1*6
E$tab&"$- >or? E v"ro me t Sta +ar+$
+sta'lish and maintain 3or4 en)ironment standards.

6or2 environment standards allo' t$e or+ani-ation and pro4ects to )enefit from common tools, trainin+, and maintenance, as 'ell as cost savin+s from volume purc$ases. 6or2 environment standards address t$e needs of all sta2e$olders and consider productivit*, cost, availa)ilit*, securit*, and 'or2place $ealt$, safet*, and er+onomic factors. 6or2 environment standards can include +uidelines for tailorin+ and t$e use of 'aivers t$at allo' adaptation of t$e pro4ect;s 'or2 environment to meet needs. Examples of wor1 environment standards include the following: 'rocedures for the operation, safety, and security of the wor1 environment *tandard wor1station hardware and software *tandard application software and tailoring guidelines for it *tandard production and calibration e0uipment 'rocess for re0uesting and approving tailoring or waivers
1. 1. ".
6or2 environment standards Evaluate commerciall* availa)le 'or2 environment standards appropriate for t$e or+ani-ation. 0dopt e5istin+ 'or2 environment standards and develop ne' ones to fill +aps )ased on t$e or+ani-ation;s process needs and o)4ectives.
S/b'ra#t"#e$
SP 1*8
E$tab&"$- R/&e$ a + 7/"+e&" e$ for Team$
+sta'lish and maintain organi5ational rules and guidelines for the structure* formation* and operation of teams.
7peratin+ rules and +uidelines for teams define and control $o' teams are created and $o' t$e* interact to accomplis$ o)4ectives. Team mem)ers s$ould understand t$e standards for 'or2 and participate accordin+ to t$ose standards. 6$en esta)lis$in+ rules and +uidelines for teams, ensure t$e* compl* 'it$ all local and national re+ulations or la's t$at can affect t$e use of teams.
203
tructurin+ teams involves definin+ t$e num)er of teams, t$e t*pe of eac$ team, and $o' eac$ team relates to t$e ot$ers in t$e structure. 1ormin+ teams involves c$arterin+ eac$ team, assi+nin+ team mem)ers and team leaders, and providin+ resources to eac$ team to accomplis$ 'or2.
1. ". 1.
!ules and +uidelines for structurin+ and formin+ teams 7peratin+ rules for teams Esta)lis$ and maintain empo'erment mec$anisms to ena)le timel* decision ma2in+. &n a successful teaming environment, clear channels of responsibility and authority are established by documenting and deploying organi6ational guidelines that clearly define the empowerment of teams.
S/b'ra#t"#e$
".
Esta)lis$ and maintain rules and +uidelines for structurin+ and formin+ teams. Organi6ational process assets can help the project to structure and implement teams. *uch assets can include the following:
(eam structure guidelines (eam formation guidelines (eam authority and responsibility guidelines uidelines for establishing lines of communication, authority, and escalation (eam leader selection criteria
3.
Define t$e e5pectations, rules, and +uidelines t$at +uide $o' teams 'or2 collectivel*. (hese rules and guidelines establish organi6ational practices for consistency across teams and can include the following:
/ow interfaces among teams are established and maintained /ow assignments are accepted and transferred /ow resources and inputs are accessed /ow wor1 gets done 4ho chec1s, reviews, and approves wor1 /ow wor1 is approved /ow wor1 is delivered and communicated 4ho reports to whom 4hat the reporting re0uirements 2e.g., cost, schedule, performance status3, measures, and methods are 4hich progress reporting measures and methods are used
204
205
OR/A*I1A(IO*A+ PRO!$)) FO!U)

Purpose
T$e purpose of 7r+ani-ational Process 1ocus (7P1, is to plan, implement, and deplo* or+ani-ational process improvements )ased on a t$orou+$ understandin+ of current stren+t$s and 'ea2nesses of t$e or+ani-ation;s processes and process assets.
Introductor" *otes
T$e or+ani-ation;s processes include all processes used )* t$e or+ani-ation and its pro4ects. Candidate improvements to t$e or+ani-ation;s processes and process assets are o)tained from various sources, includin+ t$e measurement of processes, lessons learned in implementin+ processes, results of process appraisals, results of product and service evaluation activities, results of customer satisfaction evaluations, results of )enc$mar2in+ a+ainst ot$er or+ani-ations; processes, and recommendations from ot$er improvement initiatives in t$e or+ani-ation. Process improvement occurs in t$e conte5t of t$e or+ani-ation;s needs and is used to address t$e or+ani-ation;s o)4ectives. T$e or+ani-ation encoura+es participation in process improvement activities )* t$ose '$o perform t$e process. T$e responsi)ilit* for facilitatin+ and mana+in+ t$e or+ani-ation;s process improvement activities, includin+ coordinatin+ t$e participation of ot$ers, is t*picall* assi+ned to a process +roup. T$e or+ani-ation provides t$e lon+-term commitment and resources re/uired to sponsor t$is +roup and to ensure t$e effective and timel* deplo*ment of improvements. Careful plannin+ is re/uired to ensure t$at process improvement efforts across t$e or+ani-ation are ade/uatel* mana+ed and implemented. !esults of t$e or+ani-ation;s process improvement plannin+ are documented in a process improvement plan. T$e Lor+ani-ation;s process improvement planM addresses appraisal plannin+, process action plannin+, pilot plannin+, and deplo*ment plannin+. 0ppraisal plans descri)e t$e appraisal timeline and sc$edule, t$e scope of t$e appraisal, resources re/uired to perform t$e appraisal, t$e reference model a+ainst '$ic$ t$e appraisal 'ill )e performed, and lo+istics for t$e appraisal. Process action plans usuall* result from appraisals and document $o' improvements tar+etin+ 'ea2nesses uncovered )* an appraisal 'ill )e implemented. ometimes t$e improvement descri)ed in t$e process action plan s$ould )e tested on a small +roup )efore deplo*in+ it across t$e or+ani-ation. In t$ese cases, a pilot plan is +enerated.
206
Or!a "Aat"o a& Pro#e$$ .o#/$ :OP.;
6$en t$e improvement is to )e deplo*ed, a deplo*ment plan is created. T$is plan descri)es '$en and $o' t$e improvement 'ill )e deplo*ed across t$e or+ani-ation. 7r+ani-ational process assets are used to descri)e, implement, and improve t$e or+ani-ation;s processes. ( ee t$e definition of Lor+ani-ational process assetsM in t$e +lossar*.,
"efer to the 0rgani-ational Process efinition process area for more information about establishing organi-ational process assets%
3 1 Determine Process Improvement 7pportunities P 1.1 P 1." P 1.3 P ".1 P "." P 3.1 P 3." P 3.3 P 3.8 Esta)lis$ 7r+ani-ational Process <eeds 0ppraise t$e 7r+ani-ation;s Processes Identif* t$e 7r+ani-ation;s Process Improvements Esta)lis$ Process 0ction Plans Implement Process 0ction Plans Deplo* 7r+ani-ational Process 0ssets Deplo* tandard Processes Monitor t$e Implementation Incorporate E5periences into 7r+ani-ational Process 0ssets
3 " Plan and Implement Process 0ctions
3 3 Deplo* 7r+ani-ational Process 0ssets and Incorporate E5periences
)pecific Practices b" /oal S7 1 %eterm" e Pro#e$$ Im'roveme t O''ort/ "t"e$
trengths* 3ea4nesses* and impro)ement opportunities for the organi5ation7s processes are identified periodically and as needed.
tren+t$s, 'ea2nesses, and improvement opportunities can )e determined relative to a process standard or model suc$ as a CMMI model or I 7 standard. Process improvements s$ould )e selected to address t$e or+ani-ation;s needs. Process improvement opportunities can arise as a result of c$an+in+ )usiness o)4ectives, le+al and re+ulator* re/uirements, and results of )enc$mar2in+ studies.
SP 1*1 E$tab&"$- Or!a "Aat"o a& Pro#e$$ Nee+$
+sta'lish and maintain the description of process needs and o'/ecti)es for the organi5ation.
T$e or+ani-ation;s processes operate in a )usiness conte5t t$at s$ould )e understood. T$e or+ani-ation;s )usiness o)4ectives, needs, and constraints determine t$e needs and o)4ectives for t$e or+ani-ation;s processes. T*picall*, issues related to customer satisfaction, finance, tec$nolo+*, /ualit*, $uman resources, and mar2etin+ are important process considerations.
208
(he organi6ation9s process needs and objectives cover aspects that include the following: Characteristics of processes 'rocess performance objectives, such as time5to5mar1et and delivered 0uality 'rocess effectiveness
1. 1.
T$e or+ani-ation;s process needs and o)4ectives Identif* policies, standards, and )usiness o)4ectives t$at are applica)le to t$e or+ani-ation;s processes. Examples of standards include the following:
&*OE&EC =<<>G:<>>B *ystems and *oftware Engineering H *oftware -ife Cycle 'rocesses I&*O <>>BaJ &*OE&EC =K<BB:<>>B *ystems and *oftware Engineering H *ystem -ife Cycle 'rocesses I&*O <>>BbJ &*OE&EC <G>>=:<>>K &nformation technology H *ecurity techni0ues H &nformation *ecurity $anagement *ystems H #e0uirements I&*OE&EC <>>KJ &*OE&EC =LGML:<>>M *oftware Engineering H *oftware -ife Cycle 'rocesses H $aintenance I&*O <>>MbJ &*OE&EC <>>>> &nformation (echnology H *ervice $anagement I&*O <>>KbJ "ssurance Focus for C$$& I%/* <>>NJ 7%&" Engineering for *ystem "ssurance uideboo1 I7%&" <>>BJ #esiliency $anagement $odel I*E& <>=>cJ
S/b'ra#t"#e$
". 3.
E5amine relevant process standards and models for )est practices. Determine t$e or+ani-ation;s process performance o)4ectives. 'rocess performance objectives can be expressed in 0uantitative or 0ualitative terms. "efer to the Measurement and $nalysis process area for more information about establishing measurement ob.ectives% "efer to the 0rgani-ational Process Performance process area for more information about establishing ,uality and process performance ob.ectives% Examples of process performance objectives include the following:
"chieve a customer satisfaction rating of a certain value Ensure product reliability is at least a certain percentage #educe defect insertion rate by a certain percentage "chieve a certain cycle time for a given activity &mprove productivity by a given percentage *implify the re0uirements approval wor1flow &mprove 0uality of products delivered to customer
20<
8.
Define essential c$aracteristics of t$e or+ani-ation;s processes. Essential characteristics of the organi6ation9s processes are determined based on the following:
'rocesses currently being used in the organi6ation *tandards imposed by the organi6ation *tandards commonly imposed by customers of the organi6ation
Examples of process characteristics include the following:

-evel of detail 'rocess notation ranularity
9. G.
SP 1*2
Document t$e or+ani-ation;s process needs and o)4ectives. !evise t$e or+ani-ation;s process needs and o)4ectives as needed.
A''ra"$e t-e Or!a "Aat"o B$ Pro#e$$e$
"ppraise the organi5ation7s processes periodically and as needed to maintain an understanding of their strengths and 3ea4nesses.
'rocess appraisals can be performed for the following reasons: (o identify processes to be improved (o confirm progress and ma1e the benefits of process improvement visible (o satisfy the needs of a customer5supplier relationship (o motivate and facilitate buy5in
T$e )u*-in +ained durin+ a process appraisal can )e eroded si+nificantl* if it is not follo'ed )* an appraisal )ased action plan.
1. ". 3. 1.
Plans for t$e or+ani-ation;s process appraisals 0ppraisal findin+s t$at address stren+t$s and 'ea2nesses of t$e or+ani-ation;s processes Improvement recommendations for t$e or+ani-ation;s processes 7)tain sponsors$ip of t$e process appraisal from senior mana+ement. *enior management sponsorship includes the commitment to have the organi6ation9s managers and staff participate in the process appraisal and to provide resources and funding to analy6e and communicate findings of the appraisal.
S/b'ra#t"#e$
".
Define t$e scope of t$e process appraisal. 'rocess appraisals can be performed on the entire organi6ation or can be performed on a smaller part of an organi6ation such as a single project or business area. (he scope of the process appraisal addresses the following:
203
%efinition of the organi6ation 2e.g., sites, business areas3 to be covered by the appraisal &dentification of the project and support functions that will represent the organi6ation in the appraisal 'rocesses to be appraised
3.
Determine t$e met$od and criteria to )e used for t$e process appraisal. 'rocess appraisals can occur in many forms. (hey should address the needs and objectives of the organi6ation, which can change over time. For example, the appraisal can be based on a process model, such as a C$$& model, or on a national or international standard, such as &*O N>>= I&*O <>>BcJ. "ppraisals can also be based on a benchmar1 comparison with other organi6ations in which practices that can contribute to improved organi6ational performance are identified. (he characteristics of the appraisal method may vary, including time and effort, ma1eup of the appraisal team, and the method and depth of investigation.
8. 9. G.
SP 1*3
Plan, sc$edule, and prepare for t$e process appraisal. Conduct t$e process appraisal. Document and deliver t$e appraisal;s activities and findin+s.
I+e t"f1 t-e Or!a "Aat"o B$ Pro#e$$ Im'roveme t$
Identify impro)ements to the organi5ation7s processes and process assets.

1. ". 1.
0nal*sis of candidate process improvements Identification of improvements for t$e or+ani-ation;s processes Determine candidate process improvements. Candidate process improvements are typically determined by doing the following:
$easuring processes and analy6ing measurement results #eviewing processes for effectiveness and suitability "ssessing customer satisfaction #eviewing lessons learned from tailoring the organi6ation9s set of standard processes #eviewing lessons learned from implementing processes #eviewing process improvement proposals submitted by the organi6ation9s managers, staff, and other relevant sta1eholders *oliciting inputs on process improvements from senior management and other leaders in the organi6ation Examining results of process appraisals and other process related reviews #eviewing results of other organi6ational improvement initiatives
S/b'ra#t"#e$
".
Prioriti-e candidate process improvements. Criteria for prioriti6ation are as follows:
210
Consider the estimated cost and effort to implement the process improvements. Evaluate the expected improvement against the organi6ation9s improvement objectives and priorities. %etermine the potential barriers to the process improvements and develop strategies for overcoming these barriers.
Examples of techni0ues to help determine and prioriti6e possible improvements to be implemented include the following:
" cost benefit analysis that compares the estimated cost and effort to implement the process improvements and their associated benefits " gap analysis that compares current conditions in the organi6ation with optimal conditions Force field analysis of potential improvements to identify potential barriers and strategies for overcoming those barriers Cause5and5effect analyses to provide information on the potential effects of different improvements that can then be compared
3. 8.
S7 2
Identif* and document t$e process improvements to )e implemented. !evise t$e list of planned process improvements to 2eep it current.
P&a a + Im'&eme t Pro#e$$ A#t"o $
!rocess actions that address impro)ements to the organi5ation7s processes and process assets are planned and implemented.
T$e successful implementation of improvements re/uires participation in process action plannin+ and implementation )* process o'ners, t$ose '$o perform t$e process, and support or+ani-ations.
SP 2*1 E$tab&"$- Pro#e$$ A#t"o P&a $
+sta'lish and maintain process action plans to address impro)ements to the organi5ation7s processes and process assets.
Establishing and maintaining process action plans typically involves the following roles: $anagement steering committees that set strategies and oversee process improvement activities 'rocess groups that facilitate and manage process improvement activities 'rocess action teams that define and implement process actions 'rocess owners that manage deployment 'ractitioners that perform the process
ta2e$older involvement $elps to o)tain )u*-in on process improvements and increases t$e li2eli$ood of effective deplo*ment. Process action plans are detailed implementation plans. T$ese plans differ from t$e or+ani-ation;s process improvement plan )* tar+etin+ improvements t$at 'ere defined to address 'ea2nesses and t$at 'ere usuall* uncovered )* appraisals.
211
1. 1.
T$e or+ani-ation;s approved process action plans Identif* strate+ies, approac$es, and actions to address identified process improvements. 7ew, unproven, and major changes are piloted before they are incorporated into normal use.
S/b'ra#t"#e$
".
Esta)lis$ process action teams to implement actions. (he teams and people performing the process improvement actions are called @process action teams.A 'rocess action teams typically include process owners and those who perform the process.
3.
Document process action plans. 'rocess action plans typically cover the following:
'rocess improvement infrastructure 'rocess improvement objectives 'rocess improvements to be addressed 'rocedures for planning and trac1ing process actions *trategies for piloting and implementing process actions #esponsibility and authority for implementing process actions #esources, schedules, and assignments for implementing process actions $ethods for determining the effectiveness of process actions #is1s associated with process action plans
8. 9.
SP 2*2
!evie' and ne+otiate process action plans 'it$ relevant sta2e$olders. !evise process action plans as necessar*.
Im'&eme t Pro#e$$ A#t"o P&a $
Implement process action plans.

1. ". 3. 1. ". 3. 8.
Commitments amon+ process action teams tatus and results of implementin+ process action plans Plans for pilots Ma2e process action plans readil* availa)le to relevant sta2e$olders. <e+otiate and document commitments amon+ process action teams and revise t$eir process action plans as necessar*. Trac2 pro+ress and commitments a+ainst process action plans. Conduct 4oint revie's 'it$ process action teams and relevant sta2e$olders to monitor t$e pro+ress and results of process actions.
S/b'ra#t"#e$
212
9. G. =. H.
Plan pilots needed to test selected process improvements. !evie' t$e activities and 'or2 products of process action teams. Identif*, document, and trac2 to closure issues encountered '$en implementin+ process action plans. Ensure t$at results of implementin+ process action plans satisf* t$e or+ani-ation;s process improvement o)4ectives.
S7 3
%e'&o1 Or!a "Aat"o a& Pro#e$$ A$$et$ a + I #or'orate E,'er"e #e$
6rgani5ational process assets are deployed across the organi5ation and process related e,periences are incorporated into organi5ational process assets.
T$e specific practices under t$is specific +oal descri)e on+oin+ activities. <e' opportunities to )enefit from or+ani-ational process assets and c$an+es to t$em can arise t$rou+$out t$e life of eac$ pro4ect. Deplo*ment of standard processes and ot$er or+ani-ational process assets s$ould )e continuall* supported in t$e or+ani-ation, particularl* for ne' pro4ects at startup.
SP 3*1 %e'&o1 Or!a "Aat"o a& Pro#e$$ A$$et$
Deploy organi5ational process assets across the organi5ation.

Deplo*in+ or+ani-ational process assets or c$an+es to t$em s$ould )e performed in an orderl* manner. ome or+ani-ational process assets or c$an+es to t$em ma* not )e appropriate for use in some parts of t$e or+ani-ation (e.+., )ecause of sta2e$older re/uirements or t$e current lifec*cle p$ase )ein+ implemented,. It is t$erefore important t$at t$ose '$o are or 'ill )e e5ecutin+ t$e process, as 'ell as ot$er or+ani-ation functions (e.+., trainin+, /ualit* assurance,, )e involved in deplo*ment as necessar*. "efer to the 0rgani-ational Process efinition process area for more information about establishing organi-ational process assets%
1. ". 3. 8.
Plans for deplo*in+ or+ani-ational process assets and c$an+es to t$em across t$e or+ani-ation Trainin+ materials for deplo*in+ or+ani-ational process assets and c$an+es to t$em Documentation of c$an+es to or+ani-ational process assets upport materials for deplo*in+ or+ani-ational process assets and c$an+es to t$em Deplo* or+ani-ational process assets across t$e or+ani-ation.
S/b'ra#t"#e$
1.
213
(ypical activities performed as a part of the deployment of process assets include the following:
&dentifying organi6ational process assets that should be adopted by those who perform the process %etermining how organi6ational process assets are made available 2e.g., via a website3 &dentifying how changes to organi6ational process assets are communicated &dentifying resources 2e.g., methods, tools3 needed to support the use of organi6ational process assets 'lanning the deployment "ssisting those who use organi6ational process assets Ensuring that training is available for those who use organi6ational process assets
"efer to the 0rgani-ational Training process area for more information about establishing an organi-ational training capability% ". Document c$an+es to or+ani-ational process assets. %ocumenting changes to organi6ational process assets serves two main purposes:
(o enable the communication of changes (o understand the relationship of changes in the organi6ational process assets to changes in process performance and results
3.
Deplo* c$an+es t$at 'ere made to or+ani-ational process assets across t$e or+ani-ation. (ypical activities performed as a part of deploying changes include the following:
%etermining which changes are appropriate for those who perform the process 'lanning the deployment "rranging for the support needed for the successful transition of changes
8.
Provide +uidance and consultation on t$e use of or+ani-ational process assets.
SP 3*2
%e'&o1 Sta +ar+ Pro#e$$e$
Deploy the organi5ation7s set of standard processes to pro/ects at their startup and deploy changes to them as appropriate throughout the life of each pro/ect.
It is important t$at ne' pro4ects use proven and effective processes to perform critical earl* activities (e.+., pro4ect plannin+, receivin+ re/uirements, o)tainin+ resources,. Pro4ects s$ould also periodicall* update t$eir defined processes to incorporate t$e latest c$an+es made to t$e or+ani-ation;s set of standard processes '$en it 'ill )enefit t$em. T$is periodic update $elps to ensure t$at all pro4ect activities derive t$e full )enefit of '$at ot$er pro4ects $ave learned.
214
"efer to the 0rgani-ational Process efinition process area for more information about establishing standard processes and establishing tailoring criteria and guidelines%
1. ". 3.
T$e or+ani-ation;s list of pro4ects and t$e status of process deplo*ment on eac$ (i.e., e5istin+ and planned pro4ects, 3uidelines for deplo*in+ t$e or+ani-ation;s set of standard processes on ne' pro4ects !ecords of tailorin+ and implementin+ t$e or+ani-ation;s set of standard processes Identif* pro4ects in t$e or+ani-ation t$at are startin+ up. Identif* active pro4ects t$at 'ould )enefit from implementin+ t$e or+ani-ation;s current set of standard processes. Esta)lis$ plans to implement t$e or+ani-ation;s current set of standard processes on t$e identified pro4ects. 0ssist pro4ects in tailorin+ t$e or+ani-ation;s set of standard processes to meet t$eir needs. "efer to the Integrated Pro.ect Management process area for more information about establishing the pro.ect3s defined process%
S/b'ra#t"#e$
1. ". 3. 8.
9. G.
Maintain records of tailorin+ and implementin+ processes on t$e identified pro4ects. Ensure t$at t$e defined processes resultin+ from process tailorin+ are incorporated into plans for process compliance audits. 'rocess compliance audits are objective evaluations of project activities against the project9s defined process.
=.
0s t$e or+ani-ation;s set of standard processes is updated, identif* '$ic$ pro4ects s$ould implement t$e c$an+es.
SP 3*3
Mo "tor t-e Im'&eme tat"o
Monitor the implementation of the organi5ation7s set of standard processes and use of process assets on all pro/ects.
.* monitorin+ implementation, t$e or+ani-ation ensures t$at t$e or+ani-ation;s set of standard processes and ot$er process assets are appropriatel* deplo*ed to all pro4ects. Monitorin+ implementation also $elps t$e or+ani-ation to develop an understandin+ of t$e or+ani-ational process assets )ein+ used and '$ere t$e* are used in t$e or+ani-ation. Monitorin+ also $elps to esta)lis$ a )roader conte5t for interpretin+ and usin+ process and product measures, lessons learned, and improvement information o)tained from pro4ects.
1.
!esults of monitorin+ process implementation on pro4ects
215
". 3.
tatus and results of process compliance audits !esults of revie'in+ selected process artifacts created as part of process tailorin+ and implementation Monitor t$e pro4ects; use of or+ani-ational process assets and c$an+es to t$em. !evie' selected process artifacts created durin+ t$e life of eac$ pro4ect. #eviewing selected process artifacts created during the life of a project ensures that all projects are ma1ing appropriate use of the organi6ation9s set of standard processes.
S/b'ra#t"#e$
1. ".
3.
!evie' results of process compliance audits to determine $o' 'ell t$e or+ani-ation;s set of standard processes $as )een deplo*ed. "efer to the Process and Product 4uality $ssurance process area for more information about ob.ectively evaluating processes%
8.
Identif*, document, and trac2 to closure issues related to implementin+ t$e or+ani-ation;s set of standard processes.
SP 3*4
I #or'orate E,'er"e #e$ " to Or!a "Aat"o a& Pro#e$$ A$$et$
Incorporate process related e,periences deri)ed from planning and performing the process into organi5ational process assets.
1. ". 3. 8. 9. G.
Process improvement proposals Process lessons learned Measurements of or+ani-ational process assets Improvement recommendations for or+ani-ational process assets !ecords of t$e or+ani-ation;s process improvement activities Information on or+ani-ational process assets and improvements to t$em Conduct periodic revie's of t$e effectiveness and suita)ilit* of t$e or+ani-ation;s set of standard processes and related or+ani-ational process assets relative to t$e process needs and o)4ectives derived from t$e or+ani-ation;s )usiness o)4ectives. 7)tain feed)ac2 a)out t$e use of or+ani-ational process assets. Derive lessons learned from definin+, pilotin+, implementin+, and deplo*in+ or+ani-ational process assets. Ma2e lessons learned availa)le to people in t$e or+ani-ation as appropriate. "ctions may be necessary to ensure that lessons learned are used appropriately.
S/b'ra#t"#e$
1.
". 3. 8.
216
Examples of the inappropriate use of lessons learned include the following:

Evaluating the performance of people Cudging process performance or results
Examples of ways to prevent the inappropriate use of lessons learned include the following:
Controlling access to lessons learned Educating people about the appropriate use of lessons learned
9.
0nal*-e measurement data o)tained from t$e use of t$e or+ani-ation;s common set of measures. "efer to the Measurement and $nalysis process area for more information about analy-ing measurement data% "efer to the 0rgani-ational Process efinition process area for more information about establishing the organi-ation3s measurement repository%
G.
0ppraise processes, met$ods, and tools in use in t$e or+ani-ation and develop recommendations for improvin+ or+ani-ational process assets. (his appraisal typically includes the following:
%etermining which processes, methods, and tools are of potential use to other parts of the organi6ation "ppraising the 0uality and effectiveness of organi6ational process assets &dentifying candidate improvements to organi6ational process assets %etermining compliance with the organi6ation9s set of standard processes and tailoring guidelines
=. H.
Ma2e t$e )est of t$e or+ani-ation;s processes, met$ods, and tools availa)le to people in t$e or+ani-ation as appropriate. Mana+e process improvement proposals. 'rocess improvement proposals can address both process and technology improvements. (he activities for managing process improvement proposals typically include the following:
*oliciting process improvement proposals Collecting process improvement proposals #eviewing process improvement proposals *electing the process improvement proposals to be implemented (rac1ing the implementation of process improvement proposals
'rocess improvement proposals are documented as process change re0uests or problem reports as appropriate.
218
*ome process improvement proposals can be incorporated into the organi6ation9s process action plans. F. Esta)lis$ and maintain records of t$e or+ani-ation;s process improvement activities.
21<
213
OR/A*I1A(IO*A+ P$RFOR#A*!$ #A*A/$#$*(

Purpose
T$e purpose of 7r+ani-ational Performance Mana+ement (7PM, is to proactivel* mana+e t$e or+ani-ation;s performance to meet its )usiness o)4ectives.
Introductor" *otes
T$e 7r+ani-ational Performance Mana+ement process area ena)les t$e or+ani-ation to mana+e or+ani-ational performance )* iterativel* anal*-in+ a++re+ated pro4ect data, identif*in+ +aps in performance a+ainst t$e )usiness o)4ectives, and selectin+ and deplo*in+ improvements to close t$e +aps. In t$is process area, t$e term LimprovementM includes all incremental and innovative process and tec$nolo+* improvements, includin+ t$ose improvements made to pro4ect 'or2 environments. LImprovementM refers to all ideas t$at 'ould c$an+e t$e or+ani-ation;s processes, tec$nolo+ies, and performance to )etter meet t$e or+ani-ation;s )usiness o)4ectives and associated /ualit* and process performance o)4ectives. .usiness o)4ectives t$at t$is process area mi+$t address include t$e follo'in+% Improved product /ualit* (e.+., functionalit*, /ualit* attri)utes, Increased productivit* Increased process efficienc* and effectiveness Increased consistenc* in meetin+ )ud+et and sc$edule Decreased c*cle time 3reater customer and end-user satisfaction $orter development or production time to c$an+e functionalit*, add ne' features, or adapt to ne' tec$nolo+ies Improved performance of a suppl* c$ain involvin+ multiple suppliers Improved use of resources across t$e or+ani-ation
T$e or+ani-ation anal*-es product and process performance data from t$e pro4ects to determine if it is capa)le of meetin+ t$e /ualit* and process performance o)4ectives. Process performance )aselines and process performance models, developed usin+ 7r+ani-ational Process Performance processes, are used as part of t$e anal*sis. Causal 0nal*sis and !esolution processes can also )e used to identif* potential areas of improvement or specific improvement proposals.
220
Or!a "Aat"o a& Performa #e Ma a!eme t :OPM;
T$e or+ani-ation identifies and proactivel* solicits incremental and innovative improvements from 'it$in t$e or+ani-ation and from e5ternal sources suc$ as academia, competitive intelli+ence, and successful improvements implemented else'$ere. !eali-ation of t$e improvements and t$eir effects on t$e /ualit* and process performance o)4ectives depends on )ein+ a)le to effectivel* identif*, evaluate, implement, and deplo* improvements to t$e or+ani-ation;s processes and tec$nolo+ies. !eali-ation of t$e improvements and )eneficial effects also depends on en+a+in+ t$e 'or2force in identif*in+ and evaluatin+ possi)le improvements and maintainin+ a focus on lon+-term plannin+ t$at includes t$e identification of innovations. Improvement proposals are evaluated and validated for t$eir effectiveness in t$e tar+et environment. .ased on t$is evaluation, improvements are prioriti-ed and selected for deplo*ment to ne' and on+oin+ pro4ects. Deplo*ment is mana+ed in accordance 'it$ t$e deplo*ment plan and performance data are anal*-ed usin+ statistical and ot$er /uantitative tec$ni/ues to determine t$e effects of t$e improvement on /ualit* and process performance o)4ectives. T$is improvement c*cle continuall* optimi-es or+ani-ational processes )ased on /ualit* and process performance o)4ectives. .usiness o)4ectives are periodicall* revie'ed to ensure t$e* are current and /ualit* and process performance o)4ectives are updated as appropriate. T$e 7r+ani-ational Process 1ocus process area includes no assumptions a)out t$e /uantitative )asis for identif*in+ improvements, nor t$eir e5pected results. T$is process area e5tends t$e 7r+ani-ational Process 1ocus practices )* focusin+ on process improvement )ased on a /uantitative understandin+ of t$e or+ani-ation;s set of standard processes and tec$nolo+ies and t$eir e5pected /ualit* and process performance. T$e specific practices of t$is process area appl* to or+ani-ations '$ose pro4ects are /uantitativel* mana+ed. :se of t$e specific practices of t$is process area can add value in ot$er situations, )ut t$e results ma* not provide t$e same de+ree of impact to t$e or+ani-ation;s /ualit* and process performance o)4ectives.
"efer to the Causal $nalysis and "esolution process area for more information about identifying causes of selected outcomes and ta1ing action to improve process performance% "efer to the ecision $nalysis and "esolution process area for more information about analy-ing possible decisions using a formal evaluation process that evaluates identified alternatives against established criteria%
221
"efer to the Measurement and $nalysis process area for more information about aligning measurement and analysis activities and providing measurement results% "efer to the 0rgani-ational Process 9ocus process area for more information about planning2 implementing2 and deploying organi-ational process improvements based on a thorough understanding of current strengths and wea1nesses of the organi-ation3s processes and process assets% "efer to the 0rgani-ational Process Performance process area for more information about establishing ,uality and process performance ob.ectives and establishing process performance baselines and models% "efer to the 0rgani-ational Training process area for more information about providing training%
3 1 Mana+e .usiness Performance P 1.1 P 1." P 1.3 P ".1 P "." P ".3 P ".8 P 3.1 P 3." P 3.3 Maintain .usiness 7)4ectives 0nal*-e Process Performance Data Identif* Potential 0reas for Improvement Elicit u++ested Improvements 0nal*-e u++ested Improvements Validate Improvements elect and Implement Improvements for Deplo*ment Plan t$e Deplo*ment Mana+e t$e Deplo*ment Evaluate Improvement Effects
3 " elect Improvements
3 3 Deplo* Improvements
)pecific Practices b" /oal S7 1 Ma a!e 9/$" e$$ Performa #e
The organi5ation7s 'usiness performance is managed using statistical and other -uantitati)e techni-ues to understand process performance shortfalls* and to identify areas for process impro)ement.
Mana+in+ )usiness performance re/uires t$e follo'in+% Maintainin+ t$e or+ani-ation;s )usiness o)4ectives :nderstandin+ t$e or+ani-ation;s a)ilit* to meet t$e )usiness o)4ectives Continuall* improvin+ processes related to ac$ievin+ t$e )usiness o)4ectives
T$e or+ani-ation uses defined process performance )aselines to determine if t$e current and pro4ected or+ani-ational )usiness o)4ectives are )ein+ met. $ortfalls in process performance are identified and anal*-ed to determine potential areas for process improvement. "efer to the 0rgani-ational Process Performance process area for more information about establishing performance baselines and models%
222
0s t$e or+ani-ation improves its process performance or as )usiness strate+ies c$an+e, ne' )usiness o)4ectives are identified and associated /ualit* and process performance o)4ectives are derived. pecific +oal " addresses elicitin+ and anal*-in+ improvement su++estions t$at address s$ortfalls in ac$ievin+ /ualit* and process performance o)4ectives.
SP 1*1 Ma" ta" 9/$" e$$ Ob0e#t"ve$
Maintain 'usiness o'/ecti)es 'ased on an understanding of 'usiness strategies and actual performance results.
7r+ani-ational performance data, c$aracteri-ed )* process performance )aselines, are used to evaluate '$et$er )usiness o)4ectives are realistic and ali+ned 'it$ )usiness strate+ies. 0fter )usiness o)4ectives $ave )een revised and prioriti-ed )* senior mana+ement, /ualit* and process performance o)4ectives ma* need to )e created or maintained and recommunicated.
E,am'&e >or? Pro+/#t$ 1.
!evised )usiness o)4ectives !evised /ualit* and process performance o)4ectives enior mana+ement approval of revised )usiness o)4ectives and /ualit* and process performance o)4ectives Communication of all revised o)4ectives :pdated process performance measures Evaluate )usiness o)4ectives periodicall* to ensure t$e* are ali+ned 'it$ )usiness strate+ies. *enior management is responsible for understanding the mar1etplace, establishing business strategies, and establishing business objectives. ;ecause business strategies and organi6ational performance evolve, business objectives should be reviewed periodically to determine whether they should be updated. For example, a business objective might be retired when process performance data show that the business objective is being met consistently over time or when the associated business strategy has changed.
". 3. 8. 9. 1.
S/b'ra#t"#e$
".
Compare )usiness o)4ectives 'it$ actual process performance results to ensure t$e* are realistic. ;usiness objectives can set the bar too high to motivate real improvement. :sing process performance baselines helps balance desires and reality. &f process performance baselines are unavailable, sampling techni0ues can be used to develop a 0uantitative basis for comparison in a short period of time.
3.
Prioriti-e )usiness o)4ectives )ased on documented criteria, suc$ as t$e a)ilit* to 'in ne' )usiness, retain e5istin+ clients, or accomplis$ ot$er 2e* )usiness strate+ies.
223
8.
Maintain /ualit* and process performance o)4ectives to address c$an+es in )usiness o)4ectives. ;usiness objectives and 0uality and process performance objectives will typically evolve over time. "s existing objectives are achieved, they will be monitored to ensure they continue to be met, while new business objectives and associated 0uality and process performance objectives are identified and managed. "efer to the 0rgani-ational Process Performance process area for more information about establishing ,uality and process performance ob.ectives%
9.
!evise process performance measures to ali+n 'it$ /ualit* and process performance o)4ectives. "efer to the 0rgani-ational Process Performance process area for more information about establishing process performance measures%
SP 1*2
A a&1Ae Pro#e$$ Performa #e %ata
"naly5e process performance data to determine the organi5ation7s a'ility to meet identified 'usiness o'/ecti)es.
T$e data t$at result from appl*in+ t$e process performance measures, '$ic$ are defined usin+ 7r+ani-ational Process Performance processes, are anal*-ed to create process performance )aselines t$at $elp in understandin+ t$e current capa)ilit* of t$e or+ani-ation. Comparin+ process performance )aselines to /ualit* and process performance o)4ectives $elps t$e or+ani-ation to determine its a)ilit* to meet )usiness o)4ectives. T$is data t*picall* are collected from pro4ect level process performance data to ena)le or+ani-ational anal*sis.
1. ". 3. 1.
0nal*sis of current capa)ilit* vs. )usiness o)4ectives Process performance s$ortfalls !is2s associated 'it$ meetin+ )usiness o)4ectives Periodicall* compare /ualit* and process performance o)4ectives to current process performance )aselines to evaluate t$e a)ilit* of t$e or+ani-ation to meet its )usiness o)4ectives. For example, if cycle time is a critical business need, many different cycle time measures may be collected by the organi6ation. Overall cycle time performance data should be compared to the business objectives to understand if expected performance will satisfy business objectives.
S/b'ra#t"#e$
". 3.
Identif* s$ortfalls '$ere t$e actual process performance is not satisf*in+ t$e )usiness o)4ectives. Identif* and anal*-e ris2s associated 'it$ not meetin+ )usiness o)4ectives.
224
8.
!eport results of t$e process performance and ris2 anal*ses to or+ani-ational leaders$ip.
SP 1*3
I+e t"f1 Pote t"a& Area$ for Im'roveme t
Identify potential areas for impro)ement that could contri'ute to meeting 'usiness o'/ecti)es.
Potential areas for improvement are identified t$rou+$ a proactive anal*sis to determine areas t$at could address process performance s$ortfalls. Causal 0nal*sis and !esolution processes can )e used to dia+nose and resolve root causes. T$e output from t$is activit* is used to evaluate and prioriti-e potential improvements, and can result in eit$er incremental or innovative improvement su++estions as descri)ed in specific +oal ".
1. 1.
Potential areas for improvement Identif* potential improvement areas )ased on t$e anal*sis of process performance s$ortfalls. 'erformance shortfalls include not meeting productivity, cycle time, or customer satisfaction objectives. Examples of areas to consider for improvement include product technology, process technology, staffing and staff development, team structures, supplier selection and management, and other organi6ational infrastructures.
S/b'ra#t"#e$
".
Document t$e rationale for t$e potential improvement areas, includin+ references to applica)le )usiness o)4ectives and process performance data. Document anticipated costs and )enefits associated 'it$ addressin+ potential improvement areas. Communicate t$e set of potential improvement areas for furt$er evaluation, prioriti-ation, and use.
3. 8.
S7 2
Se&e#t Im'roveme t$
Impro)ements are proacti)ely identified* e)aluated using statistical and other -uantitati)e techni-ues* and selected for deployment 'ased on their contri'ution to meeting -uality and process performance o'/ecti)es.
Improvements to )e deplo*ed across t$e or+ani-ation are selected from improvement su++estions '$ic$ $ave )een evaluated for effectiveness in t$e tar+et deplo*ment environment. T$ese improvement su++estions are elicited and su)mitted from across t$e or+ani-ation to address t$e improvement areas identified in specific +oal 1. Evaluations of improvement su++estions are )ased on t$e follo'in+% 0 /uantitative understandin+ of t$e or+ani-ation;s current /ualit* and process performance
225

SP 2*1
atisfaction of t$e or+ani-ation;s /ualit* and process performance o)4ectives Estimated costs and impacts of developin+ and deplo*in+ t$e improvements, resources, and fundin+ availa)le for deplo*ment Estimated )enefits in /ualit* and process performance resultin+ from deplo*in+ t$e improvements
E&"#"t S/!!e$te+ Im'roveme t$
+licit and categori5e suggested impro)ements.

T$is practice focuses on elicitin+ su++ested improvements and includes cate+ori-in+ su++ested improvements as incremental or innovative. Incremental improvements +enerall* ori+inate 'it$ t$ose '$o do t$e 'or2 (i.e., users of t$e process or tec$nolo+*,. Incremental improvements can )e simple and ine5pensive to implement and deplo*. Incremental improvement su++estions are anal*-ed, )ut, if selected, ma* not need ri+orous validation or pilotin+. Innovative improvements suc$ as ne' or redesi+ned processes are more transformational t$an incremental improvements. Innovative improvements often arise out of a s*stematic searc$ for solutions to particular performance issues or opportunities to improve performance. T$e* are identified )* t$ose '$o are trained and e5perienced 'it$ t$e maturation of particular tec$nolo+ies or '$ose 4o) it is to trac2 or directl* contri)ute to increased performance. Innovations can )e found e5ternall* )* activel* monitorin+ innovations used in ot$er or+ani-ations or documented in t$e researc$ literature. Innovations can also )e found )* loo2in+ internall* (e.+., )* e5aminin+ pro4ect lessons learned,. Innovations are inspired )* t$e need to ac$ieve /ualit* and process performance o)4ectives, t$e need to improve performance )aselines, or t$e e5ternal )usiness environment. Examples of incremental improvements include the following: "dding an item to a peer review chec1list. Combining the technical review and management review for suppliers into a single review. &ntroducing an incident wor1around. *ubstituting a new component. $a1ing minor updates to a tool.
226
Examples of innovative improvements typically include additions or major updates to the following: Computer and related hardware products (ransformational support tools 7ew or redesigned wor1flows 'rocesses or lifecycle models &nterface standards #eusable components $anagement techni0ues and methodologies )uality improvement techni0ues and methodologies %evelopment techni0ues and methodologies
ome su++ested improvements ma* )e received in t$e form of a proposal (e.+., an or+ani-ational improvement proposal arisin+ from a causal anal*sis and resolution activit*,. T$ese su++ested improvements 'ill $ave )een anal*-ed and documented prior to input to 7r+ani-ational Performance Mana+ement processes. 6$en su++ested improvements are received as proposals, t$e proposals are revie'ed for completeness and are evaluated as part of t$e selection process for implementation. Improvement searc$es can involve loo2in+ outside t$e or+ani-ation, derivin+ innovations from pro4ects usin+ Causal 0nal*sis and !esolution processes, usin+ competitive )usiness intelli+ence, or anal*-in+ e5istin+ or+ani-ational performance.
1. ". 1.
u++ested incremental improvements u++ested innovative improvements Elicit su++ested improvements. (hese suggestions document potential improvements to processes and technologies. $anagers and staff in the organi6ation as well as customers, end users, and suppliers can submit suggestions. (he organi6ation can also search the academic and technology communities for suggested improvements. *ome suggested improvements may have been implemented at the project level before being proposed for the organi6ation.
S/b'ra#t"#e$
228
Examples of sources for improvements include the following:

Findings and recommendations from process appraisals (he organi6ation9s 0uality and process performance objectives "nalysis of data about customer and end5user problems as well as customer and end5 user satisfaction #esults of process and product benchmar1ing efforts $easured effectiveness of process activities $easured effectiveness of project wor1 environments Examples of improvements that were successfully adopted elsewhere Feedbac1 on previous improvements *pontaneous ideas from managers and staff &mprovement proposals from Causal "nalysis and #esolution processes resulting from implemented actions with proven effectiveness "nalysis of technical performance measures "nalysis of data on defect causes "nalysis of project and organi6ational performance compared to 0uality and productivity objectives
"efer to the 0rgani-ational Process 9ocus process area for more information about deploying organi-ational process assets and incorporating e:periences% ". 3. Identif* su++ested improvements as incremental or innovative. Investi+ate innovative improvements t$at ma* improve t$e or+ani-ationPs processes and tec$nolo+ies. &nvestigating innovative improvements typically involves the following:
$aintaining awareness of leading relevant technical wor1 and technology trends *earching for commercially available innovative improvements Collecting proposals for innovative improvements from the projects and the organi6ation #eviewing processes and technologies used externally and comparing them to the processes and technologies used in the organi6ation &dentifying areas where innovative improvements have been used successfully, and reviewing data and documentation of experience using these improvements &dentifying improvements that integrate new technology into products and project wor1 environments SP 2*2 A a&1Ae S/!!e$te+ Im'roveme t$
"naly5e suggested impro)ements for their possi'le impact on achie)ing the organi5ation7s -uality and process performance o'/ecti)es.
22<
u++ested improvements are incremental and innovative improvements t$at are anal*-ed and possi)l* selected for validation, implementation, and deplo*ment t$rou+$out t$e or+ani-ation.
1. ". 1.
u++ested improvement proposals elected improvements to )e validated 0nal*-e t$e costs and )enefits of su++ested improvements. 'rocess performance models provide insight into the effect of process changes on process capability and performance. "efer to the 0rgani-ational Process Performance process area for more information about establishing process performance models% &mprovement suggestions that have a large cost5to5benefit ratio or that would not improve the organi6ation9s processes may be rejected. Criteria for evaluating costs and benefits include the following:
Contribution toward meeting the organi6ation9s 0uality and process performance objectives Effect on mitigating identified project and organi6ational ris1s "bility to respond 0uic1ly to changes in project re0uirements, mar1et situations, and the business environment Effect on related processes and associated assets Cost of defining and collecting data that support the measurement and analysis of the process and technology improvement Expected life span of the improvement
S/b'ra#t"#e$
".
Identif* potential )arriers and ris2s to deplo*in+ eac$ su++ested improvement. Examples of barriers to deploying improvements include the following:
(urf guarding and parochial perspectives :nclear or wea1 business rationale -ac1 of short5term benefits and visible successes :nclear picture of what is expected from everyone (oo many changes at the same time -ac1 of involvement and support from relevant sta1eholders
223
Examples of ris1 factors that affect the deployment of improvements include the following:
Compatibility of the improvement with existing processes, values, and s1ills of potential end users Complexity of the improvement %ifficulty implementing the improvement "bility to demonstrate the value of the improvement before widespread deployment Custification for large, up5front investments in areas such as tools and training &nability to overcome @technology dragA where the current implementation is used successfully by a large and mature installed base of end users
3. 8.
Estimate t$e cost, effort, and sc$edule re/uired for implementin+, verif*in+, and deplo*in+ eac$ su++ested improvement. elect su++ested improvements for validation and possi)le implementation and deplo*ment )ased on t$e evaluations. "efer to the ecision $nalysis and "esolution process area for more information about analy-ing possible decisions using a formal evaluation process that evaluates identified alternatives against established criteria%
9.
Document t$e evaluation results of eac$ selected improvement su++estion in an improvement proposal. (he proposal should include a problem statement, a plan 2including cost and schedule, ris1 handling, method for evaluating effectiveness in the target environment3 for implementing the improvement, and 0uantitative success criteria for evaluating actual results of the deployment.
G. =.
Determine t$e detailed c$an+es needed to implement t$e improvement and document t$em in t$e improvement proposal. Determine t$e validation met$od t$at 'ill )e used )efore )road-scale deplo*ment of t$e c$an+e and document it in t$e improvement proposal.
%etermining the validation method includes defining the 0uantitative success criteria that will be used to evaluate results of the validation. *ince innovations, by definition, represent a major change with high impact, most innovative improvements will be piloted. Other validation methods, including modeling and simulation can be used as appropriate.
H.
Document results of t$e selection process. #esults of the selection process usually include the following:
(he disposition of each suggested improvement (he rationale for the disposition of each suggested improvement
SP 2*3
)a&"+ate Im'roveme t$
9alidate selected impro)ements.
230
elected improvements are validated in accordance 'it$ t$eir improvement proposals. Examples of validation methods include the following: %iscussions with sta1eholders, perhaps in the context of a formal review 'rototype demonstrations 'ilots of suggested improvements $odeling and simulation
Pilots can )e conducted to evaluate si+nificant c$an+es involvin+ untried, $i+$-ris2, or innovative improvements )efore t$e* are )roadl* deplo*ed. <ot all improvements need t$e ri+or of a pilot. Criteria for selectin+ improvements for pilotin+ are defined and used. 1actors suc$ as ris2, transformational nature of c$an+e, or num)er of functional areas affected 'ill determine t$e need for a pilot of t$e improvement. !ed-lined or rou+$-draft process documentation can )e made availa)le for use in pilotin+.
1. ". 3. 1.
Validation plans Validation evaluation reports Documented lessons learned from validation Plan t$e validation. )uantitative success criteria documented in the improvement proposal can be useful when planning validation. ,alidation plans for selected improvements to be piloted should include target projects, project characteristics, a schedule for reporting results, and measurement activities.
S/b'ra#t"#e$
". 3. 8. 9. G. =.
!evie' and +et relevant sta2e$older a+reement on validation plans. Consult 'it$ and assist t$ose '$o perform t$e validation. Create a trial implementation, in accordance 'it$ t$e validation plan, for selected improvements to )e piloted. Perform eac$ validation in an environment t$at is similar to t$e environment present in a )road scale deplo*ment. Trac2 validation a+ainst validation plans. !evie' and document t$e results of validation. ,alidation results are evaluated using the 0uantitative criteria defined in the improvement proposal.
231
#eviewing and documenting results of pilots typically involves the following activities:
#eviewing pilot results with sta1eholders %eciding whether to terminate the pilot, rewor1 implementation of the improvement, replan and continue the pilot, or proceed with deployment :pdating the disposition of improvement proposals associated with the pilot &dentifying and documenting new improvement proposals as appropriate &dentifying and documenting lessons learned and problems encountered during the pilot including feedbac1 to the improvement team and changes to the improvement SP 2*4 Se&e#t a + Im'&eme t Im'roveme t$ for %e'&o1me t
elect and implement impro)ements for deployment throughout the organi5ation 'ased on an e)aluation of costs* 'enefits* and other factors.
election of su++ested improvements for deplo*ment is )ased on cost-to)enefit ratios 'it$ re+ard to /ualit* and process performance o)4ectives, availa)le resources, and t$e results of improvement proposal evaluation and validation activities. "efer to the ecision $nalysis and "esolution process area for more information about analy-ing possible decisions using a formal evaluation process that evaluates identified alternatives against established criteria%
1. ". 1.
Improvements selected for deplo*ment :pdated process documentation and trainin+ Prioriti-e improvements for deplo*ment. (he priority of an improvement is based on an evaluation of its estimated cost5to5 benefit ratio with regard to the 0uality and process performance objectives as compared to the performance baselines. #eturn on investment can be used as a basis of comparison.
S/b'ra#t"#e$
".
elect improvements to )e deplo*ed. *election of improvements to be deployed is based on their priorities, available resources, and results of improvement proposal evaluation and validation activities.
3.
Determine $o' to deplo* eac$ improvement. Examples of where the improvements may be deployed include the following:
'roject specific or common wor1 environments 'roduct families Organi6ation9s projects Organi6ational groups
8.
Document results of t$e selection process.
232
#esults of the selection process usually include the following:

(he selection criteria for suggested improvements (he characteristics of the target projects (he disposition of each improvement proposal (he rationale for the disposition of each improvement proposal
9.
!evie' an* c$an+es needed to implement t$e improvements. Examples of changes needed to deploy an improvement include the following:
'rocess descriptions, standards, and procedures 4or1 environments Education and training *1ills Existing commitments Existing activities Continuing support to end users Organi6ational culture and characteristics
G.
:pdate t$e or+ani-ational process assets. :pdating the organi6ational process assets typically includes reviewing them, gaining approval for them, and communicating them. "efer to the 0rgani-ational Process efinition process area for more information about establishing organi-ational process assets%
S7 3
%e'&o1 Im'roveme t$
Measura'le impro)ements to the organi5ation7s processes and technologies are deployed and e)aluated using statistical and other -uantitati)e techni-ues.
7nce improvements are selected for deplo*ment, a plan for deplo*ment is created and e5ecuted. T$e deplo*ment of improvements is mana+ed and t$e effects of t$e improvements are measured and evaluated as to $o' 'ell t$e* contri)ute to meetin+ /ualit* and process performance o)4ectives.
SP 3*1 P&a t-e %e'&o1me t
+sta'lish and maintain plans for deploying selected impro)ements.

T$e plans for deplo*in+ selected improvements can )e included in t$e plan for or+ani-ational performance mana+ement, in improvement proposals, or in separate deplo*ment documents. T$is specific practice complements t$e Deplo* 7r+ani-ational Process 0ssets specific practice in t$e 7r+ani-ational Process 1ocus process area
233
and adds t$e use of /uantitative data to +uide t$e deplo*ment and to determine t$e value of improvements. "efer to the 0rgani-ational Process 9ocus process area for more information about deploying organi-ational process assets and incorporating e:periences%
1. 1.
Deplo*ment plans for selected improvements Determine $o' eac$ improvement s$ould )e ad4usted for deplo*ment. &mprovements identified in a limited context 2e.g., for a single improvement proposal3 might need to be modified for a selected portion of the organi6ation.
S/b'ra#t"#e$
". 3.
Identif* strate+ies t$at address t$e potential )arriers to deplo*in+ eac$ improvement t$at 'ere defined in t$e improvement proposals. Identif* t$e tar+et pro4ect population for deplo*ment of t$e improvement. 7ot all projects are good candidates for all improvements. For example, improvements may be targeted to software only projects, CO(* integration projects, or operations and support projects.
8.
Esta)lis$ measures and o)4ectives for determinin+ t$e value of eac$ improvement 'it$ respect to t$e or+ani-ation;s /ualit* and process performance o)4ectives. $easures can be based on the 0uantitative success criteria documented in the improvement proposal or derived from organi6ational objectives. Examples of measures for determining the value of an improvement include the following:
$easured improvement in the project9s or organi6ation9s process performance (ime to recover the cost of the improvement 7umber and types of project and organi6ational ris1s mitigated by the process or technology improvement "verage time re0uired to respond to changes in project re0uirements, mar1et situations, and the business environment
"efer to the Measurement and $nalysis process area for more information about aligning measurement and analysis activities and providing measurement results% 9. Document t$e plans for deplo*in+ selected improvements. (he deployment plans should include relevant sta1eholders, ris1 strategies, target projects, measures of success, and schedule. G. !evie' and +et a+reement 'it$ relevant sta2e$olders on t$e plans for deplo*in+ selected improvements.
234
#elevant sta1eholders include the improvement sponsor, target projects, support organi6ations, etc. =.
SP 3*2
!evise t$e plans for deplo*in+ selected improvements as necessar*.
Ma a!e t-e %e'&o1me t
Manage the deployment of selected impro)ements.

T$is specific practice can overlap 'it$ t$e Implement 0ction Proposals specific practice in t$e Causal 0nal*sis and !esolution process area (e.+., '$en causal anal*sis and resolution is used or+ani-ationall* or across multiple pro4ects,.
1. ". 3.
:pdated trainin+ materials (to reflect deplo*ed improvements, Documented results of improvement deplo*ment activities !evised improvement measures, o)4ectives, priorities, and deplo*ment plans Monitor t$e deplo*ment of improvements usin+ deplo*ment plans. Coordinate t$e deplo*ment of improvements across t$e or+ani-ation. Coordinating deployment includes the following activities:
Coordinating activities of projects, support groups, and organi6ational groups for each improvement Coordinating activities for deploying related improvements
S/b'ra#t"#e$
1. ".
3.
Deplo* improvements in a controlled and disciplined manner. Examples of methods for deploying improvements include the following:
%eploying improvements incrementally rather than as a single deployment 'roviding comprehensive consulting to early adopters of improvement in lieu of revised formal training
8.
Coordinate t$e deplo*ment of improvements into t$e pro4ects; defined processes as appropriate. "efer to the 0rgani-ational Process 9ocus process area for more information about deploying organi-ational process assets and incorporating e:periences%
9. G.
Provide consultin+ as appropriate to support deplo*ment of improvements. Provide updated trainin+ materials or develop communication pac2a+es to reflect improvements to or+ani-ational process assets. "efer to the 0rgani-ational Training process area for more information about providing training%
235
=. H.
Confirm t$at t$e deplo*ment of all improvements is completed in accordance 'it$ t$e deplo*ment plan. Document and revie' results of improvement deplo*ment. %ocumenting and reviewing results includes the following:
&dentifying and documenting lessons learned #evising improvement measures, objectives, priorities, and deployment plans
SP 3*3
Eva&/ate Im'roveme t Effe#t$
+)aluate the effects of deployed impro)ements on -uality and process performance using statistical and other -uantitati)e techni-ues.
"efer to the Measurement and $nalysis process area for more information about aligning measurement and analysis activities and providing measurement results% T$is specific practice can overlap 'it$ t$e Evaluate t$e Effect of Implemented 0ctions specific practice in t$e Causal 0nal*sis and !esolution process area (e.+., '$en causal anal*sis and resolution is applied or+ani-ationall* or across multiple pro4ects,.
1.
Documented measures of t$e effects resultin+ from deplo*ed improvements Measure t$e results of eac$ improvement as implemented on t$e tar+et pro4ects, usin+ t$e measures defined in t$e deplo*ment plans. Measure and anal*-e pro+ress to'ard ac$ievin+ t$e or+ani-ation;s /ualit* and process performance o)4ectives usin+ statistical and ot$er /uantitative tec$ni/ues and ta2e corrective action as needed. "efer to the 0rgani-ational Process Performance process area for more information about establishing ,uality and process performance ob.ectives and establishing process performance baselines and models%
S/b'ra#t"#e$
1. ".
236
238
OR/A*I1A(IO*A+ PRO!$)) P$RFOR#A*!$

Purpose
T$e purpose of 7r+ani-ational Process Performance (7PP, is to esta)lis$ and maintain a /uantitative understandin+ of t$e performance of selected processes in t$e or+ani-ation;s set of standard processes in support of ac$ievin+ /ualit* and process performance o)4ectives, and to provide process performance data, )aselines, and models to /uantitativel* mana+e t$e or+ani-ation;s pro4ects.
Introductor" *otes
T$e 7r+ani-ational Process Performance process area involves t$e follo'in+ activities% Esta)lis$in+ or+ani-ational /uantitative /ualit* and process performance o)4ectives )ased on )usiness o)4ectives ( ee t$e definition of L/ualit* and process performance o)4ectivesM in t$e +lossar*., electin+ processes or su)processes for process performance anal*ses Esta)lis$in+ definitions of t$e measures to )e used in process performance anal*ses ( ee t$e definition of Lprocess performanceM in t$e +lossar*., Esta)lis$in+ process performance )aselines and process performance models ( ee t$e definitions of Lprocess performance )aselinesM and Lprocess performance modelsM in t$e +lossar*.,
T$e collection and anal*sis of t$e data and creation of t$e process performance )aselines and models can )e performed at different levels of t$e or+ani-ation, includin+ individual pro4ects or +roups of related pro4ects as appropriate )ased on t$e needs of t$e pro4ects and or+ani-ation. T$e common measures for t$e or+ani-ation consist of process and product measures t$at can )e used to c$aracteri-e t$e actual performance of processes in t$e or+ani-ation;s individual pro4ects. .* anal*-in+ t$e resultin+ measurements, a distri)ution or ran+e of results can )e esta)lis$ed t$at c$aracteri-e t$e e5pected performance of t$e process '$en used on an individual pro4ect. Measurin+ /ualit* and process performance can involve com)inin+ e5istin+ measures into additional derived measures to provide more insi+$t into overall efficienc* and effectiveness at a pro4ect or or+ani-ation level. T$e anal*sis at t$e or+ani-ation level can )e used to stud* productivit*, improve efficiencies, and increase t$rou+$put across pro4ects in t$e or+ani-ation.
23<
Or!a "Aat"o a& Pro#e$$ Performa #e :OPP;
T$e e5pected process performance can )e used in esta)lis$in+ t$e pro4ect;s /ualit* and process performance o)4ectives and can )e used as a )aseline a+ainst '$ic$ actual pro4ect performance can )e compared. T$is information is used to /uantitativel* mana+e t$e pro4ect. Eac$ /uantitativel* mana+ed pro4ect, in turn, provides actual performance results t$at )ecome a part of or+ani-ational process assets t$at are made availa)le to all pro4ects. Process performance models are used to represent past and current process performance and to predict future results of t$e process. 1or e5ample, t$e latent defects in t$e delivered product can )e predicted usin+ measurements of 'or2 product attri)utes suc$ as comple5it* and process attri)utes suc$ as preparation time for peer revie's. 6$en t$e or+ani-ation $as sufficient measures, data, and anal*tical tec$ni/ues for critical process, product, and service c$aracteristics, it is a)le to do t$e follo'in+% Determine '$et$er processes are )e$avin+ consistentl* or $ave sta)le trends (i.e., are predicta)le, Identif* processes in '$ic$ performance is 'it$in natural )ounds t$at are consistent across pro4ects and could potentiall* )e a++re+ated Identif* processes t$at s$o' unusual (e.+., sporadic, unpredicta)le, )e$avior Identif* aspects of processes t$at can )e improved in t$e or+ani-ation;s set of standard processes Identif* t$e implementation of a process t$at performs )est
T$is process area interfaces 'it$ and supports t$e implementation of ot$er $i+$ maturit* process areas. T$e assets esta)lis$ed and maintained as part of implementin+ t$is process area (e.+., t$e measures to )e used to c$aracteri-e su)process )e$avior, process performance )aselines, process performance models, are inputs to t$e /uantitative pro4ect mana+ement, causal anal*sis and resolution, and or+ani-ational performance mana+ement processes in support of t$e anal*ses descri)ed t$ere. Buantitative pro4ect mana+ement processes provide t$e /ualit* and process performance data needed to maintain t$e assets descri)ed in t$is process area.
"efer to the Measurement and $nalysis process area for more information about specifying measures2 obtaining measurement data2 and analy-ing measurement data% "efer to the 0rgani-ational Performance Management process area for more information about proactively managing the organi-ation3s performance to meet its business ob.ectives%
233
"efer to the 4uantitative Pro.ect Management process area for more information about ,uantitatively managing the pro.ect to achieve the pro.ect3s established ,uality and process performance ob.ectives%
3 1 Esta)lis$ Performance .aselines and Models P 1.1 P 1." P 1.3 P 1.8 P 1.9 Esta)lis$ Bualit* and Process Performance 7)4ectives elect Processes Esta)lis$ Process Performance Measures 0nal*-e Process Performance and Esta)lis$ Process Performance .aselines Esta)lis$ Process Performance Models
)pecific Practices b" /oal S7 1 E$tab&"$- Performa #e 9a$e&" e$ a + Mo+e&$
.aselines and models* 3hich characteri5e the e,pected process performance of the organi5ation7s set of standard processes* are esta'lished and maintained.
Prior to esta)lis$in+ process performance )aselines and models, it is necessar* to determine t$e /ualit* and process performance o)4ectives for t$ose processes (t$e Esta)lis$ Bualit* and Process Performance 7)4ectives specific practice,, '$ic$ processes are suita)le to )e measured (t$e elect Processes specific practice,, and '$ic$ measures are useful for determinin+ process performance (t$e Esta)lis$ Process Performance Measures specific practice,. T$e first t$ree practices of t$is +oal are interrelated and often need to )e performed concurrentl* and iterativel* to select /ualit* and process performance o)4ectives, processes, and measures. 7ften, t$e selection of one /ualit* and process performance o)4ective, process, or measure 'ill constrain t$e selection of t$e ot$ers. 1or e5ample, selectin+ a /ualit* and process performance o)4ective relatin+ to defects delivered to t$e customer 'ill almost certainl* re/uire selectin+ t$e verification processes and defect related measures. T$e intent of t$is +oal is to provide pro4ects 'it$ t$e process performance )aselines and models t$e* need to perform /uantitative pro4ect mana+ement. Man* times t$ese )aselines and models are collected or created )* t$e or+ani-ation, )ut t$ere are circumstances in '$ic$ a pro4ect ma* need to create t$e )aselines and models for t$emselves. T$ese circumstances include pro4ects t$at are not covered )* t$e or+ani-ation;s )aselines and models. 1or t$ese cases t$e pro4ect follo's t$e practices in t$is +oal to create its )aselines and models.
SP 1*1 E$tab&"$- @/a&"t1 a + Pro#e$$ Performa #e Ob0e#t"ve$
+sta'lish and maintain the organi5ation7s -uantitati)e o'/ecti)es for -uality and process performance* 3hich are tracea'le to 'usiness o'/ecti)es.
T$e or+ani-ation;s /ualit* and process performance o)4ectives can )e esta)lis$ed for different levels in t$e or+ani-ational structure (e.+., )usiness
240
area, product line, function, pro4ect, as 'ell as at different levels in t$e process $ierarc$*. 6$en esta)lis$in+ /ualit* and process performance o)4ectives, consider t$e follo'in+% Tracea)ilit* to t$e or+ani-ation;s )usiness o)4ectives Past performance of t$e selected processes or su)processes in conte5t (e.+., on pro4ects, Multiple attri)utes of process performance (e.+., product /ualit*, productivit*, c*cle time, response time, In$erent varia)ilit* or natural )ounds of t$e selected processes or su)processes
T$e or+ani-ation;s /ualit* and process performance o)4ectives provide focus and direction to t$e process performance anal*sis and /uantitative pro4ect mana+ement activities. @o'ever, it s$ould )e noted t$at ac$ievin+ /ualit* and process performance o)4ectives t$at are si+nificantl* different from current process capa)ilit* re/uires use of tec$ni/ues found in Causal 0nal*sis and !esolution and 7r+ani-ational Performance Mana+ement.
1. 1.
7r+ani-ation;s /ualit* and process performance o)4ectives !evie' t$e or+ani-ation;s )usiness o)4ectives related to /ualit* and process performance. Examples of business objectives include the following:
%eliver products within budget and on time &mprove product 0uality by a specified percent in a specified timeframe &mprove productivity by a specified percent in a specified timeframe $aintain customer satisfaction ratings &mprove time5to5mar1et for new product or service releases by a specified percent in a specified timeframe #educe deferred product functionality by a specified percent in a specified timeframe #educe the rate of product recalls by a specified percent in a specified timeframe #educe customer total cost of ownership by a specified percent in a specified timeframe %ecrease the cost of maintaining legacy products by a specified percent in a specified timeframe
S/b'ra#t"#e$
".
Define t$e or+ani-ation;s /uantitative o)4ectives for /ualit* and process performance. )uality and process performance objectives can be established for process or subprocess measurements 2e.g., effort, cycle time, defect removal effectiveness3 as well as for product measurements 2e.g., reliability, defect density3 and service measurements 2e.g., capacity, response times3 as appropriate.
241
Examples of 0uality and process performance objectives include the following:

"chieve a specified defect escape rate, productivity, duration, capacity, or cost target &mprove the defect escape rate, productivity, duration, capacity, or cost performance by a specified percent of the process performance baseline in a specified timeframe &mprove service level agreement performance by a specified percent of the process performance baseline in a specified timeframe
3. 8.
Define t$e priorities of t$e or+ani-ation;s o)4ectives for /ualit* and process performance. !evie', ne+otiate, and o)tain commitment to t$e or+ani-ation;s /ualit* and process performance o)4ectives and t$eir priorities from relevant sta2e$olders. !evise t$e or+ani-ation;s /uantitative o)4ectives for /ualit* and process performance as necessar*. Examples of when the organi6ation9s 0uantitative objectives for 0uality and process performance may need to be revised include the following:
4hen the organi6ation9s business objectives change 4hen the organi6ation9s set of standard processes change 4hen actual 0uality and process performance differ significantly from objectives
9.
SP 1*2
Se&e#t Pro#e$$e$
elect processes or su'processes in the organi5ation7s set of standard processes to 'e included in the organi5ation7s process performance analyses and maintain tracea'ility to 'usiness o'/ecti)es.
"efer to the 0rgani-ational Process efinition process area for more information about establishing organi-ational process assets% T$e or+ani-ation;s set of standard processes consists of a set of standard processes t$at, in turn, are composed of su)processes. T*picall*, it is not possi)le, useful, or economicall* 4ustifia)le to appl* statistical mana+ement tec$ni/ues to all processes or su)processes of t$e or+ani-ation;s set of standard processes. election of processes or su)processes is )ased on t$e /ualit* and process performance o)4ectives of t$e or+ani-ation, '$ic$ are derived from )usiness o)4ectives as descri)ed in t$e previous specific practice.
1.
Aist of processes or su)processes identified for process performance anal*ses 'it$ rationale for t$eir selection includin+ tracea)ilit* to )usiness o)4ectives Esta)lis$ t$e criteria to use '$en selectin+ su)processes.
S/b'ra#t"#e$
1.
242
Examples of criteria that can be used for the selection of a process or subprocess for the organi6ation9s process performance analysis include the following:
(he process or subprocess is strongly related to 1ey business objectives. (he process or subprocess has demonstrated stability in the past. ,alid historical data are currently available that is relevant to the process or subprocess. (he process or subprocess will generate data with sufficient fre0uency to allow for statistical management. (he process or subprocess is an important contributor to 0uality and process performance. (he process or subprocess is an important predictor of 0uality and process performance. (he process or subprocess is a factor important to understanding the ris1 associated with achieving the 0uality and process performance objectives. (he 0uality of the measures and measurements associated with the process or subprocess 2e.g., measurement system error3 is ade0uate. $ultiple measurable attributes that characteri6e process or subprocess behavior are available.
".
elect t$e su)processes and document t$e rationale for t$eir selection. Example approaches to identifying and evaluating subprocess alternatives as part of a selection include the following:
Causal analysis *ensitivity analysis
"efer to the ecision $nalysis and "esolution process area for more information about analy-ing possible decisions using a formal evaluation process that evaluates identified alternatives against established criteria% 3. Esta)lis$ and maintain tracea)ilit* )et'een t$e selected su)processes, /ualit* and process performance o)4ectives, and )usiness o)4ectives. Examples of ways in which traceability can be expressed include the following:
$apping of subprocesses to 0uality and process performance objectives $apping of subprocesses to business objectives Objective flow5down 2e.g., ;ig O to ,ital P, /oshin planning3 ;alanced scorecard )uality Function %eployment 2)F%3 oal )uestion $etric %ocumentation for a process performance model
8.
!evise t$e selection as necessar*. &t may be necessary to revise the selection in the following situations:
243
SP 1*3
(he predictions made by process performance models result in too much variation to ma1e them useful. (he objectives for 0uality and process performance change. (he organi6ation9s set of standard processes change. (he underlying 0uality and process performance changes.
E$tab&"$- Pro#e$$ Performa #e Mea$/re$
+sta'lish and maintain definitions of measures to 'e included in the organi5ation7s process performance analyses.
"efer to the Measurement and $nalysis process area for more information about specifying measures%
1.
Definitions of selected measures of process performance 'it$ rationale for t$eir selection includin+ tracea)ilit* to selected processes or su)processes elect measures t$at reflect appropriate attri)utes of t$e selected processes or su)processes to provide insi+$t into t$e or+ani-ation;s /ualit* and process performance. &t is often helpful to define multiple measures for a process or subprocess to understand the impact of changes to the process and avoid sub5optimi6ation. "lso, it is often helpful to establish measures for both product and process attributes for the selected process and subprocess, as well as its inputs, outputs, and resources 2including people and the s1ill they bring3 consumed. (he oal )uestion $etric paradigm is an approach that can be used to select measures that provide insight into the organi6ation9s 0uality and process performance objectives. &t is often useful to analy6e how these 0uality and process performance objectives can be achieved based on an understanding of process performance provided by the selected measures. Examples of criteria used to select measures include the following:
#elationship of measures to the organi6ation9s 0uality and process performance objectives Coverage that measures provide over the life of the product or service ,isibility that measures provide into process performance "vailability of measures Fre0uency at which observations of the measure can be collected Extent to which measures are controllable by changes to the process or subprocess Extent to which measures represent the end users9 view of effective process performance
S/b'ra#t"#e$
1.
".
Esta)lis$ operational definitions for t$e selected measures. "efer to the Measurement and $nalysis process area for more information about specifying measures%
244
3.
Incorporate selected measures into t$e or+ani-ation;s set of common measures. "efer to the 0rgani-ational Process efinition process area for more information about establishing organi-ational process assets%
8.
!evise t$e set of measures as necessar*. $easures are periodically evaluated for their continued usefulness and ability to indicate process effectiveness.
SP 1*4
A a&1Ae Pro#e$$ Performa #e a + E$tab&"$- Pro#e$$ Performa #e 9a$e&" e$
"naly5e the performance of the selected processes* and esta'lish and maintain the process performance 'aselines.
T$e selected measures are anal*-ed to c$aracteri-e t$e performance of t$e selected processes or su)processes ac$ieved on pro4ects. T$is c$aracteri-ation is used to esta)lis$ and maintain process performance )aselines ( ee t$e definition of Lprocess performance )aselineM in t$e +lossar*., T$ese )aselines are used to determine t$e e5pected results of t$e process or su)process '$en used on a pro4ect under a +iven set of circumstances. Process performance )aselines are compared to t$e or+ani-ation;s /ualit* and process performance o)4ectives to determine if t$e /ualit* and process performance o)4ectives are )ein+ ac$ieved. T$e process performance )aselines are a measurement of performance for t$e or+ani-ation;s set of standard processes at various levels of detail. T$e processes t$at t$e process performance )aselines can address include t$e follo'in+% e/uence of connected processes Processes t$at cover t$e entire life of t$e pro4ect Processes for developin+ individual 'or2 products
T$ere can )e several process performance )aselines to c$aracteri-e performance for su)+roups of t$e or+ani-ation. Examples of criteria used to categori6e subgroups include the following: 'roduct line -ine of business "pplication domain Complexity (eam si6e 4or1 product si6e 'rocess elements from the organi6ation9s set of standard processes
Tailorin+ t$e or+ani-ation;s set of standard processes can si+nificantl* affect t$e compara)ilit* of data for inclusion in process performance
245
)aselines. Effects of tailorin+ s$ould )e considered in esta)lis$in+ )aselines. Dependin+ on t$e tailorin+ allo'ed, separate performance )aselines ma* e5ist for eac$ t*pe of tailorin+. "efer to the 4uantitative Pro.ect Management process area for more information about ,uantitatively managing the pro.ect to achieve the pro.ect3s established ,uality and process performance ob.ectives%
1. ". 1.
0nal*sis of process performance data .aseline data on t$e or+ani-ation;s process performance Collect t$e selected measurements for t$e selected processes and su)processes. (he process or subprocess in use when the measurement was ta1en is recorded to enable its use later. "efer to the Measurement and $nalysis process area for more information about specifying measurement data collection and storage procedures%
S/b'ra#t"#e$
".
0nal*-e t$e collected measures to esta)lis$ a distri)ution or ran+e of results t$at c$aracteri-e t$e e5pected performance of selected processes or su)processes '$en used on a pro4ect. (his analysis should include the stability of the related process or subprocess, and the impacts of associated factors and context. #elated factors include inputs to the process and other attributes that can affect the results obtained. (he context includes the business context 2e.g., domain3 and significant tailoring of the organi6ation9s set of standard processes. (he measurements from stable subprocesses in projects should be used when possible8 other data may not be reliable.
3.
Esta)lis$ and maintain t$e process performance )aselines from collected measurements and anal*ses. "efer to the Measurement and $nalysis process area for more information about aligning measurement and analysis activities and providing measurement results% 'rocess performance baselines are derived by analy6ing collected measures to establish a distribution or range of results that characteri6e the expected performance for selected processes or subprocesses when used on a project in the organi6ation.
8. 9.
!evie' and +et a+reement 'it$ relevant sta2e$olders a)out t$e process performance )aselines. Ma2e t$e process performance information availa)le across t$e or+ani-ation in t$e measurement repositor*. (he organi6ation9s process performance baselines are used by projects to estimate the natural bounds for process performance.
246
G.
Compare t$e process performance )aselines to associated /ualit* and process performance o)4ectives to determine if t$ose /ualit* and process performance o)4ectives are )ein+ ac$ieved. (hese comparisons should use statistical techni0ues beyond a simple comparison of the mean to gauge the extent of 0uality and process performance objective achievement. &f the 0uality and process performance objectives are not being achieved, corrective actions should be considered. "efer to the Causal $nalysis and "esolution process area for more information about determining causes of selected outcomes% "efer to the 0rgani-ational Process 9ocus process area for more information about planning and implementing process actions% "efer to the 0rgani-ational Performance Management for more information about analy-ing process performance data and identifying potential areas for improvement%
=.
!evise t$e process performance )aselines as necessar*. Examples of when the organi6ation9s process performance baselines may need to be revised include the following:
4hen processes change 4hen the organi6ation9s results change 4hen the organi6ation9s needs change 4hen suppliers9 processes change 4hen suppliers change
SP 1*5
E$tab&"$- Pro#e$$ Performa #e Mo+e&$
+sta'lish and maintain process performance models for the organi5ation7s set of standard processes.
@i+$ maturit* or+ani-ations +enerall* esta)lis$ and maintain a set of process performance models at various levels of detail t$at cover a ran+e of activities t$at are common across t$e or+ani-ation and address t$e or+ani-ation;s /ualit* and process performance o)4ectives. ( ee t$e definition of Lprocess performance modelM in t$e +lossar*., :nder some circumstances, pro4ects ma* need to create t$eir o'n process performance models. Process performance models are used to estimate or predict t$e value of a process performance measure from t$e values of ot$er process, product, and service measurements. T$ese process performance models t*picall* use process and product measurements collected t$rou+$out t$e life of t$e pro4ect to estimate pro+ress to'ard ac$ievin+ /ualit* and process performance o)4ectives t$at cannot )e measured until later in t$e pro4ect;s life. Process performance models are used as follo's%
248
T$e or+ani-ation uses t$em for estimatin+, anal*-in+, and predictin+ t$e process performance associated 'it$ processes in and c$an+es to t$e or+ani-ation;s set of standard processes. T$e or+ani-ation uses t$em to assess t$e (potential, return on investment for process improvement activities. Pro4ects use t$em for estimatin+, anal*-in+, and predictin+ t$e process performance of t$eir defined processes. Pro4ects use t$em for selectin+ processes or su)processes for use. Pro4ects use t$em for estimatin+ pro+ress to'ard ac$ievin+ t$e pro4ect;s /ualit* and process performance o)4ectives.
T$ese measures and models are defined to provide insi+$t into and to provide t$e a)ilit* to predict critical process and product c$aracteristics t$at are relevant to t$e or+ani-ation;s /ualit* and process performance o)4ectives. Examples of process performance models include the following: *ystem dynamics models #egression models Complexity models %iscrete event simulation models $onte Carlo simulation models
"efer to the 4uantitative Pro.ect Management process area for more information about ,uantitatively managing the pro.ect to achieve the pro.ect3s established ,uality and process performance ob.ectives%
1. 1. ". 3. 8. 9.
Process performance models Esta)lis$ process performance models )ased on t$e or+ani-ation;s set of standard processes and process performance )aselines. Cali)rate process performance models )ased on t$e past results and current needs. !evie' process performance models and +et a+reement 'it$ relevant sta2e$olders. upport t$e pro4ects; use of process performance models. !evise process performance models as necessar*. Examples of when process performance models may need to be revised include the following:
4hen processes change 4hen the organi6ation9s results change 4hen the organi6ation9s 0uality and process performance objectives change
S/b'ra#t"#e$
24<
243
OR/A*I1A(IO*A+ (RAI*I*/
Purpose
T$e purpose of 7r+ani-ational Trainin+ (7T, is to develop s2ills and 2no'led+e of people so t$e* can perform t$eir roles effectivel* and efficientl*.
Introductor" *otes
7r+ani-ational Trainin+ addresses trainin+ provided to support t$e or+ani-ation;s strate+ic )usiness o)4ectives and to meet t$e tactical trainin+ needs t$at are common across pro4ects and support +roups. Trainin+ needs identified )* individual pro4ects and support +roups to meet t$eir specific needs are $andled at t$e pro4ect and support +roup level and are outside t$e scope of t$e 7r+ani-ational Trainin+ process area. "efer to the Pro.ect Planning process area for more information about planning needed 1nowledge and s1ills% 0n or+ani-ational trainin+ pro+ram involves t$e follo'in+ activities% Identif*in+ t$e trainin+ needed )* t$e or+ani-ation 7)tainin+ and providin+ trainin+ to address t$ose needs Esta)lis$in+ and maintainin+ a trainin+ capa)ilit* Esta)lis$in+ and maintainin+ trainin+ records 0ssessin+ trainin+ effectiveness
Effective trainin+ re/uires t$e assessment of needs, plannin+, instructional desi+n, and appropriate trainin+ media (e.+., 'or2)oo2s, computer soft'are,, as 'ell as a repositor* of trainin+ process data. 0s an or+ani-ational process, t$e main components of trainin+ include a mana+ed trainin+ development pro+ram, documented plans, staff 'it$ an appropriate master* of disciplines and ot$er areas of 2no'led+e, and mec$anisms for measurin+ t$e effectiveness of t$e trainin+ pro+ram. Identif*in+ process trainin+ needs is )ased primaril* on t$e s2ills re/uired to perform t$e or+ani-ation;s set of standard processes. "efer to the 0rgani-ational Process efinition process area for more information about establishing standard processes% Certain s2ills can )e effectivel* and efficientl* imparted t$rou+$ ve$icles ot$er t$an classroom trainin+ e5periences (e.+., informal mentorin+,. 7t$er s2ills re/uire more formali-ed trainin+ ve$icles, suc$ as in a classroom, )* 'e)-)ased trainin+, t$rou+$ +uided self stud*, or via a formali-ed on-t$e4o) trainin+ pro+ram. T$e formal or informal trainin+ ve$icles emplo*ed for eac$ situation s$ould )e )ased on an assessment of t$e need for trainin+
250
Or!a "Aat"o a& Tra" " ! :OT;
and t$e performance +ap to )e addressed. T$e term Ltrainin+M used t$rou+$out t$is process area is used )roadl* to include all of t$ese learnin+ options. uccess in trainin+ is indicated )* t$e availa)ilit* of opportunities to ac/uire t$e s2ills and 2no'led+e needed to perform ne' and on+oin+ enterprise activities. 2ills and 2no'led+e can )e tec$nical, or+ani-ational, or conte5tual. Tec$nical s2ills pertain to t$e a)ilit* to use e/uipment, tools, materials, data, and processes re/uired )* a pro4ect or process. 7r+ani-ational s2ills pertain to )e$avior 'it$in and accordin+ to t$e staff mem)ers; or+ani-ation structure, role and responsi)ilities, and +eneral operatin+ principles and met$ods. Conte5tual s2ills are t$e self-mana+ement, communication, and interpersonal a)ilities needed to successfull* perform 'or2 in t$e or+ani-ational and social conte5t of t$e pro4ect and support +roups.
"efer to the ecision $nalysis and "esolution process area for more information about analy-ing possible decisions using a formal evaluation process that evaluates identified alternatives against established criteria% "efer to the 0rgani-ational Process efinition process area for more information about establishing organi-ational process assets% "efer to the Pro.ect Planning process area for more information about planning needed 1nowledge and s1ills%
3 1 Esta)lis$ an 7r+ani-ational Trainin+ Capa)ilit* P 1.1 P 1." P 1.3 P 1.8 P ".1 P "." P ".3 Esta)lis$ trate+ic Trainin+ <eeds Determine 6$ic$ Trainin+ <eeds 0re t$e !esponsi)ilit* of t$e 7r+ani-ation Esta)lis$ an 7r+ani-ational Trainin+ Tactical Plan Esta)lis$ a Trainin+ Capa)ilit* Deliver Trainin+ Esta)lis$ Trainin+ !ecords 0ssess Trainin+ Effectiveness
3 " Provide Trainin+
)pecific Practices b" /oal S7 1 E$tab&"$- a Or!a "Aat"o a& Tra" " ! Ca'ab"&"t1
" training capa'ility* 3hich supports the roles in the organi5ation* is esta'lished and maintained.
T$e or+ani-ation identifies trainin+ re/uired to develop t$e s2ills and 2no'led+e necessar* to perform enterprise activities. 7nce t$e needs are identified, a trainin+ pro+ram addressin+ t$ose needs is developed.
SP 1*1 E$tab&"$- Strate!"# Tra" " ! Nee+$
+sta'lish and maintain strategic training needs of the organi5ation.
251
trate+ic trainin+ needs address lon+-term o)4ectives to )uild a capa)ilit* )* fillin+ si+nificant 2no'led+e +aps, introducin+ ne' tec$nolo+ies, or implementin+ ma4or c$an+es in )e$avior. trate+ic plannin+ t*picall* loo2s t'o to five *ears into t$e future. Examples of sources of strategic training needs include the following: (he organi6ation9s standard processes (he organi6ation9s strategic business plan (he organi6ation9s process improvement plan Enterprise level initiatives *1ill assessments #is1 analyses "c0uisition and supplier management
1. ". 1. ".
Trainin+ needs 0ssessment anal*sis 0nal*-e t$e or+ani-ation;s strate+ic )usiness o)4ectives and process improvement plan to identif* potential trainin+ needs. Document t$e strate+ic trainin+ needs of t$e or+ani-ation. Examples of categories of training needs include the following:
'rocess analysis and documentation Engineering 2e.g., re0uirements analysis, design, testing, configuration management, 0uality assurance3 *election and management of suppliers (eam building $anagement 2e.g., estimating, trac1ing, ris1 management3 -eadership %isaster recovery and continuity of operations Communication and negotiation s1ills
S/b'ra#t"#e$
3. 8. 9. G.
Determine t$e roles and s2ills needed to perform t$e or+ani-ation;s set of standard processes. Document t$e trainin+ needed to perform roles in t$e or+ani-ation;s set of standard processes. Document t$e trainin+ needed to maintain t$e safe, secure, and continued operation of t$e )usiness. !evise t$e or+ani-ation;s strate+ic needs and re/uired trainin+ as necessar*.
252
SP 1*2
%eterm" e >-"#- Tra" " ! Nee+$ Are t-e Re$'o $"b"&"t1 of t-e Or!a "Aat"o
Determine 3hich training needs are the responsi'ility of the organi5ation and 3hich are left to the indi)idual pro/ect or support group.
"efer to the Pro.ect Planning process area for more information about planning needed 1nowledge and s1ills% In addition to strate+ic trainin+ needs, or+ani-ational trainin+ addresses trainin+ re/uirements t$at are common across pro4ects and support +roups. Pro4ects and support +roups $ave t$e primar* responsi)ilit* for identif*in+ and addressin+ t$eir trainin+ needs. T$e or+ani-ation;s trainin+ staff is responsi)le for addressin+ onl* common cross-pro4ect and support +roup trainin+ needs (e.+., trainin+ in 'or2 environments common to multiple pro4ects,. In some cases, $o'ever, t$e or+ani-ation;s trainin+ staff ma* address additional trainin+ needs of pro4ects and support +roups, as ne+otiated 'it$ t$em, in t$e conte5t of t$e trainin+ resources availa)le and t$e or+ani-ation;s trainin+ priorities.
1. ". 1.
Common pro4ect and support +roup trainin+ needs Trainin+ commitments 0nal*-e t$e trainin+ needs identified )* pro4ects and support +roups. "nalysis of project and support group needs is intended to identify common training needs that can be most efficiently addressed organi6ation wide. (hese needs analysis activities are used to anticipate future training needs that are first visible at the project and support group level.
S/b'ra#t"#e$
".
<e+otiate 'it$ pro4ects and support +roups on $o' t$eir trainin+ needs 'ill )e satisfied. (he support provided by the organi6ation9s training staff depends on the training resources available and the organi6ation9s training priorities. Examples of training appropriately performed by the project or support group include the following:
(raining in the application or service domain of the project (raining in the uni0ue tools and methods used by the project or support group (raining in safety, security, and human factors
3.
Document commitments for providin+ trainin+ support to pro4ects and support +roups.
SP 1*3
E$tab&"$- a Or!a "Aat"o a& Tra" " ! Ta#t"#a& P&a
+sta'lish and maintain an organi5ational training tactical plan.
253
T$e or+ani-ational trainin+ tactical plan is t$e plan to deliver t$e trainin+ t$at is t$e responsi)ilit* of t$e or+ani-ation and is necessar* for individuals to perform t$eir roles effectivel*. T$is plan addresses t$e near-term e5ecution of trainin+ and is ad4usted periodicall* in response to c$an+es (e.+., in needs, in resources, and to evaluations of effectiveness.
1. 1.
7r+ani-ational trainin+ tactical plan Esta)lis$ t$e content of t$e plan. Organi6ational training tactical plans typically contain the following:
(raining needs (raining topics *chedules based on training activities and their dependencies $ethods used for training #e0uirements and 0uality standards for training materials (raining tas1s, roles, and responsibilities #e0uired resources including tools, facilities, environments, staffing, s1ills, and 1nowledge
S/b'ra#t"#e$
".
Esta)lis$ commitments to t$e plan. %ocumented commitments by those who are responsible for implementing and supporting the plan are essential for the plan to be effective.
3.
SP 1*4
!evise t$e plan and commitments as necessar*.
E$tab&"$- a Tra" " ! Ca'ab"&"t1
+sta'lish and maintain a training capa'ility to address organi5ational training needs.

"efer to the ecision $nalysis and "esolution process area for more information about analy-ing possible decisions using a formal evaluation process that evaluates identified alternatives against established criteria%
1. 1.
Trainin+ materials and supportin+ artifacts elect appropriate approac$es to satisf* or+ani-ational trainin+ needs. $any factors may affect the selection of training approaches, including audience specific 1nowledge, costs, schedule, and the wor1 environment. *electing an approach re0uires consideration of the means to provide s1ills and 1nowledge in the most effective way possible given the constraints.
S/b'ra#t"#e$
254
Examples of training approaches include the following:

Classroom training Computer aided instruction uided self study Formal apprenticeship and mentoring programs Facilitated videos Chal1 tal1s ;rown bag lunch seminars *tructured on5the5job training
".
Determine '$et$er to develop trainin+ materials internall* or to ac/uire t$em e5ternall*. %etermine the costs and benefits of internal training development and of ac0uiring training externally. Example criteria that can be used to determine the most effective mode of 1nowledge or s1ill ac0uisition include the following:
"pplicability to wor1 or process performance objectives "vailability of time to prepare for project execution "pplicability to business objectives "vailability of in5house expertise "vailability of training from external sources
Examples of external sources of training include the following:

Customer provided training Commercially available training courses "cademic programs 'rofessional conferences *eminars
3.
Develop or o)tain trainin+ materials. (raining can be provided by the project, support groups, the organi6ation, or an external organi6ation. (he organi6ation9s training staff coordinates the ac0uisition and delivery of training regardless of its source. Examples of training materials include the following:
Courses Computer5aided instruction ,ideos
8.
Develop or o)tain /ualified instructors, instructional desi+ners, or mentors.
255
(o ensure that those who develop and deliver internal training have the necessary 1nowledge and training s1ills, criteria can be defined to identify, develop, and 0ualify them. (he development of training, including self study and online training, should involve those who have experience in instructional design. &n the case of external training, the organi6ation9s training staff can investigate how the training provider determines which instructors will deliver the training. (his selection of 0ualified instructors can also be a factor in selecting or continuing to use a training provider. 9. Descri)e t$e trainin+ in t$e or+ani-ation;s trainin+ curriculum. Examples of the information provided in training descriptions for each course include the following:
(opics covered in the training &ntended audience 'rere0uisites and preparation for participating (raining objectives -ength of the training -esson plans Completion criteria for the course Criteria for granting training waivers
G.
!evise trainin+ materials and supportin+ artifacts as necessar*. Examples of situations in which training materials and supporting artifacts may need to be revised include the following:
(raining needs change 2e.g., when new technology associated with the training topic is available3 "n evaluation of the training identifies the need for change 2e.g., evaluations of training effectiveness surveys, training program performance assessments, instructor evaluation forms3
S7 2
Prov"+e Tra" " !
Training for indi)iduals to perform their roles effecti)ely is pro)ided.

6$en selectin+ people to )e trained, t$e follo'in+ s$ould )e considered% .ac2+round of t$e tar+et population of trainin+ participants Prere/uisite )ac2+round to receive trainin+ 2ills and a)ilities needed )* people to perform t$eir roles <eed for cross-discipline trainin+ for all disciplines, includin+ pro4ect mana+ement <eed for mana+ers to $ave trainin+ in appropriate or+ani-ational processes <eed for trainin+ in )asic principles of all appropriate disciplines or services to support staff in /ualit* mana+ement, confi+uration mana+ement, and ot$er related support functions <eed to provide competenc* development for critical functional areas
256
SP 2*1
<eed to maintain competencies and /ualifications of staff to operate and maintain 'or2 environments common to multiple pro4ects
%e&"ver Tra" " !
Deli)er training follo3ing the organi5ational training tactical plan.

1. 1.
Delivered trainin+ course elect t$ose '$o 'ill receive t$e trainin+ necessar* to perform t$eir roles effectivel*. (raining is intended to impart 1nowledge and s1ills to people performing various roles in the organi6ation. *ome people already possess the 1nowledge and s1ills re0uired to perform well in their designated roles. (raining can be waived for these people, but care should be ta1en that training waivers are not abused.
S/b'ra#t"#e$
".
c$edule t$e trainin+, includin+ an* resources, as necessar* (e.+., facilities, instructors,. (raining should be planned and scheduled. (raining is provided that has a direct bearing on wor1 performance expectations. (herefore, optimal training occurs in a timely manner with regard to imminent job performance expectations. (hese performance expectations often include the following:
(raining in the use of speciali6ed tools (raining in procedures that are new to the person who will perform them
3.
Deliver t$e trainin+. &f the training is delivered by a person, then appropriate training professionals 2e.g., experienced instructors, mentors3 should deliver the training. 4hen possible, training is delivered in settings that closely resemble the actual wor1 environment and includes activities to simulate actual wor1 situations. (his approach includes integration of tools, methods, and procedures for competency development. (raining is tied to wor1 responsibilities so that on5the5job activities or other outside experiences will reinforce the training within a reasonable time after the training was delivered.
8.
SP 2*2
Trac2 t$e deliver* of trainin+ a+ainst t$e plan.
E$tab&"$- Tra" " ! Re#or+$
+sta'lish and maintain records of organi5ational training.

T$is practice applies to t$e trainin+ performed at t$e or+ani-ational level. Esta)lis$ment and maintenance of trainin+ records for pro4ect or support +roup sponsored trainin+ is t$e responsi)ilit* of eac$ individual pro4ect or support +roup.
1. ".
Trainin+ records Trainin+ updates to t$e or+ani-ational repositor*
258
S/b'ra#t"#e$
1.
Neep records of all students '$o successfull* complete eac$ trainin+ course or ot$er approved trainin+ activit* as 'ell as t$ose '$o are unsuccessful. Neep records of all staff '$o are 'aived from trainin+. (he rationale for granting a waiver should be documented, and both the manager responsible and the manager of the excepted individual should approve the waiver.
".
3. 8.
Neep records of all students '$o successfull* complete t$eir re/uired trainin+. Ma2e trainin+ records availa)le to t$e appropriate people for consideration in assi+nments. (raining records may be part of a s1ills matrix developed by the training organi6ation to provide a summary of the experience and education of people, as well as training sponsored by the organi6ation.
SP 2*3
A$$e$$ Tra" " ! Effe#t"ve e$$
"ssess the effecti)eness of the organi5ation7s training program.

0 process s$ould e5ist to determine t$e effectiveness of trainin+ (i.e., $o' 'ell trainin+ is meetin+ t$e or+ani-ation;s needs,. Examples of methods used to assess training effectiveness include the following: (esting in the training context 'ost5training surveys of training participants *urveys of manager satisfaction with post5training effects "ssessment mechanisms embedded in courseware
Measures can )e ta2en to assess t$e )enefits of trainin+ a+ainst )ot$ t$e pro4ect;s and or+ani-ation;s o)4ectives. Particular attention s$ould )e paid to t$e need for various trainin+ met$ods, suc$ as trainin+ teams as inte+ral 'or2 units. 6$en used, 'or2 or process performance o)4ectives s$ould )e unam)i+uous, o)serva)le, verifia)le, and s$ared 'it$ course participants. T$e results of t$e trainin+ effectiveness assessment s$ould )e used to revise trainin+ materials as descri)ed in t$e Esta)lis$ a Trainin+ Capa)ilit* specific practice.
1. ". 3. 8. 1.
Trainin+ effectiveness surve*s Trainin+ pro+ram performance assessments Instructor evaluation forms Trainin+ e5aminations 0ssess in-pro+ress or completed pro4ects to determine '$et$er staff 2no'led+e is ade/uate for performin+ pro4ect tas2s.
S/b'ra#t"#e$
25<
".
Provide a mec$anism for assessin+ t$e effectiveness of eac$ trainin+ course 'it$ respect to esta)lis$ed or+ani-ational, pro4ect, or individual learnin+ (or performance, o)4ectives. 7)tain student evaluations of $o' 'ell trainin+ activities met t$eir needs.
3.
253
PRODU!( I*($/RA(IO*
An Engineering Process Area at Maturity Level 3
Purpose
T$e purpose of Product Inte+ration (PI, is to assem)le t$e product from t$e product components, ensure t$at t$e product, as inte+rated, )e$aves properl* (i.e., possesses t$e re/uired functionalit* and /ualit* attri)utes,, and deliver t$e product.
Introductor" *otes
T$is process area addresses t$e inte+ration of product components into more comple5 product components or into complete products. T$e scope of t$is process area is to ac$ieve complete product inte+ration t$rou+$ pro+ressive assem)l* of product components, in one sta+e or in incremental sta+es, accordin+ to a defined inte+ration strate+* and procedures. T$rou+$out t$e process areas, '$ere t$e terms LproductM and Lproduct componentM are used, t$eir intended meanin+s also encompass services, service s*stems, and t$eir components. 0 critical aspect of product inte+ration is t$e mana+ement of internal and e5ternal interfaces of t$e products and product components to ensure compati)ilit* amon+ t$e interfaces. T$ese interfaces are not limited to user interfaces, )ut also appl* to interfaces amon+ components of t$e product, includin+ internal and e5ternal data sources, middle'are, and ot$er components t$at ma* or ma* not )e 'it$in t$e development or+ani-ation;s control )ut on '$ic$ t$e product relies. 0ttention s$ould )e paid to interface mana+ement t$rou+$out t$e pro4ect. Product inte+ration is more t$an 4ust a one-time assem)l* of t$e product components at t$e conclusion of desi+n and fa)rication. Product inte+ration can )e conducted incrementall*, usin+ an iterative process of assem)lin+ product components, evaluatin+ t$em, and t$en assem)lin+ more product components. It can )e conducted usin+ $i+$l* automated )uilds and continuous inte+ration of t$e completed unit tested product. T$is process can )e+in 'it$ anal*sis and simulations (e.+., t$reads, rapid protot*pes, virtual protot*pes, p$*sical protot*pes, and steadil* pro+ress t$rou+$ increasin+l* more realistic increments until t$e final product is ac$ieved. In eac$ successive )uild, protot*pes (virtual, rapid, or p$*sical, are constructed, evaluated, improved, and reconstructed )ased on 2no'led+e +ained in t$e evaluation process. T$e de+ree of virtual versus p$*sical protot*pin+ re/uired depends on t$e functionalit* of t$e desi+n tools, t$e comple5it* of t$e product, and its associated ris2. T$ere is a $i+$ pro)a)ilit* t$at t$e product, inte+rated in t$is manner, 'ill pass product verification and validation. 1or some products and services, t$e last inte+ration p$ase 'ill occur '$en t$e* are deplo*ed at t$e intended operational site.
260
Pro+/#t I te!rat"o :PI;
1or product lines, products are assem)led accordin+ to t$e product line production plan. T$e product line production plan specifies t$e assem)l* process, includin+ '$ic$ core assets to use and $o' product line variation is resolved 'it$in t$ose core assets. &n "gile environments, product integration is a fre0uent, often daily, activity. For example, for software, wor1ing code is continuously added to the code base in a process called @continuous integration.A &n addition to addressing continuous integration, the product integration strategy can address how supplier supplied components will be incorporated, how functionality will be built 2in layers vs. @vertical slicesA3, and when to @refactor.A (he strategy should be established early in the project and be revised to reflect evolving and emerging component interfaces, external feeds, data exchange, and application program interfaces. 2*ee @&nterpreting C$$& 4hen :sing "gile "pproachesA in 'art &.3
"efer to the "e,uirements evelopment process area for more information about identifying interface re,uirements% "efer to the Technical Solution process area for more information about designing interfaces using criteria% "efer to the 8alidation process area for more information about performing validation% "efer to the 8erification process area for more information about performing verification% "efer to the Configuration Management process area for more information about trac1ing and controlling changes% "efer to the ecision $nalysis and "esolution process area for more information about analy-ing possible decisions using a formal evaluation process that evaluates identified alternatives against established criteria% "efer to the "is1 Management process area for more information about identifying ris1s and mitigating ris1s% "efer to the Supplier $greement Management process area for more information about managing the ac,uisition of products and services from suppliers%
261

3 1 Prepare for Product Inte+ration P 1.1 P 1." P 1.3 P ".1 P "." P 3.1 P 3." P 3.3 P 3.8 Esta)lis$ an Inte+ration trate+* Esta)lis$ t$e Product Inte+ration Environment Esta)lis$ Product Inte+ration Procedures and Criteria !evie' Interface Descriptions for Completeness Mana+e Interfaces Confirm !eadiness of Product Components for Inte+ration 0ssem)le Product Components Evaluate 0ssem)led Product Components Pac2a+e and Deliver t$e Product or Product Component
3 " Ensure Interface Compati)ilit*
3 3 0ssem)le Product Components and Deliver t$e Product
)pecific Practices b" /oal S7 1 Pre'are for Pro+/#t I te!rat"o
!reparation for product integration is conducted.

Preparin+ for t$e inte+ration of product components involves esta)lis$in+ an inte+ration strate+*, esta)lis$in+ t$e environment for performin+ t$e inte+ration, and esta)lis$in+ inte+ration procedures and criteria. Preparation for inte+ration starts earl* in t$e pro4ect.
SP 1*1 E$tab&"$- a I te!rat"o Strate!1
+sta'lish and maintain a product integration strategy.

T$e product inte+ration strate+* descri)es t$e approac$ for receivin+, assem)lin+, and evaluatin+ t$e product components t$at comprise t$e product. 0 product inte+ration strate+* addresses items suc$ as t$e follo'in+% Ma2in+ product components availa)le for inte+ration (e.+., in '$at se/uence, 0ssem)lin+ and evaluatin+ as a sin+le )uild or as a pro+ression of incremental )uilds Includin+ and testin+ features in eac$ iteration '$en usin+ iterative development Mana+in+ interfaces :sin+ models, protot*pes, and simulations to assist in evaluatin+ an assem)l*, includin+ its interfaces Esta)lis$in+ t$e product inte+ration environment Definin+ procedures and criteria Ma2in+ availa)le t$e appropriate test tools and e/uipment Mana+in+ product $ierarc$*, arc$itecture, and comple5it* !ecordin+ results of evaluations @andlin+ e5ceptions
262
T$e inte+ration strate+* s$ould also )e ali+ned 'it$ t$e tec$nical approac$ descri)ed in t$e Pro4ect Plannin+ process area and $armoni-ed 'it$ t$e selection of solutions and t$e desi+n of product and product components in t$e Tec$nical olution process area. "efer to the Technical Solution process area for more information about selecting product component solutions and implementing the design% "efer to the ecision $nalysis and "esolution process area for more information about analy-ing possible decisions using a formal evaluation process that evaluates identified alternatives against established criteria% "efer to the Pro.ect Planning process area for more information about establishing and maintaining plans that define pro.ect activities% "efer to the "is1 Management process area for more information about identifying ris1s and mitigating ris1s% "efer to the Supplier $greement Management process area for more information about managing the ac,uisition of products and services from suppliers% T$e results of developin+ a product inte+ration strate+* are t*picall* documented in a product inte+ration plan, '$ic$ is revie'ed 'it$ sta2e$olders to promote commitment and understandin+. ome of t$e items addressed in a product inte+ration strate+* are covered in more detail in t$e ot$er specific practices and +eneric practices of t$is process area (e.+., environment, procedures and criteria, trainin+, roles and responsi)ilities, involvement of relevant sta2e$olders,.
1. ".
Product inte+ration strate+* !ationale for selectin+ or re4ectin+ alternative product inte+ration strate+ies Identif* t$e product components to )e inte+rated. Identif* t$e verifications to )e performed durin+ t$e inte+ration of t$e product components. (his identification includes verifications to be performed on interfaces.
S/b'ra#t"#e$
1. ".
3.
Identif* alternative product component inte+ration strate+ies. %eveloping an integration strategy can involve specifying and evaluating several alternative integration strategies or se0uences.
8.
elect t$e )est inte+ration strate+*. (he availability of the following will need to be aligned or harmoni6ed with the integration strategy: product components8 the integration environment8 test tools and e0uipment8 procedures and criteria8 relevant sta1eholders8 and staff who possess the appropriate s1ills.
263
9.
Periodicall* revie' t$e product inte+ration strate+* and revise as needed. "ssess the product integration strategy to ensure that variations in production and delivery schedules have not had an adverse impact on the integration se0uence or compromised the factors on which earlier decisions were made.
G.
SP 1*2
!ecord t$e rationale for decisions made and deferred.
E$tab&"$- t-e Pro+/#t I te!rat"o E v"ro me t
+sta'lish and maintain the en)ironment needed to support the integration of the product components.
T$e environment for product inte+ration can eit$er )e ac/uired or developed. To esta)lis$ an environment, re/uirements for t$e purc$ase or development of e/uipment, soft'are, or ot$er resources 'ill need to )e developed. T$ese re/uirements are +at$ered '$en implementin+ t$e processes associated 'it$ t$e !e/uirements Development process area. T$e product inte+ration environment can include t$e reuse of e5istin+ or+ani-ational resources. T$e decision to ac/uire or develop t$e product inte+ration environment is addressed in t$e processes associated 'it$ t$e Tec$nical olution process area. "efer to the Technical Solution process area for more information about performing ma1e2 buy2 or reuse analyses% T$e environment re/uired at eac$ step of t$e product inte+ration process can include test e/uipment, simulators (ta2in+ t$e place of unavaila)le product components,, pieces of real e/uipment, and recordin+ devices.
1. ". 1. ". 3.
Verified environment for product inte+ration upport documentation for t$e product inte+ration environment Identif* t$e re/uirements for t$e product inte+ration environment. Identif* verification procedures and criteria for t$e product inte+ration environment. Decide '$et$er to ma2e or )u* t$e needed product inte+ration environment. "efer to the Supplier $greement Management process area for more information about managing the ac,uisition of products and services from suppliers%
S/b'ra#t"#e$
8.
Develop an inte+ration environment if a suita)le environment cannot )e ac/uired. For unprecedented, complex projects, the product integration environment can be a major development. "s such, it would involve project planning, re0uirements development, technical solutions, verification, validation, and ris1 management.
9. G.
Maintain t$e product inte+ration environment t$rou+$out t$e pro4ect. Dispose of t$ose portions of t$e environment t$at are no lon+er useful.
264
SP 1*3
E$tab&"$- Pro+/#t I te!rat"o Pro#e+/re$ a + Cr"ter"a
+sta'lish and maintain procedures and criteria for integration of the product components.
Procedures for t$e inte+ration of t$e product components can include suc$ t$in+s as t$e num)er of incremental iterations to )e performed and details of t$e e5pected tests and ot$er evaluations to )e carried out at eac$ sta+e. Criteria can indicate t$e readiness of a product component for inte+ration or its accepta)ilit*. Procedures and criteria for product inte+ration address t$e follo'in+% Aevel of testin+ for )uild components Verification of interfaces T$res$olds of performance deviation Derived re/uirements for t$e assem)l* and its e5ternal interfaces 0llo'a)le su)stitutions of components Testin+ environment parameters Aimits on cost of testin+ Bualit*&cost tradeoffs for inte+ration operations Pro)a)ilit* of proper functionin+ Deliver* rate and its variation Aead time from order to deliver* taff mem)er availa)ilit* 0vaila)ilit* of t$e inte+ration facilit*&line&environment
Criteria can )e defined for $o' t$e product components are to )e verified and t$e )e$aviors (functionalit* and /ualit* attri)utes, t$e* are e5pected to $ave. Criteria can )e defined for $o' t$e assem)led product components and final inte+rated product are to )e validated and delivered. Criteria can also constrain t$e de+ree of simulation permitted for a product component to pass a test, or can constrain t$e environment to )e used for t$e inte+ration test. Pertinent parts of t$e sc$edule and criteria for assem)l* s$ould )e s$ared 'it$ suppliers of 'or2 products to reduce t$e occurrence of dela*s and component failure. "efer to the Supplier $greement Management process area for more information about e:ecuting the supplier agreement%
1. ". 1.
Product inte+ration procedures Product inte+ration criteria Esta)lis$ and maintain product inte+ration procedures for t$e product components.
S/b'ra#t"#e$
265
". 3.
Esta)lis$ and maintain criteria for product component inte+ration and evaluation. Esta)lis$ and maintain criteria for validation and deliver* of t$e inte+rated product.
S7 2
E $/re I terfa#e Com'at"b"&"t1
The product component interfaces* 'oth internal and e,ternal* are compati'le.
Man* product inte+ration pro)lems arise from un2no'n or uncontrolled aspects of )ot$ internal and e5ternal interfaces. Effective mana+ement of product component interface re/uirements, specifications, and desi+ns $elps ensure t$at implemented interfaces 'ill )e complete and compati)le.
SP 2*1 Rev"ew I terfa#e %e$#r"'t"o $ for Com'&ete e$$
#e)ie3 interface descriptions for co)erage and completeness.

T$e interfaces s$ould include, in addition to product component interfaces, all t$e interfaces 'it$ t$e product inte+ration environment.
1. ". 3.
Cate+ories of interfaces Aist of interfaces per cate+or* Mappin+ of t$e interfaces to t$e product components and t$e product inte+ration environment !evie' interface data for completeness and ensure complete covera+e of all interfaces. Consider all the product components and prepare a relationship table. &nterfaces are usually classified in three main classes: environmental, physical, and functional. (ypical categories for these classes include the following: mechanical, fluid, sound, electrical, climatic, electromagnetic, thermal, message, and the human5machine or human interface.
S/b'ra#t"#e$
1.
266
Examples of interfaces 2e.g., for mechanical or electronic components3 that can be classified within these three classes include the following:
$echanical interfaces 2e.g., weight and si6e, center of gravity, clearance of parts in operation, space re0uired for maintenance, fixed lin1s, mobile lin1s, shoc1s and vibrations received from the bearing structure3 7oise interfaces 2e.g., noise transmitted by the structure, noise transmitted in the air, acoustics3 Climatic interfaces 2e.g., temperature, humidity, pressure, salinity3 (hermal interfaces 2e.g., heat dissipation, transmission of heat to the bearing structure, air conditioning characteristics3 Fluid interfaces 2e.g., fresh water inletEoutlet, seawater inletEoutlet for a navalEcoastal product, air conditioning, compressed air, nitrogen, fuel, lubricating oil, exhaust gas outlet3 Electrical interfaces 2e.g., power supply consumption by networ1 with transients and pea1 values8 nonsensitive control signal for power supply and communications8 sensitive signal Ie.g., analog lin1sJ8 disturbing signal Ie.g., microwaveJ8 grounding signal to comply with the (E$'E*( standard3 Electromagnetic interfaces 2e.g., magnetic field, radio and radar lin1s, optical band lin1 wave guides, coaxial and optical fibers3 /uman5machine interface 2e.g., audio or voice synthesis, audio or voice recognition, display Ianalog dial, li0uid crystal display, indicators? light emitting diodesJ, manual controls Ipedal, joystic1, trac1 ball, 1eyboard, push buttons, touch screenJ3 $essage interfaces 2e.g., origination, destination, stimulus, protocols, data characteristics3
". 3.
Ensure t$at product components and interfaces are mar2ed to ensure eas* and correct connection to t$e 4oinin+ product component. Periodicall* revie' t$e ade/uac* of interface descriptions. Once established, the interface descriptions should be periodically reviewed to ensure there is no deviation between the existing descriptions and the products being developed, processed, produced, or bought. (he interface descriptions for product components should be reviewed with relevant sta1eholders to avoid misinterpretations, reduce delays, and prevent the development of interfaces that do not wor1 properly.
SP 2*2
Ma a!e I terfa#e$
Manage internal and e,ternal interface definitions* designs* and changes for products and product components.
Interface re/uirements drive t$e development of t$e interfaces necessar* to inte+rate product components. Mana+in+ product and product component interfaces starts earl* in t$e development of t$e product. T$e definitions and desi+ns for interfaces affect not onl* t$e product components and e5ternal s*stems, )ut can also affect t$e verification and validation environments. "efer to the "e,uirements evelopment process area for more information about identifying interface re,uirements%
268
"efer to the Technical Solution process area for more information about designing interfaces using criteria% "efer to the Configuration Management process area for more information about establishing and maintaining the integrity of wor1 products using configuration identification2 configuration control2 configuration status accounting2 and configuration audits% "efer to the Manage "e,uirements Changes specific practice in the "e,uirements Management process area for more information about managing the changes to the interface re,uirements% Mana+ement of t$e interfaces includes maintenance of t$e consistenc* of t$e interfaces t$rou+$out t$e life of t$e product, compliance 'it$ arc$itectural decisions and constraints, and resolution of conflict, noncompliance, and c$an+e issues. T$e mana+ement of interfaces )et'een products ac/uired from suppliers and ot$er products or product components is critical for success of t$e pro4ect. "efer to the Supplier $greement Management process area for more information about managing the ac,uisition of products and services from suppliers% T$e interfaces s$ould include, in addition to product component interfaces, all t$e interfaces 'it$ t$e environment as 'ell as ot$er environments for verification, validation, operations, and support. T$e interface c$an+es are documented, maintained, and readil* accessi)le.
1.
Ta)le of relations$ips amon+ t$e product components and t$e e5ternal environment (e.+., main po'er suppl*, fastenin+ product, computer )us s*stem, Ta)le of relations$ips amon+ t$e different product components Aist of a+reed-to interfaces defined for eac$ pair of product components, '$en applica)le !eports from t$e interface control 'or2in+ +roup meetin+s 0ction items for updatin+ interfaces 0pplication pro+ram interface (0PI, :pdated interface description or a+reement Ensure t$e compati)ilit* of t$e interfaces t$rou+$out t$e life of t$e product. !esolve conflict, noncompliance, and c$an+e issues. Maintain a repositor* for interface data accessi)le to pro4ect participants.
". 3. 8. 9. G. =. 1. ". 3.
S/b'ra#t"#e$
26<
" common accessible repository for interface data provides a mechanism to ensure that everyone 1nows where the current interface data reside and can access them for use.
S7 3 A$$emb&e Pro+/#t Com'o e t$ a + %e&"ver t-e Pro+/#t
9erified product components are assem'led and the integrated* )erified* and )alidated product is deli)ered.
Inte+ration of product components proceeds accordin+ to t$e product inte+ration strate+* and procedures. .efore inte+ration, eac$ product component s$ould )e confirmed to )e compliant 'it$ its interface re/uirements. Product components are assem)led into lar+er, more comple5 product components. T$ese assem)led product components are c$ec2ed for correct interoperation. T$is process continues until product inte+ration is complete. If, durin+ t$is process, pro)lems are identified, t$e pro)lem s$ould )e documented and a corrective action process initiated. T$e timel* receipt of needed product components and t$e involvement of t$e ri+$t people contri)ute to t$e successful inte+ration of t$e product components t$at compose t$e product.
SP 3*1 Co f"rm Rea+" e$$ of Pro+/#t Com'o e t$ for I te!rat"o
Confirm* prior to assem'ly* that each product component re-uired to assem'le the product has 'een properly identified* 'eha)es according to its description* and that the product component interfaces comply 3ith the interface descriptions.
"efer to the 8erification process area for more information about performing verification% T$e purpose of t$is specific practice is to ensure t$at t$e properl* identified product component t$at meets its description can actuall* )e assem)led accordin+ to t$e product inte+ration strate+* and procedures. T$e product components are c$ec2ed for /uantit*, o)vious dama+e, and consistenc* )et'een t$e product component and interface descriptions. T$ose '$o conduct product inte+ration are ultimatel* responsi)le for c$ec2in+ to ma2e sure ever*t$in+ is proper 'it$ t$e product components )efore assem)l*.
1. ". 3. 8. 9. 1.
0cceptance documents for t$e received product components Deliver* receipts C$ec2ed pac2in+ lists E5ception reports 6aivers Trac2 t$e status of all product components as soon as t$e* )ecome availa)le for inte+ration.
S/b'ra#t"#e$
263
".
Ensure t$at product components are delivered to t$e product inte+ration environment in accordance 'it$ t$e product inte+ration strate+* and procedures. Confirm t$e receipt of eac$ properl* identified product component. Ensure t$at eac$ received product component meets its description. C$ec2 t$e confi+uration status a+ainst t$e e5pected confi+uration. Perform a pre-c$ec2 (e.+., )* a visual inspection, usin+ )asic measures, of all t$e p$*sical interfaces )efore connectin+ product components to+et$er.
3. 8. 9. G.
SP 3*2
A$$emb&e Pro+/#t Com'o e t$
"ssem'le product components according to the product integration strategy and procedures.
T$e assem)l* activities of t$is specific practice and t$e evaluation activities of t$e ne5t specific practice are conducted iterativel*, from t$e initial product components, t$rou+$ t$e interim assem)lies of product components, to t$e product as a '$ole.
1. 1. ".
0ssem)led product or product components Ensure t$e readiness of t$e product inte+ration environment. Conduct inte+ration in accordance 'it$ t$e product inte+ration strate+*, procedures, and criteria. #ecord all appropriate information 2e.g., configuration status, serial numbers of the product components, types, calibration date of the meters3.
S/b'ra#t"#e$
3.
!evise t$e product inte+ration strate+*, procedures, and criteria as appropriate.
SP 3*3
Eva&/ate A$$emb&e+ Pro+/#t Com'o e t$
+)aluate assem'led product components for interface compati'ility.

"efer to the 8alidation process area for more information about performing validation% "efer to the 8erification process area for more information about performing verification% T$is evaluation involves e5aminin+ and testin+ assem)led product components for performance, suita)ilit*, or readiness usin+ t$e product inte+ration procedures, criteria, and environment. It is performed as appropriate for different sta+es of assem)l* of product components as identified in t$e product inte+ration strate+* and procedures. T$e product inte+ration strate+* and procedures can define a more refined inte+ration and evaluation se/uence t$an mi+$t )e envisioned 4ust )* e5aminin+ t$e product $ierarc$* or arc$itecture. 1or e5ample, if an assem)l* of product
280
components is composed of four less comple5 product components, t$e inte+ration strate+* 'ill not necessaril* call for t$e simultaneous inte+ration and evaluation of t$e four units as one. !at$er, t$e four less comple5 units can )e inte+rated pro+ressivel*, one at a time, 'it$ an evaluation after eac$ assem)l* operation prior to reali-in+ t$e more comple5 product component t$at matc$ed t$e specification in t$e product arc$itecture. 0lternativel*, t$e product inte+ration strate+* and procedures could $ave determined t$at onl* a final evaluation 'as t$e )est one to perform.
1. ". 3. 1. ".
E5ception reports Interface evaluation reports Product inte+ration summar* reports Conduct t$e evaluation of assem)led product components follo'in+ t$e product inte+ration strate+*, procedures, and criteria. !ecord t$e evaluation results. Example results include the following:
"ny adaptation re0uired to the integration procedure or criteria "ny change to the product configuration 2spare parts, new release3 Evaluation procedure or criteria deviations
S/b'ra#t"#e$
SP 3*4
Pa#?a!e a + %e&"ver t-e Pro+/#t or Pro+/#t Com'o e t
!ac4age the assem'led product or product component and deli)er it to the customer.
"efer to the 8alidation process area for more information about performing validation% "efer to the 8erification process area for more information about performing verification% T$e pac2a+in+ re/uirements for some products can )e addressed in t$eir specifications and verification criteria. T$is $andlin+ of re/uirements is especiall* important '$en items are stored and transported )* t$e customer. In suc$ cases, t$ere can )e a spectrum of environmental and stress conditions specified for t$e pac2a+e. In ot$er circumstances, factors suc$ as t$e follo'in+ can )ecome important% Econom* and ease of transportation (e.+., containeri-ation, 0ccounta)ilit* (e.+., s$rin2 'rappin+, Ease and safet* of unpac2in+ (e.+., s$arp ed+es, stren+t$ of )indin+ met$ods, c$ildproofin+, environmental friendliness of pac2in+ material, 'ei+$t,
T$e ad4ustment re/uired to fit product components to+et$er in t$e factor* could )e different from t$e one re/uired to fit product components to+et$er
281
'$en installed on t$e operational site. In t$at case, t$e product;s lo+)oo2 for t$e customer s$ould )e used to record suc$ specific parameters.
1. ". 1.
Pac2a+ed product or product components Deliver* documentation !evie' t$e re/uirements, desi+n, product, verification results, and documentation to ensure t$at issues affectin+ t$e pac2a+in+ and deliver* of t$e product are identified and resolved. :se effective met$ods to pac2a+e and deliver t$e assem)led product. Examples of software pac1aging and delivery methods include the following:
$agnetic tape %is1ettes /ardcopy documents Compact dis1s Other electronic distribution such as the &nternet
S/b'ra#t"#e$
".
3.
atisf* t$e applica)le re/uirements and standards for pac2a+in+ and deliverin+ t$e product. Examples of re0uirements and standards include ones for safety, the environment, security, transportability, and disposal. Examples of re0uirements and standards for pac1aging and delivering software include the following:
(ype of storage and delivery media Custodians of the master and bac1up copies #e0uired documentation Copyrights -icense provisions *ecurity of the software
8.
Prepare t$e operational site for installation of t$e product. 'reparing the operational site can be the responsibility of the customer or end users.
9. G.
Deliver t$e product and related documentation and confirm receipt. Install t$e product at t$e operational site and confirm correct operation. &nstalling the product can be the responsibility of the customer or the end users. &n some circumstances, little may need to be done to confirm correct operation. &n other circumstances, final verification of the integrated product occurs at the operational site.
282
283
PRO0$!( #O*I(ORI*/ A*D !O*(RO+

Purpose
T$e purpose of Pro4ect Monitorin+ and Control (PMC, is to provide an understandin+ of t$e pro4ect;s pro+ress so t$at appropriate corrective actions can )e ta2en '$en t$e pro4ect;s performance deviates si+nificantl* from t$e plan.
Introductor" *otes
0 pro4ect;s documented plan is t$e )asis for monitorin+ activities, communicatin+ status, and ta2in+ corrective action. Pro+ress is primaril* determined )* comparin+ actual 'or2 product and tas2 attri)utes, effort, cost, and sc$edule to t$e plan at prescri)ed milestones or control levels in t$e pro4ect sc$edule or 6. . 0ppropriate visi)ilit* of pro+ress ena)les timel* corrective action to )e ta2en '$en performance deviates si+nificantl* from t$e plan. 0 deviation is si+nificant if, '$en left unresolved, it precludes t$e pro4ect from meetin+ its o)4ectives. T$e term Lpro4ect planM is used t$rou+$out t$is process area to refer to t$e overall plan for controllin+ t$e pro4ect. 6$en actual status deviates si+nificantl* from e5pected values, corrective actions are ta2en as appropriate. T$ese actions can re/uire replannin+, '$ic$ can include revisin+ t$e ori+inal plan, esta)lis$in+ ne' a+reements, or includin+ additional miti+ation activities in t$e current plan.
"efer to the Measurement and $nalysis process area for more information about providing measurement results% "efer to the Pro.ect Planning process area for more information about establishing and maintaining plans that define pro.ect activities%
284
Pro0e#t Mo "tor" ! a + Co tro& :PMC;

3 1 Monitor t$e Pro4ect 0+ainst t$e Plan P 1.1 P 1." P 1.3 P 1.8 P 1.9 P 1.G P 1.= P ".1 P "." P ".3 Monitor Pro4ect Plannin+ Parameters Monitor Commitments Monitor Pro4ect !is2s Monitor Data Mana+ement Monitor ta2e$older Involvement Conduct Pro+ress !evie's Conduct Milestone !evie's 0nal*-e Issues Ta2e Corrective 0ction Mana+e Corrective 0ctions
3 " Mana+e Corrective 0ction to Closure
)pecific Practices b" /oal S7 1 Mo "tor t-e Pro0e#t A!a" $t t-e P&a
"ctual pro/ect progress and performance are monitored against the pro/ect plan.
SP 1*1 Mo "tor Pro0e#t P&a " ! Parameter$
Monitor actual )alues of pro/ect planning parameters against the pro/ect plan.
Pro4ect plannin+ parameters constitute t*pical indicators of pro4ect pro+ress and performance and include attri)utes of 'or2 products and tas2s, costs, effort, and sc$edule. 0ttri)utes of t$e 'or2 products and tas2s include si-e, comple5it*, service level, availa)ilit*, 'ei+$t, form, fit, and function. T$e fre/uenc* of monitorin+ parameters s$ould )e considered. Monitorin+ t*picall* involves measurin+ actual values of pro4ect plannin+ parameters, comparin+ actual values to estimates in t$e plan, and identif*in+ si+nificant deviations. !ecordin+ actual values of pro4ect plannin+ parameters includes recordin+ associated conte5tual information to $elp understand measures. 0n anal*sis of t$e impact t$at si+nificant deviations $ave on determinin+ t$e corrective actions to ta2e is $andled in specific +oal " and its specific practices in t$is process area.
1. ". 3. 1.
!ecords of pro4ect performance !ecords of si+nificant deviations Cost performance reports Monitor pro+ress a+ainst t$e sc$edule.
S/b'ra#t"#e$
285
'rogress monitoring typically includes the following:

'eriodically measuring the actual completion of activities and milestones Comparing actual completion of activities and milestones against the project plan schedule &dentifying significant deviations from the project plan schedule estimates
".
Monitor t$e pro4ect;s costs and e5pended effort. Effort and cost monitoring typically includes the following:
'eriodically measuring the actual effort and costs expended and staff assigned Comparing actual effort, costs, staffing, and training to the project plan budget and estimates &dentifying significant deviations from the project plan budget and estimates
3.
Monitor t$e attri)utes of 'or2 products and tas2s. "efer to the Measurement and $nalysis process area for more information about developing and sustaining a measurement capability used to support management information needs% "efer to the Pro.ect Planning process area for more information about establishing estimates of wor1 product and tas1 attributes% $onitoring the attributes of wor1 products and tas1s typically includes the following:
'eriodically measuring the actual attributes of wor1 products and tas1s, such as si6e, complexity, or service levels 2and changes to these attributes3 Comparing the actual attributes of wor1 products and tas1s 2and changes to these attributes3 to the project plan estimates &dentifying significant deviations from the project plan estimates
8.
Monitor resources provided and used. "efer to the Pro.ect Planning process area for more information about planning the pro.ect3s resources% Examples of resources include the following:
'hysical facilities Computers, peripherals, and software 7etwor1s *ecurity environment 'roject staff 'rocesses
9.
Monitor t$e 2no'led+e and s2ills of pro4ect staff. "efer to the Pro.ect Planning process area for more information about planning needed 1nowledge and s1ills%
286
$onitoring the 1nowledge and s1ills of project staff typically includes the following:
'eriodically measuring the ac0uisition of 1nowledge and s1ills by project staff Comparing the actual training obtained to that documented in the project plan &dentifying significant deviations from the project plan estimates
G.
SP 1*2
Document si+nificant deviations in pro4ect plannin+ parameters.
Mo "tor Comm"tme t$
Monitor commitments against those identified in the pro/ect plan.

1. 1. ". 3.
SP 1*3
!ecords of commitment revie's !e+ularl* revie' commitments ()ot$ e5ternal and internal,. Identif* commitments t$at $ave not )een satisfied or are at si+nificant ris2 of not )ein+ satisfied. Document t$e results of commitment revie's.
S/b'ra#t"#e$
Mo "tor Pro0e#t R"$?$
Monitor ris4s against those identified in the pro/ect plan.

"efer to the Pro.ect Planning process area for more information about identifying pro.ect ris1s% "efer to the "is1 Management process area for more information about identifying potential problems before they occur so that ris1 handling activities can be planned and invo1ed as needed across the life of the product or pro.ect to mitigate adverse impacts on achieving ob.ectives%
1. 1. ".
!ecords of pro4ect ris2 monitorin+ Periodicall* revie' t$e documentation of ris2s in t$e conte5t of t$e pro4ect;s current status and circumstances. !evise t$e documentation of ris2s as additional information )ecomes availa)le. "s projects progress 2especially projects of long duration or continuous operation3, new ris1s arise. &t is important to identify and analy6e these new ris1s. For example, software, e0uipment, and tools in use can become obsolete8 or 1ey staff can gradually lose s1ills in areas of particular long5term importance to the project and organi6ation.
S/b'ra#t"#e$
3.
Communicate t$e ris2 status to relevant sta2e$olders. Examples of ris1 status include the following:
" change in the probability that the ris1 occurs " change in ris1 priority
288
SP 1*4
Mo "tor %ata Ma a!eme t
Monitor the management of pro/ect data against the pro/ect plan.

"efer to the Plan ata Management specific practice in the Pro.ect Planning process area for more information about identifying types of data to be managed and how to plan for their management% Data mana+ement activities s$ould )e monitored to ensure t$at data mana+ement re/uirements are )ein+ satisfied. Dependin+ on t$e results of monitorin+ and c$an+es in pro4ect re/uirements, situation, or status, it ma* )e necessar* to re-plan t$e pro4ect;s data mana+ement activities.
1. 1. ".
!ecords of data mana+ement Periodicall* revie' data mana+ement activities a+ainst t$eir description in t$e pro4ect plan. Identif* and document si+nificant issues and t$eir impacts. "n example of a significant issue is when sta1eholders do not have the access to project data they need to fulfill their roles as relevant sta1eholders.
S/b'ra#t"#e$
3.
SP 1*5
Document results of data mana+ement activit* revie's.
Mo "tor Sta?e-o&+er I vo&veme t
Monitor sta4eholder in)ol)ement against the pro/ect plan.

"efer to the Plan Sta1eholder Involvement specific practice in the Pro.ect Planning process area for more information about identifying relevant sta1eholders and planning appropriate involvement with them% ta2e$older involvement s$ould )e monitored to ensure t$at appropriate interactions occur. Dependin+ on t$e results of monitorin+ and c$an+es in pro4ect re/uirements, situation, or status, it ma* )e necessar* to re-plan sta2e$older involvement. &n "gile environments, the sustained involvement of customer and potential end users in the project9s product development activities can be crucial to project success8 thus, customer and end5user involvement in project activities should be monitored. 2*ee @&nterpreting C$$& 4hen :sing "gile "pproachesA in 'art &.3
1. 1. ". 3.
!ecords of sta2e$older involvement Periodicall* revie' t$e status of sta2e$older involvement. Identif* and document si+nificant issues and t$eir impacts. Document t$e results of sta2e$older involvement status revie's.
S/b'ra#t"#e$
28<
SP 1*6
Co +/#t Pro!re$$ Rev"ew$
!eriodically re)ie3 the pro/ect7s progress* performance* and issues.

0 Lpro4ect;s pro+ressM is t$e pro4ect;s status as vie'ed at a particular time '$en t$e pro4ect activities performed so far and t$eir results and impacts are revie'ed 'it$ relevant sta2e$olders (especiall* pro4ect representatives and pro4ect mana+ement, to determine '$et$er t$ere are si+nificant issues or performance s$ortfalls to )e addressed. Pro+ress revie's are pro4ect revie's to 2eep relevant sta2e$olders informed. T$ese pro4ect revie's can )e informal and ma* not )e specified e5plicitl* in pro4ect plans.
1. 1.
Documented pro4ect revie' results !e+ularl* communicate status on assi+ned activities and 'or2 products to relevant sta2e$olders. $anagers, staff, customers, end users, suppliers, and other relevant sta1eholders are included in reviews as appropriate.
S/b'ra#t"#e$
".
!evie' t$e results of collectin+ and anal*-in+ measures for controllin+ t$e pro4ect. (he measurements reviewed can include measures of customer satisfaction. "efer to the Measurement and $nalysis process area for more information about aligning measurement and analysis activities and providing measurement results%
3. 8.
Identif* and document si+nificant issues and deviations from t$e plan. Document c$an+e re/uests and pro)lems identified in 'or2 products and processes. "efer to the Configuration Management process area for more information about trac1ing and controlling changes%
9. G.
SP 1*8
Document t$e results of revie's. Trac2 c$an+e re/uests and pro)lem reports to closure.
Co +/#t M"&e$to e Rev"ew$
#e)ie3 the pro/ect7s accomplishments and results at selected pro/ect milestones.

"efer to the Establish the *udget and Schedule specific practice in the Pro.ect Planning process area for more information about identifying ma.or milestones% Milestones are pre-planned events or points in time at '$ic$ a t$orou+$ revie' of status is conducted to understand $o' 'ell sta2e$older re/uirements are )ein+ met. (If t$e pro4ect includes a developmental
283
milestone, t$en t$e revie' is conducted to ensure t$at t$e assumptions and re/uirements associated 'it$ t$at milestone are )ein+ met., Milestones can )e associated 'it$ t$e overall pro4ect or a particular service t*pe or instance. Milestones can t$us )e event )ased or calendar )ased. Milestone revie's are planned durin+ pro4ect plannin+ and are t*picall* formal revie's. Pro+ress revie's and milestone revie's need not )e $eld separatel*. 0 sin+le revie' can address t$e intent of )ot$. 1or e5ample, a sin+le preplanned revie' can evaluate pro+ress, issues, and performance up t$rou+$ a planned time period (or milestone, a+ainst t$e plan;s e5pectations. Dependin+ on t$e pro4ect, Lpro4ect startupM and Lpro4ect close-outM could )e p$ases covered )* milestone revie's.
1. 1.
Documented milestone revie' results Conduct milestone revie's 'it$ relevant sta2e$olders at meanin+ful points in t$e pro4ect;s sc$edule, suc$ as t$e completion of selected p$ases. $anagers, staff, customers, end users, suppliers, and other relevant sta1eholders are included in milestone reviews as appropriate.
S/b'ra#t"#e$
". 3. 8. 9.
S7 2
!evie' commitments, t$e plan, status, and ris2s of t$e pro4ect. Identif* and document si+nificant issues and t$eir impacts. Document results of t$e revie', action items, and decisions. Trac2 action items to closure.
Ma a!e Corre#t"ve A#t"o to C&o$/re
Correcti)e actions are managed to closure 3hen the pro/ect7s performance or results de)iate significantly from the plan.
SP 2*1 A a&1Ae I$$/e$
Collect and analy5e issues and determine correcti)e actions to address them.
1. 1.
Aist of issues re/uirin+ corrective actions 3at$er issues for anal*sis. &ssues are collected from reviews and the execution of other processes.
S/b'ra#t"#e$
2<0
Examples of issues to be gathered include the following:

&ssues discovered when performing technical reviews, verification, and validation *ignificant deviations in project planning parameters from estimates in the project plan Commitments 2either internal or external3 that have not been satisfied *ignificant changes in ris1 status %ata access, collection, privacy, or security issues *ta1eholder representation or involvement issues 'roduct, tool, or environment transition assumptions 2or other customer or supplier commitments3 that have not been achieved
".
0nal*-e issues to determine t$e need for corrective action. "efer to the Establish the *udget and Schedule specific practice in the Pro.ect Planning process area for more information about corrective action criteria% Corrective action is re0uired when the issue, if left unresolved, may prevent the project from meeting its objectives.
SP 2*2
Ta?e Corre#t"ve A#t"o
Ta4e correcti)e action on identified issues.

1. 1.
Corrective action plans Determine and document t$e appropriate actions needed to address identified issues. "efer to the Pro.ect Planning process area for more information about developing a pro.ect plan% Examples of potential actions include the following:
$odifying the statement of wor1 $odifying re0uirements #evising estimates and plans #enegotiating commitments "dding resources Changing processes #evising project ris1s
S/b'ra#t"#e$
". 3.
SP 2*3
!evie' and +et a+reement 'it$ relevant sta2e$olders on t$e actions to )e ta2en. <e+otiate c$an+es to internal and e5ternal commitments.
Ma a!e Corre#t"ve A#t"o $
Manage correcti)e actions to closure.
2<1
1. 1. ". 3.
Corrective action results Monitor corrective actions for t$eir completion. 0nal*-e results of corrective actions to determine t$e effectiveness of t$e corrective actions. Determine and document appropriate actions to correct deviations from planned results from performin+ corrective actions. -essons learned as a result of ta1ing corrective action can be inputs to planning and ris1 management processes.
S/b'ra#t"#e$
2<2
2<3
PRO0$!( P+A**I*/
Purpose
T$e purpose of Pro4ect Plannin+ (PP, is to esta)lis$ and maintain plans t$at define pro4ect activities.
Introductor" *otes
7ne of t$e 2e*s to effectivel* mana+in+ a pro4ect is pro4ect plannin+. T$e Pro4ect Plannin+ process area involves t$e follo'in+ activities% Developin+ t$e pro4ect plan Interactin+ 'it$ relevant sta2e$olders appropriatel* 3ettin+ commitment to t$e plan Maintainin+ t$e plan
Plannin+ includes estimatin+ t$e attri)utes of 'or2 products and tas2s, determinin+ t$e resources needed, ne+otiatin+ commitments, producin+ a sc$edule, and identif*in+ and anal*-in+ pro4ect ris2s. Iteratin+ t$rou+$ t$ese activities ma* )e necessar* to esta)lis$ t$e pro4ect plan. T$e pro4ect plan provides t$e )asis for performin+ and controllin+ pro4ect activities t$at address commitments 'it$ t$e pro4ect;s customer. ( ee t$e definition of Lpro4ectM in t$e +lossar*., T$e pro4ect plan is usuall* revised as t$e pro4ect pro+resses to address c$an+es in re/uirements and commitments, inaccurate estimates, corrective actions, and process c$an+es. pecific practices descri)in+ )ot$ plannin+ and replannin+ are contained in t$is process area. T$e term Lpro4ect planM is used t$rou+$out t$is process area to refer to t$e overall plan for controllin+ t$e pro4ect. T$e pro4ect plan can )e a standalone document or )e distri)uted across multiple documents. In eit$er case, a co$erent picture of '$o does '$at s$ould )e included. Ai2e'ise, monitorin+ and control can )e centrali-ed or distri)uted, as lon+ as at t$e pro4ect level a co$erent picture of pro4ect status can )e maintained.
2<4
Pro0e#t P&a
" ! :PP;
For product lines, there are multiple sets of wor1 activities that would benefit from the practices of this process area. (hese wor1 activities include the creation and maintenance of the core assets, developing products to be built using the core assets, and orchestrating the overall product line effort to support and coordinate the operations of the inter5related wor1 groups and their activities. &n "gile environments, performing incremental development involves planning, monitoring, controlling, and re5planning more fre0uently than in more traditional development environments. 4hile a high5level plan for the overall project or wor1 effort is typically established, teams will estimate, plan, and carry out the actual wor1 an increment or iteration at a time. (eams typically do not forecast beyond what is 1nown about the project or iteration, except for anticipating ris1s, major events, and large5scale influences and constraints. Estimates reflect iteration and team specific factors that influence the time, effort, resources, and ris1s to accomplish the iteration. (eams plan, monitor, and adjust plans during each iteration as often as it ta1es 2e.g., daily3. Commitments to plans are demonstrated when tas1s are assigned and accepted during iteration planning, user stories are elaborated or estimated, and iterations are populated with tas1s from a maintained bac1log of wor1. 2*ee @&nterpreting C$$& 4hen :sing "gile "pproachesA in 'art &.3
"efer to the "e,uirements evelopment process area for more information about eliciting2 analy-ing2 and establishing customer2 product2 and product component re,uirements% "efer to the Technical Solution process area for more information about selecting2 designing2 and implementing solutions to re,uirements% "efer to the Measurement and $nalysis process area for more information about specifying measures% "efer to the "e,uirements Management process area for more information about managing re,uirements% "efer to the "is1 Management process area for more information about identifying and analy-ing ris1s and mitigating ris1s%
Pro0e#t P&a
" ! :PP;
2<5

3 1 Esta)lis$ Estimates P 1.1 P 1." P 1.3 P 1.8 P ".1 P "." P ".3 P ".8 P ".9 P ".G P ".= P 3.1 P 3." P 3.3 Estimate t$e cope of t$e Pro4ect Esta)lis$ Estimates of 6or2 Product and Tas2 0ttri)utes Define Pro4ect Aifec*cle P$ases Estimate Effort and Cost Esta)lis$ t$e .ud+et and c$edule Identif* Pro4ect !is2s Plan Data Mana+ement Plan t$e Pro4ect;s !esources Plan <eeded Nno'led+e and 2ills Plan ta2e$older Involvement Esta)lis$ t$e Pro4ect Plan !evie' Plans T$at 0ffect t$e Pro4ect !econcile 6or2 and !esource Aevels 7)tain Plan Commitment
3 " Develop a Pro4ect Plan
3 3 7)tain Commitment to t$e Plan
)pecific Practices b" /oal S7 1 E$tab&"$- E$t"mate$
+stimates of pro/ect planning parameters are esta'lished and maintained.

Pro4ect plannin+ parameters include all information needed )* t$e pro4ect to perform necessar* plannin+, or+ani-in+, staffin+, directin+, coordinatin+, reportin+, and )ud+etin+. Estimates of plannin+ parameters s$ould $ave a sound )asis to instill confidence t$at plans )ased on t$ese estimates are capa)le of supportin+ pro4ect o)4ectives. 1actors to consider '$en estimatin+ t$ese parameters include pro4ect re/uirements, includin+ product re/uirements, re/uirements imposed )* t$e or+ani-ation, re/uirements imposed )* t$e customer, and ot$er re/uirements t$at affect t$e pro4ect Documentation of t$e estimatin+ rationale and supportin+ data is needed for sta2e$older revie' and commitment to t$e plan and for maintenance of t$e plan as t$e pro4ect pro+resses.
SP 1*1 E$t"mate t-e S#o'e of t-e Pro0e#t
+sta'lish a top:le)el 3or4 'rea4do3n structure ;<. = to estimate the scope of the pro/ect.
T$e 6. evolves 'it$ t$e pro4ect. 0 top-level 6. can serve to structure initial estimatin+. T$e development of a 6. divides t$e overall pro4ect into an interconnected set of mana+ea)le components. T*picall*, t$e 6. is a product, 'or2 product, or tas2 oriented structure t$at provides a sc$eme for identif*in+ and or+ani-in+ t$e lo+ical units of 'or2 to )e mana+ed, '$ic$ are called L'or2 pac2a+es.M T$e 6. provides
2<6
Pro0e#t P&a
" ! :PP;
a reference and or+ani-ational mec$anism for assi+nin+ effort, sc$edule, and responsi)ilit* and is used as t$e underl*in+ frame'or2 to plan, or+ani-e, and control t$e 'or2 done on t$e pro4ect. ome pro4ects use t$e term Lcontract 6. M to refer to t$e portion of t$e 6. placed under contract (possi)l* t$e entire 6. ,. <ot all pro4ects $ave a contract 6. (e.+., internall* funded development,.
1. ". 3. 1.
Tas2 descriptions 6or2 pac2a+e descriptions 6. Develop a 6. . (he 4;* provides a scheme for organi6ing the project9s wor1. (he 4;* should permit the identification of the following items:
#is1s and their mitigation tas1s (as1s for deliverables and supporting activities (as1s for s1ill and 1nowledge ac0uisition (as1s for the development of needed support plans, such as configuration management, 0uality assurance, and verification plans (as1s for the integration and management of nondevelopmental items
S/b'ra#t"#e$
".
Define t$e 'or2 pac2a+es in sufficient detail so t$at estimates of pro4ect tas2s, responsi)ilities, and sc$edule can )e specified. (he top5level 4;* is intended to help gauge the project wor1 effort for tas1s and organi6ational roles and responsibilities. (he amount of detail in the 4;* at this level helps in developing realistic schedules, thereby minimi6ing the need for management reserve.
3.
Identif* products and product components to )e e5ternall* ac/uired. "efer to the Supplier $greement Management process area for more information about managing the ac,uisition of products and services from suppliers%
8.
SP 1*2
Identif* 'or2 products to )e reused.
E$tab&"$- E$t"mate$ of >or? Pro+/#t a + Ta$? Attr"b/te$
+sta'lish and maintain estimates of 3or4 product and tas4 attri'utes.

i-e is t$e primar* input to man* models used to estimate effort, cost, and sc$edule. Models can also )e )ased on ot$er attri)utes suc$ as service level, connectivit*, comple5it*, availa)ilit*, and structure.
Pro0e#t P&a
" ! :PP;
2<8
Examples of attributes to estimate include the following: 7umber and complexity of re0uirements 7umber and complexity of interfaces ,olume of data 7umber of functions Function points *ource lines of code 7umber of classes and objects 7umber of database tables 7umber of fields in data tables "rchitecture elements Experience of project participants "mount of code to be reused versus created (eam velocity and complexity 7umber of pages 7umber of inputs and outputs 7umber of technical ris1 items 7umber of database tables 7umber of fields in data tables "rchitecture elements Experience of project participants "mount of code to be reused versus created 7umber of logic gates for integrated circuits 7umber of parts 2e.g., printed circuit boards, components, mechanical parts3 'hysical constraints 2e.g., weight, volume3 eographic dispersal of project members 'roximity of customers, end users, and suppliers /ow agreeable or difficult the customer is )uality and @cleanlinessA of the existing code base
T$e estimates s$ould )e consistent 'it$ pro4ect re/uirements to determine t$e pro4ect;s effort, cost, and sc$edule. 0 relative level of difficult* or comple5it* s$ould )e assi+ned for eac$ si-e attri)ute.
1. ". 3. 8.
i-e and comple5it* of tas2s and 'or2 products Estimatin+ models 0ttri)ute estimates Tec$nical approac$
2<<
Pro0e#t P&a
" ! :PP;
S/b'ra#t"#e$
1.
Determine t$e tec$nical approac$ for t$e pro4ect. (he technical approach defines a top5level strategy for development of the product. &t includes decisions on architectural features, such as distributed or clientEserver8 state5 of5the5art or established technologies to be applied, such as robotics, composite materials, or artificial intelligence8 and the functionality and 0uality attributes expected in the final products, such as safety, security, and ergonomics.
".
:se appropriate met$ods to determine t$e attri)utes of t$e 'or2 products and tas2s to )e used to estimate resource re/uirements. $ethods for determining si6e and complexity should be based on validated models or historical data. (he methods for determining attributes evolve as the understanding of the relationship of product characteristics to attributes increases.
3.
Estimate t$e attri)utes of 'or2 products and tas2s. Examples of wor1 products for which si6e estimates are made include the following:
%eliverable and nondeliverable wor1 products %ocuments and files Operational and support hardware, firmware, and software
SP 1*3
%ef" e Pro0e#t L"fe#1#&e P-a$e$
Define pro/ect lifecycle phases on 3hich to scope the planning effort.

T$e determination of a pro4ect;s lifec*cle p$ases provides for planned periods of evaluation and decision ma2in+. T$ese periods are normall* defined to support lo+ical decision points at '$ic$ t$e appropriateness of continued reliance on t$e pro4ect plan and strate+* is determined and si+nificant commitments are made concernin+ resources. uc$ points provide planned events at '$ic$ pro4ect course corrections and determinations of future scope and cost can )e made. :nderstandin+ t$e pro4ect lifec*cle is crucial in determinin+ t$e scope of t$e plannin+ effort and t$e timin+ of initial plannin+, as 'ell as t$e timin+ and criteria (critical milestones, for replannin+. T$e pro4ect lifec*cle p$ases need to )e defined dependin+ on t$e scope of re/uirements, t$e estimates for pro4ect resources, and t$e nature of t$e pro4ect. Aar+er pro4ects can contain multiple p$ases, suc$ as concept e5ploration, development, production, operations, and disposal. 6it$in t$ese p$ases, su)p$ases ma* )e needed. 0 development p$ase can include su)p$ases suc$ as re/uirements anal*sis, desi+n, fa)rication, inte+ration, and verification. T$e determination of pro4ect p$ases t*picall* includes selection and refinement of one or more development models to address interdependencies and appropriate se/uencin+ of t$e activities in t$e p$ases.
Pro0e#t P&a
" ! :PP;
2<3
Dependin+ on t$e strate+* for development, t$ere can )e intermediate p$ases for t$e creation of protot*pes, increments of capa)ilit*, or spiral model c*cles. In addition, e5plicit p$ases for Lpro4ect startupM and Lpro4ect close-outM can )e included.
1.
SP 1*4
Pro4ect lifec*cle p$ases
E$t"mate Effort a + Co$t
+stimate the pro/ect7s effort and cost for 3or4 products and tas4s 'ased on estimation rationale.
Estimates of effort and cost are +enerall* )ased on results of anal*sis usin+ models or $istorical data applied to si-e, activities, and ot$er plannin+ parameters. Confidence in t$ese estimates is )ased on rationale for t$e selected model and t$e nature of t$e data. T$ere can )e occasions '$en availa)le $istorical data do not appl*, suc$ as '$en efforts are unprecedented or '$en t$e t*pe of tas2 does not fit availa)le models. 1or e5ample, an effort can )e considered unprecedented if t$e or+ani-ation $as no e5perience 'it$ suc$ a product or tas2. :nprecedented efforts are more ris2*, re/uire more researc$ to develop reasona)le )ases of estimate, and re/uire more mana+ement reserve. T$e uni/ueness of t$e pro4ect s$ould )e documented '$en usin+ t$ese models to ensure a common understandin+ of an* assumptions made in t$e initial plannin+ p$ases.
1. ". 3. 1.
Estimation rationale Pro4ect effort estimates Pro4ect cost estimates Collect models or $istorical data to )e used to transform t$e attri)utes of 'or2 products and tas2s into estimates of la)or $ours and costs. $any parametric models have been developed to help estimate cost and schedule. (he use of these models as the sole source of estimation is not recommended because these models are based on historical project data that may or may not be pertinent to the project. $ultiple models and methods can be used to ensure a high level of confidence in the estimate. /istorical data should include the cost, effort, and schedule data from previously executed projects and appropriate scaling data to account for differing si6es and complexity.
S/b'ra#t"#e$
".
Include supportin+ infrastructure needs '$en estimatin+ effort and cost. (he supporting infrastructure includes resources needed from a development and sustainment perspective for the product.
230
Pro0e#t P&a
" ! :PP;
Consider the infrastructure resource needs in the development environment, the test environment, the production environment, the operational environment, or any appropriate combination of these environments when estimating effort and cost. Examples of infrastructure resources include the following:
Critical computer resources 2e.g., memory, dis1 and networ1 capacity, peripherals, communication channels, the capacities of these resources3 Engineering environments and tools 2e.g., tools for prototyping, testing, integration, assembly, computer5aided design IC"%J, simulation3 Facilities, machinery, and e0uipment 2e.g., test benches, recording devices3
3.
Estimate effort and cost usin+ models, $istorical data, or a com)ination of )ot$. Examples of effort and cost inputs used for estimating typically include the following:
Estimates provided by an expert or group of experts 2e.g., %elphi method, Extreme 'rogramming9s 'lanning ame3 #is1s, including the extent to which the effort is unprecedented Critical competencies and roles needed to perform the wor1 (ravel 4;* *elected project lifecycle model and processes -ifecycle cost estimates *1ill levels of managers and staff needed to perform the wor1 +nowledge, s1ill, and training needs %irect labor and overhead *ervice agreements for call centers and warranty wor1 -evel of security re0uired for tas1s, wor1 products, hardware, software, staff, and wor1 environment Facilities needed 2e.g., office and meeting space and wor1stations3 'roduct and product component re0uirements *i6e estimates of wor1 products, tas1s, and anticipated changes Cost of externally ac0uired products Capability of manufacturing processes Engineering facilities needed Capability of tools provided in engineering environment (echnical approach
Pro0e#t P&a
" ! :PP;
231
S7 2
%eve&o' a Pro0e#t P&a
" pro/ect plan is esta'lished and maintained as the 'asis for managing the pro/ect.
0 pro4ect plan is a formal, approved document used to mana+e and control t$e e5ecution of t$e pro4ect. It is )ased on pro4ect re/uirements and esta)lis$ed estimates. T$e pro4ect plan s$ould consider all p$ases of t$e pro4ect lifec*cle. Pro4ect plannin+ s$ould ensure t$at all plans affectin+ t$e pro4ect are consistent 'it$ t$e overall pro4ect plan.
SP 2*1 E$tab&"$- t-e 9/+!et a + S#-e+/&e
+sta'lish and maintain the pro/ect7s 'udget and schedule.

T$e pro4ect;s )ud+et and sc$edule are )ased on developed estimates and ensure t$at )ud+et allocation, tas2 comple5it*, and tas2 dependencies are appropriatel* addressed. Event driven, resource-limited sc$edules $ave proven to )e effective in dealin+ 'it$ pro4ect ris2. Identif*in+ accomplis$ments to )e demonstrated )efore initiation of an event provides some fle5i)ilit* in t$e timin+ of t$e event, a common understandin+ of '$at is e5pected, a )etter vision of t$e state of t$e pro4ect, and a more accurate status of t$e pro4ect;s tas2s.
1. ". 3. 1.
Pro4ect sc$edules c$edule dependencies Pro4ect )ud+et Identif* ma4or milestones. $ilestones are pre5planned events or points in time at which a thorough review of status is conducted to understand how well sta1eholder re0uirements are being met. 2&f the project includes a developmental milestone, then the review is conducted to ensure that the assumptions and re0uirements associated with that milestone are being met.3 $ilestones can be associated with the overall project or a particular service type or instance. $ilestones can thus be event based or calendar based. &f calendar based, once agreed, milestone dates are often difficult to change.
S/b'ra#t"#e$
".
Identif* sc$edule assumptions. 4hen schedules are initially developed, it is common to ma1e assumptions about the duration of certain activities. (hese assumptions are fre0uently made on items for which little if any estimation data are available. &dentifying these assumptions provides insight into the level of confidence 2i.e., uncertainties3 in the overall schedule.
3.
Identif* constraints. Factors that limit the flexibility of management options should be identified as early as possible. (he examination of the attributes of wor1 products and tas1s often bring
232
Pro0e#t P&a
" ! :PP;
these issues to the surface. *uch attributes can include tas1 duration, resources, inputs, and outputs. 8. Identif* tas2 dependencies. Fre0uently, the tas1s for a project or service can be accomplished in some ordered se0uence that minimi6es the duration. (his se0uencing involves the identification of predecessor and successor tas1s to determine optimal ordering. Examples of tools and inputs that can help determine optimal ordering of tas1 activities include the following:
Critical 'ath $ethod 2C'$3 'rogram Evaluation and #eview (echni0ue 2'E#(3 #esource limited scheduling Customer priorities $ar1etable features End5user value
9.
Esta)lis$ and maintain t$e )ud+et and sc$edule. Establishing and maintaining the project9s budget and schedule typically includes the following:
%efining the committed or expected availability of resources and facilities %etermining the time phasing of activities %etermining a brea1out of subordinate schedules %efining dependencies among activities 2predecessor or successor relationships3 %efining schedule activities and milestones to support project monitoring and control &dentifying milestones, releases, or increments for the delivery of products to the customer %efining activities of appropriate duration %efining milestones of appropriate time separation %efining a management reserve based on the confidence level in meeting the schedule and budget :sing appropriate historical data to verify the schedule %efining incremental funding re0uirements %ocumenting project assumptions and rationale
G.
Esta)lis$ corrective action criteria. Criteria are established for determining what constitutes a significant deviation from the project plan. " basis for gauging issues and problems is necessary to determine when corrective action should be ta1en. Corrective actions can lead to replanning, which may include revising the original plan, establishing new agreements, or including mitigation activities in the current plan. (he project plan defines when 2e.g., under what circumstances, with what fre0uency3 the criteria will be applied and by whom.
Pro0e#t P&a
" ! :PP;
233
SP 2*2
I+e t"f1 Pro0e#t R"$?$
Identify and analy5e pro/ect ris4s.

"efer to the Monitor Pro.ect "is1s specific practice in the Pro.ect Monitoring and Control process area for more information about ris1 monitoring activities% "efer to the "is1 Management process area for more information about identifying potential problems before they occur so that ris1 handling activities can be planned and invo1ed as needed across the life of the product or pro.ect to mitigate adverse impacts on achieving ob.ectives% !is2s are identified or discovered and anal*-ed to support pro4ect plannin+. T$is specific practice s$ould )e e5tended to all plans t$at affect t$e pro4ect to ensure t$at appropriate interfacin+ is ta2in+ place amon+ all relevant sta2e$olders on identified ris2s. 'roject planning ris1 identification and analysis typically include the following: &dentifying ris1s "naly6ing ris1s to determine the impact, probability of occurrence, and time frame in which problems are li1ely to occur 'rioriti6ing ris1s
1. ". 3. 1.
Identified ris2s !is2 impacts and pro)a)ilit* of occurrence !is2 priorities Identif* ris2s. (he identification of ris1s involves the identification of potential issues, ha6ards, threats, vulnerabilities, and so on that could negatively affect wor1 efforts and plans. #is1s should be identified and described understandably before they can be analy6ed and managed properly. 4hen identifying ris1s, it is a good idea to use a standard method for defining ris1s. #is1 identification and analysis tools can be used to help identify possible problems.
S/b'ra#t"#e$
234
Pro0e#t P&a
" ! :PP;
Examples of ris1 identification and analysis tools include the following:

#is1 taxonomies #is1 assessments Chec1lists *tructured interviews ;rainstorming 'rocess, project, and product performance models Cost models 7etwor1 analysis )uality factor analysis
". 3. 8.
Document ris2s. !evie' and o)tain a+reement 'it$ relevant sta2e$olders on t$e completeness and correctness of documented ris2s. !evise ris2s as appropriate. Examples of when identified ris1s may need to be revised include the following:
4hen new ris1s are identified 4hen ris1s become problems 4hen ris1s are retired 4hen project circumstances change significantly
SP 2*3
P&a %ata Ma a!eme t
!lan for the management of pro/ect data.

Data are forms of documentation re/uired to support a pro4ect in all of its areas (e.+., administration, en+ineerin+, confi+uration mana+ement, finance, lo+istics, /ualit*, safet*, manufacturin+, procurement,. T$e data can ta2e an* form (e.+., reports, manuals, note)oo2s, c$arts, dra'in+s, specifications, files, correspondence,. T$e data can e5ist in an* medium (e.+., printed or dra'n on various materials, p$oto+rap$s, electronic, multimedia,. Data can )e delivera)le (e.+., items identified )* a pro4ect;s contract data re/uirements, or data can )e nondelivera)le (e.+., informal data, trade studies, anal*ses, internal meetin+ minutes, internal desi+n revie' documentation, lessons learned, action items,. Distri)ution can ta2e man* forms, includin+ electronic transmission. Data re/uirements for t$e pro4ect s$ould )e esta)lis$ed for )ot$ data items to )e created and t$eir content and form, )ased on a common or standard set of data re/uirements. :niform content and format re/uirements for data items facilitate understandin+ of data content and $elp 'it$ consistent mana+ement of data resources.
Pro0e#t P&a
" ! :PP;
235
T$e reason for collectin+ eac$ document s$ould )e clear. T$is tas2 includes t$e anal*sis and verification of pro4ect delivera)les and nondelivera)les, data re/uirements, and customer supplied data. 7ften, data are collected 'it$ no clear understandin+ of $o' t$e* 'ill )e used. Data are costl* and s$ould )e collected onl* '$en needed.
1. ". 3. 8. 9. G. =. H. F.
Data mana+ement plan Master list of mana+ed data Data content and format description Aists of data re/uirements for ac/uirers and suppliers Privac* re/uirements ecurit* re/uirements ecurit* procedures Mec$anisms for data retrieval, reproduction, and distri)ution c$edule for t$e collection of pro4ect data
1#. Aist of pro4ect data to )e collected

S/b'ra#t"#e$
1.
Esta)lis$ re/uirements and procedures to ensure privac* and t$e securit* of data. 7ot everyone will have the need or clearance necessary to access project data. 'rocedures should be established to identify who has access to which data as well as when they have access to which data.
".
Esta)lis$ a mec$anism to arc$ive data and to access arc$ived data. "ccessed information should be in an understandable form 2e.g., electronic or computer output from a database3 or represented as originally generated.
3. 8.
Determine t$e pro4ect data to )e identified, collected, and distri)uted. Determine t$e re/uirements for providin+ access to and distri)ution of data to relevant sta2e$olders. " review of other elements of the project plan can help to determine who re0uires access to or receipt of project data as well as which data are involved.
9.
Decide '$ic$ pro4ect data and plans re/uire version control or ot$er levels of confi+uration control and esta)lis$ mec$anisms to ensure pro4ect data are controlled.
SP 2*4
P&a t-e Pro0e#tB$ Re$o/r#e$
!lan for resources to perform the pro/ect.

Definin+ pro4ect resources (e.+., la)or, e/uipment, materials, met$ods, and /uantities needed to perform pro4ect activities )uilds on initial estimates and provides additional information t$at can )e applied to e5pand t$e 6. used to mana+e t$e pro4ect.
236
Pro0e#t P&a
" ! :PP;
T$e top-level 6. developed earlier as an estimation mec$anism is t*picall* e5panded )* decomposin+ t$ese top levels into 'or2 pac2a+es t$at represent sin+le 'or2 units t$at can )e separatel* assi+ned, performed, and trac2ed. T$is su)division is done to distri)ute mana+ement responsi)ilit* and provide )etter mana+ement control. Eac$ 'or2 pac2a+e in t$e 6. s$ould )e assi+ned a uni/ue identifier (e.+., num)er, to permit trac2in+. 0 6. can )e )ased on re/uirements, activities, 'or2 products, services, or a com)ination of t$ese items. 0 dictionar* t$at descri)es t$e 'or2 for eac$ 'or2 pac2a+e in t$e 6. s$ould accompan* t$e 'or2 )rea2do'n structure.
1. ". 3. 8. 9. G. =. 1.
6or2 pac2a+es 6. tas2 dictionar* taffin+ re/uirements )ased on pro4ect si-e and scope Critical facilities and e/uipment list Process and 'or2flo' definitions and dia+rams Pro4ect administration re/uirements list tatus reports Determine process re/uirements. (he processes used to manage a project are identified, defined, and coordinated with all relevant sta1eholders to ensure efficient operations during project execution.
S/b'ra#t"#e$
".
Determine communication re/uirements. (hese re0uirements address the 1inds of mechanisms to be used for communicating with customers, end users, project staff, and other relevant sta1eholders.
3.
Determine staffin+ re/uirements. (he staffing of a project depends on the decomposition of project re0uirements into tas1s, roles, and responsibilities for accomplishing project re0uirements as laid out in the wor1 pac1ages of the 4;*. *taffing re0uirements should consider the 1nowledge and s1ills re0uired for each identified position as defined in the 'lan 7eeded +nowledge and *1ills specific practice.
8.
Determine facilit*, e/uipment, and component re/uirements. $ost projects are uni0ue in some way and re0uire a set of uni0ue assets to accomplish project objectives. (he determination and ac0uisition of these assets in a timely manner are crucial to project success. &t is best to identify lead5time items early to determine how they will be addressed. Even when re0uired assets are not uni0ue, compiling a list of all facilities, e0uipment, and parts 2e.g., number of computers for the staff wor1ing on the project, software applications, office space3 provides insight into aspects of the scope of an effort that are often overloo1ed.
Pro0e#t P&a
" ! :PP;
238
9.
Determine ot$er continuin+ resource re/uirements. ;eyond determining processes, reporting templates, staffing, facilities, and e0uipment, there may be a continuing need for other types of resources to effectively carry out project activities, including the following:
Consumables 2e.g., electricity, office supplies3 "ccess to intellectual property "ccess to transportation 2for people and e0uipment3
(he re0uirements for such resources are derived from the re0uirements found in 2existing and future3 agreements 2e.g., customer agreements, service agreements, supplier agreements3, the project9s strategic approach, and the need to manage and maintain the project9s operations for a period of time.
SP 2*5 P&a Nee+e+ C ow&e+!e a + S?"&&$
!lan for 4no3ledge and s4ills needed to perform the pro/ect.

"efer to the 0rgani-ational Training process area for more information about developing s1ills and 1nowledge of people so they can perform their roles effectively and efficiently% Nno'led+e deliver* to pro4ects involves trainin+ pro4ect staff and ac/uirin+ 2no'led+e from outside sources. taffin+ re/uirements are dependent on t$e 2no'led+e and s2ills availa)le to support t$e e5ecution of t$e pro4ect.
1. ". 3. 8. 1. ". 3.
Inventor* of s2ill needs taffin+ and ne' $ire plans Data)ases (e.+., s2ills, trainin+, Trainin+ plans Identif* t$e 2no'led+e and s2ills needed to perform t$e pro4ect. 0ssess t$e 2no'led+e and s2ills availa)le. elect mec$anisms for providin+ needed 2no'led+e and s2ills. Example mechanisms include the following:
&n5house training 2both organi6ational and project3 External training *taffing and new hires External s1ill ac0uisition
S/b'ra#t"#e$
(he choice of in5house training or outsourced training for needed 1nowledge and s1ills is determined by the availability of training expertise, the project9s schedule, and business objectives. 8. Incorporate selected mec$anisms into t$e pro4ect plan.
23<
Pro0e#t P&a
" ! :PP;
SP 2*6
P&a Sta?e-o&+er I vo&veme t
!lan the in)ol)ement of identified sta4eholders.

ta2e$olders are identified from all p$ases of t$e pro4ect lifec*cle )* identif*in+ t$e people and functions t$at s$ould )e represented in t$e pro4ect and descri)in+ t$eir relevance and t$e de+ree of interaction for pro4ect activities. 0 t'o-dimensional matri5 'it$ sta2e$olders alon+ one a5is and pro4ect activities alon+ t$e ot$er a5is is a convenient format for accomplis$in+ t$is identification. !elevance of t$e sta2e$older to t$e activit* in a particular pro4ect p$ase and t$e amount of interaction e5pected 'ould )e s$o'n at t$e intersection of t$e pro4ect p$ase activit* a5is and t$e sta2e$older a5is. 1or inputs of sta2e$olders to )e useful, careful selection of relevant sta2e$olders is necessar*. 1or eac$ ma4or activit*, identif* sta2e$olders '$o are affected )* t$e activit* and t$ose '$o $ave e5pertise t$at is needed to conduct t$e activit*. T$is list of relevant sta2e$olders 'ill pro)a)l* c$an+e as t$e pro4ect moves t$rou+$ p$ases of t$e pro4ect lifec*cle. It is important, $o'ever, to ensure t$at relevant sta2e$olders in t$e latter p$ases of t$e lifec*cle $ave earl* input to re/uirements and desi+n decisions t$at affect t$em. Examples of the type of material that should be included in a plan for sta1eholder interaction include the following: -ist of all relevant sta1eholders #ationale for sta1eholder involvement #elationships among sta1eholders #esources 2e.g., training, materials, time, funding3 needed to ensure sta1eholder interaction *chedule for the phasing of sta1eholder interaction #oles and responsibilities of relevant sta1eholders with respect to the project, by project lifecycle phase #elative importance of the sta1eholder to the success of the project, by project lifecycle phase
Implementin+ t$is specific practice relies on s$ared or e5c$an+ed information 'it$ t$e previous Plan <eeded Nno'led+e and 2ills specific practice.
1.
SP 2*8
ta2e$older involvement plan
E$tab&"$- t-e Pro0e#t P&a
+sta'lish and maintain the o)erall pro/ect plan.

0 documented plan t$at addresses all relevant plannin+ items is necessar* to ac$ieve t$e mutual understandin+ and commitment of individuals, +roups, and or+ani-ations t$at e5ecute or support t$e plans.
Pro0e#t P&a
" ! :PP;
233
T$e plan +enerated for t$e pro4ect defines all aspects of t$e effort, t*in+ to+et$er t$e follo'in+ in a lo+ical manner% Pro4ect lifec*cle considerations Pro4ect tas2s .ud+ets and sc$edules Milestones Data mana+ement !is2 identification !esource and s2ill re/uirements ta2e$older identification and interaction Infrastructure considerations
Infrastructure considerations include responsi)ilit* and aut$orit* relations$ips for pro4ect staff, mana+ement, and support or+ani-ations. Aifec*cle considerations can include covera+e of later p$ases of t$e product or service life (t$at mi+$t )e )e*ond t$e life of t$e pro4ect,, especiall* transition to anot$er p$ase or part* (e.+., transition to manufacturin+, trainin+, operations, a service provider,. For software, the planning document is often referred to as one of the following: *oftware development plan *oftware project plan *oftware plan
For hardware, the planning document is often referred to as a hardware development plan. %evelopment activities in preparation for production can be included in the hardware development plan or defined in a separate production plan.
300
Pro0e#t P&a
" ! :PP;
Examples of plans that have been used in the :.*. %epartment of %efense community include the following: &ntegrated $aster 'lanQan event driven plan that documents significant accomplishments with passEfail criteria for both business and technical elements of the project and that ties each accomplishment to a 1ey project event. &ntegrated $aster *cheduleQan integrated and networ1ed multi5layered schedule of project tas1s re0uired to complete the wor1 effort documented in a related &ntegrated $aster 'lan. *ystems Engineering $anagement 'lanQa plan that details the integrated technical effort across the project. *ystems Engineering $aster *cheduleQan event based schedule that contains a compilation of 1ey technical accomplishments, each with measurable criteria, re0uiring successful completion to pass identified events. *ystems Engineering %etailed *cheduleQa detailed, time dependent, tas1 oriented schedule that associates dates and milestones with the *ystems Engineering $aster *chedule.
1.
S7 3
7verall pro4ect plan
Obta" Comm"tme t to t-e P&a
Commitments to the pro/ect plan are esta'lished and maintained.

To )e effective, plans re/uire commitment )* t$ose '$o are responsi)le for implementin+ and supportin+ t$e plan.
SP 3*1 Rev"ew P&a $ T-at Affe#t t-e Pro0e#t
#e)ie3 all plans that affect the pro/ect to understand pro/ect commitments.
Plans developed in ot$er process areas t*picall* contain information similar to t$at called for in t$e overall pro4ect plan. T$ese plans can provide additional detailed +uidance and s$ould )e compati)le 'it$ and support t$e overall pro4ect plan to indicate '$o $as t$e aut$orit*, responsi)ilit*, accounta)ilit*, and control. 0ll plans t$at affect t$e pro4ect s$ould )e revie'ed to ensure t$e* contain a common understandin+ of t$e scope, o)4ectives, roles, and relations$ips t$at are re/uired for t$e pro4ect to )e successful. Man* of t$ese plans are descri)ed )* t$e Plan t$e Process +eneric practice.
1.
SP 3*2
!ecord of t$e revie's of plans t$at affect t$e pro4ect
Re#o #"&e >or? a + Re$o/r#e Leve&$
"d/ust the pro/ect plan to reconcile a)aila'le and estimated resources.
Pro0e#t P&a
" ! :PP;
301
To esta)lis$ a pro4ect t$at is feasi)le, o)tain commitment from relevant sta2e$olders and reconcile differences )et'een estimates and availa)le resources. !econciliation is t*picall* accomplis$ed )* modif*in+ or deferrin+ re/uirements, ne+otiatin+ more resources, findin+ 'a*s to increase productivit*, outsourcin+, ad4ustin+ t$e staff s2ill mi5, or revisin+ all plans t$at affect t$e pro4ect or its sc$edules.
1. ". 3. 8. 9.
SP 3*3
!evised met$ods and correspondin+ estimatin+ parameters (e.+., )etter tools, t$e use of off-t$e-s$elf components, !ene+otiated )ud+ets !evised sc$edules !evised re/uirements list !ene+otiated sta2e$older a+reements
Obta" P&a Comm"tme t
6'tain commitment from rele)ant sta4eholders responsi'le for performing and supporting plan e,ecution.
7)tainin+ commitment involves interaction amon+ all relevant sta2e$olders, )ot$ internal and e5ternal to t$e pro4ect. T$e individual or +roup ma2in+ a commitment s$ould $ave confidence t$at t$e 'or2 can )e performed 'it$in cost, sc$edule, and performance constraints. 7ften, a provisional commitment is ade/uate to allo' t$e effort to )e+in and to permit researc$ to )e performed to increase confidence to t$e appropriate level needed to o)tain a full commitment.
1. ". 1.
Documented re/uests for commitments Documented commitments Identif* needed support and ne+otiate commitments 'it$ relevant sta2e$olders. (he 4;* can be used as a chec1list for ensuring that commitments are obtained for all tas1s. (he plan for sta1eholder interaction should identify all parties from whom commitment should be obtained.
S/b'ra#t"#e$
".
Document all or+ani-ational commitments, )ot$ full and provisional, ensurin+ t$e appropriate level of si+natories. Commitments should be documented to ensure a consistent mutual understanding and for project trac1ing and maintenance. 'rovisional commitments should be accompanied by a description of ris1s associated with the relationship.
3. 8.
!evie' internal commitments 'it$ senior mana+ement as appropriate. !evie' e5ternal commitments 'it$ senior mana+ement as appropriate.
302
Pro0e#t P&a
" ! :PP;
$anagement can have the necessary insight and authority to reduce ris1s associated with external commitments. 9. Identif* commitments re+ardin+ interfaces )et'een pro4ect elements and ot$er pro4ects and or+ani-ational units so t$at t$ese commitments can )e monitored. 4ell5defined interface specifications form the basis for commitments.
Pro0e#t P&a
" ! :PP;
303
304
Pro0e#t P&a
" ! :PP;
PRO!$)) A*D PRODU!( 2UA+I(- A))URA*!$

Purpose
T$e purpose of Process and Product Bualit* 0ssurance (PPB0, is to provide staff and mana+ement 'it$ o)4ective insi+$t into processes and associated 'or2 products.
Introductor" *otes
T$e Process and Product Bualit* 0ssurance process area involves t$e follo'in+ activities% 7)4ectivel* evaluatin+ performed processes and 'or2 products a+ainst applica)le process descriptions, standards, and procedures Identif*in+ and documentin+ noncompliance issues Providin+ feed)ac2 to pro4ect staff and mana+ers on t$e results of /ualit* assurance activities Ensurin+ t$at noncompliance issues are addressed
T$e Process and Product Bualit* 0ssurance process area supports t$e deliver* of $i+$-/ualit* products )* providin+ pro4ect staff and mana+ers at all levels 'it$ appropriate visi)ilit* into, and feed)ac2 on, processes and associated 'or2 products t$rou+$out t$e life of t$e pro4ect. T$e practices in t$e Process and Product Bualit* 0ssurance process area ensure t$at planned processes are implemented, '$ile t$e practices in t$e Verification process area ensure t$at specified re/uirements are satisfied. T$ese t'o process areas can on occasion address t$e same 'or2 product )ut from different perspectives. Pro4ects s$ould ta2e advanta+e of t$e overlap to minimi-e duplication of effort '$ile ta2in+ care to maintain separate perspectives. 7)4ectivit* in process and product /ualit* assurance evaluations is critical to t$e success of t$e pro4ect. ( ee t$e definition of Lo)4ectivel* evaluateM in t$e +lossar*., 7)4ectivit* is ac$ieved )* )ot$ independence and t$e use of criteria. 0 com)ination of met$ods providin+ evaluations a+ainst criteria )* t$ose '$o do not produce t$e 'or2 product is often used. Aess formal met$ods can )e used to provide )road da*-to-da* covera+e. More formal met$ods can )e used periodicall* to assure o)4ectivit*.
Pro#e$$ a + Pro+/#t @/a&"t1 A$$/ra #e :PP@A;
305
Examples of ways to perform objective evaluations include the following: Formal audits by organi6ationally separate 0uality assurance organi6ations 'eer reviews, which can be performed at various levels of formality &n5depth review of wor1 at the place it is performed 2i.e., des1 audits3 %istributed review and comment of wor1 products 'rocess chec1s built into the processes such as a fail5safe for processes when they are done incorrectly 2e.g., 'o1a5Oo1e3
Traditionall*, a /ualit* assurance +roup t$at is independent of t$e pro4ect provides o)4ectivit*. @o'ever, anot$er approac$ ma* )e appropriate in some or+ani-ations to implement t$e process and product /ualit* assurance role 'it$out t$at 2ind of independence. For example, in an organi6ation with an open, 0uality oriented culture, the process and product 0uality assurance role can be performed, partially or completely, by peers and the 0uality assurance function can be embedded in the process. For small organi6ations, this embedded approach might be the most feasible approach. If /ualit* assurance is em)edded in t$e process, several issues s$ould )e addressed to ensure o)4ectivit*. Ever*one performin+ /ualit* assurance activities s$ould )e trained in /ualit* assurance. T$ose '$o perform /ualit* assurance activities for a 'or2 product s$ould )e separate from t$ose '$o are directl* involved in developin+ or maintainin+ t$e 'or2 product. 0n independent reportin+ c$annel to t$e appropriate level of or+ani-ational mana+ement s$ould )e availa)le so t$at noncompliance issues can )e escalated as necessar*. For example, when implementing peer reviews as an objective evaluation method, the following issues should be addressed: $embers are trained and roles are assigned for people attending the peer reviews. " member of the peer review who did not produce this wor1 product is assigned to perform the 0uality assurance role. Chec1lists based on process descriptions, standards, and procedures are available to support the 0uality assurance activity. 7oncompliance issues are recorded as part of the peer review report and are trac1ed and escalated outside the project when necessary.
Bualit* assurance s$ould )e+in in t$e earl* p$ases of a pro4ect to esta)lis$ plans, processes, standards, and procedures t$at 'ill add value to t$e pro4ect and satisf* t$e re/uirements of t$e pro4ect and or+ani-ational policies. T$ose '$o perform /ualit* assurance activities participate in esta)lis$in+ plans, processes, standards, and procedures to ensure t$at t$e* fit pro4ect needs and t$at t$e* 'ill )e usa)le for performin+ /ualit* assurance evaluations. In addition, processes and associated 'or2 products to )e evaluated durin+ t$e pro4ect are desi+nated. T$is desi+nation can )e )ased on samplin+ or on o)4ective criteria t$at are
306
consistent 'it$ or+ani-ational policies, pro4ect re/uirements, and pro4ect needs. 6$en noncompliance issues are identified, t$e* are first addressed in t$e pro4ect and resolved t$ere if possi)le. <oncompliance issues t$at cannot )e resolved in t$e pro4ect are escalated to an appropriate level of mana+ement for resolution. T$is process area applies to evaluations of pro4ect activities and 'or2 products, and to or+ani-ational (e.+., process +roup, or+ani-ational trainin+, activities and 'or2 products. 1or or+ani-ational activities and 'or2 products, t$e term Lpro4ectM s$ould )e appropriatel* interpreted. &n "gile environments, teams tend to focus on immediate needs of the iteration rather than on longer term and broader organi6ational needs. (o ensure that objective evaluations are perceived to have value and are efficient, discuss the following early: 2=3 how objective evaluations are to be done, 2<3 which processes and wor1 products will be evaluated, 2!3 how results of evaluations will be integrated into the team9s rhythms 2e.g., as part of daily meetings, chec1lists, peer reviews, tools, continuous integration, retrospectives3. 2*ee @&nterpreting C$$& 4hen :sing "gile "pproachesA in 'art &.3
"efer to the 8erification process area for more information about ensuring that selected wor1 products meet their specified re,uirements%
3 1 7)4ectivel* Evaluate Processes and 6or2 Products P 1.1 P 1." P ".1 P "." 7)4ectivel* Evaluate Processes 7)4ectivel* Evaluate 6or2 Products Communicate and !esolve <oncompliance Issues Esta)lis$ !ecords
3 " Provide 7)4ective Insi+$t
)pecific Practices b" /oal S7 1 Ob0e#t"ve&1 Eva&/ate Pro#e$$e$ a + >or? Pro+/#t$
"dherence of the performed process and associated 3or4 products to applica'le process descriptions* standards* and procedures is o'/ecti)ely e)aluated.
SP 1*1 Ob0e#t"ve&1 Eva&/ate Pro#e$$e$
6'/ecti)ely e)aluate selected performed processes against applica'le process descriptions* standards* and procedures.
7)4ectivit* in /ualit* assurance evaluations is critical to t$e success of t$e pro4ect. 0 description of t$e /ualit* assurance reportin+ c$ain and $o' it ensures o)4ectivit* s$ould )e defined.
1.
Evaluation reports
308
". 3. 1.
<oncompliance reports Corrective actions Promote an environment (created as part of pro4ect mana+ement, t$at encoura+es staff participation in identif*in+ and reportin+ /ualit* issues. Esta)lis$ and maintain clearl* stated criteria for evaluations. (he intent of this subpractice is to provide criteria, based on business needs, such as the following:
4hat will be evaluated 4hen or how often a process will be evaluated /ow the evaluation will be conducted 4ho must be involved in the evaluation
S/b'ra#t"#e$
".
3. 8. 9.
SP 1*2
:se t$e stated criteria to evaluate selected performed processes for ad$erence to process descriptions, standards, and procedures. Identif* eac$ noncompliance found durin+ t$e evaluation. Identif* lessons learned t$at could improve processes.
Ob0e#t"ve&1 Eva&/ate >or? Pro+/#t$
6'/ecti)ely e)aluate selected 3or4 products against applica'le process descriptions* standards* and procedures.
1. ". 3. 1.
Evaluation reports <oncompliance reports Corrective actions elect 'or2 products to )e evaluated )ased on documented samplin+ criteria if samplin+ is used. 4or1 products can include services produced by a process whether the recipient of the service is internal or external to the project or organi6ation.
S/b'ra#t"#e$
".
Esta)lis$ and maintain clearl* stated criteria for t$e evaluation of selected 'or2 products. (he intent of this subpractice is to provide criteria, based on business needs, such as the following:
4hat will be evaluated during the evaluation of a wor1 product 4hen or how often a wor1 product will be evaluated /ow the evaluation will be conducted 4ho must be involved in the evaluation
3.
:se t$e stated criteria durin+ evaluations of selected 'or2 products.
30<
8.
Evaluate selected 'or2 products at selected times. Examples of when wor1 products can be evaluated against process descriptions, standards, or procedures include the following:
;efore delivery to the customer %uring delivery to the customer &ncrementally, when it is appropriate %uring unit testing %uring integration 4hen demonstrating an increment
9. G.
S7 2
Identif* eac$ case of noncompliance found durin+ evaluations. Identif* lessons learned t$at could improve processes.
Prov"+e Ob0e#t"ve I $"!-t
2oncompliance issues are o'/ecti)ely trac4ed and communicated* and resolution is ensured.
SP 2*1 Comm/ "#ate a + Re$o&ve No #om'&"a #e I$$/e$
Communicate -uality issues and ensure the resolution of noncompliance issues 3ith the staff and managers.
<oncompliance issues are pro)lems identified in evaluations t$at reflect a lac2 of ad$erence to applica)le standards, process descriptions, or procedures. T$e status of noncompliance issues provides an indication of /ualit* trends. Bualit* issues include noncompliance issues and trend anal*sis results. 6$en noncompliance issues cannot )e resolved in t$e pro4ect, use esta)lis$ed escalation mec$anisms to ensure t$at t$e appropriate level of mana+ement can resolve t$e issue. Trac2 noncompliance issues to resolution.
1. ". 3. 1. ".
Corrective action reports Evaluation reports Bualit* trends !esolve eac$ noncompliance 'it$ t$e appropriate mem)ers of t$e staff if possi)le. Document noncompliance issues '$en t$e* cannot )e resolved in t$e pro4ect.
S/b'ra#t"#e$
303
Examples of ways to resolve noncompliance in the project include the following:

Fixing the noncompliance Changing the process descriptions, standards, or procedures that were violated Obtaining a waiver to cover the noncompliance
3.
Escalate noncompliance issues t$at cannot )e resolved in t$e pro4ect to t$e appropriate level of mana+ement desi+nated to receive and act on noncompliance issues. 0nal*-e noncompliance issues to see if t$ere are /ualit* trends t$at can )e identified and addressed. Ensure t$at relevant sta2e$olders are a'are of results of evaluations and /ualit* trends in a timel* manner. Periodicall* revie' open noncompliance issues and trends 'it$ t$e mana+er desi+nated to receive and act on noncompliance issues. Trac2 noncompliance issues to resolution.
8. 9. G. =.
SP 2*2
E$tab&"$- Re#or+$
+sta'lish and maintain records of -uality assurance acti)ities.

1. ". 3. 8. 1. ".
Evaluation lo+s Bualit* assurance reports tatus reports of corrective actions !eports of /ualit* trends !ecord process and product /ualit* assurance activities in sufficient detail so t$at status and results are 2no'n. !evise t$e status and $istor* of /ualit* assurance activities as necessar*.
S/b'ra#t"#e$
310
2UA*(I(A(I3$ PRO0$!( #A*A/$#$*(

Purpose
T$e purpose of Buantitative Pro4ect Mana+ement (BPM, is to /uantitativel* mana+e t$e pro4ect to ac$ieve t$e pro4ect;s esta)lis$ed /ualit* and process performance o)4ectives.
Introductor" *otes
T$e Buantitative Pro4ect Mana+ement process area involves t$e follo'in+ activities% Esta)lis$in+ and maintainin+ t$e pro4ect;s /ualit* and process performance o)4ectives Composin+ a defined process for t$e pro4ect to $elp to ac$ieve t$e pro4ectPs /ualit* and process performance o)4ectives electin+ su)processes and attri)utes critical to understandin+ performance and t$at $elp to ac$ieve t$e pro4ect;s /ualit* and process performance o)4ectives electin+ measures and anal*tic tec$ni/ues to )e used in /uantitative mana+ement Monitorin+ t$e performance of selected su)processes usin+ statistical and ot$er /uantitative tec$ni/ues Mana+in+ t$e pro4ect usin+ statistical and ot$er /uantitative tec$ni/ues to determine '$et$er or not t$e pro4ect;s o)4ectives for /ualit* and process performance are )ein+ satisfied Performin+ root cause anal*sis of selected issues to address deficiencies in ac$ievin+ t$e pro4ect;s /ualit* and process performance o)4ectives
7r+ani-ational process assets used to ac$ieve $i+$ maturit*, includin+ /ualit* and process performance o)4ectives, selected processes, measures, )aselines, and models, are esta)lis$ed usin+ or+ani-ational process performance processes and used in /uantitative pro4ect mana+ement processes. T$e pro4ect can use or+ani-ational process performance processes to define additional o)4ectives, measures, )aselines, and models as needed to effectivel* anal*-e and mana+e performance. T$e measures, measurements, and ot$er data resultin+ from /uantitative pro4ect mana+ement processes are incorporated into t$e or+ani-ational process assets. In t$is 'a*, t$e or+ani-ation and its pro4ects derive )enefit from assets improved t$rou+$ use. T$e pro4ect;s defined process is a set of interrelated su)processes t$at form an inte+rated and co$erent process for t$e pro4ect. T$e Inte+rated Pro4ect
@/a t"tat"ve Pro0e#t Ma a!eme t :@PM;
311
Mana+ement practices descri)e esta)lis$in+ t$e pro4ect;s defined process )* selectin+ and tailorin+ processes from t$e or+ani-ation;s set of standard processes. ( ee t$e definition of Ldefined processM in t$e +lossar*., Buantitative Pro4ect Mana+ement practices, unli2e Inte+rated Pro4ect Mana+ement practices, $elp *ou to develop a /uantitative understandin+ of t$e e5pected performance of processes or su)processes. T$is understandin+ is used as a )asis for esta)lis$in+ t$e pro4ect;s defined process )* evaluatin+ alternative processes or su)processes for t$e pro4ect and selectin+ t$e ones t$at 'ill )est ac$ieve t$e /ualit* and process performance o)4ectives. Esta)lis$in+ effective relations$ips 'it$ suppliers is also important to t$e successful implementation of t$is process area. Esta)lis$in+ effective relations$ips can involve esta)lis$in+ /ualit* and process performance o)4ectives for suppliers, determinin+ t$e measures and anal*tic tec$ni/ues to )e used to +ain insi+$t into supplier pro+ress and performance, and monitorin+ pro+ress to'ard ac$ievin+ t$ose o)4ectives. 0n essential element of /uantitative mana+ement is $avin+ confidence in predictions (i.e., t$e a)ilit* to accuratel* predict t$e e5tent to '$ic$ t$e pro4ect can fulfill its /ualit* and process performance o)4ectives,. u)processes to )e mana+ed t$rou+$ t$e use of statistical and ot$er /uantitative tec$ni/ues are c$osen )ased on t$e needs for predicta)le process performance. 0not$er essential element of /uantitative mana+ement is understandin+ t$e nature and e5tent of t$e variation e5perienced in process performance and reco+ni-in+ '$en t$e pro4ect;s actual performance ma* not )e ade/uate to ac$ieve t$e pro4ect;s /ualit* and process performance o)4ectives. T$us, /uantitative mana+ement includes statistical t$in2in+ and t$e correct use of a variet* of statistical tec$ni/ues. ( ee t$e definition of L/uantitative mana+ementM in t$e +lossar*., tatistical and ot$er /uantitative tec$ni/ues are used to develop an understandin+ of t$e actual performance or to predict t$e performance of processes. uc$ tec$ni/ues can )e applied at multiple levels, from a focus on individual su)processes to anal*ses t$at span lifec*cle p$ases, pro4ects, and support functions. <on-statistical tec$ni/ues provide a less ri+orous )ut still useful set of approac$es t$at to+et$er 'it$ statistical tec$ni/ues $elp t$e pro4ect to understand '$et$er or not /ualit* and process performance o)4ectives are )ein+ satisfied and to identif* an* needed corrective actions. T$is process area applies to mana+in+ a pro4ect. 0ppl*in+ t$ese concepts to mana+in+ ot$er +roups and functions can $elp to lin2 different aspects of performance in t$e or+ani-ation to provide a )asis for )alancin+ and reconcilin+ competin+ priorities to address a )roader set of )usiness o)4ectives.
312
Examples of other groups and functions that could benefit from using this process area include the following: )uality assurance or 0uality control functions 'rocess definition and improvement &nternal research and development functions #is1 identification and management functions (echnology scouting functions $ar1et research Customer satisfaction assessment 'roblem trac1ing and reporting
"efer to the Causal $nalysis and "esolution process area for more information about identifying causes of selected outcomes and ta1ing action to improve process performance% "efer to the Integrated Pro.ect Management process area for more information about establishing the pro.ect3s defined process% "efer to the Measurement and $nalysis process area for more information about aligning measurement and analysis activities and providing measurement results% "efer to the 0rgani-ational Process efinition process area for more information about establishing organi-ational process assets% "efer to the 0rgani-ational Performance Management process area for more information about proactively managing the organi-ation3s performance to meet its business ob.ectives% "efer to the 0rgani-ational Process Performance process area for more information about establishing and maintaining a ,uantitative understanding of the performance of selected processes in the organi-ation3s set of standard processes in support of achieving ,uality and process performance ob.ectives2 and providing process performance data2 baselines2 and models to ,uantitatively manage the organi-ation3s pro.ects% "efer to the Pro.ect Monitoring and Control process area for more information about providing an understanding of the pro.ect3s progress so that appropriate corrective actions can be ta1en when the pro.ect3s performance deviates significantly from the plan% "efer to the Supplier $greement Management process area for more information about managing the ac,uisition of products and services from suppliers%
313

3 1 Prepare for Buantitative Mana+ement P 1.1 P 1." P 1.3 P 1.8 P ".1 P "." P ".3 Esta)lis$ t$e Pro4ect;s 7)4ectives Compose t$e Defined Process elect u)processes and 0ttri)utes elect Measures and 0nal*tic Tec$ni/ues Monitor t$e Performance of elected u)processes Mana+e Pro4ect Performance Perform !oot Cause 0nal*sis
3 " Buantitativel* Mana+e t$e Pro4ect
)pecific Practices b" /oal S7 1 Pre'are for @/a t"tat"ve Ma a!eme t
!reparation for -uantitati)e management is conducted.

Preparation activities include esta)lis$in+ /uantitative o)4ectives for t$e pro4ect, composin+ a defined process for t$e pro4ect t$at can $elp to ac$ieve t$ose o)4ectives, selectin+ su)processes and attri)utes critical to understandin+ performance and ac$ievin+ t$e o)4ectives, and selectin+ measures and anal*tic tec$ni/ues t$at support /uantitative mana+ement. T$ese activities ma* need to )e repeated '$en needs and priorities c$an+e, '$en t$ere is an improved understandin+ of process performance, or as part of ris2 miti+ation or corrective action.
SP 1*1 E$tab&"$- t-e Pro0e#tB$ Ob0e#t"ve$
+sta'lish and maintain the pro/ect7s -uality and process performance o'/ecti)es.
6$en esta)lis$in+ t$e pro4ect;s /ualit* and process performance o)4ectives, t$in2 a)out t$e processes t$at 'ill )e included in t$e pro4ect;s defined process and '$at t$e $istorical data indicate re+ardin+ t$eir process performance. T$ese considerations, alon+ 'it$ ot$ers suc$ as tec$nical capa)ilit*, 'ill $elp in esta)lis$in+ realistic o)4ectives for t$e pro4ect. T$e pro4ect;s o)4ectives for /ualit* and process performance are esta)lis$ed and ne+otiated at an appropriate level of detail (e.+., for individual product components, su)processes, pro4ect teams, to permit an overall evaluation of t$e o)4ectives and ris2s at t$e pro4ect level. 0s t$e pro4ect pro+resses, pro4ect o)4ectives can )e updated as t$e pro4ect;s actual performance )ecomes 2no'n and more predicta)le, and to reflect c$an+in+ needs and priorities of relevant sta2e$olders.
1. ".
T$e pro4ect;s /ualit* and process performance o)4ectives 0ssessment of t$e ris2 of not ac$ievin+ t$e pro4ect;s o)4ectives
314
S/b'ra#t"#e$
1.
!evie' t$e or+ani-ationPs o)4ectives for /ualit* and process performance. (his review ensures that project members understand the broader business context in which the project operates. (he project9s objectives for 0uality and process performance are developed in the context of these overarching organi6ational objectives. "efer to the 0rgani-ational Process Performance process area for more information about establishing ,uality and process performance ob.ectives%
".
Identif* t$e /ualit* and process performance needs and priorities of t$e customer, suppliers, end users, and ot$er relevant sta2e$olders. (ypically, the identification of relevant sta1eholders9 needs will begin early 2e.g., during development of the statement of wor13. 7eeds are further elicited, analy6ed, refined, prioriti6ed, and balanced during re0uirements development. Examples of 0uality and process performance attributes for which needs and priorities might be identified include the following:
%uration 'redictability #eliability $aintainability :sability (imeliness Functionality "ccuracy
3.
Define and document measura)le /ualit* and process performance o)4ectives for t$e pro4ect. %efining and documenting objectives for the project involve the following:
&ncorporating appropriate organi6ational 0uality and process performance objectives 4riting objectives that reflect the 0uality and process performance needs and priorities of the customer, end users, and other relevant sta1eholders %etermining how each objective will be achieved #eviewing the objectives to ensure they are sufficiently specific, measurable, attainable, relevant, and time5bound
Examples of measurable 0uality attributes include the following:

$ean time between failures 7umber and severity of defects in the released product Critical resource utili6ation 7umber and severity of customer complaints concerning the provided service
315
Examples of measurable process performance attributes include the following:

Cycle time 'ercentage of rewor1 time 'ercentage of defects removed by product verification activities 2perhaps by type of verification, such as peer reviews and testing3 %efect escape rates 7umber and severity of defects found 2or incidents reported3 in first year following product delivery 2or start of service3
Examples of project 0uality and process performance objectives include:

$aintain change re0uest bac1log si6e below a target value. &mprove velocity in an "gile environment to a target value by a target date. #educe idle time by xF by a target date. $aintain schedule slippage below a specified percent. #educe the total lifecycle cost by a specified percent by a target date. #educe defects in products delivered to the customer by =>F without affecting cost.
8.
Derive interim o)4ectives to monitor pro+ress to'ard ac$ievin+ t$e pro4ect;s o)4ectives. &nterim objectives can be established for attributes of selected lifecycle phases, milestones, wor1 products, and subprocesses. *ince process performance models characteri6e relationships among product and process attributes, these models can be used to help derive interim objectives that guide the project toward achieving its objectives.
9.
Determine t$e ris2 of not ac$ievin+ t$e pro4ect;s /ualit* and process performance o)4ectives. (he ris1 is a function of the established objectives, the product architecture, the project9s defined process, availability of needed 1nowledge and s1ills, etc. 'rocess performance baselines and models can be used to evaluate the li1elihood of achieving a set of objectives and provide guidance in negotiating objectives and commitments. (he assessment of ris1 can involve various project sta1eholders and can be conducted as part of the conflict resolution described in the next subpractice.
G.
!esolve conflicts amon+ t$e pro4ect;s /ualit* and process performance o)4ectives (e.+., if one o)4ective cannot )e ac$ieved 'it$out compromisin+ anot$er,. 'rocess performance models can help to identify conflicts and help to ensure that the resolution of conflicts does not introduce new conflicts or ris1s. #esolving conflicts involves the following activities:
*etting relative priorities for objectives Considering alternative objectives in light of long5term business strategies as well as short5term needs
316
&nvolving the customer, end users, senior management, project management, and other relevant sta1eholders in tradeoff decisions #evising objectives as necessary to reflect results of conflict resolution
=.
Esta)lis$ tracea)ilit* to t$e pro4ect;s /ualit* and process performance o)4ectives from t$eir sources. Examples of sources of objectives include the following:
#e0uirements (he organi6ation9s 0uality and process performance objectives (he customer9s 0uality and process performance objectives ;usiness objectives %iscussions with customers and potential customers $ar1et surveys 'roduct "rchitecture
"n example of a method to identify and trace these needs and priorities is )uality Function %eployment 2)F%3. H. F. Define and ne+otiate /ualit* and process performance o)4ectives for suppliers. !evise t$e pro4ect;s /ualit* and process performance o)4ectives as necessar*.
SP 1*2
Com'o$e t-e %ef" e+ Pro#e$$
8sing statistical and other -uantitati)e techni-ues* compose a defined process that ena'les the pro/ect to achie)e its -uality and process performance o'/ecti)es.
"efer to the Integrated Pro.ect Management process area for more information about establishing the pro.ect3s defined process% "efer to the 0rgani-ational Process efinition process area for more information about establishing organi-ational process assets% "efer to the 0rgani-ational Process Performance process area for more information about establishing performance baselines and models% Composin+ t$e pro4ect;s defined process +oes )e*ond t$e process selection and tailorin+ descri)ed in t$e Inte+rated Pro4ect Mana+ement process area. It involves identif*in+ alternatives to one or more processes or su)processes, performin+ /uantitative anal*sis of performance and selectin+ t$e alternatives t$at are )est a)le to $elp t$e pro4ect to ac$ieve its /ualit* and process performance o)4ectives.
1. ". 3.
Criteria used to evaluate alternatives for t$e pro4ect 0lternative su)processes u)processes to )e included in t$e pro4ect;s defined process
318
8. 1.
0ssessment of ris2 of not ac$ievin+ t$e pro4ect;s o)4ectives Esta)lis$ t$e criteria to use in evaluatin+ process alternatives for t$e pro4ect. Criteria can be based on the following:
)uality and process performance objectives "vailability of process performance data and the relevance of the data to evaluating an alternative Familiarity with an alternative or with alternatives similar in composition Existence of process performance models that can be used in evaluating an alternative 'roduct line standards 'roject lifecycle models *ta1eholder re0uirements -aws and regulations
S/b'ra#t"#e$
".
Identif* alternative processes and su)processes for t$e pro4ect. &dentifying alternatives can include one or more of the following:
"naly6ing organi6ational process performance baselines to identify candidate subprocesses that would help achieve the project9s 0uality and process performance objectives &dentifying subprocesses from the organi6ation9s set of standard processes as well as tailored processes in the process asset library that can help to achieve the objectives &dentifying processes from external sources 2e.g., such as other organi6ations, professional conferences, academic research3 "djusting the level or depth of intensity with which a subprocess is applied 2as described in further detail in a subpractice that follows3
"djusting the level or depth of intensity with which the subprocesses are applied can involve the following choices: 7umber and type of peer reviews to be held and when "mount of effort or calendar time devoted to particular tas1s 7umber and selection of people involved *1ill level re0uirements for performing specific tas1s *elective application of speciali6ed construction or verification techni0ues #euse decisions and associated ris1 mitigation strategies (he product and process attributes to be measured *ampling rate for management data
"efer to the Integrated Pro.ect Management process area for more information about using organi-ational process assets for planning pro.ect activities%
31<
3.
0nal*-e t$e interaction of alternative su)processes to understand relations$ips amon+ t$e su)processes, includin+ t$eir attri)utes. "n analysis of the interaction will provide insight into the relative strengths and wea1nesses of particular alternatives. (his analysis can be supported by a calibration of the organi6ation9s process performance models with process performance data 2e.g., as characteri6ed in process performance baselines3. "dditional modeling may be needed if existing process performance models cannot address significant relationships among the alternative subprocesses under consideration and there is high ris1 of not achieving objectives.
8.
Evaluate alternative su)processes a+ainst t$e criteria. :se historical data, process performance baselines, and process performance models as appropriate to assist in evaluating alternatives against the criteria. (hese evaluations can include use of a sensitivity analysis particularly in high ris1 situations. "efer to the ecision $nalysis and "esolution process area for more information about evaluating alternatives%
9.
elect t$e alternative su)processes t$at )est meet t$e criteria. &t may be necessary to iterate through the activities described in the previous subpractices several times before confidence is achieved that the best available alternatives have been identified.
G.
Evaluate t$e ris2 of not ac$ievin+ t$e pro4ect;s /ualit* and process performance o)4ectives* "n analysis of ris1 associated with the selected alternative defined process can lead to identifying new alternatives to be evaluated, as well as areas re0uiring more management attention. "efer to the "is1 Management process area for more information about identifying and analy-ing ris1s%
SP 1*3
Se&e#t S/b'ro#e$$e$ a + Attr"b/te$
elect su'processes and attri'utes critical to e)aluating performance and that help to achie)e the pro/ect7s -uality and process performance o'/ecti)es.
ome su)processes are critical )ecause t$eir performance si+nificantl* influences or contri)utes to ac$ievin+ t$e pro4ect;s o)4ectives. T$ese su)processes ma* )e +ood candidates for monitorin+ and control usin+ statistical and ot$er /uantitative tec$ni/ues as descri)ed in t$e first specific practice of t$e second specific +oal. 0lso, some attri)utes of t$ese su)processes can serve as leadin+ indicators of t$e process performance to e5pect of su)processes t$at are furt$er do'nstream and can )e used to assess t$e ris2 of not ac$ievin+ t$e pro4ect;s o)4ectives (e.+., )* usin+ process performance models,. u)processes and attri)utes t$at pla* suc$ critical roles ma* $ave alread* )een identified as part of t$e anal*ses descri)ed in t$e previous specific practice.
313
1or small pro4ects, and ot$er circumstances in '$ic$ su)process data ma* not )e +enerated fre/uentl* enou+$ in t$e pro4ect to support a sufficientl* sensitive statistical inference, it ma* still )e possi)le to understand performance )* e5aminin+ process performance across similar iterations, teams, or pro4ects.
1. ". 3.
Criteria used to select su)processes t$at are 2e* contri)utors to ac$ievin+ t$e pro4ect;s o)4ectives elected su)processes 0ttri)utes of selected su)processes t$at $elp in predictin+ future pro4ect performance 0nal*-e $o' su)processes, t$eir attri)utes, ot$er factors, and pro4ect performance results relate to eac$ ot$er. " root cause analysis, sensitivity analysis, or process performance model can help to identify the subprocesses and attributes that most contribute to achieving particular performance results 2and variation in performance results3 or that are useful indicators of future achievement of performance results. "efer to the Causal $nalysis and "esolution process area for more information about determining causes of selected outcomes%
S/b'ra#t"#e$
1.
".
Identif* criteria to )e used in selectin+ su)processes t$at are 2e* contri)utors to ac$ievin+ t$e pro4ect;s /ualit* and process performance o)4ectives. Examples of criteria used to select subprocesses include the following:
(here is a strong correlation with performance results that are addressed in the project9s objectives. *table performance of the subprocess is important. 'oor subprocess performance is associated with major ris1s to the project. One or more attributes of the subprocess serve as 1ey inputs to process performance models used in the project. (he subprocess will be executed fre0uently enough to provide sufficient data for analysis.
3.
elect su)processes usin+ t$e identified criteria. /istorical data, process performance models, and process performance baselines can help in evaluating candidate subprocesses against selection criteria. "efer to the ecision $nalysis and "esolution process area for more information about evaluating alternatives%
8.
Identif* product and process attri)utes to )e monitored. (hese attributes may have been identified as part of performing the previous subpractices.
320
"ttributes that provide insight into current or future subprocess performance are candidates for monitoring, whether or not the associated subprocesses are under the control of the project. "lso, some of these same attributes may serve other roles, 2e.g., to help in monitoring project progress and performance as described in 'roject $onitoring and Control I'$CJ3. Examples of product and process attributes include the following:
Effort consumed to perform the subprocess (he rate at which the subprocess is performed Cycle time for process elements that ma1e up the subprocess #esource or materials consumed as input to the subprocess *1ill level of the staff member performing the subprocess )uality of the wor1 environment used to perform the subprocess ,olume of outputs of the subprocess 2e.g., intermediate wor1 products3 )uality attributes of outputs of the subprocess 2e.g., reliability, testability3 SP 1*4 Se&e#t Mea$/re$ a + A a&1t"# Te#- "=/e$
elect measures and analytic techni-ues to 'e used in -uantitati)e management.

"efer to the Measurement and $nalysis process area for more information about aligning measurement and analysis activities and providing measurement results%
1. ". 3. 8. 1.
Definitions of measures and anal*tic tec$ni/ues to )e used in /uantitative mana+ement Tracea)ilit* of measures )ac2 to t$e pro4ect;s /ualit* and process performance o)4ectives Bualit* and process performance o)4ectives for selected su)processes and t$eir attri)utes Process performance )aselines and models for use )* t$e pro4ect Identif* common measures from t$e or+ani-ational process assets t$at support /uantitative mana+ement. "efer to the 0rgani-ational Process efinition process area for more information about establishing organi-ational process assets% "efer to the 0rgani-ational Process Performance process area for more information about establishing performance baselines and models% 'roduct lines or other stratification criteria can categori6e common measures.
S/b'ra#t"#e$
".
Identif* additional measures t$at ma* )e needed to cover critical product and process attri)utes of t$e selected su)processes.
321
&n some cases, measures can be research oriented. *uch measures should be explicitly identified. 3. Identif* t$e measures to )e used in mana+in+ su)processes. 4hen selecting measures, 1eep the following considerations in mind: $easures that aggregate data from multiple sources 2e.g., different processes, input sources, environments3 or over time 2e.g., at a phase level3 can mas1 underlying problems, ma1ing problem identification and resolution difficult. For short5term projects, it may be necessary to aggregate data across similar instances of a process to enable analysis of its process performance while continuing to use the unaggregated data in support of individual projects. *election should not be limited to progress or performance measures only. @"nalysis measuresA 2e.g., inspection preparation rates, staff member s1ill levels, path coverage in testing3 may provide better insight into process performance.
8. 9.
pecif* t$e operational definitions of measures, t$eir collection points in su)processes, and $o' t$e inte+rit* of measures 'ill )e determined. 0nal*-e t$e relations$ip of identified measures to t$e pro4ect /ualit* and process performance o)4ectives and derive su)process /ualit* and process performance o)4ectives t$at state tar+ets (e.+., t$res$olds, ran+es, to )e met for eac$ measured attri)ute of eac$ selected su)process. Examples of derived subprocess 0uality and process performance objectives include the following:
$aintain a code review rate between GK to =>> lines of code per hour +eep re0uirements gathering sessions to under three hours +eep test rate over a specified number of test cases per day $aintain rewor1 levels below a specified percent $aintain productivity in generating use cases per day +eep design complexity 2fan5out rate3 below a specified threshold
G.
Identif* t$e statistical and ot$er /uantitative tec$ni/ues to )e used in /uantitative mana+ement. &n 0uantitative management, the process performance of selected subprocesses is analy6ed using statistical and other 0uantitative techni0ues that help to characteri6e subprocess variation, identify when statistically unexpected behavior occurs, recogni6e when variation is excessive, and investigate why. Examples of statistical techni0ues that can be used in the analysis of process performance include statistical process control charts, regression analysis, analysis of variance, and time series analysis. (he project can benefit from analy6ing the performance of subprocesses not selected for their impact on project performance. *tatistical and other 0uantitative techni0ues can be identified to address these subprocesses as well.
322
*tatistical and other 0uantitative techni0ues sometimes involve the use of graphical displays that help visuali6e associations among the data and results of analyses. *uch graphical displays can help visuali6e process performance and variation over time 2i.e., trends3, identify problems or opportunities, and evaluate the effects of particular factors. Examples of graphical displays include the following:
*catterplots /istograms ;ox and whis1ers plots #un charts &shi1awa diagrams
Examples of other techni0ues used to analy6e process performance include the following:
(ally sheets Classification schemas 2e.g., Orthogonal %efect Classification3
=.
Determine '$at process performance )aselines and models ma* )e needed to support identified anal*ses. &n some situations, the set of baselines and models provided as described in Organi6ational 'rocess 'erformance may be inade0uate to support 0uantitative project management. (his situation can happen when the objectives, processes, sta1eholders, s1ill levels, or environment for the project are different from other projects for which baselines and models were established. "s the project progresses, data from the project can serve as a more representative data set for establishing missing or a project specific set of process performance baselines and models. /ypothesis testing comparing project data to prior historical data can confirm the need to establish additional baselines and models specific to the project.
H.
Instrument t$e or+ani-ational or pro4ect support environment to support collection, derivation, and anal*sis of measures. (his instrumentation is based on the following:
%escription of the organi6ation9s set of standard processes %escription of the project9s defined process Capabilities of the organi6ational or project support environment
F.
!evise measures and statistical anal*sis tec$ni/ues as necessar*.
323
S7 2
@/a t"tat"ve&1 Ma a!e t-e Pro0e#t
The pro/ect is -uantitati)ely managed.

Buantitativel* mana+in+ t$e pro4ect involves t$e use of statistical and ot$er /uantitative tec$ni/ues to do t$e follo'in+%
SP 2*1
Monitor t$e selected su)processes usin+ statistical and ot$er /uantitative tec$ni/ues Determine '$et$er or not t$e pro4ect;s /ualit* and process performance o)4ectives are )ein+ satisfied Perform root cause anal*sis of selected issues to address deficiencies
Mo "tor t-e Performa #e of Se&e#te+ S/b'ro#e$$e$
Monitor the performance of selected su'processes using statistical and other -uantitati)e techni-ues.
T$e intent of t$is specific practice is to use statistical and ot$er /uantitative tec$ni/ues to anal*-e variation in su)process performance and to determine actions necessar* to ac$ieve eac$ su)process;s /ualit* and process performance o)4ectives.
1. ".
<atural )ounds of process performance for eac$ selected su)process attri)ute T$e actions needed to address deficiencies in t$e process sta)ilit* or capa)ilit* of eac$ selected su)process Collect data, as defined )* t$e selected measures, on t$e su)processes as t$e* e5ecute. Monitor t$e variation and sta)ilit* of t$e selected su)processes and address deficiencies. (his analysis involves evaluating measurements in relation to the natural bounds calculated for each selected measure and identifying outliers or other signals of potential non5random behavior, determining their causes and preventing or mitigating the effects of their recurrence 2i.e., addressing special causes of variation3. %uring such analysis, be sensitive to the sufficiency of the data and to shifts in process performance that can affect the ability to achieve or maintain process stability. "nalytic techni0ues for identifying outliers or signals include statistical process control charts, prediction intervals, and analysis of variance. *ome of these techni0ues involve graphical displays. Other deficiencies in process performance to consider include when variation is too large to have confidence that the subprocess is stable, or too great to assess its capability 2next subpractice3 of achieving the objectives established for each selected attribute.
S/b'ra#t"#e$
1. ".
324
3.
Monitor t$e capa)ilit* and performance of t$e selected su)processes and address deficiencies. (he intent of this subpractice is to identify what actions to ta1e to help the subprocess achieve its 0uality and process performance objectives. ;e sure that the subprocess performance is stable relative to the selected measures 2previous subpractice3 before comparing its capability to its 0uality and process performance objectives. Examples of actions that can be ta1en when the performance of a selected subprocess fails to satisfy its objectives include the following:
&mproving the implementation of the existing subprocess to reduce its variation or improve its performance 2i.e., addressing common causes of variation3 &dentifying and implementing an alternative subprocess through identifying and adopting new process elements, subprocesses, and technologies that may help better align with objectives &dentifying ris1s and ris1 mitigation strategies for each deficiency in subprocess capability #enegotiating or re5deriving objectives for each selected attribute of a subprocess so that they can be met by the subprocess
*ome actions can involve the use of root cause analysis, which is further described in *' <.!. "efer to the Pro.ect Monitoring and Control process area for more information about managing corrective action to closure%
SP 2*2 Ma a!e Pro0e#t Performa #e
Manage the pro/ect using statistical and other -uantitati)e techni-ues to determine 3hether or not the pro/ect7s o'/ecti)es for -uality and process performance 3ill 'e satisfied.
"efer to the Measurement and $nalysis process area for more information about aligning measurement and analysis activities and providing measurement results% "efer to the 0rgani-ational Performance Management process area for more information about managing business performance% T$is specific practice is pro4ect focused and uses multiple inputs to predict if t$e pro4ectPs /ualit* and process performance o)4ectives 'ill )e satisfied. .ased on t$is prediction, ris2s associated 'it$ not meetin+ t$e pro4ect;s /ualit* and process performance o)4ectives are identified and mana+ed, and actions to address deficiencies are defined as appropriate. Ne* inputs to t$is anal*sis include t$e individual su)process sta)ilit* and capa)ilit* data derived from t$e previous specific practice, as 'ell as performance data from monitorin+ ot$er su)processes, ris2s, and suppliers; pro+ress.
1.
Predictions of results to )e ac$ieved relative to t$e pro4ect;s /ualit* and process performance o)4ectives
325
". 3. 8. 1.
3rap$ical displa*s and data ta)ulations for ot$er su)processes, '$ic$ support /uantitative mana+ement 0ssessment of ris2s of not ac$ievin+ t$e pro4ect;s /ualit* and process performance o)4ectives 0ctions needed to address deficiencies in ac$ievin+ pro4ect o)4ectives Periodicall* revie' t$e performance of su)processes. *tability and capability data from monitoring selected subprocesses, as described in *'<.=, are a 1ey input into understanding the project9s overall ability to meet 0uality and process performance objectives. &n addition, subprocesses not selected for their impact on project objectives can still create problems or ris1s for the project and thus some level of monitoring for these subprocesses may be desired as well. "nalytic techni0ues involving the use of graphical displays can also prove to be useful to understanding subprocess performance.
S/b'ra#t"#e$
". 3. 8.
Monitor and anal*-e suppliers; pro+ress to'ard ac$ievin+ t$eir /ualit* and process performance o)4ectives. Periodicall* revie' and anal*-e actual results ac$ieved a+ainst esta)lis$ed interim o)4ectives. :se process performance models cali)rated 'it$ pro4ect data to assess pro+ress to'ard ac$ievin+ t$e pro4ect;s /ualit* and process performance o)4ectives. 'rocess performance models are used to assess progress toward achieving objectives that cannot be measured until a future phase in the project lifecycle. Objectives can either be interim objectives or overall objectives. "n example is the use of process performance models to predict the latent defects in wor1 products in future phases or in the delivered product. Calibration of process performance models is based on the results obtained from performing the activities described in the previous subpractices and specific practices.
9.
Identif* and mana+e ris2s associated 'it$ ac$ievin+ t$e pro4ect;s /ualit* and process performance o)4ectives. "efer to the "is1 Management process area for more information about identifying and analy-ing ris1s and mitigating ris1s%
326
Example sources of ris1s include the following:

*ubprocesses having inade0uate performance or capability *uppliers not achieving their 0uality and process performance objectives -ac1 of visibility into supplier capability &naccuracies in the process performance models used for predicting performance %eficiencies in predicted process performance 2estimated progress3 Other identified ris1s associated with identified deficiencies
G.
Determine and implement actions needed to address deficiencies in ac$ievin+ t$e pro4ect;s /ualit* and process performance o)4ectives. (he intent of this subpractice is to identify and implement the right set of actions, resources, and schedule to place the project bac1 on a path toward achieving its objectives. Examples of actions that can be ta1en to address deficiencies in achieving the project9s objectives include the following:
Changing 0uality and process performance objectives so that they are within the expected range of the project9s defined process &mproving the implementation of the project9s defined process "dopting new subprocesses and technologies that have the potential for satisfying objectives and managing associated ris1s &dentifying the ris1 and ris1 mitigation strategies for deficiencies (erminating the project
*ome actions can involve the use of root cause analysis, which is addressed in the next specific practice. "efer to the Pro.ect Monitoring and Control process area for more information about managing corrective action to closure% 4hen corrective actions result in changes to attributes or measures related to adjustable factors in a process performance model, the model can be used to predict the effects of the actions. 4hen underta1ing critical corrective actions in high ris1 situations, a process performance model can be created to predict the effects of the change.
SP 2*3 Perform Root Ca/$e A a&1$"$
!erform root cause analysis of selected issues to address deficiencies in achie)ing the pro/ect7s -uality and process performance o'/ecti)es.
Issues to address include deficiencies in su)process sta)ilit* and capa)ilit*, and deficiencies in pro4ect performance relative to its o)4ectives. !oot cause anal*sis of selected issues is )est performed s$ortl* after t$e pro)lem is first identified, '$ile t$e event is still recent enou+$ to )e carefull* investi+ated.
328
T$e formalit* of and effort re/uired for a root cause anal*sis can var* +reatl* and can )e determined )* suc$ factors as t$e sta2e$olders '$o are involvedI t$e ris2 or opportunit* t$at is presentI t$e comple5it* of t$e situationI t$e fre/uenc* 'it$ '$ic$ t$e situation could recurI t$e availa)ilit* of data, )aselines, and models t$at can )e used in t$e anal*sisI and $o' muc$ time $as passed since t$e events tri++erin+ t$e deficienc*. In t$e case of a su)process t$at e5$i)its too muc$ variation, is performed rarel*, and involves different sta2e$olders, it could ta2e 'ee2s or mont$s to identif* root causes. Ai2e'ise, t$e actions to ta2e can ran+e si+nificantl* in terms of effort and time needed to determine, plan, and implement t$em. It is often difficult to 2no' $o' muc$ time is needed unless an initial anal*sis of t$e deficiencies is underta2en. "efer to the Causal $nalysis and "esolution process area for more information about identifying causes of selected outcomes and ta1ing action to improve process performance% "efer to the Measurement and $nalysis process area for more information about aligning measurement and analysis activities and providing measurement results%
1.
u)process and pro4ect performance measurements and anal*ses (includin+ statistical anal*ses, recorded in t$e or+ani-ation;s measurement repositor* 3rap$ical displa*s of data used to understand su)process and pro4ect performance and performance trends Identified root causes and potential actions to ta2e Perform root cause anal*sis, as appropriate, to dia+nose process performance deficiencies. 'rocess performance baselines and models are used in diagnosing deficiencies8 identifying possible solutions8 predicting future project and process performance8 and evaluating potential actions as appropriate. (he use of process performance models in predicting future project and process performance is described in a subpractice of the previous specific practice.
". 3. 1.
S/b'ra#t"#e$
". 3. 8.
Identif* and anal*-e potential actions. Implement selected actions. 0ssess t$e impact of t$e actions on su)process performance. (his assessment of impact can include an evaluation of the statistical significance of the impacts resulting from the actions ta1en to improve process performance.
32<
R$2UIR$#$*() D$3$+OP#$*(
Purpose
T$e purpose of !e/uirements Development (!D, is to elicit, anal*-e, and esta)lis$ customer, product, and product component re/uirements.
Introductor" *otes
T$is process area descri)es t$ree t*pes of re/uirements% customer re/uirements, product re/uirements, and product component re/uirements. Ta2en to+et$er, t$ese re/uirements address t$e needs of relevant sta2e$olders, includin+ needs pertinent to various product lifec*cle p$ases (e.+., acceptance testin+ criteria, and product attri)utes (e.+., responsiveness, safet*, relia)ilit*, maintaina)ilit*,. !e/uirements also address constraints caused )* t$e selection of desi+n solutions (e.+., inte+ration of commercial off-t$e-s$elf products, use of a particular arc$itecture pattern,. 0ll development pro4ects $ave re/uirements. !e/uirements are t$e )asis for desi+n. T$e development of re/uirements includes t$e follo'in+ activities% Elicitation, anal*sis, validation, and communication of customer needs, e5pectations, and constraints to o)tain prioriti-ed customer re/uirements t$at constitute an understandin+ of '$at 'ill satisf* sta2e$olders Collection and coordination of sta2e$older needs Development of t$e lifec*cle re/uirements of t$e product Esta)lis$ment of t$e customer functional and /ualit* attri)ute re/uirements Esta)lis$ment of initial product and product component re/uirements consistent 'it$ customer re/uirements
T$is process area addresses all customer re/uirements rat$er t$an onl* product level re/uirements )ecause t$e customer can also provide specific desi+n re/uirements. Customer re/uirements are furt$er refined into product and product component re/uirements. In addition to customer re/uirements, product and product component re/uirements are derived from t$e selected desi+n solutions. T$rou+$out t$e process areas, '$ere t$e terms LproductM and Lproduct componentM are used, t$eir intended meanin+s also encompass services, service s*stems, and t$eir components. !e/uirements are identified and refined t$rou+$out t$e p$ases of t$e product lifec*cle. Desi+n decisions, su)se/uent corrective actions, and
Re=/"reme t$ %eve&o'me t :R%;
323
feed)ac2 durin+ eac$ p$ase of t$e product;s lifec*cle are anal*-ed for impact on derived and allocated re/uirements. T$e !e/uirements Development process area includes t$ree specific +oals. T$e Develop Customer !e/uirements specific +oal addresses definin+ a set of customer re/uirements to use in t$e development of product re/uirements. T$e Develop Product !e/uirements specific +oal addresses definin+ a set of product or product component re/uirements to use in t$e desi+n of products and product components. T$e 0nal*-e and Validate !e/uirements specific +oal addresses t$e anal*sis of customer, product, and product component re/uirements to define, derive, and understand t$e re/uirements. T$e specific practices of t$e t$ird specific +oal are intended to assist t$e specific practices in t$e first t'o specific +oals. T$e processes associated 'it$ t$e !e/uirements Development process area and processes associated 'it$ t$e Tec$nical olution process area can interact recursivel* 'it$ one anot$er. 0nal*ses are used to understand, define, and select t$e re/uirements at all levels from competin+ alternatives. T$ese anal*ses include t$e follo'in+% 0nal*sis of needs and re/uirements for eac$ product lifec*cle p$ase, includin+ needs of relevant sta2e$olders, t$e operational environment, and factors t$at reflect overall customer and end-user e5pectations and satisfaction, suc$ as safet*, securit*, and afforda)ilit* Development of an operational concept Definition of t$e re/uired functionalit* and /ualit* attri)utes
T$is definition of re/uired functionalit* and /ualit* attri)utes descri)es '$at t$e product is to do. ( ee t$e definition of Ldefinition of re/uired functionalit* and /ualit* attri)utesM in t$e +lossar*., T$is definition can include descriptions, decompositions, and a partitionin+ of t$e functions (or in o)4ect oriented anal*sis '$at $as )een referred to as LservicesM or Lmet$odsM, of t$e product. In addition, t$e definition specifies desi+n considerations or constraints on $o' t$e re/uired functionalit* 'ill )e reali-ed in t$e product. Bualit* attri)utes address suc$ t$in+s as product availa)ilit*I maintaina)ilit*I modifia)ilit*I timeliness, t$rou+$put, and responsivenessI relia)ilit*I securit*I and scala)ilit*. ome /ualit* attri)utes 'ill emer+e as arc$itecturall* si+nificant and t$us drive t$e development of t$e product arc$itecture. uc$ anal*ses occur recursivel* at successivel* more detailed la*ers of a product;s arc$itecture until sufficient detail is availa)le to ena)le detailed desi+n, ac/uisition, and testin+ of t$e product to proceed. 0s a result of t$e anal*sis of re/uirements and t$e operational concept (includin+ functionalit*, support, maintenance, and disposal,, t$e manufacturin+ or production concept produces more derived re/uirements, includin+ consideration of t$e follo'in+% Constraints of various t*pes Tec$nolo+ical limitations
330
Cost and cost drivers Time constraints and sc$edule drivers !is2s Consideration of issues implied )ut not e5plicitl* stated )* t$e customer or end user 1actors introduced )* t$e developer;s uni/ue )usiness considerations, re+ulations, and la's
0 $ierarc$* of lo+ical entities (e.+., functions and su)functions, o)4ect classes and su)classesI processesI ot$er arc$itectural entities, is esta)lis$ed t$rou+$ iteration 'it$ t$e evolvin+ operational concept. !e/uirements are refined, derived, and allocated to t$ese lo+ical entities. !e/uirements and lo+ical entities are allocated to products, product components, people, or associated processes. In t$e case of iterative or incremental development, t$e re/uirements are also allocated to iterations or increments. Involvement of relevant sta2e$olders in )ot$ re/uirements development and anal*sis +ives t$em visi)ilit* into t$e evolution of re/uirements. T$is activit* continuall* assures t$em t$at t$e re/uirements are )ein+ properl* defined. 1or product lines, en+ineerin+ processes (includin+ re/uirements development, ma* )e applied to at least t'o levels in t$e or+ani-ation. 0t an or+ani-ational or product line level, a Lcommonalit* and variation anal*sisM is performed to $elp elicit, anal*-e, and esta)lis$ core assets for use )* pro4ects 'it$in t$e product line. 0t t$e pro4ect level, t$ese core assets are t$en used as per t$e product line production plan as part of t$e pro4ect;s en+ineerin+ activities. &n "gile environments, customer needs and ideas are iteratively elicited, elaborated, analy6ed, and validated. #e0uirements are documented in forms such as user stories, scenarios, use cases, product bac1logs, and the results of iterations 2wor1ing code in the case of software3. 4hich re0uirements will be addressed in a given iteration is driven by an assessment of ris1 and by the priorities associated with what is left on the product bac1log. 4hat details of re0uirements 2and other artifacts3 to document is driven by the need for coordination 2among team members, teams, and later iterations3 and the ris1 of losing what was learned. 4hen the customer is on the team, there can still be a need for separate customer and product documentation to allow multiple solutions to be explored. "s the solution emerges, responsibilities for derived re0uirements are allocated to the appropriate teams. 2*ee @&nterpreting C$$& 4hen :sing "gile "pproachesA in 'art &.3
"efer to the Product Integration process area for more information about ensuring interface compatibility% "efer to the Technical Solution process area for more information about selecting product component solutions and developing the design%
331
"efer to the 8alidation process area for more information about validating product or product components% "efer to the 8erification process area for more information about verifying selected wor1 products% "efer to the Configuration Management process area for more information about trac1ing and controlling changes% "efer to the "e,uirements Management process area for more information about managing re,uirements% "efer to the "is1 Management process area for more information about identifying and analy-ing ris1s%
3 1 Develop Customer !e/uirements P 1.1 P 1." P ".1 P "." P ".3 P 3.1 P 3." P 3.3 P 3.8 P 3.9 Elicit <eeds Transform ta2e$older <eeds into Customer !e/uirements Esta)lis$ Product and Product Component !e/uirements 0llocate Product Component !e/uirements Identif* Interface !e/uirements Esta)lis$ 7perational Concepts and cenarios Esta)lis$ a Definition of !e/uired 1unctionalit* and Bualit* 0ttri)utes 0nal*-e !e/uirements 0nal*-e !e/uirements to 0c$ieve .alance Validate !e/uirements
3 " Develop Product !e/uirements
3 3 0nal*-e and Validate !e/uirements
)pecific Practices b" /oal S7 1 %eve&o' C/$tomer Re=/"reme t$
ta4eholder needs* e,pectations* constraints* and interfaces are collected and translated into customer re-uirements.
T$e needs of sta2e$olders (e.+., customers, end users, suppliers, )uilders, testers, manufacturers, lo+istics support staff, are t$e )asis for determinin+ customer re/uirements. T$e sta2e$older needs, e5pectations, constraints, interfaces, operational concepts, and product concepts are anal*-ed, $armoni-ed, refined, and ela)orated for translation into a set of customer re/uirements. 1re/uentl*, sta2e$older needs, e5pectations, constraints, and interfaces are poorl* identified or conflictin+. ince sta2e$older needs, e5pectations, constraints, and limitations s$ould )e clearl* identified and understood, an iterative process is used t$rou+$out t$e life of t$e pro4ect to accomplis$ t$is o)4ective. To facilitate t$e re/uired interaction, a surro+ate for t$e end user or customer is fre/uentl* involved to represent t$eir needs and $elp resolve conflicts. T$e customer relations or mar2etin+ part of t$e or+ani-ation as 'ell as mem)ers of t$e development team from disciplines suc$ as $uman en+ineerin+ or support can )e used as surro+ates. Environmental, le+al,
332
and ot$er constraints s$ould )e considered '$en creatin+ and resolvin+ t$e set of customer re/uirements.
SP 1*1 E&"#"t Nee+$
+licit sta4eholder needs* e,pectations* constraints* and interfaces for all phases of the product lifecycle.
Elicitin+ +oes )e*ond collectin+ re/uirements )* proactivel* identif*in+ additional re/uirements not e5plicitl* provided )* customers. 0dditional re/uirements s$ould address t$e various product lifec*cle activities and t$eir impact on t$e product. Examples of techni0ues to elicit needs include the following: (echnology demonstrations &nterface control wor1ing groups (echnical control wor1ing groups &nterim project reviews )uestionnaires, interviews, and scenarios 2operational, sustainment, and development3 obtained from end users Operational, sustainment, and development wal1throughs and end5user tas1 analysis )uality attribute elicitation wor1shops with sta1eholders 'rototypes and models ;rainstorming )uality Function %eployment $ar1et surveys ;eta testing Extraction from sources such as documents, standards, or specifications Observation of existing products, environments, and wor1flow patterns :se cases :ser stories %elivering small incremental @vertical slicesA of product functionality ;usiness case analysis #everse engineering 2for legacy products3 Customer satisfaction surveys
333
Examples of sources of re0uirements that may not be identified by the customer include the following: ;usiness policies *tandards 'revious architectural design decisions and principles ;usiness environmental re0uirements 2e.g., laboratories, testing and other facilities, information technology infrastructure3 (echnology -egacy products or product components 2reuse product components3 #egulatory statutes
1. 1.
!esults of re/uirements elicitation activities En+a+e relevant sta2e$olders usin+ met$ods for elicitin+ needs, e5pectations, constraints, and e5ternal interfaces.
S/b'ra#t"#e$
SP 1*2
Tra $form Sta?e-o&+er Nee+$ " to C/$tomer Re=/"reme t$
Transform sta4eholder needs* e,pectations* constraints* and interfaces into prioriti5ed customer re-uirements.
T$e various inputs from t$e relevant sta2e$olders s$ould )e consolidated, missin+ information s$ould )e o)tained, and conflicts s$ould )e resolved as customer re/uirements are developed and prioriti-ed. T$e customer re/uirements can include needs, e5pectations, and constraints 'it$ re+ard to verification and validation. In some situations, t$e customer provides a set of re/uirements to t$e pro4ect, or t$e re/uirements e5ist as an output of a previous pro4ectPs activities. In t$ese situations, t$e customer re/uirements could conflict 'it$ t$e relevant sta2e$oldersP needs, e5pectations, constraints, and interfaces and 'ill need to )e transformed into t$e reco+ni-ed set of customer re/uirements after appropriate resolution of conflicts. !elevant sta2e$olders representin+ all p$ases of t$e productPs lifec*cle s$ould include )usiness as 'ell as tec$nical functions. In t$is 'a*, concepts for all product related lifec*cle processes are considered concurrentl* 'it$ t$e concepts for t$e products. Customer re/uirements result from informed decisions on t$e )usiness as 'ell as tec$nical effects of t$eir re/uirements.
1. ". 3.
Prioriti-ed customer re/uirements Customer constraints on t$e conduct of verification Customer constraints on t$e conduct of validation
334
S/b'ra#t"#e$
1. ".
Translate sta2e$older needs, e5pectations, constraints, and interfaces into documented customer re/uirements. Esta)lis$ and maintain a prioriti-ation of customer functional and /ualit* attri)ute re/uirements. /aving prioriti6ed customer re0uirements helps to determine project, iteration, or increment scope. (his prioriti6ation ensures that functional and 0uality attribute re0uirements critical to the customer and other sta1eholders are addressed 0uic1ly.
3.
S7 2
Define constraints for verification and validation.
%eve&o' Pro+/#t Re=/"reme t$
Customer re-uirements are refined and ela'orated to de)elop product and product component re-uirements.
Customer re/uirements are anal*-ed in con4unction 'it$ t$e development of t$e operational concept to derive more detailed and precise sets of re/uirements called Lproduct and product component re/uirements.M Product and product component re/uirements address t$e needs associated 'it$ eac$ product lifec*cle p$ase. Derived re/uirements arise from constraintsI consideration of issues implied )ut not e5plicitl* stated in t$e customer re/uirements )aselineI factors introduced )* t$e selected arc$itecture, product lifec*cle, and desi+nI and t$e developer;s uni/ue )usiness considerations. T$e re/uirements are ree5amined 'it$ eac$ successive, lo'er level set of re/uirements and arc$itecture, and t$e preferred product concept is refined. T$e re/uirements are allocated to product functions and product components includin+ o)4ects, people, and processes. In t$e case of iterative or incremental development, t$e re/uirements are also allocated to iterations or increments )ased on customer priorities, tec$nolo+* issues, and pro4ect o)4ectives. T$e tracea)ilit* of re/uirements to functions, o)4ects, tests, issues, or ot$er entities is documented. T$e allocated re/uirements and functions (or ot$er lo+ical entities, are t$e )asis for t$e s*nt$esis of t$e tec$nical solutionI $o'ever, as t$e arc$itecture is defined or emer+es, it serves as t$e ultimate )asis for directin+ t$e allocation of re/uirements to t$e solution. 0s internal components are developed, additional interfaces are defined and interface re/uirements are esta)lis$ed. "efer to the "e,uirements Management process area for more information about maintaining bidirectional traceability of re,uirements%
SP 2*1 E$tab&"$- Pro+/#t a + Pro+/#t Com'o e t Re=/"reme t$
+sta'lish and maintain product and product component re-uirements* 3hich are 'ased on the customer re-uirements.
T$e customer functional and /ualit* attri)ute re/uirements can )e e5pressed in t$e customer;s terms and can )e nontec$nical descriptions. T$e product re/uirements are t$e e5pression of t$ese re/uirements in tec$nical terms t$at can )e used for desi+n decisions. 0n e5ample of t$is
335
translation is found in t$e first @ouse of Bualit* 1unction Deplo*ment, '$ic$ maps customer desires into tec$nical parameters. 1or instance, Lsolid soundin+ doorM ma* )e mapped to si-e, 'ei+$t, fit, dampenin+, and resonant fre/uencies. Product and product component re/uirements address t$e satisfaction of customer, )usiness, and pro4ect o)4ectives and associated attri)utes, suc$ as effectiveness and afforda)ilit*. Derived re/uirements also address t$e needs of ot$er lifec*cle p$ases (e.+., production, operations, disposal, to t$e e5tent compati)le 'it$ )usiness o)4ectives. T$e modification of re/uirements due to approved re/uirement c$an+es is covered )* t$e LmaintainM aspect of t$is specific practiceI '$ereas, t$e administration of re/uirement c$an+es is covered )* t$e !e/uirements Mana+ement process area. "efer to the "e,uirements Management process area for more information about managing re,uirements%
1. ". 3. 8.
Derived re/uirements Product re/uirements Product component re/uirements 0rc$itectural re/uirements, '$ic$ specif* or constrain t$e relations$ips amon+ product components Develop re/uirements in tec$nical terms necessar* for product and product component desi+n. Derive re/uirements t$at result from desi+n decisions. "efer to the Technical Solution process area for more information about selecting product component solutions and developing the design% *election of a technology brings with it additional re0uirements. For instance, use of electronics re0uires additional technology specific re0uirements such as electromagnetic interference limits. "rchitectural decisions, such as selection of architecture patterns, introduce additional derived re0uirements for product components. For example, the -ayers 'attern will constrain dependencies between certain product components.
S/b'ra#t"#e$
1. ".
3.
Develop arc$itectural re/uirements capturin+ critical /ualit* attri)utes and /ualit* attri)ute measures necessar* for esta)lis$in+ t$e product arc$itecture and desi+n.
336
Examples of 0uality attribute measures include the following:

#espond within = second *ystem is available NNF of the time &mplement a change with no more than one staff wee1 of effort
8.
Esta)lis$ and maintain relations$ips )et'een re/uirements for consideration durin+ c$an+e mana+ement and re/uirements allocation. "efer to the "e,uirements Management process area for more information about maintaining bidirectional traceability of re,uirements% #elationships between re0uirements can aid in evaluating the impact of changes.
SP 2*2
A&&o#ate Pro+/#t Com'o e t Re=/"reme t$
"llocate the re-uirements for each product component.

"efer to the Technical Solution process area for more information about selecting product component solutions% T$e product arc$itecture provides t$e )asis for allocatin+ product re/uirements to product components. T$e re/uirements for product components of t$e defined solution include allocation of product performanceI desi+n constraintsI and fit, form, and function to meet re/uirements and facilitate production. In cases '$ere a $i+$er level re/uirement specifies a /ualit* attri)ute t$at 'ill )e t$e responsi)ilit* of more t$an one product component, t$e /ualit* attri)ute can sometimes )e partitioned for uni/ue allocation to eac$ product component as a derived re/uirement, $o'ever, ot$er times t$e s$ared re/uirement s$ould instead )e allocated directl* to t$e arc$itecture. 1or e5ample, allocation of s$ared re/uirements to t$e arc$itecture 'ould descri)e $o' a performance re/uirement (e.+., on responsiveness, is )ud+eted amon+ components so as to account in an end-to-end manner for reali-ation of t$e re/uirement. T$is concept of s$ared re/uirements can e5tend to ot$er arc$itecturall* si+nificant /ualit* attri)utes (e.+., securit*, relia)ilit*,.
1. ". 3. 8. 9. 1. ". 3.
!e/uirement allocation s$eets Provisional re/uirement allocations Desi+n constraints Derived re/uirements !elations$ips amon+ derived re/uirements 0llocate re/uirements to functions. 0llocate re/uirements to product components and t$e arc$itecture. 0llocate desi+n constraints to product components and t$e arc$itecture.
S/b'ra#t"#e$
338
8. 9.
0llocate re/uirements to deliver* increments. Document relations$ips amon+ allocated re/uirements. #elationships include dependencies in which a change in one re0uirement can affect other re0uirements.
SP 2*3
I+e t"f1 I terfa#e Re=/"reme t$
Identify interface re-uirements.

Interfaces )et'een functions (or )et'een o)4ects or ot$er lo+ical entities, are identified. Interfaces can drive t$e development of alternative solutions descri)ed in t$e Tec$nical olution process area. "efer to the Product Integration process area for more information about ensuring interface compatibility% Interface re/uirements )et'een products or product components identified in t$e product arc$itecture are defined. T$e* are controlled as part of product and product component inte+ration and are an inte+ral part of t$e arc$itecture definition.
1. 1.
Interface re/uirements Identif* interfaces )ot$ e5ternal to t$e product and internal to t$e product (e.+., )et'een functional partitions or o)4ects,. "s the design progresses, the product architecture will be altered by technical solution processes, creating new interfaces between product components and components external to the product. &nterfaces with product related lifecycle processes should also be identified. Examples of these interfaces include interfaces with test e0uipment, transportation systems, support systems, and manufacturing facilities.
S/b'ra#t"#e$
".
Develop t$e re/uirements for t$e identified interfaces. "efer to the Technical Solution process area for more information about designing interfaces using criteria% #e0uirements for interfaces are defined in terms such as origination, destination, stimulus, data characteristics for software, and electrical and mechanical characteristics for hardware.
S7 3
A a&1Ae a + )a&"+ate Re=/"reme t$
The re-uirements are analy5ed and )alidated.

T$e specific practices of t$e 0nal*-e and Validate !e/uirements specific +oal support t$e development of t$e re/uirements in )ot$ t$e Develop Customer !e/uirements specific +oal and t$e Develop Product !e/uirements specific +oal. T$e specific practices associated 'it$ t$is specific +oal cover anal*-in+ and validatin+ t$e re/uirements 'it$ respect to t$e end user;s intended environment.
33<
0nal*ses are performed to determine '$at impact t$e intended operational environment 'ill $ave on t$e a)ilit* to satisf* t$e sta2e$olders; needs, e5pectations, constraints, and interfaces. Considerations, suc$ as feasi)ilit*, mission needs, cost constraints, potential mar2et si-e, and ac/uisition strate+*, s$ould all )e ta2en into account, dependin+ on t$e product conte5t. 0rc$itecturall* si+nificant /ualit* attri)utes are identified )ased on mission and )usiness drivers. 0 definition of re/uired functionalit* and /ualit* attri)utes is also esta)lis$ed. 0ll specified usa+e modes for t$e product are considered. T$e o)4ectives of t$e anal*ses are to determine candidate re/uirements for product concepts t$at 'ill satisf* sta2e$older needs, e5pectations, and constraints and t$en to translate t$ese concepts into re/uirements. In parallel 'it$ t$is activit*, t$e parameters t$at 'ill )e used to evaluate t$e effectiveness of t$e product are determined )ased on customer input and t$e preliminar* product concept. !e/uirements are validated to increase t$e pro)a)ilit* t$at t$e resultin+ product 'ill perform as intended in t$e use environment.
SP 3*1 E$tab&"$- O'erat"o a& Co #e't$ a + S#e ar"o$
+sta'lish and maintain operational concepts and associated scenarios.

0 scenario is t*picall* a se/uence of events t$at ma* occur in t$e development, use, or sustainment of t$e product, '$ic$ is used to ma2e e5plicit some of t$e functional or /ualit* attri)ute needs of t$e sta2e$olders. In contrast, an operational concept for a product usuall* depends on )ot$ t$e desi+n solution and t$e scenario. 1or e5ample, t$e operational concept for a satellite )ased communications product is /uite different from one )ased on landlines. ince t$e alternative solutions $ave not usuall* )een defined '$en preparin+ t$e initial operational concepts, conceptual solutions are developed for use '$en anal*-in+ t$e re/uirements. T$e operational concepts are refined as solution decisions are made and lo'er level detailed re/uirements are developed. Kust as a desi+n decision for a product can )ecome a re/uirement for a product component, t$e operational concept can )ecome t$e scenarios (re/uirements, for product components. 7perational concepts and scenarios are evolved to facilitate t$e selection of product component solutions t$at, '$en implemented, 'ill satisf* t$e intended use of t$e product or facilitate its development and sustainment. 7perational concepts and scenarios document t$e interaction of t$e product components 'it$ t$e environment, end users, and ot$er product components, re+ardless of en+ineerin+ discipline. T$e* s$ould )e documented for all modes and states 'it$in operations, product development, deplo*ment, deliver*, support (includin+ maintenance and sustainment,, trainin+, and disposal. cenarios can )e developed to address operational, sustainment, development, or ot$er event se/uences.
333
1. ". 3. 8. 9. G. 1.
7perational concept Product or product component development, installation, operational, maintenance, and support concepts Disposal concepts :se cases Timeline scenarios <e' re/uirements Develop operational concepts and scenarios t$at include operations, installation, development, maintenance, support, and disposal as appropriate. &dentify and develop scenarios, consistent with the level of detail in the sta1eholder needs, expectations, and constraints in which the proposed product or product component is expected to operate. "ugment scenarios with 0uality attribute considerations for the functions 2or other logical entities3 described in the scenario.
S/b'ra#t"#e$
". 3.
Define t$e environment in '$ic$ t$e product or product component 'ill operate, includin+ )oundaries and constraints. !evie' operational concepts and scenarios to refine and discover re/uirements. Operational concept and scenario development is an iterative process. (he reviews should be held periodically to ensure that they agree with the re0uirements. (he review can be in the form of a wal1through.
8.
Develop a detailed operational concept, as products and product components are selected, t$at defines t$e interaction of t$e product, t$e end user, and t$e environment, and t$at satisfies t$e operational, maintenance, support, and disposal needs.
SP 3*2
E$tab&"$- a %ef" "t"o of Re=/"re+ ./ #t"o a&"t1 a + @/a&"t1 Attr"b/te$
+sta'lish and maintain a definition of re-uired functionality and -uality attri'utes.

7ne approac$ to definin+ re/uired functionalit* and /ualit* attri)utes is to anal*-e scenarios usin+ '$at some $ave called a Lfunctional anal*sisM to descri)e '$at t$e product is intended to do. T$is functional description can include actions, se/uence, inputs, outputs, or ot$er information t$at communicates t$e manner in '$ic$ t$e product 'ill )e used. T$e resultin+ description of functions, lo+ical +roupin+s of functions, and t$eir association 'it$ re/uirements is referred to as a functional arc$itecture. ( ee t$e definitions of Lfunctional anal*sisM and Lfunctional arc$itectureM in t$e +lossar*.,
340
uc$ approac$es $ave evolved in recent *ears t$rou+$ t$e introduction of arc$itecture description lan+ua+es, met$ods, and tools to more full* address and c$aracteri-e t$e /ualit* attri)utes, allo'in+ a ric$er (e.+., multidimensional, specification of constraints on $o' t$e defined functionalit* 'ill )e reali-ed in t$e product, and facilitatin+ additional anal*ses of t$e re/uirements and tec$nical solutions. ome /ualit* attri)utes 'ill emer+e as arc$itecturall* si+nificant and t$us drive t$e development of t$e product arc$itecture. T$ese /ualit* attri)utes often reflect cross-cuttin+ concerns t$at ma* not )e allocata)le to lo'er level elements of a solution. 0 clear understandin+ of t$e /ualit* attri)utes and t$eir importance )ased on mission or )usiness needs is an essential input to t$e desi+n process.
1. ". 3. 8. 9. 1. ".
Definition of re/uired functionalit* and /ualit* attri)utes 1unctional arc$itecture 0ctivit* dia+rams and use cases 7)4ect oriented anal*sis 'it$ services or met$ods identified 0rc$itecturall* si+nificant /ualit* attri)ute re/uirements Determine 2e* mission and )usiness drivers. Identif* desira)le functionalit* and /ualit* attri)utes. Functionality and 0uality attributes can be identified and defined through an analysis of various scenarios with relevant sta1eholders as described in the previous specific practice.
S/b'ra#t"#e$
3. 8.
Determine arc$itecturall* si+nificant /ualit* attri)utes )ased on 2e* mission and )usiness drivers. 0nal*-e and /uantif* functionalit* re/uired )* end users. (his analysis can involve considering the se0uencing of time critical functions.
9. G.
0nal*-e re/uirements to identif* lo+ical or functional partitions (e.+., su)functions,. Partition re/uirements into +roups, )ased on esta)lis$ed criteria (e.+., similar functionalit*, similar /ualit* attri)ute re/uirements, couplin+,, to facilitate and focus t$e re/uirements anal*sis. 0llocate customer re/uirements to functional partitions, o)4ects, people, or support elements to support t$e s*nt$esis of solutions. 0llocate re/uirements to functions and su)functions (or ot$er lo+ical entities,.
=. H.
SP 3*3
A a&1Ae Re=/"reme t$
"naly5e re-uirements to ensure that they are necessary and sufficient.
341
In li+$t of t$e operational concept and scenarios, t$e re/uirements for one level of t$e product $ierarc$* are anal*-ed to determine '$et$er t$e* are necessar* and sufficient to meet t$e o)4ectives of $i+$er levels of t$e product $ierarc$*. T$e anal*-ed re/uirements t$en provide t$e )asis for more detailed and precise re/uirements for lo'er levels of t$e product $ierarc$*. 0s re/uirements are defined, t$eir relations$ip to $i+$er level re/uirements and t$e $i+$er level definition of re/uired functionalit* and /ualit* attri)utes s$ould )e understood. 0lso, t$e 2e* re/uirements used to trac2 pro+ress are determined. 1or instance, t$e 'ei+$t of a product or si-e of a soft'are product can )e monitored t$rou+$ development )ased on its ris2 or its criticalit* to t$e customer. "efer to the 8erification process area for more information about establishing verification procedures and criteria%
1. ". 3. 8. 1. ". 3.
!e/uirements defects reports Proposed re/uirements c$an+es to resolve defects Ne* re/uirements Tec$nical performance measures 0nal*-e sta2e$older needs, e5pectations, constraints, and e5ternal interfaces to or+ani-e t$em into related su)4ects and remove conflicts. 0nal*-e re/uirements to determine '$et$er t$e* satisf* t$e o)4ectives of $i+$er level re/uirements. 0nal*-e re/uirements to ensure t$at t$e* are complete, feasi)le, reali-a)le, and verifia)le. 4hile design determines the feasibility of a particular solution, this subpractice addresses 1nowing which re0uirements affect feasibility.
S/b'ra#t"#e$
8. 9.
Identif* 2e* re/uirements t$at $ave a stron+ influence on cost, sc$edule, performance, or ris2. Identif* tec$nical performance measures t$at 'ill )e trac2ed durin+ t$e development effort. "efer to the Measurement and $nalysis process area for more information about developing and sustaining a measurement capability used to support management information needs%
G.
0nal*-e operational concepts and scenarios to refine t$e customer needs, constraints, and interfaces and to discover ne' re/uirements. (his analysis can result in more detailed operational concepts and scenarios as well as supporting the derivation of new re0uirements.
342
SP 3*4
A a&1Ae Re=/"reme t$ to A#-"eve 9a&a #e
"naly5e re-uirements to 'alance sta4eholder needs and constraints.

ta2e$older needs and constraints can address suc$ t$in+s as cost, sc$edule, product or pro4ect performance, functionalit*, priorities, reusa)le components, maintaina)ilit*, or ris2.
1. 1.
0ssessment of ris2s related to re/uirements :se proven models, simulations, and protot*pin+ to anal*-e t$e )alance of sta2e$older needs and constraints. #esults of the analyses can be used to reduce the cost of the product and the ris1 in developing the product.
S/b'ra#t"#e$
".
Perform a ris2 assessment on t$e re/uirements and definition of re/uired functionalit* and /ualit* attri)utes. "efer to the "is1 Management process area for more information about identifying and analy-ing ris1s%
3. 8.
E5amine product lifec*cle concepts for impacts of re/uirements on ris2s. 0ssess t$e impact of t$e arc$itecturall* si+nificant /ualit* attri)ute re/uirements on t$e product and product development costs and ris2s. 4hen the impact of re0uirements on costs and ris1s seems to outweigh the perceived benefit, relevant sta1eholders should be consulted to determine what changes may be needed. "s an example, a really tight response time re0uirement or a high availability re0uirement could prove expensive to implement. 'erhaps the re0uirement could be relaxed once the impacts 2e.g., on cost3 are understood.
SP 3*5
)a&"+ate Re=/"reme t$
9alidate re-uirements to ensure the resulting product 3ill perform as intended in the end user>s en)ironment.
!e/uirements validation is performed earl* in t$e development effort 'it$ end users to +ain confidence t$at t$e re/uirements are capa)le of +uidin+ a development t$at results in successful final validation. T$is activit* s$ould )e inte+rated 'it$ ris2 mana+ement activities. Mature or+ani-ations 'ill t*picall* perform re/uirements validation in a more sop$isticated 'a* usin+ multiple tec$ni/ues and 'ill )roaden t$e )asis of t$e validation to include ot$er sta2e$older needs and e5pectations.
343
Examples of techni0ues used for re0uirements validation include the following: "nalysis *imulations 'rototyping %emonstrations
1. 1. ".
!ecord of anal*sis met$ods and results 0nal*-e t$e re/uirements to determine t$e ris2 t$at t$e resultin+ product 'ill not perform appropriatel* in its intended use environment. E5plore t$e ade/uac* and completeness of re/uirements )* developin+ product representations (e.+., protot*pes, simulations, models, scenarios, stor*)oards, and )* o)tainin+ feed)ac2 a)out t$em from relevant sta2e$olders. "efer to the 8alidation process area for more information about preparing for validation and validating product or product components%
S/b'ra#t"#e$
3.
0ssess t$e desi+n as it matures in t$e conte5t of t$e re/uirements validation environment to identif* validation issues and e5pose unstated needs and customer re/uirements.
344
R$2UIR$#$*() #A*A/$#$*(
Purpose
T$e purpose of !e/uirements Mana+ement (!EBM, is to mana+e re/uirements of t$e pro4ect;s products and product components and to ensure ali+nment )et'een t$ose re/uirements and t$e pro4ect;s plans and 'or2 products.
Introductor" *otes
!e/uirements mana+ement processes mana+e all re/uirements received or +enerated )* t$e pro4ect, includin+ )ot$ tec$nical and nontec$nical re/uirements as 'ell as re/uirements levied on t$e pro4ect )* t$e or+ani-ation. In particular, if t$e !e/uirements Development process area is implemented, its processes 'ill +enerate product and product component re/uirements t$at 'ill also )e mana+ed )* t$e re/uirements mana+ement processes. T$rou+$out t$e process areas, '$ere t$e terms LproductM and Lproduct componentM are used, t$eir intended meanin+s also encompass services, service s*stems, and t$eir components. 6$en t$e !e/uirements Mana+ement, !e/uirements Development, and Tec$nical olution process areas are all implemented, t$eir associated processes can )e closel* tied and )e performed concurrentl*. T$e pro4ect ta2es appropriate steps to ensure t$at t$e set of approved re/uirements is mana+ed to support t$e plannin+ and e5ecution needs of t$e pro4ect. 6$en a pro4ect receives re/uirements from an approved re/uirements provider, t$ese re/uirements are revie'ed 'it$ t$e re/uirements provider to resolve issues and prevent misunderstandin+ )efore re/uirements are incorporated into pro4ect plans. 7nce t$e re/uirements provider and t$e re/uirements receiver reac$ an a+reement, commitment to t$e re/uirements is o)tained from pro4ect participants. T$e pro4ect mana+es c$an+es to re/uirements as t$e* evolve and identifies inconsistencies t$at occur amon+ plans, 'or2 products, and re/uirements. Part of mana+in+ re/uirements is documentin+ re/uirements c$an+es and t$eir rationale and maintainin+ )idirectional tracea)ilit* )et'een source re/uirements, all product and product component re/uirements, and ot$er specified 'or2 products. ( ee t$e definition of L)idirectional tracea)ilit*M in t$e +lossar*., 0ll pro4ects $ave re/uirements. In t$e case of maintenance activities, c$an+es are )ased on c$an+es to t$e e5istin+ re/uirements, desi+n, or
Re=/"reme t$ Ma a!eme t :RE@M;
345
implementation. In pro4ects t$at deliver increments of product capa)ilit*, t$e c$an+es can also )e due to evolvin+ customer needs, tec$nolo+* maturation and o)solescence, and standards evolution. In )ot$ cases, t$e re/uirements c$an+es, if an*, mi+$t )e documented in c$an+e re/uests from t$e customer or end users, or t$e* mi+$t ta2e t$e form of ne' re/uirements received from t$e re/uirements development process. !e+ardless of t$eir source or form, activities t$at are driven )* c$an+es to re/uirements are mana+ed accordin+l*. &n "gile environments, re0uirements are communicated and trac1ed through mechanisms such as product bac1logs, story cards, and screen moc15ups. Commitments to re0uirements are either made collectively by the team or an empowered team leader. 4or1 assignments are regularly 2e.g., daily, wee1ly3 adjusted based on progress made and as an improved understanding of the re0uirements and solution emerge. (raceability and consistency across re0uirements and wor1 products is addressed through the mechanisms already mentioned as well as during start5of5iteration or end5of5iteration activities such as @retrospectivesA and @demo days.A 2*ee @&nterpreting C$$& 4hen :sing "gile "pproachesA in 'art &.3
"efer to the "e,uirements evelopment process area for more information about eliciting2 analy-ing2 and establishing customer2 product2 and product component re,uirements% "efer to the Technical Solution process area for more information about selecting2 designing2 and implementing solutions to re,uirements% "efer to the Configuration Management process area for more information about establishing baselines and trac1ing and controlling changes% "efer to the Pro.ect Monitoring and Control process area for more information about monitoring the pro.ect against the plan and managing corrective action to closure% "efer to the Pro.ect Planning process area for more information about establishing and maintaining plans that define pro.ect activities% "efer to the "is1 Management process area for more information about identifying and analy-ing ris1s%
3 1 Mana+e !e/uirements P 1.1 P 1." P 1.3 P 1.8 P 1.9 :nderstand !e/uirements 7)tain Commitment to !e/uirements Mana+e !e/uirements C$an+es Maintain .idirectional Tracea)ilit* of !e/uirements Ensure 0li+nment .et'een Pro4ect 6or2 and !e/uirements
346
)pecific Practices b" /oal S7 1 Ma a!e Re=/"reme t$
#e-uirements are managed and inconsistencies 3ith pro/ect plans and 3or4 products are identified.
T$e pro4ect maintains a current and approved set of re/uirements over t$e life of t$e pro4ect )* doin+ t$e follo'in+% Mana+in+ all c$an+es to re/uirements Maintainin+ relations$ips amon+ re/uirements, pro4ect plans, and 'or2 products Ensurin+ ali+nment amon+ re/uirements, pro4ect plans, and 'or2 products Ta2in+ corrective action
"efer to the "e,uirements evelopment process area for more information about analy-ing and validating re,uirements% "efer to the evelop $lternative Solutions and Selection Criteria specific practice in the Technical Solution process area for more information about determining the feasibility of the re,uirements% "efer to the Pro.ect Monitoring and Control process area for more information about managing corrective action to closure%
SP 1*1 U +er$ta + Re=/"reme t$
De)elop an understanding 3ith the re-uirements pro)iders on the meaning of the re-uirements.
0s t$e pro4ect matures and re/uirements are derived, all activities or disciplines 'ill receive re/uirements. To avoid re/uirements creep, criteria are esta)lis$ed to desi+nate appropriate c$annels or official sources from '$ic$ to receive re/uirements. T$ose '$o receive re/uirements conduct anal*ses of t$em 'it$ t$e provider to ensure t$at a compati)le, s$ared understandin+ is reac$ed on t$e meanin+ of re/uirements. T$e result of t$ese anal*ses and dialo+s is a set of approved re/uirements.
1. ". 3. 8. 1. ".
Aists of criteria for distin+uis$in+ appropriate re/uirements providers Criteria for evaluation and acceptance of re/uirements !esults of anal*ses a+ainst criteria 0 set of approved re/uirements Esta)lis$ criteria for distin+uis$in+ appropriate re/uirements providers. Esta)lis$ o)4ective criteria for t$e evaluation and acceptance of re/uirements. -ac1 of evaluation and acceptance criteria often results in inade0uate verification, costly rewor1, or customer rejection.
S/b'ra#t"#e$
348
Examples of evaluation and acceptance criteria include the following:

Clearly and properly stated Complete Consistent with one another :ni0uely identified Consistent with architectural approach and 0uality attribute priorities "ppropriate to implement ,erifiable 2i.e., testable3 (raceable "chievable (ied to business value &dentified as a priority for the customer
3. 8.
0nal*-e re/uirements to ensure t$at esta)lis$ed criteria are met. !eac$ an understandin+ of re/uirements 'it$ re/uirements providers so t$at pro4ect participants can commit to t$em.
SP 1*2
Obta" Comm"tme t to Re=/"reme t$
6'tain commitment to re-uirements from pro/ect participants.

"efer to the Pro.ect Monitoring and Control process area for more information about monitoring commitments% T$e previous specific practice dealt 'it$ reac$in+ an understandin+ 'it$ re/uirements providers. T$is specific practice deals 'it$ a+reements and commitments amon+ t$ose '$o carr* out activities necessar* to implement re/uirements. !e/uirements evolve t$rou+$out t$e pro4ect. 0s re/uirements evolve, t$is specific practice ensures t$at pro4ect participants commit to t$e current and approved re/uirements and t$e resultin+ c$an+es in pro4ect plans, activities, and 'or2 products.
1. ". 1.
!e/uirements impact assessments Documented commitments to re/uirements and re/uirements c$an+es 0ssess t$e impact of re/uirements on e5istin+ commitments. (he impact on the project participants should be evaluated when the re0uirements change or at the start of a new re0uirement.
S/b'ra#t"#e$
".
<e+otiate and record commitments. Changes to existing commitments should be negotiated before project participants commit to a new re0uirement or re0uirement change.
34<
SP 1*3
Ma a!e Re=/"reme t$ C-a !e$
Manage changes to re-uirements as they e)ol)e during the pro/ect.

"efer to the Configuration Management process area for more information about trac1ing and controlling changes% !e/uirements c$an+e for a variet* of reasons. 0s needs c$an+e and as 'or2 proceeds, c$an+es ma* $ave to )e made to e5istin+ re/uirements. It is essential to mana+e t$ese additions and c$an+es efficientl* and effectivel*. To effectivel* anal*-e t$e impact of c$an+es, it is necessar* t$at t$e source of eac$ re/uirement is 2no'n and t$e rationale for t$e c$an+e is documented. T$e pro4ect ma* 'ant to trac2 appropriate measures of re/uirements volatilit* to 4ud+e '$et$er ne' or revised approac$ to c$an+e control is necessar*.
1. ". 3. 8. 1. ".
!e/uirements c$an+e re/uests !e/uirements c$an+e impact reports !e/uirements status !e/uirements data)ase Document all re/uirements and re/uirements c$an+es t$at are +iven to or +enerated )* t$e pro4ect. Maintain a re/uirements c$an+e $istor*, includin+ t$e rationale for c$an+es. $aintaining the change history helps to trac1 re0uirements volatility.
S/b'ra#t"#e$
3.
Evaluate t$e impact of re/uirement c$an+es from t$e standpoint of relevant sta2e$olders. #e0uirements changes that affect the product architecture can affect many sta1eholders.
8.
SP 1*4
Ma2e re/uirements and c$an+e data availa)le to t$e pro4ect.
Ma" ta" 9"+"re#t"o a& Tra#eab"&"t1 of Re=/"reme t$
Maintain 'idirectional tracea'ility among re-uirements and 3or4 products.

T$e intent of t$is specific practice is to maintain t$e )idirectional tracea)ilit* of re/uirements. ( ee t$e definition of L)idirectional tracea)ilit*M in t$e +lossar*., 6$en re/uirements are mana+ed 'ell, tracea)ilit* can )e esta)lis$ed from a source re/uirement to its lo'er level re/uirements and from t$ose lo'er level re/uirements )ac2 to t$eir source re/uirements. uc$ )idirectional tracea)ilit* $elps to determine '$et$er all source re/uirements $ave )een completel* addressed and '$et$er all lo'er level re/uirements can )e traced to a valid source.
343
!e/uirements tracea)ilit* also covers relations$ips to ot$er entities suc$ as intermediate and final 'or2 products, c$an+es in desi+n documentation, and test plans. Tracea)ilit* can cover $ori-ontal relations$ips, suc$ as across interfaces, as 'ell as vertical relations$ips. Tracea)ilit* is particularl* needed '$en assessin+ t$e impact of re/uirements c$an+es on pro4ect activities and 'or2 products. Examples of what aspects of traceability to consider include the following: *cope of traceability: (he boundaries within which traceability is needed %efinition of traceability: (he elements that need logical relationships (ype of traceability: 4hen hori6ontal and vertical traceability is needed
uc$ )idirectional tracea)ilit* is not al'a*s automated. It can )e done manuall* usin+ spreads$eets, data)ases, and ot$er common tools.
1. ". 1. ".
!e/uirements tracea)ilit* matri5 !e/uirements trac2in+ s*stem Maintain re/uirements tracea)ilit* to ensure t$at t$e source of lo'er level (i.e., derived, re/uirements is documented. Maintain re/uirements tracea)ilit* from a re/uirement to its derived re/uirements and allocation to 'or2 products. 4or1 products for which traceability may be maintained include the architecture, product components, development iterations 2or increments3, functions, interfaces, objects, people, processes, and other wor1 products.
S/b'ra#t"#e$
3.
SP 1*5
3enerate a re/uirements tracea)ilit* matri5.
E $/re A&"! me t 9etwee Pro0e#t >or? a + Re=/"reme t$
+nsure that pro/ect plans and 3or4 products remain aligned 3ith re-uirements.
T$is specific practice finds inconsistencies )et'een re/uirements and pro4ect plans and 'or2 products and initiates corrective actions to resolve t$em.
1. ". 1. ".
Documentation of inconsistencies )et'een re/uirements and pro4ect plans and 'or2 products, includin+ sources and conditions Corrective actions !evie' pro4ect plans, activities, and 'or2 products for consistenc* 'it$ re/uirements and c$an+es made to t$em. Identif* t$e source of t$e inconsistenc* (if an*,.
S/b'ra#t"#e$
350
3. 8.
Identif* an* c$an+es t$at s$ould )e made to plans and 'or2 products resultin+ from c$an+es to t$e re/uirements )aseline. Initiate an* necessar* corrective actions.
351
352
RI)4 #A*A/$#$*(
Purpose
T$e purpose of !is2 Mana+ement (! NM, is to identif* potential pro)lems )efore t$e* occur so t$at ris2 $andlin+ activities can )e planned and invo2ed as needed across t$e life of t$e product or pro4ect to miti+ate adverse impacts on ac$ievin+ o)4ectives.
Introductor" *otes
!is2 mana+ement is a continuous, for'ard-loo2in+ process t$at is an important part of pro4ect mana+ement. !is2 mana+ement s$ould address issues t$at could endan+er ac$ievement of critical o)4ectives. 0 continuous ris2 mana+ement approac$ effectivel* anticipates and miti+ates ris2s t$at can $ave a critical impact on a pro4ect. Effective ris2 mana+ement includes earl* and a++ressive ris2 identification t$rou+$ colla)oration and t$e involvement of relevant sta2e$olders as descri)ed in t$e sta2e$older involvement plan addressed in t$e Pro4ect Plannin+ process area. tron+ leaders$ip amon+ all relevant sta2e$olders is needed to esta)lis$ an environment for free and open disclosure and discussion of ris2. !is2 mana+ement s$ould consider )ot$ internal and e5ternal, as 'ell as )ot$ tec$nical and non-tec$nical, sources of cost, sc$edule, performance, and ot$er ris2s. Earl* and a++ressive detection of ris2 is important )ecause it is t*picall* easier, less costl*, and less disruptive to ma2e c$an+es and correct 'or2 efforts durin+ t$e earlier, rat$er t$an t$e later, p$ases of t$e pro4ect. 1or e5ample, decisions related to product arc$itecture are often made earl* )efore t$eir impacts can )e full* understood, and t$us t$e ris2 implications of suc$ c$oices s$ould )e carefull* considered. Industr* standards can $elp '$en determinin+ $o' to prevent or miti+ate specific ris2s commonl* found in a particular industr*. Certain ris2s can )e proactivel* mana+ed or miti+ated )* revie'in+ industr* )est practices and lessons learned. !is2 mana+ement can )e divided into t$e follo'in+ parts% Definin+ a ris2 mana+ement strate+* Identif*in+ and anal*-in+ ris2s @andlin+ identified ris2s, includin+ t$e implementation of ris2 miti+ation plans as needed
R"$? Ma a!eme t :RSCM;
353
0s represented in t$e Pro4ect Plannin+ and Pro4ect Monitorin+ and Control process areas, or+ani-ations initiall* ma* focus on ris2 identification for a'areness and react to t$e reali-ation of t$ese ris2s as t$e* occur. T$e !is2 Mana+ement process area descri)es an evolution of t$ese specific practices to s*stematicall* plan, anticipate, and miti+ate ris2s to proactivel* minimi-e t$eir impact on t$e pro4ect. 0lt$ou+$ t$e primar* emp$asis of t$e !is2 Mana+ement process area is on t$e pro4ect, t$ese concepts can also )e applied to mana+e or+ani-ational ris2s. &n "gile environments, some ris1 management activities are inherently embedded in the "gile method used. For example, some technical ris1s can be addressed by encouraging experimentation 2early @failuresA3 or by executing a @spi1eA outside of the routine iteration. /owever, the #is1 $anagement process area encourages a more systematic approach to managing ris1s, both technical and non5technical. *uch an approach can be integrated into "gile9s typical iteration and meeting rhythms8 more specifically, during iteration planning, tas1 estimating, and acceptance of tas1s. 2*ee @&nterpreting C$$& 4hen :sing "gile "pproachesA in 'art &.3
"efer to the ecision $nalysis and "esolution process area for more information about analy-ing possible decisions using a formal evaluation process that evaluates identified alternatives against established criteria% "efer to the Pro.ect Monitoring and Control process area for more information about monitoring pro.ect ris1s% "efer to the Pro.ect Planning process area for more information about identifying pro.ect ris1s and planning sta1eholder involvement%
3 1 Prepare for !is2 Mana+ement P 1.1 P 1." P 1.3 P ".1 P "." P 3.1 P 3." Determine !is2 ources and Cate+ories Define !is2 Parameters Esta)lis$ a !is2 Mana+ement trate+* Identif* !is2s Evaluate, Cate+ori-e, and Prioriti-e !is2s Develop !is2 Miti+ation Plans Implement !is2 Miti+ation Plans
3 " Identif* and 0nal*-e !is2s
3 3 Miti+ate !is2s
)pecific Practices b" /oal S7 1 Pre'are for R"$? Ma a!eme t
!reparation for ris4 management is conducted.

Prepare for ris2 mana+ement )* esta)lis$in+ and maintainin+ a strate+* for identif*in+, anal*-in+, and miti+atin+ ris2s. T*picall*, t$is strate+* is
354
documented in a ris2 mana+ement plan. T$e ris2 mana+ement strate+* addresses specific actions and t$e mana+ement approac$ used to appl* and control t$e ris2 mana+ement pro+ram. T$e strate+* t*picall* includes identif*in+ sources of ris2, t$e sc$eme used to cate+ori-e ris2s, and parameters used to evaluate, )ound, and control ris2s for effective $andlin+.
SP 1*1 %eterm" e R"$? So/r#e$ a + Cate!or"e$
Determine ris4 sources and categories.

Identif*in+ ris2 sources provides a )asis for s*stematicall* e5aminin+ c$an+in+ situations over time to uncover circumstances t$at affect t$e a)ilit* of t$e pro4ect to meet its o)4ectives. !is2 sources are )ot$ internal and e5ternal to t$e pro4ect. 0s t$e pro4ect pro+resses, additional sources of ris2 can )e identified. Esta)lis$in+ cate+ories for ris2s provides a mec$anism for collectin+ and or+ani-in+ ris2s as 'ell as ensurin+ appropriate scrutin* and mana+ement attention to ris2s t$at can $ave serious conse/uences on meetin+ pro4ect o)4ectives.
1. ". 1.
!is2 source lists (e5ternal and internal, !is2 cate+ories list Determine ris2 sources. #is1 sources are fundamental drivers that cause ris1s in a project or organi6ation. (here are many sources of ris1s, both internal and external to a project. #is1 sources identify where ris1s can originate. (ypical internal and external ris1 sources include the following:
:ncertain re0uirements :nprecedented efforts 2i.e., estimates unavailable3 &nfeasible design Competing 0uality attribute re0uirements that affect solution selection and design :navailable technology :nrealistic schedule estimates or allocation &nade0uate staffing and s1ills Cost or funding issues :ncertain or inade0uate subcontractor capability :ncertain or inade0uate supplier capability &nade0uate communication with actual or potential customers or with their representatives %isruptions to the continuity of operations #egulatory constraints 2e.g. security, safety, environment3
S/b'ra#t"#e$
355
$any of these sources of ris1 are accepted without ade0uately planning for them. Early identification of both internal and external sources of ris1 can lead to early identification of ris1s. #is1 mitigation plans can then be implemented early in the project to preclude occurrence of ris1s or reduce conse0uences of their occurrence. ". Determine ris2 cate+ories. #is1 categories are @binsA used for collecting and organi6ing ris1s. &dentifying ris1 categories aids the future consolidation of activities in ris1 mitigation plans. (he following factors can be considered when determining ris1 categories:
'hases of the project9s lifecycle model 2e.g., re0uirements, design, manufacturing, test and evaluation, delivery, disposal3 (ypes of processes used (ypes of products used 'roject management ris1s 2e.g., contract ris1s, budget ris1s, schedule ris1s, resource ris1s3 (echnical performance ris1s 2e.g., 0uality attribute related ris1s, supportability ris1s3
" ris1 taxonomy can be used to provide a framewor1 for determining ris1 sources and categories.
SP 1*2 %ef" e R"$? Parameter$
Define parameters used to analy5e and categori5e ris4s and to control the ris4 management effort.
Parameters for evaluatin+, cate+ori-in+, and prioriti-in+ ris2s include t$e follo'in+% !is2 li2eli$ood (i.e., pro)a)ilit* of ris2 occurrence, !is2 conse/uence (i.e., impact and severit* of ris2 occurrence, T$res$olds to tri++er mana+ement activities
!is2 parameters are used to provide common and consistent criteria for comparin+ ris2s to )e mana+ed. 6it$out t$ese parameters, it is difficult to +au+e t$e severit* of an un'anted c$an+e caused )* a ris2 and to prioriti-e t$e actions re/uired for ris2 miti+ation plannin+. Pro4ects s$ould document t$e parameters used to anal*-e and cate+ori-e ris2s so t$at t$e* are availa)le for reference t$rou+$out t$e life of t$e pro4ect )ecause circumstances c$an+e over time. :sin+ t$ese parameters, ris2s can easil* )e re-cate+ori-ed and anal*-ed '$en c$an+es occur. T$e pro4ect can use tec$ni/ues suc$ as failure mode and effects anal*sis (1ME0, to e5amine ris2s of potential failures in t$e product or in selected product development processes. uc$ tec$ni/ues can $elp to provide discipline in 'or2in+ 'it$ ris2 parameters.
1.
!is2 evaluation, cate+ori-ation, and prioriti-ation criteria
356
".
!is2 mana+ement re/uirements (e.+., control and approval levels, reassessment intervals, Define consistent criteria for evaluatin+ and /uantif*in+ ris2 li2eli$ood and severit* levels. Consistently used criteria 2e.g., bounds on li1elihood, severity levels3 allow impacts of different ris1s to be commonly understood, to receive the appropriate level of scrutiny, and to obtain the management attention warranted. &n managing dissimilar ris1s 2e.g., staff safety versus environmental pollution3, it is important to ensure consistency in the end result. 2For example, a high5impact ris1 of environmental pollution is as important as a high5impact ris1 to staff safety.3 One way of providing a common basis for comparing dissimilar ris1s is assigning dollar values to ris1s 2e.g., through a process of ris1 moneti6ation3.
S/b'ra#t"#e$
1.
".
Define t$res$olds for eac$ ris2 cate+or*. For each ris1 category, thresholds can be established to determine acceptability or unacceptability of ris1s, prioriti6ation of ris1s, or triggers for management action. Examples of thresholds include the following:
'roject5wide thresholds could be established to involve senior management when product costs exceed => percent of the target cost or when cost performance indices 2C'&s3 fall below >.NK. *chedule thresholds could be established to involve senior management when schedule performance indices 2*'&s3 fall below >.NK. 'erformance thresholds could be established to involve senior management when specified 1ey items 2e.g., processor utili6ation, average response times3 exceed =<K percent of the intended design.
3.
Define )ounds on t$e e5tent to '$ic$ t$res$olds are applied a+ainst or 'it$in a cate+or*. (here are few limits to which ris1s can be assessed in either a 0uantitative or 0ualitative fashion. %efinition of bounds 2or boundary conditions3 can be used to help define the extent of the ris1 management effort and avoid excessive resource expenditures. ;ounds can include the exclusion of a ris1 source from a category. (hese bounds can also exclude conditions that occur below a given fre0uency.
SP 1*3
E$tab&"$- a R"$? Ma a!eme t Strate!1
+sta'lish and maintain the strategy to 'e used for ris4 management.
0 compre$ensive ris2 mana+ement strate+* addresses items suc$ as t$e follo'in+% T$e scope of t$e ris2 mana+ement effort Met$ods and tools to )e used for ris2 identification, ris2 anal*sis, ris2 miti+ation, ris2 monitorin+, and communication Pro4ect specific sources of ris2s
358
@o' ris2s are to )e or+ani-ed, cate+ori-ed, compared, and consolidated Parameters used for ta2in+ action on identified ris2s, includin+ li2eli$ood, conse/uence, and t$res$olds !is2 miti+ation tec$ni/ues to )e used, suc$ as protot*pin+, pilotin+, simulation, alternative desi+ns, or evolutionar* development T$e definition of ris2 measures used to monitor t$e status of ris2s Time intervals for ris2 monitorin+ or reassessment
T$e ris2 mana+ement strate+* s$ould )e +uided )* a common vision of success t$at descri)es desired future pro4ect outcomes in terms of t$e product delivered, its cost, and its fitness for t$e tas2. T$e ris2 mana+ement strate+* is often documented in a ris2 mana+ement plan for t$e or+ani-ation or pro4ect. T$is strate+* is revie'ed 'it$ relevant sta2e$olders to promote commitment and understandin+. 0 ris2 mana+ement strate+* s$ould )e developed earl* in t$e pro4ect, so t$at relevant ris2s are identified and mana+ed proactivel*. Earl* identification and assessment of critical ris2s allo's t$e pro4ect to formulate ris2 $andlin+ approac$es and ad4ust pro4ect definition and allocation of resources )ased on critical ris2s.
1.
S7 2
Pro4ect ris2 mana+ement strate+*
I+e t"f1 a + A a&1Ae R"$?$
#is4s are identified and analy5ed to determine their relati)e importance.

T$e de+ree of ris2 affects t$e resources assi+ned to $andle t$e ris2 and t$e timin+ of '$en appropriate mana+ement attention is re/uired. !is2 anal*sis entails identif*in+ ris2s from identified internal and e5ternal sources and evaluatin+ eac$ identified ris2 to determine its li2eli$ood and conse/uences. !is2 cate+ori-ation, )ased on an evaluation a+ainst esta)lis$ed ris2 cate+ories and criteria developed for t$e ris2 mana+ement strate+*, provides information needed for ris2 $andlin+. !elated ris2s can )e +rouped to ena)le efficient $andlin+ and effective use of ris2 mana+ement resources.
SP 2*1 I+e t"f1 R"$?$
Identify and document ris4s.

Identif*in+ potential issues, $a-ards, t$reats, and vulnera)ilities t$at could ne+ativel* affect 'or2 efforts or plans is t$e )asis for sound and successful ris2 mana+ement. !is2s s$ould )e identified and descri)ed understanda)l* )efore t$e* can )e anal*-ed and mana+ed properl*. !is2s are documented in a concise statement t$at includes t$e conte5t, conditions, and conse/uences of ris2 occurrence. !is2 identification s$ould )e an or+ani-ed, t$orou+$ approac$ to see2 out pro)a)le or realistic ris2s in ac$ievin+ o)4ectives. To )e effective, ris2
35<
identification s$ould not attempt to address ever* possi)le event. :sin+ cate+ories and parameters developed in t$e ris2 mana+ement strate+* and identified sources of ris2 can provide t$e discipline and streamlinin+ appropriate for ris2 identification. Identified ris2s form a )aseline for initiatin+ ris2 mana+ement activities. !is2s s$ould )e revie'ed periodicall* to ree5amine possi)le sources of ris2 and c$an+in+ conditions to uncover sources and ris2s previousl* overloo2ed or none5istent '$en t$e ris2 mana+ement strate+* 'as last updated. !is2 identification focuses on t$e identification of ris2s, not t$e placement of )lame. T$e results of ris2 identification activities s$ould never )e used )* mana+ement to evaluate t$e performance of individuals. $any methods are used for identifying ris1s. (ypical identification methods include the following: Examine each element of the project wor1 brea1down structure. Conduct a ris1 assessment using a ris1 taxonomy. &nterview subject matter experts. #eview ris1 management efforts from similar products. Examine lessons learned documents or databases. Examine design specifications and agreement re0uirements.
1.
Aist of identified ris2s, includin+ t$e conte5t, conditions, and conse/uences of ris2 occurrence Identif* t$e ris2s associated 'it$ cost, sc$edule, and performance. #is1s associated with cost, schedule, performance, and other business objectives should be examined to understand their effect on project objectives. #is1 candidates can be discovered that are outside the scope of project objectives but vital to customer interests. For example, ris1s in development costs, product ac0uisition costs, cost of spare 2or replacement3 products, and product disposition 2or disposal3 costs have design implications. (he customer may not have considered the full cost of supporting a fielded product or using a delivered service. (he customer should be informed of such ris1s, but actively managing those ris1s may not be necessary. $echanisms for ma1ing such decisions should be examined at project and organi6ation levels and put in place if deemed appropriate, especially for ris1s that affect the project9s ability to verify and validate the product. &n addition to the cost ris1s identified above, other cost ris1s can include the ones associated with funding levels, funding estimates, and distributed budgets. *chedule ris1s can include ris1s associated with planned activities, 1ey events, and milestones.
S/b'ra#t"#e$
1.
353
'erformance ris1s can include ris1s associated with the following:

#e0uirements "nalysis and design "pplication of new technology 'hysical si6e *hape 4eight $anufacturing and fabrication 'roduct behavior and operation with respect to functionality or 0uality attributes ,erification ,alidation 'erformance maintenance attributes
'erformance maintenance attributes are those characteristics that enable an in5use product or service to provide re0uired performance, such as maintaining safety and security performance. (here are ris1s that do not fall into cost, schedule, or performance categories, but can be associated with other aspects of the organi6ation9s operation. Examples of these other ris1s include ris1s related to the following:
*tri1es %iminishing sources of supply (echnology cycle time Competition
".
!evie' environmental elements t$at can affect t$e pro4ect. #is1s to a project that fre0uently are missed include ris1s supposedly outside the scope of the project 2i.e., the project does not control whether they occur but can mitigate their impact3. (hese ris1s can include weather or natural disasters, political changes, and telecommunications failures.
3.
!evie' all elements of t$e 'or2 )rea2do'n structure as part of identif*in+ ris2s to $elp ensure t$at all aspects of t$e 'or2 effort $ave )een considered. !evie' all elements of t$e pro4ect plan as part of identif*in+ ris2s to $elp ensure t$at all aspects of t$e pro4ect $ave )een considered. "efer to the Pro.ect Planning process area for more information about identifying pro.ect ris1s%
8.
9.
Document t$e conte5t, conditions, and potential conse/uences of eac$ ris2. #is1 statements are typically documented in a standard format that contains the ris1 context, conditions, and conse0uences of occurrence. (he ris1 context provides additional information about the ris1 such as the relative time frame of the ris1, the
360
circumstances or conditions surrounding the ris1 that has brought about the concern, and any doubt or uncertainty. G.
SP 2*2
Identif* t$e relevant sta2e$olders associated 'it$ eac$ ris2.
Eva&/ate( Cate!or"Ae( a + Pr"or"t"Ae R"$?$
+)aluate and categori5e each identified ris4 using defined ris4 categories and parameters* and determine its relati)e priority.
T$e evaluation of ris2s is needed to assi+n a relative importance to eac$ identified ris2 and is used in determinin+ '$en appropriate mana+ement attention is re/uired. 7ften it is useful to a++re+ate ris2s )ased on t$eir interrelations$ips and develop options at an a++re+ate level. 6$en an a++re+ate ris2 is formed )* a roll up of lo'er level ris2s, care s$ould )e ta2en to ensure t$at important lo'er level ris2s are not i+nored. Collectivel*, t$e activities of ris2 evaluation, cate+ori-ation, and prioriti-ation are sometimes called a Lris2 assessmentM or Lris2 anal*sis.M
1. 1.
Aist of ris2s and t$eir assi+ned priorit* Evaluate identified ris2s usin+ defined ris2 parameters. Each ris1 is evaluated and assigned values according to defined ris1 parameters, which can include li1elihood, conse0uence 2i.e., severity, impact3, and thresholds. (he assigned ris1 parameter values can be integrated to produce additional measures, such as ris1 exposure 2i.e., the combination of li1elihood and conse0uence3, which can be used to prioriti6e ris1s for handling. Often, a scale with three to five values is used to evaluate both li1elihood and conse0uence. -i1elihood, for example, can be categori6ed as remote, unli1ely, li1ely, highly li1ely, or nearly certain. Example categories for conse0uence include the following:
-ow $edium /igh 7egligible $arginal *ignificant Critical Catastrophic
S/b'ra#t"#e$
'robability values are fre0uently used to 0uantify li1elihood. Conse0uences are generally related to cost, schedule, environmental impact, or human measures 2e.g., labor hours lost, severity of injury3.
361
#is1 evaluation is often a difficult and time consuming tas1. *pecific expertise or group techni0ues may be needed to assess ris1s and gain confidence in the prioriti6ation. &n addition, priorities can re0uire reevaluation as time progresses. (o provide a basis for comparing the impact of the reali6ation of identified ris1s, conse0uences of the ris1s can be moneti6ed. ". Cate+ori-e and +roup ris2s accordin+ to defined ris2 cate+ories. #is1s are categori6ed into defined ris1 categories, providing a means to review them according to their source, taxonomy, or project component. #elated or e0uivalent ris1s can be grouped for efficient handling. (he cause5and5effect relationships between related ris1s are documented. 3. Prioriti-e ris2s for miti+ation. " relative priority is determined for each ris1 based on assigned ris1 parameters. Clear criteria should be used to determine ris1 priority. #is1 prioriti6ation helps to determine the most effective areas to which resources for ris1s mitigation can be applied with the greatest positive impact on the project.
S7 3 M"t"!ate R"$?$
#is4s are handled and mitigated as appropriate to reduce ad)erse impacts on achie)ing o'/ecti)es.
T$e steps in $andlin+ ris2s include developin+ ris2 $andlin+ options, monitorin+ ris2s, and performin+ ris2 $andlin+ activities '$en defined t$res$olds are e5ceeded. !is2 miti+ation plans are developed and implemented for selected ris2s to proactivel* reduce t$e potential impact of ris2 occurrence. !is2 miti+ation plannin+ can also include contin+enc* plans to deal 'it$ t$e impact of selected ris2s t$at can occur despite attempts to miti+ate t$em. !is2 parameters used to tri++er ris2 $andlin+ activities are defined )* t$e ris2 mana+ement strate+*.
SP 3*1 %eve&o' R"$? M"t"!at"o P&a $
De)elop a ris4 mitigation plan in accordance 3ith the ris4 management strategy.
0 critical component of ris2 miti+ation plannin+ is developin+ alternative courses of action, 'or2arounds, and fall)ac2 positions, and a recommended course of action for eac$ critical ris2. T$e ris2 miti+ation plan for a +iven ris2 includes tec$ni/ues and met$ods used to avoid, reduce, and control t$e pro)a)ilit* of ris2 occurrenceI t$e e5tent of dama+e incurred s$ould t$e ris2 occur (sometimes called a Lcontin+enc* planM,I or )ot$. !is2s are monitored and '$en t$e* e5ceed esta)lis$ed t$res$olds, ris2 miti+ation plans are deplo*ed to return t$e affected effort to an accepta)le ris2 level. If t$e ris2 cannot )e miti+ated, a contin+enc* plan can )e invo2ed. .ot$ ris2 miti+ation and contin+enc* plans often are +enerated onl* for selected ris2s for '$ic$ conse/uences of t$e ris2s are $i+$ or unaccepta)le. 7t$er ris2s ma* )e accepted and simpl* monitored.
362
Options for handling ris1s typically include alternatives such as the following: #is1 avoidance: changing or lowering re0uirements while still meeting end user needs #is1 control: ta1ing active steps to minimi6e ris1s #is1 transfer: reallocating re0uirements to lower ris1s #is1 monitoring: watching and periodically reevaluating the ris1 for changes in assigned ris1 parameters #is1 acceptance: ac1nowledging ris1 but not ta1ing action
7ften, especiall* for $i+$-impact ris2s, more t$an one approac$ to $andlin+ a ris2 s$ould )e +enerated. For example, in the case of an event that disrupts the continuity of operations, approaches to ris1 management can include establishing the following: #esource reserves to respond to disruptive events -ists of available bac1up e0uipment ;ac1ups to 1ey staff 'lans for testing emergency response systems 'osted procedures for emergencies %isseminated lists of 1ey contacts and information resources for emergencies
In man* cases, ris2s are accepted or 'atc$ed. !is2 acceptance is usuall* done '$en t$e ris2 is 4ud+ed too lo' for formal miti+ation or '$en t$ere appears to )e no via)le 'a* to reduce t$e ris2. If a ris2 is accepted, t$e rationale for t$is decision s$ould )e documented. !is2s are 'atc$ed '$en t$ere is an o)4ectivel* defined, verifia)le, and documented t$res$old (e.+., for cost, sc$edule, performance, ris2 e5posure, t$at 'ill tri++er ris2 miti+ation plannin+ or invo2e a contin+enc* plan. "efer to the ecision $nalysis and "esolution process area for more information about evaluating alternatives and selecting solutions% 0de/uate consideration s$ould )e +iven earl* to tec$nolo+* demonstrations, models, simulations, pilots, and protot*pes as part of ris2 miti+ation plannin+.
1. ". 3. 8. 1.
Documented $andlin+ options for eac$ identified ris2 !is2 miti+ation plans Contin+enc* plans Aist of t$ose '$o are responsi)le for trac2in+ and addressin+ eac$ ris2 Determine t$e levels and t$res$olds t$at define '$en a ris2 )ecomes unaccepta)le and tri++ers t$e e5ecution of a ris2 miti+ation plan or contin+enc* plan.
S/b'ra#t"#e$
363
#is1 level 2derived using a ris1 model3 is a measure combining the uncertainty of reaching an objective with the conse0uences of failing to reach the objective. #is1 levels and thresholds that bound planned or acceptable cost, schedule, or performance should be clearly understood and defined to provide a means with which ris1 can be understood. 'roper categori6ation of ris1 is essential for ensuring an appropriate priority based on severity and the associated management response. (here can be multiple thresholds employed to initiate varying levels of management response. (ypically, thresholds for the execution of ris1 mitigation plans are set to engage before the execution of contingency plans. ". 3. Identif* t$e person or +roup responsi)le for addressin+ eac$ ris2. Determine t$e costs and )enefits of implementin+ t$e ris2 miti+ation plan for eac$ ris2. #is1 mitigation activities should be examined for benefits they provide versus resources they will expend. Cust li1e any other design activity, alternative plans may need to be developed and costs and benefits of each alternative assessed. (he most appropriate plan is selected for implementation. 8. Develop an overall ris2 miti+ation plan for t$e pro4ect to orc$estrate t$e implementation of individual ris2 miti+ation and contin+enc* plans. (he complete set of ris1 mitigation plans may not be affordable. " tradeoff analysis should be performed to prioriti6e ris1 mitigation plans for implementation. 9. Develop contin+enc* plans for selected critical ris2s in t$e event t$eir impacts are reali-ed. #is1 mitigation plans are developed and implemented as needed to proactively reduce ris1s before they become problems. %espite best efforts, some ris1s can be unavoidable and will become problems that affect the project. Contingency plans can be developed for critical ris1s to describe actions a project can ta1e to deal with the occurrence of this impact. (he intent is to define a proactive plan for handling the ris1. Either the ris1 is reduced 2mitigation3 or addressed 2contingency3. &n either event, the ris1 is managed. *ome ris1 management literature may consider contingency plans a synonym or subset of ris1 mitigation plans. (hese plans also can be addressed together as ris1 handling or ris1 action plans.
SP 3*2 Im'&eme t R"$? M"t"!at"o P&a $
Monitor the status of each ris4 periodically and implement the ris4 mitigation plan as appropriate.
To effectivel* control and mana+e ris2s durin+ t$e 'or2 effort, follo' a proactive pro+ram to re+ularl* monitor ris2s and t$e status and results of ris2 $andlin+ actions. T$e ris2 mana+ement strate+* defines t$e intervals at '$ic$ ris2 status s$ould )e revisited. T$is activit* can result in t$e discover* of ne' ris2s or ne' ris2 $andlin+ options t$at can re/uire replannin+ and reassessment. In eit$er event, accepta)ilit* t$res$olds associated 'it$ t$e ris2 s$ould )e compared to t$e ris2 status to determine t$e need for implementin+ a ris2 miti+ation plan.
364
1. ". 3. 8. 9. 1.
:pdated lists of ris2 status :pdated assessments of ris2 li2eli$ood, conse/uence, and t$res$olds :pdated list of ris2 $andlin+ options :pdated list of actions ta2en to $andle ris2s !is2 miti+ation plans of ris2 $andlin+ options Monitor ris2 status. "fter a ris1 mitigation plan is initiated, the ris1 is still monitored. (hresholds are assessed to chec1 for the potential execution of a contingency plan. " mechanism for monitoring should be employed.
S/b'ra#t"#e$
".
Provide a met$od for trac2in+ open ris2 $andlin+ action items to closure. "efer to the Pro.ect Monitoring and Control process area for more information about managing corrective action to closure%
3.
Invo2e selected ris2 $andlin+ options '$en monitored ris2s e5ceed defined t$res$olds. Often, ris1 handling is only performed for ris1s judged to be high and medium. (he ris1 handling strategy for a given ris1 can include techni0ues and methods to avoid, reduce, and control the li1elihood of the ris1 or the extent of damage incurred should the ris1 occur, or both. &n this context, ris1 handling includes both ris1 mitigation plans and contingency plans. #is1 handling techni0ues are developed to avoid, reduce, and control adverse impact to project objectives and to bring about acceptable outcomes in light of probable impacts. "ctions generated to handle a ris1 re0uire proper resource loading and scheduling in plans and baseline schedules. (his replanning should closely consider the effects on adjacent or dependent wor1 initiatives or activities.
8. 9. G.
Esta)lis$ a sc$edule or period of performance for eac$ ris2 $andlin+ activit* t$at includes a start date and anticipated completion date. Provide a continued commitment of resources for eac$ plan to allo' t$e successful e5ecution of ris2 $andlin+ activities. Collect performance measures on ris2 $andlin+ activities.
365
366
)UPP+I$R A/R$$#$*( #A*A/$#$*(

Purpose
T$e purpose of upplier 0+reement Mana+ement ( 0M, is to mana+e t$e ac/uisition of products and services from suppliers.
Introductor" *otes
T$e scope of t$is process area addresses t$e ac/uisition of products, services, and product and service components t$at can )e delivered to t$e pro4ect;s customer or included in a product or service s*stem. T$is process area;s practices can also )e used for ot$er purposes t$at )enefit t$e pro4ect (e.+., purc$asin+ consuma)les,. T$is process area does not appl* in all conte5ts in '$ic$ commercial offt$e-s$elf (C7T , components are ac/uired )ut does appl* in cases '$ere t$ere are modifications to C7T components, +overnment off-t$e-s$elf components, or free'are, t$at are of si+nificant value to t$e pro4ect or t$at represent si+nificant pro4ect ris2. T$rou+$out t$e process areas, '$ere t$e terms LproductM and Lproduct componentM are used, t$eir intended meanin+s also encompass services, service s*stems, and t$eir components. T$e upplier 0+reement Mana+ement process area involves t$e follo'in+ activities% Determinin+ t$e t*pe of ac/uisition electin+ suppliers Esta)lis$in+ and maintainin+ a+reements 'it$ suppliers E5ecutin+ supplier a+reements 0cceptin+ deliver* of ac/uired products Ensurin+ successful transition of ac/uired products
T$is process area primaril* addresses t$e ac/uisition of products and product components t$at are delivered to t$e pro4ect;s customer. Examples of products and product components that can be ac0uired by the project include the following: *ubsystems 2e.g., navigational system on an airplane3 *oftware /ardware %ocumentation 2e.g., installation, operator9s, and user9s manuals3 'arts and materials 2e.g., gauges, switches, wheels, steel, raw materials3
S/''&"er A!reeme t Ma a!eme t :SAM;
368
To minimi-e ris2s to t$e pro4ect, t$is process area can also address t$e ac/uisition of si+nificant products and product components not delivered to t$e pro4ect;s customer )ut used to develop and maintain t$e product or service (for e5ample, development tools and test environments,. T*picall*, t$e products to )e ac/uired )* t$e pro4ect are determined durin+ t$e earl* sta+es of plannin+ and development. T$e Tec$nical olution process area provides practices for determinin+ t$e products and product components t$at can )e ac/uired from suppliers. T$is process area does not directl* address arran+ements in '$ic$ t$e supplier is inte+rated into t$e pro4ect team and uses t$e same processes and reports to t$e same mana+ement as t$e pro4ect team mem)ers (e.+., inte+rated teams,. T*picall*, t$ese situations are $andled )* ot$er processes or functions (e.+., pro4ect mana+ement processes, processes or functions e5ternal to t$e pro4ect, t$ou+$ some of t$e specific practices of t$is process area can )e useful in mana+in+ t$e supplier a+reement. T$is process area t*picall* is not implemented to address arran+ements in '$ic$ t$e pro4ect;s customer is also a supplier. T$ese situations are usuall* $andled )* eit$er informal a+reements 'it$ t$e customer or )* specification of t$e customer furnis$ed items in t$e overall a+reement t$at t$e pro4ect $as 'it$ t$e customer. In t$e latter case, some of t$e specific practices of t$is process area can )e useful in mana+in+ t$e a+reement, alt$ou+$ ot$ers ma* not, due to t$e fundamentall* different relations$ip t$at e5ists 'it$ a customer as opposed to an ordinar* supplier. ee t$e CMMI-0CB model for more information a)out ot$er t*pes of a+reements. uppliers can ta2e man* forms dependin+ on )usiness needs, includin+ in$ouse suppliers (i.e., suppliers t$at are in t$e same or+ani-ation )ut are e5ternal to t$e pro4ect,, fa)rication departments, suppliers of reuse li)raries, and commercial suppliers. ( ee t$e definition of LsupplierM in t$e +lossar*., 0 supplier a+reement is esta)lis$ed to mana+e t$e relations$ip )et'een t$e or+ani-ation and t$e supplier. 0 supplier a+reement is an* 'ritten a+reement )et'een t$e or+ani-ation (representin+ t$e pro4ect, and t$e supplier. T$is a+reement can )e a contract, license, service level a+reement, or memorandum of a+reement. T$e ac/uired product is delivered to t$e pro4ect from t$e supplier accordin+ to t$e supplier a+reement. ( ee t$e definition of Lsupplier a+reementM in t$e +lossar*.,
"efer to the Technical Solution process area for more information about performing ma1e2 buy2 or reuse analysis% "efer to the "e,uirements evelopment process area for more information about eliciting2 analy-ing2 and establishing customer2 product2 and product component re,uirements%
36<
"efer to the Pro.ect Monitoring and Control process area for more information about monitoring the pro.ect against the plan and managing corrective action to closure% "efer to the "e,uirements Management process area for more information about maintaining bidirectional traceability of re,uirements%
3 1 Esta)lis$ upplier 0+reements P 1.1 P 1." P 1.3 P ".1 P "." P ".3 Determine 0c/uisition T*pe elect uppliers Esta)lis$ upplier 0+reements E5ecute t$e upplier 0+reement 0ccept t$e 0c/uired Product Ensure Transition of Products
3 " atisf* upplier 0+reements
)pecific Practices b" /oal S7 1 E$tab&"$- S/''&"er A!reeme t$
"greements 3ith the suppliers are esta'lished and maintained.

SP 1*1 %eterm" e A#=/"$"t"o T1'e
Determine the type of ac-uisition for each product or product component to 'e ac-uired.
"efer to the Technical Solution process area for more information about performing ma1e2 buy2 or reuse analyses% Man* different t*pes of ac/uisitions can )e used to ac/uire products and product components t$at can )e used )* t$e pro4ect. Examples of types of ac0uisitions include the following: 'urchasing modified CO(* products of significant value to the project Obtaining products through a supplier agreement Obtaining products from an in5house supplier Obtaining products from the customer Obtaining products from a preferred supplier Combining some of the above 2e.g., contracting for a modification to a CO(* product, having another part of the business enterprise co5develop products with an external supplier3
If ac/uirin+ modified C7T products of si+nificant value to t$e pro4ect or t$at represent si+nificant pro4ect ris2, care in evaluatin+ and selectin+ t$ese products and t$e supplier can )e critical to t$e pro4ect. 0spects to consider in t$e selection decision include proprietar* issues and t$e availa)ilit* of t$e products.
363
1.
Aist of t$e ac/uisition t*pes t$at 'ill )e used for all products and product components to )e ac/uired
SP 1*2
Se&e#t S/''&"er$
elect suppliers 'ased on an e)aluation of their a'ility to meet the specified re-uirements and esta'lished criteria.
"efer to the ecision $nalysis and "esolution process area for more information about analy-ing possible decisions using a formal evaluation process that evaluates identified alternatives against established criteria% "efer to the "e,uirements Management process area for more information about obtaining commitment to re,uirements% Criteria s$ould )e esta)lis$ed to address factors t$at are important to t$e pro4ect. Examples of factors that can be important to the project include the following: eographical location of the supplier *upplier9s performance records on similar wor1 Engineering capabilities *taff and facilities available to perform the wor1 'rior experience in similar situations Customer satisfaction with similar products delivered by the supplier
1. ". 3. 8.
Mar2et studies Aist of candidate suppliers Preferred supplier list Trade stud* or ot$er record of evaluation criteria, advanta+es and disadvanta+es of candidate suppliers, and rationale for selection of suppliers olicitation materials and re/uirements Esta)lis$ and document criteria for evaluatin+ potential suppliers. Identif* potential suppliers and distri)ute solicitation material and re/uirements to t$em. " proactive manner of performing this activity is to conduct mar1et research to identify potential sources of candidate products to be ac0uired, including candidates from suppliers of custom made products and suppliers of CO(* products.
9. 1. ".
S/b'ra#t"#e$
3. 8.
Evaluate proposals accordin+ to evaluation criteria. Evaluate ris2s associated 'it$ eac$ proposed supplier.
380
"efer to the "is1 Management process area for more information about identifying and analy-ing ris1s% 9. Evaluate proposed suppliers; a)ilities to perform t$e 'or2. Examples of methods used to evaluate the proposed supplier9s abilities to perform the wor1 include the following:
Evaluation of prior experience in similar applications Evaluation of customer satisfaction with similar products provided Evaluation of prior performance on similar wor1 Evaluation of management capabilities Capability evaluations Evaluation of staff available to perform the wor1 Evaluation of available facilities and resources Evaluation of the project9s ability to wor1 with the proposed supplier Evaluation of the impact of candidate CO(* products on the project9s plan and commitments
4hen modified CO(* products are being evaluated, consider the following:
Cost of the modified CO(* products Cost and effort to incorporate the modified CO(* products into the project *ecurity re0uirements ;enefits and impacts that can result from future product releases
Future releases of the modified CO(* product can provide additional features that support planned or anticipated enhancements for the project, but can result in the supplier discontinuing support of its current release. G.
SP 1*3
elect t$e supplier.
E$tab&"$- S/''&"er A!reeme t$
+sta'lish and maintain supplier agreements.

0 supplier a+reement is an* 'ritten a+reement )et'een t$e or+ani-ation (representin+ t$e pro4ect, and t$e supplier. T$is a+reement can )e a contract, license, service level a+reement, or memorandum of a+reement. T$e content of t$e supplier a+reement s$ould specif* t$e arran+ement for selectin+ supplier processes and 'or2 products to )e monitored, anal*-ed, and evaluated, if t$e arran+ement is appropriate to t$e ac/uisition or product )ein+ ac/uired. T$e supplier a+reement s$ould also specif* t$e revie's, monitorin+, evaluations, and acceptance testin+ to )e performed. upplier processes t$at are critical to t$e success of t$e pro4ect (e.+., due to comple5it*, due to importance, s$ould )e monitored. upplier a+reements )et'een independent le+al entities are t*picall* revie'ed )* le+al or contract advisors prior to approval.
381
1. ". 3. 8. 1.
tatements of 'or2 Contracts Memoranda of a+reement Aicensin+ a+reement !evise t$e re/uirements (e.+., product re/uirements, service level re/uirements, to )e fulfilled )* t$e supplier to reflect ne+otiations 'it$ t$e supplier '$en necessar*. "efer to the "e,uirements evelopment process area for more information about developing product re,uirements% "efer to the "e,uirements Management process area for more information about managing re,uirements of the pro.ect3s products and product components and to ensure alignment between those re,uirements and the pro.ect3s plans and wor1 products%
S/b'ra#t"#e$
".
Document '$at t$e pro4ect 'ill provide to t$e supplier. &nclude the following:
'roject furnished facilities %ocumentation *ervices
3.
Document t$e supplier a+reement. (he supplier agreement should include a statement of wor1, a specification, terms and conditions, a list of deliverables, a schedule, a budget, and a defined acceptance process.
382
(his subpractice typically includes the following tas1s:

&dentifying the type and depth of project oversight of the supplier, procedures, and evaluation criteria to be used in monitoring supplier performance including selection of processes to be monitored and wor1 products to be evaluated Establishing the statement of wor1, specification, terms and conditions, list of deliverables, schedule, budget, and acceptance process &dentifying who from the project and supplier are responsible and authori6ed to ma1e changes to the supplier agreement &dentifying how re0uirements changes and changes to the supplier agreement are to be determined, communicated, and addressed &dentifying standards and procedures that will be followed &dentifying critical dependencies between the project and the supplier &dentifying the types of reviews that will be conducted with the supplier &dentifying the supplier9s responsibilities for ongoing maintenance and support of the ac0uired products &dentifying warranty, ownership, and rights of use for the ac0uired products &dentifying acceptance criteria
&n some cases, selection of modified CO(* products can re0uire a supplier agreement in addition to the agreements in the product9s license. Examples of what could be covered in an agreement with a CO(* supplier include the following:
%iscounts for large 0uantity purchases Coverage of relevant sta1eholders under the licensing agreement, including project suppliers, team members, and the project9s customer 'lans for future enhancements On5site support, such as responses to 0ueries and problem reports "dditional capabilities that are not in the product $aintenance support, including support after the product is withdrawn from general availability
8.
Periodicall* revie' t$e supplier a+reement to ensure it accuratel* reflects t$e pro4ect;s relations$ip 'it$ t$e supplier and current ris2s and mar2et conditions. Ensure t$at all parties to t$e supplier a+reement understand and a+ree to all re/uirements )efore implementin+ t$e a+reement or an* c$an+es. !evise t$e supplier a+reement as necessar* to reflect c$an+es to t$e supplier;s processes or 'or2 products. !evise t$e pro4ect;s plans and commitments, includin+ c$an+es to t$e pro4ect;s processes or 'or2 products, as necessar* to reflect t$e supplier a+reement. "efer to the Pro.ect Monitoring and Control process area for more information about monitoring commitments%
9.
G. =.
383
S7 2
Sat"$f1 S/''&"er A!reeme t$
"greements 3ith suppliers are satisfied 'y 'oth the pro/ect and the supplier.
SP 2*1 E,e#/te t-e S/''&"er A!reeme t
!erform acti)ities 3ith the supplier as specified in the supplier agreement.

"efer to the Pro.ect Monitoring and Control process area for more information about providing an understanding of the pro.ect3s progress so that appropriate corrective actions can be ta1en when the pro.ect3s performance deviates significantly from the plan%
1. ". 3. 8. 1. ".
upplier pro+ress reports and performance measures upplier revie' materials and reports 0ction items trac2ed to closure Product and documentation deliveries Monitor supplier pro+ress and performance (e.+., sc$edule, effort, cost, tec$nical performance, as defined in t$e supplier a+reement. elect, monitor, and anal*-e processes used )* t$e supplier as defined in t$e supplier a+reement. *upplier processes that are critical to the success of the project 2e.g., due to complexity, due to importance3 should be monitored. (he selection of processes to monitor should consider the impact of the selection on the supplier.
S/b'ra#t"#e$
3.
elect and evaluate 'or2 products from t$e supplier as defined in t$e supplier a+reement. (he wor1 products selected for evaluation should include critical products, product components, and wor1 products that provide insight into 0uality issues as early as possible. &n situations of low ris1, it may not be necessary to select any wor1 products for evaluation.
8.
Conduct revie's 'it$ t$e supplier as specified in t$e supplier a+reement. "efer to the Pro.ect Monitoring and Control process area for more information about conducting milestone reviews and conducting progress reviews% #eviews cover both formal and informal reviews and include the following steps:
'reparing for the review Ensuring that relevant sta1eholders participate Conducting the review &dentifying, documenting, and trac1ing all action items to closure 'reparing and distributing to the relevant sta1eholders a summary report of the review
384
9.
Conduct tec$nical revie's 'it$ t$e supplier as defined in t$e supplier a+reement. (echnical reviews typically include the following:
'roviding the supplier with visibility into the needs and desires of the project9s customers and end users as appropriate #eviewing the supplier9s technical activities and verifying that the supplier9s interpretation and implementation of the re0uirements are consistent with the project9s interpretation Ensuring that technical commitments are being met and that technical issues are communicated and resolved in a timely manner Obtaining technical information about the supplier9s products 'roviding appropriate technical information and support to the supplier
G.
Conduct mana+ement revie's 'it$ t$e supplier as defined in t$e supplier a+reement. $anagement reviews typically include the following:
#eviewing critical dependencies #eviewing project ris1s involving the supplier #eviewing schedule and budget #eviewing the supplier9s compliance with legal and regulatory re0uirements
(echnical and management reviews can be coordinated and held jointly. =. H. :se t$e results of revie's to improve t$e supplier;s performance and to esta)lis$ and nurture lon+-term relations$ips 'it$ preferred suppliers. Monitor ris2s involvin+ t$e supplier and ta2e corrective action as necessar*. "efer to the Pro.ect Monitoring and Control process area for more information about monitoring pro.ect ris1s%
SP 2*2 A##e't t-e A#=/"re+ Pro+/#t
+nsure that the supplier agreement is satisfied 'efore accepting the ac-uired product.
0cceptance revie's, tests, and confi+uration audits s$ould )e completed )efore acceptin+ t$e product as defined in t$e supplier a+reement.
1. ". 3. 1.
0cceptance procedures 0cceptance revie's or test results Discrepanc* reports or corrective action plans Define t$e acceptance procedures.
S/b'ra#t"#e$
385
". 3.
!evie' and o)tain a+reement from relevant sta2e$olders on t$e acceptance procedures )efore t$e acceptance revie' or test. Verif* t$at t$e ac/uired products satisf* t$eir re/uirements. "efer to the 8erification process area for more information about verifying selected wor1 products%
8.
Confirm t$at t$e nontec$nical commitments associated 'it$ t$e ac/uired 'or2 product are satisfied. (his confirmation can include confirming that the appropriate license, warranty, ownership, use, and support or maintenance agreements are in place and that all supporting materials are received.
9. G.
Document t$e results of t$e acceptance revie' or test. Esta)lis$ an action plan and o)tain supplier a+reement to ta2e action to correct ac/uired 'or2 products t$at do not pass t$eir acceptance revie' or test. Identif*, document, and trac2 action items to closure. "efer to the Pro.ect Monitoring and Control process area for more information about managing corrective action to closure%
=.
SP 2*3
E $/re Tra $"t"o of Pro+/#t$
+nsure the transition of products ac-uired from the supplier.

.efore t$e ac/uired product is transferred to t$e pro4ect, customer, or end user, appropriate preparation and evaluation s$ould occur to ensure a smoot$ transition. "efer to the Product Integration process area for more information about assembling product components%
1. ". 3. 1. ". 3.
Transition plans Trainin+ reports upport and maintenance reports Ensure t$at facilities e5ist to receive, store, inte+rate, and maintain t$e ac/uired products as appropriate. Ensure t$at appropriate trainin+ is provided for t$ose '$o are involved in receivin+, storin+, inte+ratin+, and maintainin+ ac/uired products. Ensure t$at ac/uired products are stored, distri)uted, and inte+rated accordin+ to t$e terms and conditions specified in t$e supplier a+reement or license.
S/b'ra#t"#e$
386
($!H*I!A+ )O+U(IO*
Purpose
T$e purpose of Tec$nical olution (T , is to select, desi+n, and implement solutions to re/uirements. olutions, desi+ns, and implementations encompass products, product components, and product related lifec*cle processes eit$er sin+l* or in com)ination as appropriate.
Introductor" *otes
T$e Tec$nical olution process area is applica)le at an* level of t$e product arc$itecture and to ever* product, product component, and product related lifec*cle process. T$rou+$out t$e process areas, '$ere t$e terms LproductM and Lproduct componentM are used, t$eir intended meanin+s also encompass services, service s*stems, and t$eir components. T$is process area focuses on t$e follo'in+% Evaluatin+ and selectin+ solutions (sometimes referred to as Ldesi+n approac$es,M Ldesi+n concepts,M or Lpreliminar* desi+nsM, t$at potentiall* satisf* an appropriate set of allocated functional and /ualit* attri)ute re/uirements Developin+ detailed desi+ns for t$e selected solutions (detailed in t$e conte5t of containin+ all t$e information needed to manufacture, code, or ot$er'ise implement t$e desi+n as a product or product component, Implementin+ t$e desi+ns as a product or product component
T*picall*, t$ese activities interactivel* support eac$ ot$er. ome level of desi+n, at times fairl* detailed, can )e needed to select solutions. Protot*pes or pilots can )e used as a means of +ainin+ sufficient 2no'led+e to develop a tec$nical data pac2a+e or a complete set of re/uirements. Bualit* attri)ute models, simulations, protot*pes or pilots can )e used to provide additional information a)out t$e properties of t$e potential desi+n solutions to aid in t$e selection of solutions. imulations can )e particularl* useful for pro4ects developin+ s*stems-of-s*stems. Tec$nical olution specific practices appl* not onl* to t$e product and product components )ut also to product related lifec*cle processes. T$e product related lifec*cle processes are developed in concert 'it$ t$e product or product component. uc$ development can include selectin+ and adaptin+ e5istin+ processes (includin+ standard processes, for use as 'ell as developin+ ne' processes. Processes associated 'it$ t$e Tec$nical olution process area receive t$e product and product component re/uirements from t$e re/uirements mana+ement processes. T$e re/uirements mana+ement processes place
Te#- "#a& So&/t"o :TS;
388
t$e re/uirements, '$ic$ ori+inate in re/uirements development processes, under appropriate confi+uration mana+ement and maintain t$eir tracea)ilit* to previous re/uirements. 1or a maintenance or sustainment pro4ect, t$e re/uirements in need of maintenance actions or redesi+n can )e driven )* user needs, tec$nolo+* maturation and o)solescence, or latent defects in t$e product components. <e' re/uirements can arise from c$an+es in t$e operatin+ environment. uc$ re/uirements can )e uncovered durin+ verification of t$e product(s, '$ere its actual performance can )e compared a+ainst its specified performance and unaccepta)le de+radation can )e identified. Processes associated 'it$ t$e Tec$nical olution process area s$ould )e used to perform t$e maintenance or sustainment desi+n efforts. 1or product lines, t$ese practices appl* to )ot$ core asset development (i.e., )uildin+ for reuse, and product development (i.e., )uildin+ 'it$ reuse,. Core asset development additionall* re/uires product line variation mana+ement (t$e selection and implementation of product line variation mec$anisms, and product line production plannin+ (t$e development of processes and ot$er 'or2 products t$at define $o' products 'ill )e )uilt to ma2e )est use of t$ese core assets,. &n "gile environments, the focus is on early solution exploration. ;y ma1ing the selection and tradeoff decisions more explicit, the (echnical *olution process area helps improve the 0uality of those decisions, both individually and over time. *olutions can be defined in terms of functions, feature sets, releases, or any other components that facilitate product development. 4hen someone other than the team will be wor1ing on the product in the future, release information, maintenance logs, and other data are typically included with the installed product. (o support future product updates, rationale 2for trade5offs, interfaces, and purchased parts3 is captured so that why the product exists can be better understood. &f there is low ris1 in the selected solution, the need to formally capture decisions is significantly reduced. 2*ee @&nterpreting C$$& 4hen :sing "gile "pproachesA in 'art &.3
"efer to the "e,uirements evelopment process area for more information about allocating product component re,uirements2 establishing operational concepts and scenarios2 and identifying interface re,uirements% "efer to the 8erification process area for more information about performing peer reviews and verifying selected wor1 products% "efer to the ecision $nalysis and "esolution process area for more information about analy-ing possible decisions using a formal evaluation process that evaluates identified alternatives against established criteria% "efer to the 0rgani-ational Performance Management process area for more information about selecting improvements and deploying improvements% "efer to the "e,uirements Management process area for more information about managing re,uirements of the pro.ect3s products and product
38<
components and ensuring alignment between those re,uirements and the pro.ect3s plans and wor1 products%
3 1 elect Product Component olutions P 1.1 P 1." P ".1 P "." P ".3 P ".8 P 3.1 P 3." Develop 0lternative olutions and election Criteria elect Product Component olutions Desi+n t$e Product or Product Component Esta)lis$ a Tec$nical Data Pac2a+e Desi+n Interfaces :sin+ Criteria Perform Ma2e, .u*, or !euse 0nal*ses Implement t$e Desi+n Develop Product upport Documentation
3 " Develop t$e Desi+n
3 3 Implement t$e Product Desi+n
)pecific Practices b" /oal S7 1 Se&e#t Pro+/#t Com'o e t So&/t"o $
!roduct or product component solutions are selected from alternati)e solutions.

0lternative solutions and t$eir relative merits are considered in advance of selectin+ a solution. Ne* re/uirements, desi+n issues, and constraints are esta)lis$ed for use in alternative solution anal*sis. 0rc$itectural c$oices and patterns t$at support ac$ievement of /ualit* attri)ute re/uirements are considered. 0lso, t$e use of commercial off-t$e-s$elf (C7T , product components are considered relative to cost, sc$edule, performance, and ris2. C7T alternatives can )e used 'it$ or 'it$out modification. ometimes suc$ items can re/uire modifications to aspects suc$ as interfaces or a customi-ation of some of t$e features to correct a mismatc$ 'it$ functional or /ualit* attri)ute re/uirements, or 'it$ arc$itectural desi+ns. 7ne indicator of a +ood desi+n process is t$at t$e desi+n 'as c$osen after comparin+ and evaluatin+ it a+ainst alternative solutions. Decisions a)out arc$itecture, custom development versus off t$e s$elf, and product component modulari-ation are t*pical of t$e desi+n c$oices t$at are addressed. ome of t$ese decisions can re/uire t$e use of a formal evaluation process. "efer to the ecision $nalysis and "esolution process area for more information about analy-ing possible decisions using a formal evaluation process that evaluates identified alternatives against established criteria% ometimes t$e searc$ for solutions e5amines alternative instances of t$e same re/uirements 'it$ no allocations needed for lo'er level product components. uc$ is t$e case at t$e )ottom of t$e product arc$itecture. T$ere are also cases '$ere one or more of t$e solutions are fi5ed (e.+., a specific solution is directed or availa)le product components, suc$ as C7T , are investi+ated for use,.
383
In t$e +eneral case, solutions are defined as a set. T$at is, '$en definin+ t$e ne5t la*er of product components, t$e solution for eac$ of t$e product components in t$e set is esta)lis$ed. T$e alternative solutions are not onl* different 'a*s of addressin+ t$e same re/uirements, )ut t$e* also reflect a different allocation of re/uirements amon+ t$e product components comprisin+ t$e solution set. T$e o)4ective is to optimi-e t$e set as a '$ole and not t$e individual pieces. T$ere 'ill )e si+nificant interaction 'it$ processes associated 'it$ t$e !e/uirements Development process area to support t$e provisional allocations to product components until a solution set is selected and final allocations are esta)lis$ed. Product related lifec*cle processes are amon+ t$e product component solutions t$at are selected from alternative solutions. E5amples of t$ese product related lifec*cle processes are t$e manufacturin+, deliver*, and support processes.
SP 1*1 %eve&o' A&ter at"ve So&/t"o $ a + Se&e#t"o Cr"ter"a
De)elop alternati)e solutions and selection criteria.

"efer to the $llocate Product Component "e,uirements specific practice in the "e,uirements evelopment process area for more information about obtaining allocations of re,uirements to solution alternatives for the product components% "efer to the ecision $nalysis and "esolution process area for more information about establishing evaluation criteria% 0lternative solutions s$ould )e identified and anal*-ed to ena)le t$e selection of a )alanced solution across t$e life of t$e product in terms of cost, sc$edule, performance, and ris2. T$ese solutions are )ased on proposed product arc$itectures t$at address critical product /ualit* attri)ute re/uirements and span a desi+n space of feasi)le solutions. pecific practices associated 'it$ t$e Develop t$e Desi+n specific +oal provide more information on developin+ potential product arc$itectures t$at can )e incorporated into alternative solutions for t$e product. 0lternative solutions fre/uentl* encompass alternative re/uirement allocations to different product components. T$ese alternative solutions can also include t$e use of C7T solutions in t$e product arc$itecture. Processes associated 'it$ t$e !e/uirements Development process area 'ould t$en )e emplo*ed to provide a more complete and ro)ust provisional allocation of re/uirements to t$e alternative solutions. 0lternative solutions span t$e accepta)le ran+e of cost, sc$edule, and performance. T$e product component re/uirements are received and used alon+ 'it$ desi+n issues, constraints, and criteria to develop t$e alternative solutions. election criteria 'ould t*picall* address costs (e.+., time, people, mone*,, )enefits (e.+., product performance, capa)ilit*, effectiveness,, and ris2s (e.+., tec$nical, cost, sc$edule,. Considerations for alternative solutions and selection criteria include t$e follo'in+% Cost of development, manufacturin+, procurement, maintenance, and support
3<0
0c$ievement of 2e* /ualit* attri)ute re/uirements, suc$ as product timeliness, safet*, relia)ilit*, and maintaina)ilit* Comple5it* of t$e product component and product related lifec*cle processes !o)ustness to product operatin+ and use conditions, operatin+ modes, environments, and variations in product related lifec*cle processes Product e5pansion and +ro't$ Tec$nolo+* limitations ensitivit* to construction met$ods and materials !is2 Evolution of re/uirements and tec$nolo+* Disposal Capa)ilities and limitations of end users and operators C$aracteristics of C7T products
T$e considerations listed $ere are a )asic setI or+ani-ations s$ould develop screenin+ criteria to narro' do'n t$e list of alternatives t$at are consistent 'it$ t$eir )usiness o)4ectives. Product lifec*cle cost, '$ile )ein+ a desira)le parameter to minimi-e, can )e outside t$e control of development or+ani-ations. 0 customer ma* not )e 'illin+ to pa* for features t$at cost more in t$e s$ort term )ut ultimatel* decrease cost over t$e life of t$e product. In suc$ cases, customers s$ould at least )e advised of an* potential for reducin+ lifec*cle costs. T$e criteria used to select final solutions s$ould provide a )alanced approac$ to costs, )enefits, and ris2s.
1. ". 3. 8. 9. 1. ".
0lternative solution screenin+ criteria Evaluation reports of ne' tec$nolo+ies 0lternative solutions election criteria for final selection Evaluation reports of C7T products Identif* screenin+ criteria to select a set of alternative solutions for consideration. Identif* tec$nolo+ies currentl* in use and ne' product tec$nolo+ies for competitive advanta+e. "efer to the 0rgani-ational Performance Management process area for more information about selecting improvements and deploying improvements% (he project should identify technologies applied to current products and processes and monitor the progress of currently used technologies throughout the life of the project. (he project should identify, select, evaluate, and invest in new technologies to achieve competitive advantage. "lternative solutions could include newly developed
S/b'ra#t"#e$
3<1
technologies, but could also include applying mature technologies in different applications or to maintain current methods. 3. Identif* candidate C7T products t$at satisf* t$e re/uirements. "efer to the Supplier $greement Management process area for more information about selecting suppliers% (he supplier of the CO(* product will need to meet re0uirements that include the following:
'roduct functionality and 0uality attributes (erms and conditions of warranties for the products Expectations 2e.g., for review activities3, constraints, or chec1points to help mitigate suppliers? responsibilities for ongoing maintenance and support of the products
8.
Identif* re-usa)le solution components or applica)le arc$itecture patterns. For product lines, the organi6ation9s core assets can be used as a basis for a solution.
9. G. =.
3enerate alternative solutions. 7)tain a complete re/uirements allocation for eac$ alternative. Develop t$e criteria for selectin+ t$e )est alternative solution. Criteria should be included that address design issues for the life of the product, such as provisions for more easily inserting new technologies or the ability to better exploit commercial products. Examples include criteria related to open design or open architecture concepts for the alternatives being evaluated.
SP 1*2
Se&e#t Pro+/#t Com'o e t So&/t"o $
elect the product component solutions 'ased on selection criteria.

"efer to the $llocate Product Component "e,uirements and Identify Interface "e,uirements specific practices of the "e,uirements evelopment process area for more information about establishing the allocated re,uirements for product components and interface re,uirements among product components% electin+ product components t$at )est satisf* t$e criteria esta)lis$es t$e re/uirement allocations to product components. Ao'er level re/uirements are +enerated from t$e selected alternative and used to develop product component desi+ns. Interfaces amon+ product components are descri)ed. P$*sical interface descriptions are included in t$e documentation for interfaces to items and activities e5ternal to t$e product. T$e description of t$e solutions and t$e rationale for selection are documented. T$e documentation evolves t$rou+$out development as solutions and detailed desi+ns are developed and t$ose desi+ns are implemented. Maintainin+ a record of rationale is critical to do'nstream decision ma2in+. uc$ records 2eep do'nstream sta2e$olders from redoin+ 'or2 and provide insi+$ts to appl* tec$nolo+* as it )ecomes availa)le in applica)le circumstances.
3<2
1. ". 3. 1.
Product component selection decisions and rationale Documented relations$ips )et'een re/uirements and product components Documented solutions, evaluations, and rationale Evaluate eac$ alternative solution&set of solutions a+ainst t$e selection criteria esta)lis$ed in t$e conte5t of t$e operational concepts and scenarios. %evelop timeline scenarios for product operation and user interaction for each alternative solution.
S/b'ra#t"#e$
". 3. 8. 9.
.ased on t$e evaluation of alternatives, assess t$e ade/uac* of t$e selection criteria and update t$ese criteria as necessar*. Identif* and resolve issues 'it$ t$e alternative solutions and re/uirements. elect t$e )est set of alternative solutions t$at satisf* t$e esta)lis$ed selection criteria. Esta)lis$ t$e functional and /ualit* attri)ute re/uirements associated 'it$ t$e selected set of alternatives as t$e set of allocated re/uirements to t$ose product components. Identif* t$e product component solutions t$at 'ill )e reused or ac/uired. "efer to the Supplier $greement Management process area for more information about managing the ac,uisition of products and services from suppliers%
G.
=.
Esta)lis$ and maintain t$e documentation of t$e solutions, evaluations, and rationale.
S7 2
%eve&o' t-e %e$"!
!roduct or product component designs are de)eloped.

Product or product component desi+ns s$ould provide t$e appropriate content not onl* for implementation, )ut also for ot$er p$ases of t$e product lifec*cle suc$ as modification, reprocurement, maintenance, sustainment, and installation. T$e desi+n documentation provides a reference to support mutual understandin+ of t$e desi+n )* relevant sta2e$olders and supports future c$an+es to t$e desi+n )ot$ durin+ development and in su)se/uent p$ases of t$e product lifec*cle. 0 complete desi+n description is documented in a tec$nical data pac2a+e t$at includes a full ran+e of features and parameters includin+ form, fit, function, interface, manufacturin+ process c$aracteristics, and ot$er parameters. Esta)lis$ed or+ani-ational or pro4ect desi+n standards (e.+., c$ec2lists, templates, o)4ect frame'or2s, form t$e )asis for ac$ievin+ a $i+$ de+ree of definition and completeness in desi+n documentation.
3<3
SP 2*1
%e$"! t-e Pro+/#t or Pro+/#t Com'o e t
De)elop a design for the product or product component.

Product desi+n consists of t'o )road p$ases t$at can overlap in e5ecution% preliminar* and detailed desi+n. Preliminar* desi+n esta)lis$es product capa)ilities and t$e product arc$itecture, includin+ arc$itectural st*les and patterns, product partitions, product component identifications, s*stem states and modes, ma4or intercomponent interfaces, and e5ternal product interfaces. Detailed desi+n full* defines t$e structure and capa)ilities of t$e product components. "efer to the Establish a efinition of "e,uired 9unctionality and 4uality $ttributes specific practice in the "e,uirements evelopment process area for more information about developing architectural re,uirements% 0rc$itecture definition is driven from a set of arc$itectural re/uirements developed durin+ t$e re/uirements development processes. T$ese re/uirements identif* t$e /ualit* attri)utes t$at are critical to t$e success of t$e product. T$e arc$itecture defines structural elements and coordination mec$anisms t$at eit$er directl* satisf* re/uirements or support t$e ac$ievement of t$e re/uirements as t$e details of t$e product desi+n are esta)lis$ed. 0rc$itectures can include standards and desi+n rules +overnin+ development of product components and t$eir interfaces as 'ell as +uidance to aid product developers. pecific practices in t$e elect Product Component olutions specific +oal contain more information a)out usin+ product arc$itectures as a )asis for alternative solutions. 0rc$itects postulate and develop a model of t$e product, ma2in+ 4ud+ments a)out allocation of functional and /ualit* attri)ute re/uirements to product components includin+ $ard'are and soft'are. Multiple arc$itectures, supportin+ alternative solutions, can )e developed and anal*-ed to determine t$e advanta+es and disadvanta+es in t$e conte5t of t$e arc$itectural re/uirements. 7perational concepts and operational, sustainment, and development scenarios are used to +enerate use cases and /ualit* attri)ute related scenarios t$at are used to refine t$e arc$itecture. T$e* are also used as a means to evaluate t$e suita)ilit* of t$e arc$itecture for its intended purpose durin+ arc$itecture evaluations, '$ic$ are conducted periodicall* t$rou+$out product desi+n. "efer to the Establish 0perational Concepts and Scenarios specific practice in the "e,uirements evelopment process area for more information about developing operational concepts and scenarios used in architecture evaluation%
3<4
Examples of architecture definition tas1s include the following: Establishing the structural relations of partitions and rules regarding interfaces between elements within partitions, and between partitions *electing architectural patterns that support the functional and 0uality attribute re0uirements, and instantiating or composing those patterns to create the product architecture &dentifying major internal interfaces and all external interfaces &dentifying product components and interfaces between them Formally defining component behavior and interaction using an architecture description language %efining coordination mechanisms 2e.g., for software, hardware3 Establishing infrastructure capabilities and services %eveloping product component templates or classes and framewor1s Establishing design rules and authority for ma1ing decisions %efining a processEthread model %efining physical deployment of software to hardware &dentifying major reuse approaches and sources
Durin+ detailed desi+n, t$e product arc$itecture details are finali-ed, product components are completel* defined, and interfaces are full* c$aracteri-ed. Product component desi+ns can )e optimi-ed for certain /ualit* attri)utes. Desi+ners can evaluate t$e use of le+ac* or C7T products for t$e product components. 0s t$e desi+n matures, t$e re/uirements assi+ned to lo'er level product components are trac2ed to ensure t$at t$ose re/uirements are satisfied. "efer to the "e,uirements Management process area for more information about ensuring alignment between pro.ect wor1 and re,uirements% 1or soft'are en+ineerin+, detailed desi+n is focused on soft'are product component development. T$e internal structure of product components is defined, data sc$emas are +enerated, al+orit$ms are developed, and $euristics are esta)lis$ed to provide product component capa)ilities t$at satisf* allocated re/uirements. 1or $ard'are en+ineerin+, detailed desi+n is focused on product development of electronic, mec$anical, electro-optical, and ot$er $ard'are products and t$eir components. Electrical sc$ematics and interconnection dia+rams are developed, mec$anical and optical assem)l* models are +enerated, and fa)rication and assem)l* processes are developed.
1. ". 1.
Product arc$itecture Product component desi+n Esta)lis$ and maintain criteria a+ainst '$ic$ t$e desi+n can )e evaluated.
S/b'ra#t"#e$
3<5
Examples of 0uality attributes, in addition to expected product performance, for which design criteria can be established, include the following:
$odular Clear *imple $aintainable ,erifiable 'ortable #eliable "ccurate *ecure *calable :sable
".
Identif*, develop, or ac/uire t$e desi+n met$ods appropriate for t$e product. Effective design methods can embody a wide range of activities, tools, and descriptive techni0ues. 4hether a given method is effective or not depends on the situation. (wo companies may have effective design methods for products in which they speciali6e, but these methods may not be effective in cooperative ventures. /ighly sophisticated methods are not necessarily effective in the hands of designers who have not been trained in the use of the methods. 4hether a method is effective also depends on how much assistance it provides the designer, and the cost effectiveness of that assistance. For example, a multiyear prototyping effort may not be appropriate for a simple product component but might be the right thing to do for an unprecedented, expensive, and complex product development. #apid prototyping techni0ues, however, can be highly effective for many product components. $ethods that use tools to ensure that a design will encompass all the necessary attributes needed to implement the product component design can be effective. For example, a design tool that @1nowsA the capabilities of the manufacturing processes can allow the variability of the manufacturing process to be accounted for in the design tolerances. Examples of techni0ues and methods that facilitate effective design include the following:
'rototypes *tructural models Object oriented design Essential systems analysis Entity relationship models %esign reuse %esign patterns
3<6
3.
Ensure t$at t$e desi+n ad$eres to applica)le desi+n standards and criteria. Examples of design standards include the following 2some or all of these standards may be design criteria, particularly in circumstances where the standards have not been established3:
Operator interface standards (est scenarios *afety standards %esign constraints 2e.g., electromagnetic compatibility, signal integrity, environmental3 'roduction constraints %esign tolerances 'arts standards 2e.g., production scrap, waste3
8.
Ensure t$at t$e desi+n ad$eres to allocated re/uirements. &dentified CO(* product components should be ta1en into account. For example, putting existing product components into the product architecture might modify the re0uirements and the re0uirements allocation.
9.
SP 2*2
Document t$e desi+n.
E$tab&"$- a Te#- "#a& %ata Pa#?a!e
+sta'lish and maintain a technical data pac4age.

0 tec$nical data pac2a+e provides t$e developer 'it$ a compre$ensive description of t$e product or product component as it is developed. uc$ a pac2a+e also provides procurement fle5i)ilit* in a variet* of circumstances suc$ as performance )ased contractin+ or )uild-to-print. ( ee t$e definition of Ltec$nical data pac2a+eM in t$e +lossar*., T$e desi+n is recorded in a tec$nical data pac2a+e t$at is created durin+ preliminar* desi+n to document t$e arc$itecture definition. T$is tec$nical data pac2a+e is maintained t$rou+$out t$e life of t$e product to record essential details of t$e product desi+n. T$e tec$nical data pac2a+e provides t$e description of a product or product component (includin+ product related lifec*cle processes if not $andled as separate product components, t$at supports an ac/uisition strate+*, or t$e implementation, production, en+ineerin+, and lo+istics support p$ases of t$e product lifec*cle. T$e description includes t$e definition of t$e re/uired desi+n confi+uration and procedures to ensure ade/uac* of product or product component performance. It includes all applica)le tec$nical data suc$ as dra'in+s, associated lists, specifications, desi+n descriptions, desi+n data)ases, standards, /ualit* attri)ute re/uirements, /ualit* assurance provisions, and pac2a+in+ details. T$e tec$nical data pac2a+e includes a description of t$e selected alternative solution t$at 'as c$osen for implementation.
3<8
.ecause desi+n descriptions can involve a lar+e amount of data and can )e crucial to successful product component development, it is advisa)le to esta)lis$ criteria for or+ani-in+ t$e data and for selectin+ t$e data content. It is particularl* useful to use t$e product arc$itecture as a means of or+ani-in+ t$is data and a)stractin+ vie's t$at are clear and relevant to an issue or feature of interest. T$ese vie's include t$e follo'in+% Customers !e/uirements T$e environment 1unctional Ao+ical ecurit* Data tates&modes Construction Mana+ement
T$ese vie's are documented in t$e tec$nical data pac2a+e.

1. 1.
Tec$nical data pac2a+e Determine t$e num)er of levels of desi+n and t$e appropriate level of documentation for eac$ desi+n level. %etermining the number of levels of product components 2e.g., subsystem, hardware configuration item, circuit board, computer software configuration item IC*C&J, computer software product component, computer software unit3 that re0uire documentation and re0uirements traceability is important to manage documentation costs and to support integration and verification plans.
S/b'ra#t"#e$
".
Determine t$e vie's to )e used to document t$e arc$itecture. ,iews are selected to document the structures inherent in the product and to address particular sta1eholder concerns.
3. 8. 9. G.
.ase detailed desi+n descriptions on t$e allocated product component re/uirements, arc$itecture, and $i+$er level desi+ns. Document t$e desi+n in t$e tec$nical data pac2a+e. Document t$e 2e* (i.e., si+nificant effect on cost, sc$edule, or tec$nical performance, decisions made or defined, includin+ t$eir rationale. !evise t$e tec$nical data pac2a+e as necessar*.
3<<
SP 2*3
%e$"! I terfa#e$ U$" ! Cr"ter"a
Design product component interfaces using esta'lished criteria.

Interface desi+ns include t$e follo'in+% 7ri+ination Destination timulus and data c$aracteristics for soft'are, includin+ se/uencin+ constraints or protocols !esources consumed processin+ a particular stimulus E5ception or error $andlin+ )e$avior for stimuli t$at are erroneous or out of specified limits Electrical, mec$anical, and functional c$aracteristics for $ard'are ervices lines of communication
T$e criteria for interfaces fre/uentl* reflect critical parameters t$at s$ould )e defined, or at least investi+ated, to ascertain t$eir applica)ilit*. T$ese parameters are often peculiar to a +iven t*pe of product (e.+., soft'are, mec$anical, electrical, service, and are often associated 'it$ safet*, securit*, dura)ilit*, and mission critical c$aracteristics. "efer to the Identify Interface "e,uirements specific practice in the "e,uirements evelopment process area for more information about identifying product and product component interface re,uirements%
1. ". 3. 8. 1.
Interface desi+n specifications Interface control documents Interface specification criteria !ationale for selected interface desi+n Define interface criteria. (hese criteria can be a part of the organi6ational process assets. "efer to the 0rgani-ational Process efinition process area for more information about establishing and maintaining a usable set of organi-ational process assets and wor1 environment standards%
S/b'ra#t"#e$
". 3. 8.
Identif* interfaces associated 'it$ ot$er product components. Identif* interfaces associated 'it$ e5ternal items. Identif* interfaces )et'een product components and t$e product related lifec*cle processes. For example, such interfaces could include the ones between a product component to be fabricated and the jigs and fixtures used to enable that fabrication during the manufacturing process.
9.
0ppl* t$e criteria to t$e interface desi+n alternatives.
3<3
"efer to the ecision $nalysis and "esolution process area for more information about analy-ing possible decisions using a formal evaluation process that evaluates identified alternatives against established criteria% G. Document t$e selected interface desi+ns and t$e rationale for t$e selection.
SP 2*4
Perform Ma?e( 9/1( or Re/$e A a&1$e$
+)aluate 3hether the product components should 'e de)eloped* purchased* or reused 'ased on esta'lished criteria.
T$e determination of '$at products or product components 'ill )e ac/uired is fre/uentl* referred to as a Lma2e-or-)u* anal*sis.M It is )ased on an anal*sis of t$e needs of t$e pro4ect. T$is ma2e-or-)u* anal*sis )e+ins earl* in t$e pro4ect durin+ t$e first iteration of desi+nI continues durin+ t$e desi+n processI and is completed 'it$ t$e decision to develop, ac/uire, or reuse t$e product. "efer to the "e,uirements evelopment process area for more information about eliciting2 analy-ing2 and establishing customer2 product2 and product component re,uirements% "efer to the "e,uirements Management process area for more information about managing re,uirements% 1actors affectin+ t$e ma2e-or-)u* decision include t$e follo'in+% 1unctions t$e products 'ill provide and $o' t$ese functions 'ill fit into t$e pro4ect 0vaila)le pro4ect resources and s2ills Costs of ac/uirin+ versus developin+ internall* Critical deliver* and inte+ration dates trate+ic )usiness alliances, includin+ $i+$-level )usiness re/uirements Mar2et researc$ of availa)le products, includin+ C7T products 1unctionalit* and /ualit* of availa)le products 2ills and capa)ilities of potential suppliers Impact on core competencies Aicenses, 'arranties, responsi)ilities, and limitations associated 'it$ products )ein+ ac/uired Product availa)ilit* Proprietar* issues !is2 reduction Matc$ )et'een needs and product line core assets
T$e ma2e-or-)u* decision can )e conducted usin+ a formal evaluation approac$. "efer to the ecision $nalysis and "esolution process area for more information about analy-ing possible decisions using a formal evaluation process that evaluates identified alternatives against established criteria%
330
0s tec$nolo+* evolves, so does t$e rationale for c$oosin+ to develop or purc$ase a product component. 6$ile comple5 development efforts can favor purc$asin+ an off-t$e-s$elf product component, advances in productivit* and tools can provide an opposin+ rationale. 7ff-t$e-s$elf products can $ave incomplete or inaccurate documentation and ma* or ma* not )e supported in t$e future. 7nce t$e decision is made to purc$ase an off-t$e-s$elf product component, $o' to implement t$at decision depends on t$e t*pe of item )ein+ ac/uired. T$ere are times '$en Loff t$e s$elfM refers to an e5istin+ item t$at is not readil* availa)le )ecause it must first )e customi-ed to meet particular purc$aser specified re/uirements for performance and ot$er product c$aracteristics as part of its procurement (e.+., aircraft en+ines,. To mana+e suc$ procurements, a supplier a+reement is esta)lis$ed t$at includes t$ese re/uirements and t$e acceptance criteria to )e met. In ot$er cases, t$e off-t$e-s$elf product is literall* off t$e s$elf ('ord processin+ soft'are, for e5ample, and t$ere is no a+reement 'it$ t$e supplier t$at needs to )e mana+ed. "efer to the Establish Supplier $greements specific goal in the Supplier $greement Management process area for more information about handling supplier agreements for modified C0TS products%
1. ". 3. 1. ". 3.
Criteria for desi+n and product component reuse Ma2e-or-)u* anal*ses 3uidelines for c$oosin+ C7T product components Develop criteria for t$e reuse of product component desi+ns. 0nal*-e desi+ns to determine if product components s$ould )e developed, reused, or purc$ased. 0nal*-e implications for maintenance '$en considerin+ purc$ased or nondevelopmental (e.+., C7T , +overnment off t$e s$elf, reuse, items. Examples of implications for maintenance include the following:
Compatibility with future releases of CO(* products Configuration management of supplier changes %efects in the nondevelopmental item and their resolution :nplanned obsolescence
S/b'ra#t"#e$
S7 3
Im'&eme t t-e Pro+/#t %e$"!
!roduct components* and associated support documentation* are implemented from their designs.
Product components are implemented from t$e desi+ns esta)lis$ed )* t$e specific practices in t$e Develop t$e Desi+n specific +oal. T$e implementation usuall* includes unit testin+ of t$e product components
331
)efore sendin+ t$em to product inte+ration and development of end-user documentation.

SP 3*1 Im'&eme t t-e %e$"!
Implement the designs of the product components.

7nce t$e desi+n $as )een completed, it is implemented as a product component. T$e c$aracteristics of t$at implementation depend on t$e t*pe of product component. Desi+n implementation at t$e top level of t$e product $ierarc$* involves t$e specification of eac$ of t$e product components at t$e ne5t level of t$e product $ierarc$*. T$is activit* includes t$e allocation, refinement, and verification of eac$ product component. It also involves t$e coordination )et'een t$e various product component development efforts. "efer to the Product Integration process area for more information about managing interfaces and assembling product components% "efer to the "e,uirements evelopment process area for more information about the allocating product component re,uirements and analy-ing re,uirements% Example characteristics of this implementation are as follows: *oftware is coded. %ata are documented. *ervices are documented. Electrical and mechanical parts are fabricated. 'roduct5uni0ue manufacturing processes are put into operation. 'rocesses are documented. Facilities are constructed. $aterials are produced 2e.g., a product5uni0ue material could be petroleum, oil, a lubricant, a new alloy3.
1. 1.
Implemented desi+n :se effective met$ods to implement t$e product components. Examples of software coding methods include the following:
*tructured programming Object oriented programming "spect oriented programming "utomatic code generation *oftware code reuse :se of applicable design patterns
S/b'ra#t"#e$
332
Examples of hardware implementation methods include the following:

ate level synthesis Circuit board layout 2place and route3 Computer aided design drawing 'ost layout simulation Fabrication methods
".
0d$ere to applica)le standards and criteria. Examples of implementation standards include the following:
-anguage standards 2e.g., standards for software programming languages, hardware description languages3 %rawing re0uirements *tandard parts lists $anufactured parts *tructure and hierarchy of software product components 'rocess and 0uality standards
Examples of criteria include the following:

$odularity Clarity *implicity #eliability *afety $aintainability
3.
Conduct peer revie's of t$e selected product components. "efer to the 8erification process area for more information about performing peer reviews%
8.
Perform unit testin+ of t$e product component as appropriate. 7ote that unit testing is not limited to software. :nit testing involves the testing of individual hardware or software units or groups of related items prior to integration of those items. "efer to the 8erification process area for more information about verifying selected wor1 products% Examples of unit testing methods 2manual or automated3 include the following:
*tatement coverage testing ;ranch coverage testing 'redicate coverage testing 'ath coverage testing ;oundary value testing
333
*pecial value testing
Examples of unit testing methods include the following:

Functional testing #adiation inspection testing Environmental testing
9.
!evise t$e product component as necessar*. "n example of when the product component may need to be revised is when problems surface during implementation that could not be foreseen during design.
SP 3*2
%eve&o' Pro+/#t S/''ort %o#/me tat"o
De)elop and maintain the end:use documentation.

T$is specific practice develops and maintains t$e documentation t$at 'ill )e used to install, operate, and maintain t$e product.
1. ". 3. 8. 9. 1.
End-user trainin+ materials :serPs manual 7peratorPs manual Maintenance manual 7nline $elp !evie' t$e re/uirements, desi+n, product, and test results to ensure t$at issues affectin+ t$e installation, operation, and maintenance documentation are identified and resolved. :se effective met$ods to develop t$e installation, operation, and maintenance documentation. 0d$ere to t$e applica)le documentation standards. Examples of documentation standards include the following:
Compatibility with designated word processors "cceptable fonts 7umbering of pages, sections, and paragraphs Consistency with a designated style manual :se of abbreviations *ecurity classification mar1ings &nternationali6ation re0uirements
S/b'ra#t"#e$
". 3.
334
8.
Develop preliminar* versions of t$e installation, operation, and maintenance documentation in earl* p$ases of t$e pro4ect lifec*cle for revie' )* t$e relevant sta2e$olders. Conduct peer revie's of t$e installation, operation, and maintenance documentation. "efer to the 8erification process area for more information about performing peer reviews%
9.
G.
!evise t$e installation, operation, and maintenance documentation as necessar*. Examples of when documentation may need to be revised include when the following events occur:
#e0uirements changes are made %esign changes are made 'roduct changes are made %ocumentation errors are identified 4or1around fixes are identified
335
336
3A+IDA(IO*
Purpose
T$e purpose of Validation (V0A, is to demonstrate t$at a product or product component fulfills its intended use '$en placed in its intended environment.
Introductor" *otes
Validation activities can )e applied to all aspects of t$e product in an* of its intended environments, suc$ as operation, trainin+, manufacturin+, maintenance, and support services. T$e met$ods emplo*ed to accomplis$ validation can )e applied to 'or2 products as 'ell as to t$e product and product components. (T$rou+$out t$e process areas, '$ere t$e terms LproductM and Lproduct componentM are used, t$eir intended meanin+s also encompass services, service s*stems, and t$eir components., T$e 'or2 products (e.+., re/uirements, desi+ns, protot*pes, s$ould )e selected on t$e )asis of '$ic$ are t$e )est predictors of $o' 'ell t$e product and product component 'ill satisf* end user needs and t$us validation is performed earl* (concept&e5ploration p$ases, and incrementall* t$rou+$out t$e product lifec*cle (includin+ transition to operations and sustainment,. T$e validation environment s$ould represent t$e intended environment for t$e product and product components as 'ell as represent t$e intended environment suita)le for validation activities 'it$ 'or2 products. Validation demonstrates t$at t$e product, as provided, 'ill fulfill its intended useI '$ereas, verification addresses '$et$er t$e 'or2 product properl* reflects t$e specified re/uirements. In ot$er 'ords, verification ensures t$at L*ou )uilt it ri+$tMI '$ereas, validation ensures t$at L*ou )uilt t$e ri+$t t$in+.M Validation activities use approac$es similar to verification (e.+., test, anal*sis, inspection, demonstration, simulation,. 7ften, t$e end users and ot$er relevant sta2e$olders are involved in t$e validation activities. .ot$ validation and verification activities often run concurrentl* and can use portions of t$e same environment. "efer to the 8erification process area for more information about ensuring that selected wor1 products meet their specified re,uirements% 6$enever possi)le, validation s$ould )e accomplis$ed usin+ t$e product or product component operatin+ in its intended environment. T$e entire environment can )e used or onl* part of it. @o'ever, validation issues can )e discovered earl* in t$e life of t$e pro4ect usin+ 'or2 products )* involvin+ relevant sta2e$olders. Validation activities for services can )e applied to 'or2 products suc$ as proposals, service catalo+s, statements of 'or2, and service records.
)a&"+at"o :)AL;
338
6$en validation issues are identified, t$e* are referred to processes associated 'it$ t$e !e/uirements Development, Tec$nical olution, or Pro4ect Monitorin+ and Control process areas for resolution. T$e specific practices of t$is process area )uild on eac$ ot$er in t$e follo'in+ 'a*% T$e elect Products for Validation specific practice ena)les t$e identification of t$e product or product component to )e validated and met$ods to )e used to perform t$e validation. T$e Esta)lis$ t$e Validation Environment specific practice ena)les t$e determination of t$e environment to )e used to carr* out t$e validation. T$e Esta)lis$ Validation Procedures and Criteria specific practice ena)les t$e development of validation procedures and criteria t$at are ali+ned 'it$ t$e c$aracteristics of selected products, customer constraints on validation, met$ods, and t$e validation environment. T$e Perform Validation specific practice ena)les t$e performance of validation accordin+ to met$ods, procedures, and criteria.
"efer to the "e,uirements evelopment process area for more information about eliciting2 analy-ing2 and establishing customer2 product2 and product component re,uirements% "efer to the Technical Solution process area for more information about selecting2 designing2 and implementing solutions to re,uirements% "efer to the 8erification process area for more information about ensuring that selected wor1 products meet their specified re,uirements%
3 1 Prepare for Validation P 1.1 P 1." P 1.3 P ".1 P "." elect Products for Validation Esta)lis$ t$e Validation Environment Esta)lis$ Validation Procedures and Criteria Perform Validation 0nal*-e Validation !esults
3 " Validate Product or Product Components
)pecific Practices b" /oal S7 1 Pre'are for )a&"+at"o
!reparation for )alidation is conducted.

Preparation activities include selectin+ products and product components for validation and esta)lis$in+ and maintainin+ t$e validation environment, procedures, and criteria. Items selected for validation can include onl* t$e product or it can include appropriate levels of product components used to )uild t$e product. 0n* product or product component can )e su)4ect to validation, includin+ replacement, maintenance, and trainin+ products, to name a fe'.
33<
)a&"+at"o :)AL;
T$e environment re/uired to validate t$e product or product component is prepared. T$e environment can )e purc$ased or can )e specified, desi+ned, and )uilt. Environments used for product inte+ration and verification can )e considered in colla)oration 'it$ t$e validation environment to reduce cost and improve efficienc* or productivit*.
SP 1*1 Se&e#t Pro+/#t$ for )a&"+at"o
elect products and product components to 'e )alidated and )alidation methods to 'e used.
Products and product components are selected for validation )ased on t$eir relations$ip to end user needs. 1or eac$ product component, t$e scope of t$e validation (e.+., operational )e$avior, maintenance, trainin+, user interface, s$ould )e determined. Examples of products and product components that can be validated include the following: 'roduct and product component re0uirements and designs 'roduct and product components 2e.g., system, hardware units, software, service documentation3 :ser interfaces :ser manuals (raining materials 'rocess documentation "ccess protocols %ata interchange reporting formats
T$e re/uirements and constraints for performin+ validation are collected. T$en, validation met$ods are selected )ased on t$eir a)ilit* to demonstrate t$at end user needs are satisfied. T$e validation met$ods not onl* define t$e approac$ to product validation, )ut also drive t$e needs for t$e facilities, e/uipment, and environments. T$e validation approac$ and needs can result in t$e +eneration of lo'er level product component re/uirements t$at are $andled )* t$e re/uirements development processes. Derived re/uirements, suc$ as interface re/uirements to test sets and test e/uipment, can )e +enerated. T$ese re/uirements are also passed to t$e re/uirements development processes to ensure t$at t$e product or product components can )e validated in an environment t$at supports t$e met$ods. Validation met$ods s$ould )e selected earl* in t$e life of t$e pro4ect so t$e* are clearl* understood and a+reed to )* relevant sta2e$olders. Validation met$ods address t$e development, maintenance, support, and trainin+ for t$e product or product component as appropriate.
)a&"+at"o :)AL;
333
Examples of validation methods include the following: %iscussions with end users, perhaps in the context of a formal review 'rototype demonstrations Functional demonstrations 2e.g., system, hardware units, software, service documentation, user interfaces3 'ilots of training materials (ests of products and product components by end users and other relevant sta1eholders &ncremental delivery of wor1ing and potentially acceptable product "nalyses of product and product components 2e.g., simulations, modeling, user analyses3
/ardware validation activities include modeling to validate form, fit, and function of mechanical designs8 thermal modeling8 maintainability and reliability analysis8 timeline demonstrations8 and electrical design simulations of electronic or mechanical product components.
1. ". 3. 8. 1. ".
Aists of products and product components selected for validation Validation met$ods for eac$ product or product component !e/uirements for performin+ validation for eac$ product or product component Validation constraints for eac$ product or product component Identif* t$e 2e* principles, features, and p$ases for product or product component validation t$rou+$out t$e life of t$e pro4ect. Determine '$ic$ cate+ories of end user needs (operational, maintenance, trainin+, or support, are to )e validated. (he product or product component should be maintainable and supportable in its intended operational environment. (his specific practice also addresses the actual maintenance, training, and support services that can be delivered with the product. "n example of evaluation of maintenance concepts in the operational environment is a demonstration that maintenance tools are operating with the actual product.
S/b'ra#t"#e$
3. 8. 9.
elect t$e product and product components to )e validated. elect t$e evaluation met$ods for product or product component validation. !evie' t$e validation selection, constraints, and met$ods 'it$ relevant sta2e$olders.
400
)a&"+at"o :)AL;
SP 1*2
E$tab&"$- t-e )a&"+at"o E v"ro me t
+sta'lish and maintain the en)ironment needed to support )alidation.

T$e re/uirements for t$e validation environment are driven )* t$e product or product components selected, )* t$e t*pe of t$e 'or2 products (e.+., desi+n, protot*pe, final version,, and )* t$e met$ods of validation. T$ese selections can *ield re/uirements for t$e purc$ase or development of e/uipment, soft'are, or ot$er resources. T$ese re/uirements are provided to t$e re/uirements development processes for development. T$e validation environment can include t$e reuse of e5istin+ resources. In t$is case, arran+ements for t$e use of t$ese resources s$ould )e made. Example types of elements in a validation environment include the following: (est tools interfaced with the product being validated 2e.g., scope, electronic devices, probes3 (emporary embedded test software #ecording tools for dump or further analysis and replay *imulated subsystems or components 2e.g., software, electronics, mechanics3 *imulated interfaced systems 2e.g., a dummy warship for testing a naval radar3 #eal interfaced systems 2e.g., aircraft for testing a radar with trajectory trac1ing facilities3 Facilities and customer supplied products *1illed people to operate or use all the preceding elements %edicated computing or networ1 test environment 2e.g., pseudo5operational telecommunications networ1 test bed or facility with actual trun1s, switches, and systems established for realistic integration and validation trials3
Earl* selection of products or product components to )e validated, 'or2 products to )e used in validation, and validation met$ods is needed to ensure t$at t$e validation environment 'ill )e availa)le '$en necessar*. T$e validation environment s$ould )e carefull* controlled to provide for replication, results anal*sis, and revalidation of pro)lem areas.
1. 1. ". 3. 8. 9.
Validation environment Identif* re/uirements for t$e validation environment. Identif* customer supplied products. Identif* test e/uipment and tools. Identif* validation resources t$at are availa)le for reuse and modification. Plan t$e availa)ilit* of resources in detail.
S/b'ra#t"#e$
)a&"+at"o :)AL;
401
SP 1*3
E$tab&"$- )a&"+at"o Pro#e+/re$ a + Cr"ter"a
+sta'lish and maintain procedures and criteria for )alidation.

Validation procedures and criteria are defined to ensure t$e product or product component 'ill fulfill its intended use '$en placed in its intended environment. Test cases and procedures for acceptance testin+ can )e used for validation procedures. T$e validation procedures and criteria include test and evaluation of maintenance, trainin+, and support services. Examples of sources for validation criteria include the following: 'roduct and product component re0uirements *tandards Customer acceptance criteria Environmental performance (hresholds of performance deviation
1. ". 3. 1.
Validation procedures Validation criteria Test and evaluation procedures for maintenance, trainin+, and support !evie' t$e product re/uirements to ensure t$at issues affectin+ validation of t$e product or product component are identified and resolved. Document t$e environment, operational scenario, procedures, inputs, outputs, and criteria for t$e validation of t$e selected product or product component. 0ssess t$e desi+n as it matures in t$e conte5t of t$e validation environment to identif* validation issues.
S/b'ra#t"#e$
".
3.
S7 2
)a&"+ate Pro+/#t or Pro+/#t Com'o e t$
The product or product components are )alidated to ensure they are suita'le for use in their intended operating en)ironment.
T$e validation met$ods, procedures, and criteria are used to validate t$e selected products and product components and an* associated maintenance, trainin+, and support services usin+ t$e appropriate validation environment. Validation activities are performed t$rou+$out t$e product lifec*cle.
SP 2*1 Perform )a&"+at"o
!erform )alidation on selected products and product components.

To )e accepta)le to sta2e$olders, a product or product component s$ould perform as e5pected in its intended operational environment.
402
)a&"+at"o :)AL;
Validation activities are performed and t$e resultin+ data are collected accordin+ to esta)lis$ed met$ods, procedures, and criteria. T$e as-run validation procedures s$ould )e documented and t$e deviations occurrin+ durin+ t$e e5ecution s$ould )e noted as appropriate.
1. ". 3. 8. 9.
SP 2*2
Validation reports Validation results Validation cross reference matri5 0s-run procedures lo+ 7perational demonstrations
A a&1Ae )a&"+at"o Re$/&t$
"naly5e results of )alidation acti)ities.

T$e data resultin+ from validation tests, inspections, demonstrations, or evaluations are anal*-ed a+ainst defined validation criteria. 0nal*sis reports indicate '$et$er needs 'ere met. In t$e case of deficiencies, t$ese reports document t$e de+ree of success or failure and cate+ori-e pro)a)le causes of failure. T$e collected test, inspection, or revie' results are compared 'it$ esta)lis$ed evaluation criteria to determine '$et$er to proceed or to address re/uirements or desi+n issues in t$e re/uirements development or tec$nical solution processes. 0nal*sis reports or as-run validation documentation can also indicate t$at )ad test results are due to a validation procedure pro)lem or a validation environment pro)lem.
1. ". 3. 1. ".
Validation deficienc* reports Validation issues Procedure c$an+e re/uest Compare actual results to e5pected results. .ased on t$e esta)lis$ed validation criteria, identif* products and product components t$at do not perform suita)l* in t$eir intended operatin+ environments, or identif* pro)lems 'it$ met$ods, criteria, or t$e environment. 0nal*-e validation data for defects. !ecord results of t$e anal*sis and identif* issues. :se validation results to compare actual measurements and performance to t$e intended use or operational need.
S/b'ra#t"#e$
3. 8. 9.
)a&"+at"o :)AL;
403
G.
Provide information on $o' defects can )e resolved (includin+ validation met$ods, criteria, and validation environment, and initiate corrective action. "efer to the Pro.ect Monitoring and Control process area for more information about managing corrective actions%
404
)a&"+at"o :)AL;
3$RIFI!A(IO*
Purpose
T$e purpose of Verification (VE!, is to ensure t$at selected 'or2 products meet t$eir specified re/uirements.
Introductor" *otes
T$e Verification process area involves t$e follo'in+% verification preparation, verification performance, and identification of corrective action. Verification includes verification of t$e product and intermediate 'or2 products a+ainst all selected re/uirements, includin+ customer, product, and product component re/uirements. 1or product lines, core assets and t$eir associated product line variation mec$anisms s$ould also )e verified. T$rou+$out t$e process areas, '$ere t$e terms LproductM and Lproduct componentM are used, t$eir intended meanin+s also encompass services, service s*stems, and t$eir components. Verification is in$erentl* an incremental process )ecause it occurs t$rou+$out t$e development of t$e product and 'or2 products, )e+innin+ 'it$ verification of re/uirements, pro+ressin+ t$rou+$ t$e verification of evolvin+ 'or2 products, and culminatin+ in t$e verification of t$e completed product. T$e specific practices of t$is process area )uild on eac$ ot$er in t$e follo'in+ 'a*% T$e elect 6or2 Products for Verification specific practice ena)les t$e identification of 'or2 products to )e verified, met$ods to )e used to perform t$e verification, and t$e re/uirements to )e satisfied )* eac$ selected 'or2 product. T$e Esta)lis$ t$e Verification Environment specific practice ena)les t$e determination of t$e environment to )e used to carr* out t$e verification. T$e Esta)lis$ Verification Procedures and Criteria specific practice ena)les t$e development of verification procedures and criteria t$at are ali+ned 'it$ selected 'or2 products, re/uirements, met$ods, and c$aracteristics of t$e verification environment. T$e Perform Verification specific practice conducts t$e verification accordin+ to availa)le met$ods, procedures, and criteria.
Verification of 'or2 products su)stantiall* increases t$e li2eli$ood t$at t$e product 'ill meet t$e customer, product, and product component re/uirements. T$e Verification and Validation process areas are similar, )ut t$e* address different issues. Validation demonstrates t$at t$e product, as provided (or
)er"f"#at"o :)ER;
405
as it 'ill )e provided,, 'ill fulfill its intended use, '$ereas verification addresses '$et$er t$e 'or2 product properl* reflects t$e specified re/uirements. In ot$er 'ords, verification ensures t$at L*ou )uilt it ri+$tMI '$ereas, validation ensures t$at L*ou )uilt t$e ri+$t t$in+.M Peer revie's are an important part of verification and are a proven mec$anism for effective defect removal. 0n important corollar* is to develop a )etter understandin+ of t$e 'or2 products and t$e processes t$at produced t$em so t$at defects can )e prevented and process improvement opportunities can )e identified. Peer revie's involve a met$odical e5amination of 'or2 products )* t$e producers; peers to identif* defects and ot$er c$an+es t$at are needed. Examples of peer review methods include the following: &nspections *tructured wal1throughs %eliberate refactoring 'air programming
&n "gile environments, because of customer involvement and fre0uent releases, verification and validation mutually support each other. For example, a defect can cause a prototype or early release to fail validation prematurely. Conversely, early and continuous validation helps ensure verification is applied to the right product. (he ,erification and ,alidation process areas help ensure a systematic approach to selecting the wor1 products to be reviewed and tested, the methods and environments to be used, and the interfaces to be managed, which help ensure that defects are identified and addressed early. (he more complex the product, the more systematic the approach needs to be to ensure compatibility among re0uirements and solutions, and consistency with how the product will be used. 2*ee @&nterpreting C$$& 4hen :sing "gile "pproachesA in 'art &.3
"efer to the "e,uirements evelopment process area for more information about eliciting2 analy-ing2 and establishing customer2 product2 and product component re,uirements% "efer to the 8alidation process area for more information about demonstrating that a product or product component fulfills its intended use when placed in its intended environment% "efer to the "e,uirements Management process area for more information about ensuring alignment between pro.ect wor1 and re,uirements%
406
)er"f"#at"o :)ER;

3 1 Prepare for Verification P 1.1 P 1." P 1.3 P ".1 P "." P ".3 P 3.1 P 3." elect 6or2 Products for Verification Esta)lis$ t$e Verification Environment Esta)lis$ Verification Procedures and Criteria Prepare for Peer !evie's Conduct Peer !evie's 0nal*-e Peer !evie' Data Perform Verification 0nal*-e Verification !esults
3 " Perform Peer !evie's
3 3 Verif* elected 6or2 Products
)pecific Practices b" /oal S7 1 Pre'are for )er"f"#at"o
!reparation for )erification is conducted.

:p-front preparation is necessar* to ensure t$at verification provisions are em)edded in product and product component re/uirements, desi+ns, developmental plans, and sc$edules. Verification includes t$e selection, inspection, testin+, anal*sis, and demonstration of 'or2 products. Met$ods of verification include, )ut are not limited to, inspections, peer revie's, audits, 'al2t$rou+$s, anal*ses, arc$itecture evaluations, simulations, testin+, and demonstrations. Practices related to peer revie's as a specific verification met$od are included in specific +oal ". Preparation also entails t$e definition of support tools, test e/uipment and soft'are, simulations, protot*pes, and facilities.
SP 1*1 Se&e#t >or? Pro+/#t$ for )er"f"#at"o
elect 3or4 products to 'e )erified and )erification methods to 'e used.
6or2 products are selected )ased on t$eir contri)ution to meetin+ pro4ect o)4ectives and re/uirements, and to addressin+ pro4ect ris2s. T$e 'or2 products to )e verified can include t$e ones associated 'it$ maintenance, trainin+, and support services. T$e 'or2 product re/uirements for verification are included 'it$ t$e verification met$ods. T$e verification met$ods address t$e approac$ to 'or2 product verification and t$e specific approac$es t$at 'ill )e used to verif* t$at specific 'or2 products meet t$eir re/uirements.
)er"f"#at"o :)ER;
408
Examples of verification methods include the following: *oftware architecture evaluation and implementation conformance evaluation 'ath coverage testing -oad, stress, and performance testing %ecision table based testing Functional decomposition based testing (est case reuse "cceptance testing Continuous integration 2i.e., "gile approach that identifies integration issues early3
,erification for systems engineering typically includes prototyping, modeling, and simulation to verify ade0uacy of system design 2and allocation3. ,erification for hardware engineering typically re0uires a parametric approach that considers various environmental conditions 2e.g., pressure, temperature, vibration, humidity3, various input ranges 2e.g., input power could be rated at <>, to !<, for a planned nominal of <B,3, variations induced from part to part tolerance issues, and many other variables. /ardware verification normally tests most variables separately except when problematic interactions are suspected. election of verification met$ods t*picall* )e+ins 'it$ t$e definition of product and product component re/uirements to ensure t$at t$e re/uirements are verifia)le. !e-verification s$ould )e addressed )* verification met$ods to ensure t$at re'or2 performed on 'or2 products does not cause unintended defects. uppliers s$ould )e involved in t$is selection to ensure t$at t$e pro4ectPs met$ods are appropriate for t$e supplierPs environment.
1. ". 1. ".
Aists of 'or2 products selected for verification Verification met$ods for eac$ selected 'or2 product Identif* 'or2 products for verification. Identif* re/uirements to )e satisfied )* eac$ selected 'or2 product. "efer to the Maintain *idirectional Traceability of "e,uirements specific practice in the "e,uirements Management process area for more information about tracing re,uirements to wor1 products%
S/b'ra#t"#e$
3. 8. 9.
Identif* verification met$ods availa)le for use. Define verification met$ods to )e used for eac$ selected 'or2 product. u)mit for inte+ration 'it$ t$e pro4ect plan t$e identification of 'or2 products to )e verified, t$e re/uirements to )e satisfied, and t$e met$ods to )e used.
40<
)er"f"#at"o :)ER;
"efer to the Pro.ect Planning process area for more information about developing the pro.ect plan%
SP 1*2 E$tab&"$- t-e )er"f"#at"o E v"ro me t
+sta'lish and maintain the en)ironment needed to support )erification.

0n environment s$ould )e esta)lis$ed to ena)le verification to ta2e place. T$e verification environment can )e ac/uired, developed, reused, modified, or o)tained usin+ a com)ination of t$ese activities, dependin+ on t$e needs of t$e pro4ect. T$e t*pe of environment re/uired depends on t$e 'or2 products selected for verification and t$e verification met$ods used. 0 peer revie' can re/uire little more t$an a pac2a+e of materials, revie'ers, and a room. 0 product test can re/uire simulators, emulators, scenario +enerators, data reduction tools, environmental controls, and interfaces 'it$ ot$er s*stems.
1. 1. ". 3. 8.
Verification environment Identif* verification environment re/uirements. Identif* verification resources t$at are availa)le for reuse or modification. Identif* verification e/uipment and tools. 0c/uire verification support e/uipment and an environment (e.+., test e/uipment, soft'are,.
S/b'ra#t"#e$
SP 1*3
E$tab&"$- )er"f"#at"o Pro#e+/re$ a + Cr"ter"a
+sta'lish and maintain )erification procedures and criteria for the selected 3or4 products.
Verification criteria are defined to ensure t$at 'or2 products meet t$eir re/uirements. Examples of sources for verification criteria include the following: 'roduct and product component re0uirements *tandards Organi6ational policies (est type (est parameters 'arameters for tradeoff between 0uality and cost of testing (ype of wor1 products *uppliers 'roposals and agreements Customers reviewing wor1 products collaboratively with developers
)er"f"#at"o :)ER;
403
1. ". 1. ". 3. 8.
Verification procedures Verification criteria 3enerate a set of compre$ensive, inte+rated verification procedures for 'or2 products and commercial off-t$e-s$elf products, as necessar*. Develop and refine verification criteria as necessar*. Identif* t$e e5pected results, tolerances allo'ed, and ot$er criteria for satisf*in+ t$e re/uirements. Identif* e/uipment and environmental components needed to support verification.
S/b'ra#t"#e$
S7 2
Perform Peer Rev"ew$
!eer re)ie3s are performed on selected 3or4 products.

Peer revie's involve a met$odical e5amination of 'or2 products )* t$e producers; peers to identif* defects for removal and to recommend ot$er c$an+es t$at are needed. T$e peer revie' is an important and effective verification met$od implemented via inspections, structured 'al2t$rou+$s, or a num)er of ot$er colle+ial revie' met$ods. Peer revie's are primaril* applied to 'or2 products developed )* t$e pro4ects, )ut t$e* can also )e applied to ot$er 'or2 products suc$ as documentation and trainin+ 'or2 products t$at are t*picall* developed )* support +roups.
SP 2*1 Pre'are for Peer Rev"ew$
!repare for peer re)ie3s of selected 3or4 products.

Preparation activities for peer revie's t*picall* include identif*in+ t$e staff to )e invited to participate in t$e peer revie' of eac$ 'or2 productI identif*in+ 2e* revie'ers '$o s$ould participate in t$e peer revie'I preparin+ and updatin+ materials to )e used durin+ peer revie's, suc$ as c$ec2lists and revie' criteria and sc$edulin+ peer revie's.
1. ". 3. 8. 9. G. 1.
Peer revie' sc$edule Peer revie' c$ec2list Entr* and e5it criteria for 'or2 products Criteria for re/uirin+ anot$er peer revie' Peer revie' trainin+ material elected 'or2 products to )e revie'ed Determine t$e t*pe of peer revie' to )e conducted.
S/b'ra#t"#e$
410
)er"f"#at"o :)ER;
Examples of types of peer reviews include the following:

&nspections *tructured wal1throughs "ctive reviews "rchitecture implementation conformance evaluation
".
Define re/uirements for collectin+ data durin+ t$e peer revie'. "efer to the Measurement and $nalysis process area for more information about obtaining measurement data%
3. 8. 9.
Esta)lis$ and maintain entr* and e5it criteria for t$e peer revie'. Esta)lis$ and maintain criteria for re/uirin+ anot$er peer revie'. Esta)lis$ and maintain c$ec2lists to ensure t$at 'or2 products are revie'ed consistentl*. Examples of items addressed by the chec1lists include the following:
#ules of construction %esign guidelines Completeness Correctness $aintainability Common defect types
(he chec1lists are modified as necessary to address the specific type of wor1 product and peer review. (he peers of the chec1list developers and potential end5users review the chec1lists. G. Develop a detailed peer revie' sc$edule, includin+ t$e dates for peer revie' trainin+ and for '$en materials for peer revie's 'ill )e availa)le. Ensure t$at t$e 'or2 product satisfies t$e peer revie' entr* criteria prior to distri)ution. Distri)ute t$e 'or2 product to )e revie'ed and related information to participants earl* enou+$ to ena)le t$em to ade/uatel* prepare for t$e peer revie'. 0ssi+n roles for t$e peer revie' as appropriate. Examples of roles include the following:
-eader #eader #ecorder "uthor
=. H.
F.
)er"f"#at"o :)ER;
411
1#. Prepare for t$e peer revie' )* revie'in+ t$e 'or2 product prior to conductin+ t$e peer revie'.
SP 2*2 Co +/#t Peer Rev"ew$
Conduct peer re)ie3s of selected 3or4 products and identify issues resulting from these re)ie3s.
7ne of t$e purposes of conductin+ a peer revie' is to find and remove defects earl*. Peer revie's are performed incrementall* as 'or2 products are )ein+ developed. T$ese revie's are structured and are not mana+ement revie's. Peer revie's can )e performed on 2e* 'or2 products of specification, desi+n, test, and implementation activities and specific plannin+ 'or2 products. T$e focus of t$e peer revie' s$ould )e on t$e 'or2 product in revie', not on t$e person '$o produced it. 6$en issues arise durin+ t$e peer revie', t$e* s$ould )e communicated to t$e primar* developer of t$e 'or2 product for correction. "efer to the Pro.ect Monitoring and Control process area for more information about monitoring the pro.ect against the plan% Peer revie's s$ould address t$e follo'in+ +uidelines% t$ere s$ould )e sufficient preparation, t$e conduct s$ould )e mana+ed and controlled, consistent and sufficient data s$ould )e recorded (an e5ample is conductin+ a formal inspection,, and action items s$ould )e recorded.
1. ". 3. 1. ". 3. 8.
Peer revie' results Peer revie' issues Peer revie' data Perform t$e assi+ned roles in t$e peer revie'. Identif* and document defects and ot$er issues in t$e 'or2 product. !ecord results of t$e peer revie', includin+ action items. Collect peer revie' data. "efer to the Measurement and $nalysis process area for more information about obtaining measurement data%
S/b'ra#t"#e$
9. G. =.
SP 2*3
Identif* action items and communicate issues to relevant sta2e$olders. Conduct an additional peer revie' if needed. Ensure t$at t$e e5it criteria for t$e peer revie' are satisfied.
A a&1Ae Peer Rev"ew %ata
"naly5e data a'out the preparation* conduct* and results of the peer re)ie3s.
"efer to the Measurement and $nalysis process area for more information about obtaining measurement data and analy-ing measurement data%
412
)er"f"#at"o :)ER;
1. ". 1.
Peer revie' data Peer revie' action items !ecord data related to t$e preparation, conduct, and results of t$e peer revie's. (ypical data are product name, product si6e, composition of the peer review team, type of peer review, preparation time per reviewer, length of the review meeting, number of defects found, type and origin of defect, and so on. "dditional information on the wor1 product being peer reviewed can be collected, such as si6e, development stage, operating modes examined, and re0uirements being evaluated.
S/b'ra#t"#e$
". 3.
tore t$e data for future reference and anal*sis. Protect t$e data to ensure t$at peer revie' data are not used inappropriatel*. Examples of the inappropriate use of peer review data include using data to evaluate the performance of people and using data for attribution.
8.
0nal*-e t$e peer revie' data. Examples of peer review data that can be analy6ed include the following:
'hase defect was injected 'reparation time or rate versus expected time or rate 7umber of defects versus number expected (ypes of defects detected Causes of defects %efect resolution impact :ser stories or case studies associated with a defect (he end users and customers who are associated with defects
S7 3
)er"f1 Se&e#te+ >or? Pro+/#t$
elected 3or4 products are )erified against their specified re-uirements.

Verification met$ods, procedures, and criteria are used to verif* selected 'or2 products and associated maintenance, trainin+, and support services usin+ t$e appropriate verification environment. Verification activities s$ould )e performed t$rou+$out t$e product lifec*cle. Practices related to peer revie's as a specific verification met$od are included in specific +oal ".
SP 3*1 Perform )er"f"#at"o
!erform )erification on selected 3or4 products.

Verif*in+ products and 'or2 products incrementall* promotes earl* detection of pro)lems and can result in t$e earl* removal of defects. T$e
)er"f"#at"o :)ER;
413
results of verification save t$e considera)le cost of fault isolation and re'or2 associated 'it$ trou)les$ootin+ pro)lems.
1. ". 3. 8. 1. ". 3. 8.
Verification results Verification reports Demonstrations 0s-run procedures lo+ Perform t$e verification of selected 'or2 products a+ainst t$eir re/uirements. !ecord t$e results of verification activities. Identif* action items resultin+ from t$e verification of 'or2 products. Document t$e Las-runM verification met$od and deviations from availa)le met$ods and procedures discovered durin+ its performance.
S/b'ra#t"#e$
SP 3*2
A a&1Ae )er"f"#at"o Re$/&t$
"naly5e results of all )erification acti)ities.

0ctual results s$ould )e compared to esta)lis$ed verification criteria to determine accepta)ilit*. T$e results of t$e anal*sis are recorded as evidence t$at verification 'as conducted. 1or eac$ 'or2 product, all availa)le verification results are incrementall* anal*-ed to ensure t$at re/uirements $ave )een met. ince a peer revie' is one of several verification met$ods, peer revie' data s$ould )e included in t$is anal*sis activit* to ensure t$at verification results are anal*-ed sufficientl*. 0nal*sis reports or Las-runM met$od documentation can also indicate t$at )ad verification results are due to met$od pro)lems, criteria pro)lems, or a verification environment pro)lem.
1.
0nal*sis report (e.+., statistics on performance, causal anal*sis of nonconformances, comparison of t$e )e$avior )et'een t$e real product and models, trends, Trou)le reports C$an+e re/uests for verification met$ods, criteria, and t$e environment Compare actual results to e5pected results. .ased on t$e esta)lis$ed verification criteria, identif* products t$at do not meet t$eir re/uirements or identif* pro)lems 'it$ met$ods, procedures, criteria, and t$e verification environment.
". 3. 1. ".
S/b'ra#t"#e$
414
)er"f"#at"o :)ER;
3. 8. 9. G.
0nal*-e defect data. !ecord all results of t$e anal*sis in a report. :se verification results to compare actual measurements and performance to tec$nical performance parameters. Provide information on $o' defects can )e resolved (includin+ verification met$ods, criteria, and verification environment, and initiate corrective action. "efer to the Pro.ect Monitoring and Control process area for more information about ta1ing corrective action%
)er"f"#at"o :)ER;
415
416
)er"f"#at"o :)ER;
Part T$ree% T-e A''e +"#e$
418
41<
A''e +", A2 Refere #e$
A-er 2005
0$ern, Dennis M.I 0rmstron+, KimI Clouse, 0aronI 1er+uson, Kac2 !.I @a*es, 6illI Q <idiffer, Nennet$ E. CMMI SC$MPI istilled: $ppraisals for Process Improvement% .oston, M0% 0ddison-6esle*, "##9. 0$ern, Dennis M.I Clouse, 0aronI Q Turner, !ic$ard. CMMI istilled: $ Practical Introduction to Integrated Process Improvement2 (rd Edition% .oston% 0ddison-6esle*, "##H. .ec2, Nent et. al. Manifesto for 0+ile oft'are Development. "##1. $ttp%&&a+ilemanifesto.or+&. C$rissis, Mar* .et$I Nonrad, Mi2eI Q $rum, and*. CMMI: Guidelines for Process Integration and Product Improvement2 (rd Edition% .oston% 0ddison-6esle*, "#11. Cros)*, P$ilip .. 4uality Is 9ree: The $rt of Ma1ing 4uality Certain% <e' Dor2% Mc3ra'-@ill, 1F=F. Curtis, .illI @efle*, 6illiam E.I Q Miller, all* 0. The People CMM: $ 9ramewor1 for 5uman Capital Management2 'nd Edition% .oston, M0% 0ddison-6esle*, "##F. Demin+, 6. Ed'ards. 0ut of the Crisis% Cam)rid+e, M0% MIT Center for 0dvanced En+ineerin+, 1FHG. Department of Defense. o Guide to Integrated Product and Process evelopment 68ersion &%<7% 6as$in+ton, DC% 7ffice of t$e :nder ecretar* of Defense (0c/uisition and Tec$nolo+*,, 1e)ruar* 9, 1FFG. $ttps%&&'''.ac/uisition.+ov&sevensteps&li)rar*& dod=guide=to= integrated%pdf. D*mond, Nennet$ M. $ Guide to the CMMI: Interpreting the Capability Maturity Model Integration2 'nd Edition% 0nnapolis, MD% Process Transition International Inc., "##9. Electronic Industries 0lliance. Systems Engineering Capability Model 6EI$>IS=?(&%&7% 6as$in+ton, DC, "##".
A-er 200<
9e#? 2001 C-r"$$"$ 2011
Cro$b1 1383 C/rt"$ 2003
%em" ! 13<6 %o% 1336
%1mo + 2005
EIA 2002a
Refere #e$
413
EIA 2002b
3overnment Electronics and Information Tec$nolo+* 0lliance. Earned 8alue Management Systems 6$#SI>EI$=?@A7% <e' Dor2, <D, "##". $ttp%&&'e)store.ansi.or+&!ecordDetail.asp5Js2uO0< IR"1EI0=8H-.. Electronic Industries 0lliance. EI$ Interim Standard: Systems Engineering 6EI$>IS=/('7% 6as$in+ton, DC, "##3. 1orrester, EileenI .uteau, .randonI Q $rum, and*. CMMI for Services: Guidelines for Superior Service2 'nd Edition% .oston% 0ddison-6esle*, "#11. 3alla+$er, .rianI P$illips, Mi2eI !ic$ter, NarenI Q $rum, and*. CMMI=$C4: Guidelines for Improving the $c,uisition of Products and Services2 'nd Edition% .oston% 0ddison-6esle*, "#11. 3overnment Electronic Industries 0lliance. ata Management 6GEI$=ABC7% 6as$in+ton, DC, "##8. $ttp%&&'e)store.ansi.or+&!ecordDetail.asp5Js2uO0< I R"13EI0SH9F-"##F. 3i)son, Diane A.I 3oldenson, Dennis !. Q Nost, Neit$. Performance "esults of CMMI=*ased Process Improvement% (CM:& EI-"##G-T!-##8, E C-T!-"##G-##8,. Pitts)ur+$, P0% oft'are En+ineerin+ Institute, Carne+ie Mellon :niversit*, 0u+ust "##G. $ttp%&&'''.sei.cmu.edu&li)rar*&a)stracts&reports&#Gtr##8.cfm. 3la-er, @illelI Dalton, KeffI 0nderson, DavidI Nonrad, Mi2eI Q $rum, and*. CMMI or $gile: )hy #ot Embrace *oth+ (CM:& EI-"##H-T<-##3,. Pitts)ur+$, P0% oft'are En+ineerin+ Institute, Carne+ie Mellon :niversit*, <ovem)er "##H. $ttp%&&'''.sei.cmu.edu&li)rar*&a)stracts&reports&#Htn##3.cfm. @ump$re*, 6atts . Managing the Software Process% !eadin+, M0% 0ddison-6esle*, 1FHF. Institute of Electrical and Electronics En+ineers. IEEE Standard Computer ictionary: $ Compilation of IEEE Standard Computer Glossaries% <e' Dor2% IEEE, 1FF1. International 7r+ani-ation for tandardi-ation. IS0 C<<<: International Standard% "##9. $ttp%&&'''.iso.or+&iso&isoTcatalo+ue&catalo+ueTtc&catalo+ueTd etail.$tmJcsnum)erO8"1H#.
EIA 2003 .orre$ter 2011
7a&&a!-er 2011
7EIA 2004
7"b$o 2006
7&aAer 200<
H/m'-re1 13<3 IEEE 1331
ISO 2005a
420
Refere #e$
ISO 2005b
International 7r+ani-ation for tandardi-ation and International Electrotec$nical Commission. IS0>IEC '<<<<=& Information Technology D Service Management2 Part &: SpecificationE IS0>IEC '<<<<=' Information Technology D Service Management2 Part ': Code of Practice, "##9. $ttp%&&'''.iso.or+&iso&isoTcatalo+ue&catalo+ueTtc&catalo+ueTtc T)ro'se.$tmJcommidO89#HG. International 7r+ani-ation for tandardi-ation and International Electrotec$nical Commission. IS0>IEC &BB<@ Information TechnologyFProcess $ssessment Part &: Concepts and 8ocabulary2 Part ': Performing an $ssessment2 Part (: Guidance on Performing an $ssessment2 Part @: Guidance on ;se for Process Improvement and Process Capability etermination2 Part B: $n E:emplar Process $ssessment Model, "##3-"##G. $ttp%&&'''.iso.or+&iso&isoTcatalo+ue&catalo+ueTtc&catalo+ueTtc T)ro'se.$tmJcommidO89#HG. International 7r+ani-ation for tandardi-ation and International Electrotec$nical Commission. IS0>IEC &@?/@ Software Engineering D Software !ife Cycle Processes D Maintenance2 "##G% $ttp%&&'''.iso.or+&iso&isoTcatalo+ue&catalo+ueTtc&catalo+ueTtc T)ro'se.$tmJcommidO89#HG. International 7r+ani-ation for tandardi-ation and International Electrotec$nical Commission. IS0>IEC &BC(C Systems and Software EngineeringFMeasurement Process, "##=. $ttp%&&'''.iso.or+&iso&isoTcatalo+ue&catalo+ueTtc&catalo+ueTtc T)ro'se.$tmJcommidO89#HG. International 7r+ani-ation for tandardi-ation and International Electrotec$nical Commission. IS0>IEC &''<? Systems and Software EngineeringFSoftware !ife Cycle Processes, "##H. $ttp%&&'''.iso.or+&iso&isoTcatalo+ue&catalo+ueTtc&catalo+ueTtc T)ro'se.$tmJcommidO89#HG. International 7r+ani-ation for tandardi-ation and International Electrotec$nical Commission. IS0>IEC &B'AA Systems and Software EngineeringFSystem !ife Cycle Processes, "##H. $ttp%&&'''.iso.or+&iso&isoTcatalo+ue&catalo+ueTtc&catalo+ueTtc T)ro'se.$tmJcommidO89#HG. International 7r+ani-ation for tandardi-ation. IS0 C<<&2 4uality Management SystemsF"e,uirements , "##H. $ttp%&&'''.iso.or+&iso&isoTcatalo+ue&catalo+ueTtc&catalo+ueTtc T)ro'se.$tmJcommidO93HFG.
ISO 2006a
ISO 2006b
ISO 2008
ISO 200<a
ISO 200<b
ISO 200<#
Refere #e$
421
IT 7over a #e 2005
IT 3overnance Institute. CobiT @%<% !ollin+ Meado's, IA% IT 3overnance Institute, "##9. $ttp%&&'''.isaca.or+&Content&<avi+ationMenu&Mem)ersTandT Aeaders&C7.ITG&7)tainTC7.IT&7)tainTC7.IT.$tm. Kuran, Kosep$ M. Guran on Planning for 4uality% <e' Dor2% Macmillan, 1FHH. Mc1eele*, !o)ert. I E$!: $ ;ser3s Guide for Software Process Improvement (CM:& EI-FG-@.-##1, 0D03#98=",. Pitts)ur+$, P0% oft'are En+ineerin+ Institute, Carne+ie Mellon :niversit*, 1e)ruar* 1FFG. $ttp%&&'''.sei.cmu.edu&li)rar*&a)stracts&reports&FG$)##1.cfm. Mc3arr*, Ko$nI Card, DavidI Kones, C$er*lI Aa*man, .et$I Clar2, Eli-a)et$I Dean, Kosep$I Q @all, 1red. Practical Software Measurement: 0b.ective Information for ecision Ma1ers% .oston% 0ddison-6esle*, "##1. 7ffice of 3overnment Commerce. ITI!: Continual Service Improvement% Aondon, :N% 7ffice of 3overnment Commerce, "##=. 7ffice of 3overnment Commerce. ITI!: Service esign% Aondon, :N% 7ffice of 3overnment Commerce, "##=. 7ffice of 3overnment Commerce. ITI!: Service 0peration% Aondon, :N% 7ffice of 3overnment Commerce, "##=. 7ffice of 3overnment Commerce. ITI!: Service Strategy% Aondon, :N% 7ffice of 3overnment Commerce, "##=. 7ffice of 3overnment Commerce. ITI!: Service Transition% Aondon, :N% 7ffice of 3overnment Commerce, "##=. oft'are En+ineerin+ Institute. The Capability Maturity Model: Guidelines for Improving the Software Process% !eadin+, M0% 0ddison-6esle*, 1FF9. oft'are En+ineerin+ Institute. Software $c,uisition Capability Maturity Model 6S$=CMM7 8ersion &%<( (CM:& EI-"##"-T!#1#, E C-T!-"##"-#1#,. Pitts)ur+$, P0% oft'are En+ineerin+ Institute, Carne+ie Mellon :niversit*, Marc$ "##". $ttp%&&'''.sei.cmu.edu&pu)lications&documents&#".reports&#"tr #1#.$tml.
D/ra 13<< M#.ee&e1 1336
M#7arr1 2001
Off"#e of 7over me t Commer#e 2008a Off"#e of 7over me t Commer#e 2008b Off"#e of 7over me t Commer#e 2008# Off"#e of 7over me t Commer#e 2008+ Off"#e of 7over me t Commer#e 2008e SEI 1335
SEI 2002
422
Refere #e$
SEI 2006
CMMI Product Team. CMMI for evelopment2 8ersion &%' (CM:& EI-"##G-T!-##H, 0D0899H9H,. Pitts)ur+$, P0% oft'are En+ineerin+ Institute, Carne+ie Mellon :niversit*, 0u+ust "##G. $ttp%&&'''.sei.cmu.edu&li)rar*&a)stracts&reports&#Gtr##H.cfm. CMMI Product Team. CMMI for Services2 8ersion &%( (CM:& EI-"#1#-T!-#38,. Pitts)ur+$, P0% oft'are En+ineerin+ Institute, Carne+ie Mellon :niversit*, <ovem)er "#1#. $ttp%&&'''.sei.cmu.edu&li)rar*&a)stracts&reports&1#tr#38.cfm. CMMI Product Team. CMMI for $c,uisition2 8ersion &%( (CM:& EI-"#1#-T!-#3",. Pitts)ur+$, P0% oft'are En+ineerin+ Institute, Carne+ie Mellon :niversit*, <ovem)er "#1#. $ttp%&&'''.sei.cmu.edu&li)rar*&a)stracts&reports&1#tr#3".cfm. Caralli, !ic$ardI 0llen, KuliaI Curtis, PamelaI 6$ite, DavidI and Doun+, Aisa. CE"TH "esilience Management Model2 8ersion &%< (CM:& EI-"#1#-T!-#1",. Pitts)ur+$, P0% oft'are En+ineerin+ Institute, Carne+ie Mellon :niversit*, Ma* "#1#. $ttp%&&'''.sei.cmu.edu&li)rar*&a)stracts&reports&1#tr#1".cfm. C0MPI :p+rade Team. Standard CMMI $ppraisal Method for Process Improvement 6SC$MPI7 $2 8ersion &%(: Method efinition ocument (CM:& EI-"#11-@.-##1,. Pitts)ur+$, P0% oft'are En+ineerin+ Institute, Carne+ie Mellon :niversit*, e5pected Kanuar* "#11. $ttp%&&'''.sei.cmu.edu&li)rar*&a)stracts&reports&11$)##1.cfm. C0MPI :p+rade Team. $ppraisal "e,uirements for CMMI2 8ersion &%' 6$"C2 8&%(7 (CM:& EI-"#11-T!-##1,. Pitts)ur+$, P0% oft'are En+ineerin+ Institute, Carne+ie Mellon :niversit*, e5pected Kanuar* "#11. $ttp%&&'''.sei.cmu.edu&li)rar*&a)stracts&reports&11tr#1#1.cfm. $e'$art, 6alter 0. Economic Control of 4uality of Manufactured Product% <e' Dor2% Van <ostrand, 1F31.
SEI 2010a
SEI 2010b
SEI 2010#
SEI 2011a
SEI 2011b
S-ew-art 1331
Information Assurance5Information )ecurit" Related )ources
%HS 2003
Department of @omeland ecurit*. $ssurance 9ocus for CMMI 6Summary of $ssurance for CMMI Efforts7, "##F. $ttps%&&)uildsecurit*in.us-cert.+ov&s'a&proselfTassm.$tml.
Refere #e$
423
%o% a + %HS 200<
Department of Defense and Department of @omeland ecurit*. Software $ssurance in $c,uisition: Mitigating "is1s to the Enterprise2 '<<A. $ttps%&&)uildsecurit*in.uscert.+ov&s'a&do'nloads& '0TinT0c/uisitionT1#""#H.pdf. International 7r+ani-ation for tandardi-ation and International Electrotec$nical Commission. IS0>IEC '?<<& Information Technology D Security Techni,ues D Information Security Management Systems D "e,uirements2 '<<B. $ttp%&&'''.iso.or+&iso&isoTcatalo+ue&catalo+ueTtc&catalo+ue Tdetail.$tmJcsnum)erO 8"1#3. <DI0 *stem 0ssurance Committee. Engineering for System $ssurance% 0rlin+ton, V0% <DI0, "##H. $ttp%&&'''.ndia.or+&Divisions&Divisions& *stemsEn+ineerin+ &Documents& tudies& 0-3uide)oo2-v1-7ct"##H-!EV.pdf.
ISO/IEC 2005
N%IA 200<
424
Refere #e$
A''e +", 92 A#ro 1m$
ANSI API ARC CA% CAR CC9 CL CM CMU CM. CMM CMMI CMMI-AC@ CMMI-%E) CMMI-S)C Cob"T COTS CPI CPM CSCI %AR
0merican <ational tandards Institute application pro+ram interface 0ppraisal !e/uirements for CMMI computer-aided desi+n Causal 0nal*sis and !esolution (process area, confi+uration control )oard capa)ilit* level Confi+uration Mana+ement (process area, Carne+ie Mellon :niversit* CMMI Model 1oundation Capa)ilit* Maturit* Model Capa)ilit* Maturit* Model Inte+ration CMMI for 0c/uisition CMMI for Development CMMI for ervices Control 7)4ectives for Information and related Tec$nolo+* commercial off-t$e-s$elf cost performance inde5 critical pat$ met$od computer soft'are confi+uration item Decision 0nal*sis and !esolution (process area,
A#ro 1m$
425
%HS %o% EIA EIA/IS .CA .MEA 77 7P I9M I%EAL IEEE INCOSE IP%-CMM IPM ISO ISO/IEC ITIL MA M%% ML N%IA OI% OP% OP.
Department of @omeland ecurit* Department of Defense Electronic Industries 0lliance Electronic Industries 0lliance&Interim tandard functional confi+uration audit failure mode and effects anal*sis +eneric +oal +eneric practice International .usiness Mac$ines Initiatin+, Dia+nosin+, Esta)lis$in+, 0ctin+, Aearnin+ Institute of Electrical and Electronics En+ineers International Council on *stems En+ineerin+ Inte+rated Product Development Capa)ilit* Maturit* Model Inte+rated Pro4ect Mana+ement (process area, International 7r+ani-ation for tandardi-ation International 7r+ani-ation for tandardi-ation and International Electrotec$nical Commission Information Tec$nolo+* Infrastructure Ai)rar* Measurement and 0nal*sis (process area, Met$od Definition Document maturit* level <ational Defense Industrial 0ssociation 7r+ani-ational Innovation and Deplo*ment (former process area, 7r+ani-ational Process Definition (process area, 7r+ani-ational Process 1ocus (process area,
426
A#ro 1m$
OPM OPP OT P-CMM PCA PERT PI PMC PP PP@A @.% @PM R% RE@M RSCM SA-CMM SAM SCAMPI SECAM SECM SEI S7 SP SPI SS%
7r+ani-ational Performance Mana+ement (process area, 7r+ani-ational Process Performance (process area, 7r+ani-ational Trainin+ (process area, People Capa)ilit* Maturit* Model p$*sical confi+uration audit Pro+ram Evaluation and !evie' Tec$ni/ue Product Inte+ration (process area, Pro4ect Monitorin+ and Control (process area, Pro4ect Plannin+ (process area, Process and Product Bualit* 0ssurance (process area, Bualit* 1unction Deplo*ment Buantitative Pro4ect Mana+ement (process area, !e/uirements Development (process area, !e/uirements Mana+ement (process area, !is2 Mana+ement (process area, oft'are 0c/uisition Capa)ilit* Maturit* Model upplier 0+reement Mana+ement (process area, tandard CMMI 0ppraisal Met$od for Process Improvement *stems En+ineerin+ Capa)ilit* 0ssessment Model *stems En+ineerin+ Capa)ilit* Model oft'are En+ineerin+ Institute specific +oal specific practice sc$edule performance inde5 ervice *stem Development (process area in CMMI- VC,
A#ro 1m$
428
SSE-CMM S>-CMM TS )AL )ER >9S
*stems ecurit* En+ineerin+ Capa)ilit* Maturit* Model Capa)ilit* Maturit* Model for oft'are or oft'are Capa)ilit* Maturit* Model Tec$nical olution (process area, Validation (process area, Verification (process area, 'or2 )rea2do'n structure
42<
A#ro 1m$
A''e +", C2 CMMI )er$"o 1*3 Pro0e#t Part"#"'a t$
Man* talented people 'ere part of t$e product team t$at developed CMMI Version 1.3 models. Aisted )elo' are t$ose '$o participated in one or more of t$e follo'in+ teams durin+ t$e development of CMMI Version 1.3. T$e or+ani-ations listed )* mem)ers; names are t$ose t$e* represented at t$e time of t$eir team mem)ers$ip. T$e follo'in+ are t$e primar* +roups involved in t$e development of t$is model%
!##I )teering /roup
CMMI teerin+ 3roup CMMI for ervices 0dvisor* 3roup CMMI V1.3 Coordination Team CMMI V1.3 Confi+uration Control .oard CMMI V1.3 Core Model Team CMMI V1.3 Translation Team CMMI V1.3 @i+$ Maturit* Team CMMI V1.3 0c/uisition Mini Team CMMI V1.3 ervices Mini Team CMMI V1.3 C0MPI :p+rade Team CMMI V1.3 Trainin+ Teams CMMI V1.3 Bualit* Team
T$e CMMI teerin+ 3roup +uides and approves t$e plans of t$e CMMI Product Team, provides consultation on si+nificant CMMI pro4ect issues, ensures involvement from a variet* of interested communities, and approves t$e final release of t$e model.
Steer" ! 7ro/' Member$
0lan .emis$, : 0ir 1orce 0nita Carleton, oft'are En+ineerin+ Institute Cl*de C$ittister, oft'are En+ineerin+ Institute Kames 3ill, .oein+ Inte+rated Defense *stems Ko$n C. Nell*, <0 0 Nat$r*n Aundeen, Defense Contract Mana+ement 0+enc*
CMMI )er$"o 1*3 Pro0e#t Part"#"'a t$
423
Aarr* McCart$*, Motorola, Inc. Aa'rence 7siec2i, : 0rm* !o)ert !assa, !a*t$eon pace and 0ir)orne *stems (lead, Naren !ic$ter, Institute for Defense 0nal*ses Koan 6es-2a, Aoc2$eed Martin Corporation @arold 6ilson, <ort$rop 3rumman .renda Uettervall, : <av*
E,-Off"#"o Steer" ! 7ro/' Member$
Mi2e Nonrad, oft'are En+ineerin+ Institute usan Aa1ortune, <ational ecurit* 0+enc* David (Mi2e, P$illips, oft'are En+ineerin+ Institute
Steer" ! 7ro/' S/''ort
Mar* .et$ C$rissis, oft'are En+ineerin+ Institute (CC., Eric @a*es, oft'are En+ineerin+ Institute (secretar*, !a'don Doun+, oft'are En+ineerin+ Institute (0ppraisal pro+ram,
!##I for )er ices Ad isor" /roup
T$e ervices 0dvisor* 3roup provides advice to t$e product development team a)out service industries. .randon .uteau, <ort$rop 3rumman Corporation C$ristian Carmod*, :niversit* of Pitts)ur+$ Medical Center andra Cepeda, Cepeda *stems Q oft'are 0nal*sis&!DEC7M ED 0nnie Com)elles, D<V IT 3lo)al ervices Keff Dutton, Kaco)s Tec$nolo+*, Inc. Eileen 1orrester, oft'are En+ineerin+ Institute Crai+ @ollen)ac$, <ort$rop 3rumman Corporation (lead, .radle* <elson, Department of Defense Aa'rence 7siec2i, : 0rm* 0!DEC David (Mi2e, P$illips, oft'are En+ineerin+ Institute Timot$* alerno, Aoc2$eed Martin Corporation and* $rum, oft'are En+ineerin+ Institute <id$i rivastava, Tata Consultanc* ervices Eli-a)et$ umpter, < 0 David 'idors2*, .an2 of 0merica
430
!##I 3678 !oordination (eam
T$e Coordination team )rin+s to+et$er mem)ers of ot$er product development teams to ensure coordination across t$e pro4ect. !$onda .ro'n, oft'are En+ineerin+ Institute Mar* .et$ C$rissis, oft'are En+ineerin+ Institute Eileen 1orrester, oft'are En+ineerin+ Institute 6ill @a*es, oft'are En+ineerin+ Institute Mi2e Nonrad, oft'are En+ineerin+ Institute o <orimatsu, <orimatsu Process En+ineerin+ Aa), Inc. Mar* A*nn Penn, Aoc2$eed Martin Corporation David (Mi2e, P$illips, oft'are En+ineerin+ Institute (lead, and* $rum, oft'are En+ineerin+ Institute Nat$* mit$, @e'lett Pac2ard .ar)ara T*son, oft'are En+ineerin+ Institute !a'don Doun+, oft'are En+ineerin+ Institute Mar* A*nn !usso, oft'are En+ineerin+ Institute (non-votin+ mem)er,
!##I 3678 !onfiguration !ontrol 9oard
T$e Confi+uration Control .oard approves all c$an+es to CMMI materials, includin+ t$e models, t$e C0MPI MDD, and introductor* model trainin+. !$onda .ro'n, oft'are En+ineerin+ Institute Mic$ael Campo, !a*t$eon Mar* .et$ C$rissis, oft'are En+ineerin+ Institute (lead, Nirsten Dauplaise, <0V0I! Mi2e Evanoo, *stems and oft'are Consortium, Inc. !ic$ 1rost, 3eneral Motors .rian 3alla+$er, <ort$rop 3rumman all* 3odfre*, <0 0 tep$en 3ristoc2, KP Mor+an C$ase and Co. Eric @a*es (non-votin+ mem)er, <ils Kaco)sen, Motorola teve Napurc$, <0 0 Mi2e Nonrad, oft'are En+ineerin+ Institute C$ris Moore, : 0ir 1orce 6endell Mullison, 3eneral D*namics Aand *stems David (Mi2e, P$illips, oft'are En+ineerin+ Institute !o)ert !assa, !a*t$eon pace and 0ir)orne *stems Naren !ic$ter, Institute for Defense 0nal*ses Mar* Aou !usso (non-votin+ mem)er,
431
6arren c$'oeme*er, Aoc2$eed Martin Corporation Ko$n ci)ilia, : 0rm* Dave 'idors2*, .an2 of 0merica .ar)ara T*son, oft'are En+ineerin+ Institute Mar* Van T*ne, oft'are En+ineerin+ Institute (non-votin+ mem)er, !a'don Doun+, oft'are En+ineerin+ Institute
!##I 3678 !ore #odel (eam
T$e Core Model Team develops t$e model material for all t$ree constellations. Kim 0rmstron+, tevens Institute of Tec$nolo+* !$onda .ro'n, oft'are En+ineerin+ Institute (co-lead, .randon .uteau, <ort$rop 3rumman Mic$ael Campo, !a*t$eon andra Cepeda, Cepeda *stems Q oft'are 0nal*sis&!DEC7M ED Mar* .et$ C$rissis, oft'are En+ineerin+ Institute Mi2e D;0m)rosa, Process Performance Professionals Eileen 1orrester, oft'are En+ineerin+ Institute 6ill @a*es, oft'are En+ineerin+ Institute Mi2e Nonrad, oft'are En+ineerin+ Institute (co-lead, o <orimatsu, <orimatsu Process En+ineerin+ Aa), Inc. Mar* A*nn Penn, Aoc2$eed Martin Corporation David (Mi2e, P$illips, oft'are En+ineerin+ Institute Naren !ic$ter, Institute for Defense 0nal*ses Mar* A*nn !usso, oft'are En+ineerin+ Institute (non-votin+ mem)er, Ko$n ci)ilia, : 0rm* and* $rum, oft'are En+ineerin+ Institute (co-lead, Nat$* mit$, @e'lett Pac2ard Natie mit$-Mc3art*, : <av*
!##I 3678 (ranslation (eam
T$e Translation Team coordinates translation 'or2 on CMMI materials. !ic$ard .as/ue, 0lc*oni5 Kose 0ntonio Calvo-Man-ano, :niversidad Politecnica de Madrid Carlos Caram, Inte+rated *stems Dia+nostics .ra-il 3on-alo Cuevas, :niversidad Politecnica de Madrid Mi2e Nonrad, oft'are En+ineerin+ Institute 0ntoine <arde-e, 0lc*oni5
432
o <orimatsu, <orimatsu Process En+ineerin+ Aa), Inc. (lead, even 7u, Institute for Information Industr* !icardo Panero Aamot$e, 0ccenture Mar* A*nn !usso, oft'are En+ineerin+ Institute (non-votin+ mem)er, 6infried !uss'urm, iemens 03 Tomas an 1eliu, :niversidad Politecnica de Madrid
!##I 3678 High #aturit" (eam
T$e @i+$ Maturit* team developed $i+$ maturit* model material. Dan .ennett, : 0ir 1orce 6ill @a*es, oft'are En+ineerin+ Institute !ic2 @efner, <ort$rop 3rumman Kim Nu)ec2, Aoc2$eed Martin Corporation 0lice Parr*, !a*t$eon Mar* A*nn Penn, Aoc2$eed Martin Corporation (lead, Nat$* mit$, @e'lett Pac2ard !a'don Doun+, oft'are En+ineerin+ Institute
!##I 3678 Ac%uisition #ini (eam
T$e 0c/uisition Mini Team provides ac/uisition e5pertise for model development 'or2. !ic$ 1rost, 3eneral Motors Tom Neuten, Neuten and 0ssociates David (Mi2e, P$illips, oft'are En+ineerin+ Institute (lead, Naren !ic$ter, Institute for Defense 0nal*ses Ko$n ci)ilia, : 0rm*
!##I 3678 )er ices #ini (eam
T$e ervices Mini Team provides service e5pertise for model development 'or2. Dre' 0llison, *stems and oft'are Consortium, Inc. .randon .uteau, <ort$rop 3rumman Eileen 1orrester, oft'are En+ineerin+ Institute (lead, C$ristian @ertnec2, 0n*'$ere."8 3m)@ Pam c$oppert, cience 0pplications International Corporation
433
!##I 3678 )!A#PI Upgrade (eam
T$e C0MPI :p+rade team develops t$e 0ppraisal !e/uirements for CMMI (0!C, document and C0MPI Met$od Definition Document (MDD,. Mar* .us)*, Aoc2$eed Martin Corporation Palma .uttles-Valde-, oft'are En+ineerin+ Institute Paul .*rnes, Inte+rated *stem Dia+nostics 6ill @a*es, oft'are En+ineerin+ Institute (leader, !avi N$etan, <ort$rop 3rumman Denise Nir2$am, T$e .oein+ Compan* Aisa Min+, T$e .oein+ Compan* C$arlie !*an, oft'are En+ineerin+ Institute Nevin c$aaff, oft'are En+ineerin+ Institute 0le5ander tall, oft'are En+ineerin+ Institute 0+api volou, oft'are En+ineerin+ Institute !on :lric$, <ort$rop 3rumman
!##I 3ersion 678 (raining (eams
T$e t'o trainin+ teams (one for CMMI-DEV and CMMI-0CB and t$e ot$er for CMMI- VC, developed model trainin+ materials.
AC@ a + %E) Tra" " ! Team
.ar)ara .ald'in, oft'are En+ineerin+ Institute .onnie .ollin+er, Process 1ocus Mana+ement Cat .randt-Uaccardi, oft'are En+ineerin+ Institute !$onda .ro'n, oft'are En+ineerin+ Institute Mic$ael Campo, !a*t$eon Mar* .et$ C$rissis, oft'are En+ineerin+ Institute (lead, tace* Cope, oft'are En+ineerin+ Institute Eric Dorsett, Keppesen Dan 1oster, P1 6illiamson Eric @a*es, oft'are En+ineerin+ Institute Nurt @ess, oft'are En+ineerin+ Institute Mi2e Nonrad, oft'are En+ineerin+ Institute teve Masters, oft'are En+ineerin+ Institute !o)ert Mc1eele*, oft'are En+ineerin+ Institute Diane Mi-u2ami-6illiams, <ort$rop 3rumman Daniel Pipitone, oft'are En+ineerin+ Institute Mar* Aou !usso, oft'are En+ineerin+ Institute (non-votin+ mem)er, and* $rum, oft'are En+ineerin+ Institute
434
Natie mit$-Mc3art*, : <av* .ar)ara T*son, oft'are En+ineerin+ Institute
S)C Tra" " ! Team
Dre' 0llison, *stems and oft'are Consortium, Inc. Mi2e .rid+es, :niversit* of Pitts)ur+$ Medical Center Paul .*rnes, Inte+rated *stem Dia+nostics andra Cepeda, Cepeda *stems Q oft'are 0nal*sis&!DEC7M ED Eileen Clar2, Tide'aters Consultin+ Nieran Do*le, E5cellence in Measurement Eileen 1orrester, oft'are En+ineerin+ Institute (lead of VC trainin+, u-anne Miller, oft'are En+ineerin+ Institute @illel 3la-er, Entine5 C$ristian @ertnec2, 0n*'$ere."8 3m)@ Pat Nir'an, oft'are En+ineerin+ Institute Kuda$ Mo+ilens2*, PEP @eat$er 7ppen$eimer, 7ppen$eimer Partners Pat 7;Toole, P0CT 0+api volou, 0le5anna Keff 6elc$, oft'are En+ineerin+ Institute
!##I 3678 2ualit" (eam
T$e Bualit* team conducts various /ualit* assurance c$ec2s on t$e model material to ensure its accurac*, reada)ilit*, and consistenc*. !$onda .ro'n, oft'are En+ineerin+ Institute (co-lead, Erin @arper, oft'are En+ineerin+ Institute Mi2e Nonrad, oft'are En+ineerin+ Institute Mar* Aou !usso, oft'are En+ineerin+ Institute Mar* A*nn !usso, oft'are En+ineerin+ Institute and* $rum, oft'are En+ineerin+ Institute (co-lead,
435
436
A''e +", %2 7&o$$ar1
T$e +lossar* defines t$e )asic terms used in CMMI models. 3lossar* entries are t*picall* multiple-'ord terms consistin+ of a noun and one or more restrictive modifiers. (T$ere are some e5ceptions to t$is rule t$at account for one-'ord terms in t$e +lossar*., T$e CMMI +lossar* of terms is not a re/uired, e5pected, or informative component of CMMI models. Interpret t$e terms in t$e +lossar* in t$e conte5t of t$e model component in '$ic$ t$e* appear. To formulate definitions appropriate for CMMI, 'e consulted multiple sources. 6e first consulted t$e Merriam=)ebster 0n!ine dictionar* ($ttp%&&'''.merriam-'e)ster.com&,. 6e also consulted ot$er standards as needed, includin+ t$e follo'in+% I 7 F### >I 7 "##9a? I 7&IEC 1""#= >I 7 "##Ha? I 7&IEC 199#8 >I 7 "##Ga? I 7&IEC 19"HH >I 7 "##H)? I 7&IEC 19F3F >I 7 "##=? I 7 "####-1 >I 7 "##9)? IEEE >IEEE 1FF1? CMM for oft'are ( 6-CMM, v1.1 EI0 G3" >EI0 "##3? 0-CMM > EI "##"? People CMM (P-CMM, >Curtis "##F? Co)iT v. 8.# >IT 3overnance "##9? ITIA v3 ( ervice Improvement, ervice Desi+n, ervice 7peration, ervice trate+*, and ervice Transition, >7ffice of 3overnment Commerce "##=?
6e developed t$e +lossar* reco+ni-in+ t$e importance of usin+ terminolo+* t$at all model users can understand. 6e also reco+ni-ed t$at 'ords and terms can $ave different meanin+s in different conte5ts and environments. T$e +lossar* in CMMI models is desi+ned to document t$e meanin+s of 'ords and terms t$at s$ould $ave t$e 'idest use and understandin+ )* users of CMMI products. Even t$ou+$ t$e term LproductM includes services as 'ell as products and t$e term LserviceM is defined as a t*pe of product, man* of t$e terms in t$e +lossar* contain )ot$ t$e 'ords LproductM and LserviceM to emp$asi-e t$at CMMI applies to )ot$ products and services.
7&o$$ar1
438
Ever* +lossar* entr* $as t'o to t$ree components. T$ere is al'a*s a term and al'a*s a definition. ometimes additional notes are provided. T$e term defined is listed on t$e left side of t$e pa+e. T$e definition appears first in a t*pe si-e similar to t$e term listed. 3lossar* notes follo' t$e definition and are in a smaller t*pe si-e.
a##e'ta #e #r"ter"a
T$e criteria t$at a delivera)le must satisf* to )e accepted )* a user, customer, or ot$er aut$ori-ed entit*. ( ee also Ldelivera)le.M, 1ormal testin+ conducted to ena)le a user, customer, or ot$er aut$ori-ed entit* to determine '$et$er to accept a delivera)le. ( ee also Lunit testin+.M, 0 list of process areas and t$eir correspondin+ capa)ilit* levels t$at represent t$e or+ani-ation;s pro+ress for eac$ process area '$ile advancin+ t$rou+$ t$e capa)ilit* levels. ( ee also Lcapa)ilit* level profile,M Ltar+et profile,M and Ltar+et sta+in+.M, T$e sta2e$older t$at ac/uires or procures a product or service from a supplier. ( ee also Lsta2e$older.M, T$e process of o)tainin+ products or services t$rou+$ supplier a+reements. ( ee also Lsupplier a+reement.M, T$e specific approac$ to ac/uirin+ products and services t$at is )ased on considerations of suppl* sources, ac/uisition met$ods, re/uirements specification t*pes, a+reement t*pes, and related ac/uisition ris2s. 0 clearl* mar2ed model component t$at contains information of interest to particular users. &n a C$$& model, all additions bearing the same name can be optionally selected as a group for use. &n C$$& for *ervices, the *ervice *ystem %evelopment 2**%3 process area is an addition.
a##e'ta #e te$t" !
a#-"eveme t 'rof"&e
a#=/"rer a#=/"$"t"o a#=/"$"t"o $trate!1
a++"t"o
a&&o#ate+ re=/"reme t
!e/uirement t$at results from lev*in+ all or part of a $i+$er level re/uirement on a lo'er level arc$itectural element or desi+n component. $ore generally, re0uirements can be allocated to other logical or physical components including people, consumables, delivery increments, or the architecture as a whole, depending on what best enables the product or service to achieve the re0uirements.
43<
7&o$$ar1
a''ra"$a&
0n e5amination of one or more processes )* a trained team of professionals usin+ an appraisal reference model as t$e )asis for determinin+, at a minimum, stren+t$s and 'ea2nesses. (his term has a special meaning in the C$$& 'roduct *uite besides its common standard English meaning.
a''ra"$a& f" +" !$
T$e results of an appraisal t$at identif* t$e most important issues, pro)lems, or opportunities for process improvement 'it$in t$e appraisal scope. "ppraisal findings are inferences drawn from corroborated objective evidence.
a''ra"$a& 'art"#"'a t$ a''ra"$a& rat" !
Mem)ers of t$e or+ani-ational unit '$o participate in providin+ information durin+ an appraisal. T$e value assi+ned )* an appraisal team to (a, a CMMI +oal or process area, (), t$e capa)ilit* level of a process area, or (c, t$e maturit* level of an or+ani-ational unit. (his term is used in C$$& appraisal materials such as the *C"$'& $%%. " rating is determined by enacting the defined rating process for the appraisal method being employed.
a''ra"$a& refere #e mo+e&
T$e CMMI model to '$ic$ an appraisal team correlates implemented process activities. (his term is used in C$$& appraisal materials such as the *C"$'& $%%.
a''ra"$a& $#o'e
T$e definition of t$e )oundaries of an appraisal encompassin+ t$e or+ani-ational limits and CMMI model limits 'it$in '$ic$ t$e processes to )e investi+ated operate. (his term is used in C$$& appraisal materials such as the *C"$'& $%%.
ar#-"te#t/re
T$e set of structures needed to reason a)out a product. T$ese structures are comprised of elements, relations amon+ t$em, and properties of )ot$. &n a service context, the architecture is often applied to the service system. 7ote that functionality is only one aspect of the product. )uality attributes, such as responsiveness, reliability, and security, are also important to reason about. *tructures provide the means for highlighting different portions of the architecture. 2*ee also @functional architecture.A3
7&o$$ar1
433
a/+"t
0n o)4ective e5amination of a 'or2 product or set of 'or2 products a+ainst specific criteria (e.+., re/uirements,. ( ee also Lo)4ectivel* evaluate.M, (his is a term used in several ways in C$$&, including configuration audits and process compliance audits.
ba$e&" e
0 set of specifications or 'or2 products t$at $as )een formall* revie'ed and a+reed on, '$ic$ t$ereafter serves as t$e )asis for furt$er development, and '$ic$ can )e c$an+ed onl* t$rou+$ c$an+e control procedures. ( ee also Lconfi+uration )aselineM and Lproduct )aseline.M, Measure defined in terms of an attri)ute and t$e met$od for /uantif*in+ it. ( ee also Lderived measure.M, " base measure is functionally independent of other measures.
ba$e mea$/re
b"+"re#t"o a& tra#eab"&"t1 b/$" e$$ ob0e#t"ve$ #a'ab"&"t1 &eve&
0n association amon+ t'o or more lo+ical entities t$at is discerna)le in eit$er direction (i.e., to and from an entit*,. ( ee also Lre/uirements tracea)ilit*M and Ltracea)ilit*.M, ( ee Lor+ani-ation;s )usiness o)4ectives.M, 0c$ievement of process improvement 'it$in an individual process area. ( ee also L+eneric +oal,M Lspecific +oal,M Lmaturit* level,M and Lprocess area.M, " capability level is defined by appropriate specific and generic goals for a process area.
#a'ab"&"t1 &eve& 'rof"&e
0 list of process areas and t$eir correspondin+ capa)ilit* levels. ( ee also Lac$ievement profile,M Ltar+et profile,M and Ltar+et sta+in+.M, " capability level profile can be an @achievement profileA when it represents the organi6ation9s progress for each process area while advancing through the capability levels. Or, it can be a @target profileA when it represents an objective for process improvement.
#a'ab"&"t1 mat/r"t1 mo+e&
0 model t$at contains t$e essential elements of effective processes for one or more areas of interest and descri)es an evolutionar* improvement pat$ from ad $oc, immature processes to disciplined, mature processes 'it$ improved /ualit* and effectiveness. 0 process t$at can satisf* its specified product /ualit*, service /ualit*, and process performance o)4ectives. ( ee also Lsta)le processM and Lstandard process.M, T$e anal*sis of outcomes to determine t$eir causes.
#a'ab&e 'ro#e$$
#a/$a& a a&1$"$
440
7&o$$ar1
#-a !e ma a!eme t CMMI .ramewor?
Kudicious use of means to effect a c$an+e, or a proposed c$an+e, to a product or service. ( ee also Lconfi+uration mana+ement.M, T$e )asic structure t$at or+ani-es CMMI components, includin+ elements of current CMMI models as 'ell as rules and met$ods for +eneratin+ models, appraisal met$ods (includin+ associated artifacts,, and trainin+ materials. ( ee also LCMMI modelM and LCMMI Product uite.M, (he framewor1 enables new areas of interest to be added to C$$& so that they will integrate with the existing ones.
CMMI mo+e& CMMI mo+e& #om'o e t
0 model +enerated from t$e CMMI 1rame'or2. ( ee also LCMMI 1rame'or2M and LCMMI Product uite.M, 0n* of t$e main arc$itectural elements t$at compose a CMMI model. *ome of the main elements of a C$$& model include specific practices, generic practices, specific goals, generic goals, process areas, capability levels, and maturity levels.
CMMI Pro+/#t S/"te
T$e complete set of products developed around t$e CMMI concept. ( ee also LCMMI 1rame'or2M and LCMMI model.M, (hese products include the framewor1 itself, models, appraisal methods, appraisal materials, and training materials.
#ommer#"a& offt-e-$-e&f #ommo #a/$e of var"at"o #o f"!/rat"o a/+"t
Items t$at can )e purc$ased from a commercial supplier. T$e variation of a process t$at e5ists )ecause of normal and e5pected interactions amon+ components of a process. ( ee also Lspecial cause of variation.M, 0n audit conducted to verif* t$at a confi+uration item or a collection of confi+uration items t$at ma2e up a )aseline conforms to a specified standard or re/uirement. ( ee also LauditM and Lconfi+uration item.M, T$e confi+uration information formall* desi+nated at a specific time durin+ a product;s or product component;s life. ( ee also Lproduct lifec*cle.M, Configuration baselines plus approved changes from those baselines constitute the current configuration information.
#o f"!/rat"o ba$e&" e
7&o$$ar1
441
#o f"!/rat"o #o tro&
0n element of confi+uration mana+ement consistin+ of t$e evaluation, coordination, approval or disapproval, and implementation of c$an+es to confi+uration items after formal esta)lis$ment of t$eir confi+uration identification. ( ee also Lconfi+uration identification,M Lconfi+uration item,M and Lconfi+uration mana+ement.M, 0 +roup of people responsi)le for evaluatin+ and approvin+ or disapprovin+ proposed c$an+es to confi+uration items and for ensurin+ implementation of approved c$an+es. ( ee also Lconfi+uration item.M, Configuration control boards are also 1nown as @change control boards.A
#o f"!/rat"o #o tro& boar+
#o f"!/rat"o "+e t"f"#at"o
0n element of confi+uration mana+ement consistin+ of selectin+ t$e confi+uration items for a product, assi+nin+ uni/ue identifiers to t$em, and recordin+ t$eir functional and p$*sical c$aracteristics in tec$nical documentation. ( ee also Lconfi+uration item,M Lconfi+uration mana+ement,M and Lproduct.M, 0n a++re+ation of 'or2 products t$at is desi+nated for confi+uration mana+ement and treated as a sin+le entit* in t$e confi+uration mana+ement process. ( ee also Lconfi+uration mana+ement.M, 0 discipline appl*in+ tec$nical and administrative direction and surveillance to (1, identif* and document t$e functional and p$*sical c$aracteristics of a confi+uration item, (", control c$an+es to t$ose c$aracteristics, (3, record and report c$an+e processin+ and implementation status, and (8, verif* compliance 'it$ specified re/uirements. ( ee also Lconfi+uration audit,M Lconfi+uration control,M Lconfi+uration identification,M and Lconfi+uration status accountin+.M, 0n element of confi+uration mana+ement consistin+ of t$e recordin+ and reportin+ of information needed to mana+e a confi+uration effectivel*. ( ee also Lconfi+uration identificationM and Lconfi+uration mana+ement.M, (his information includes a list of the approved configuration, the status of proposed changes to the configuration, and the implementation status of approved changes.
#o f"!/rat"o "tem
#o f"!/rat"o ma a!eme t
#o f"!/rat"o $tat/$ a##o/ t" !
#o $te&&at"o
0 collection of CMMI components t$at are used to construct models, trainin+ materials, and appraisal related documents for an area of interest (e.+., ac/uisition, development, services,.
442
7&o$$ar1
#o t" /o/$ re're$e tat"o
0 capa)ilit* maturit* model structure '$erein capa)ilit* levels provide a recommended order for approac$in+ process improvement 'it$in eac$ specified process area. ( ee also Lcapa)ilit* level,M Lprocess area,M and Lsta+ed representation.M, ( ee Lsupplier.M, T$e result of t$e anal*sis and refinement of customer re/uirements into a set of re/uirements suita)le to )e included in one or more solicitation pac2a+es, or supplier a+reements. ( ee also Lac/uirer,M Lcustomer re/uirement,M Lsupplier a+reement,M and Lsolicitation pac2a+e.M, Contractual re0uirements include both technical and nontechnical re0uirements necessary for the ac0uisition of a product or service.
#o tra#tor #o tra#t/a& re=/"reme t$
#orre#t"ve a#t"o #/$tomer
0cts or deeds used to remed* a situation or remove an error. T$e part* responsi)le for acceptin+ t$e product or for aut$ori-in+ pa*ment. (he customer is external to the project or wor1 group 2except possibly in certain project structures in which the customer effectively is on the project team or in the wor1 group3 but not necessarily external to the organi6ation. (he customer can be a higher level project or wor1 group. Customers are a subset of sta1eholders. 2*ee also @sta1eholder.A3 &n most cases where this term is used, the preceding definition is intended8 however, in some contexts, the term @customerA is intended to include other relevant sta1eholders. 2*ee also @customer re0uirement.A3 End users can be distinguished from customers if the parties that directly receive the value of products and services are not the same as the parties that arrange for, pay for, or negotiate agreements. &n contexts where customers and end users are essentially the same parties, the term @customerA can encompass both types. 2*ee also @end user.A3
#/$tomer re=/"reme t
T$e result of elicitin+, consolidatin+, and resolvin+ conflicts amon+ t$e needs, e5pectations, constraints, and interfaces of t$e product;s relevant sta2e$olders in a 'a* t$at is accepta)le to t$e customer. ( ee also Lcustomer.M, !ecorded information. #ecorded information can include technical data, computer software documents, financial information, management information, representation of facts, numbers, or datum of any nature that can be communicated, stored, and processed.
+ata
7&o$$ar1
443
+ata ma a!eme t
T$e disciplined processes and s*stems t$at plan for, ac/uire, and provide ste'ards$ip for )usiness and tec$nical data, consistent 'it$ data re/uirements, t$rou+$out t$e data lifec*cle. <um)er of defects per unit of product si-e. "n example is the number of problem reports per thousand lines of code.
+efe#t +e $"t1
+ef" e+ 'ro#e$$
0 mana+ed process t$at is tailored from t$e or+ani-ation;s set of standard processes accordin+ to t$e or+ani-ation;s tailorin+ +uidelinesI $as a maintained process descriptionI and contri)utes process related e5periences to t$e or+ani-ational process assets. ( ee also Lmana+ed process.M, 0 c$aracteri-ation of re/uired functionalit* and /ualit* attri)utes o)tained t$rou+$ Lc$un2in+,M or+ani-in+, annotatin+, structurin+, or formali-in+ t$e re/uirements (functional and non-functional, to facilitate furt$er refinement and reasonin+ a)out t$e re/uirements as 'ell as (possi)l*, initial, solution e5ploration, definition, and evaluation. ( ee also Larc$itecture,M Lfunctional arc$itecture,M and L/ualit* attri)ute.M, "s technical solution processes progress, this characteri6ation can be further evolved into a description of the architecture versus simply helping scope and guide its development, depending on the engineering processes used8 re0uirements specification and architectural languages used8 and the tools and the environment used for product or service system development.
+ef" "t"o of re=/"re+ f/ #t"o a&"t1 a + =/a&"t1 attr"b/te$
+e&"verab&e
0n item to )e provided to an ac/uirer or ot$er desi+nated recipient as specified in an a+reement. ( ee also Lac/uirer.M, (his item can be a document, hardware item, software item, service, or any type of wor1 product.
444
7&o$$ar1
+e&"ver1 e v"ro me t
T$e complete set of circumstances and conditions under '$ic$ services are delivered in accordance 'it$ service a+reements. ( ee also LserviceM and Lservice a+reement.M, (he delivery environment encompasses everything that has or can have a significant effect on service delivery, including but not limited to service system operation, natural phenomena, and the behavior of all parties, whether or not they intend to have such an effect. For example, consider the effect of weather or traffic patterns on a transportation service. 2*ee also @service system.A3 (he delivery environment is uni0uely distinguished from other environments 2e.g., simulation environments, testing environments3. (he delivery environment is the one in which services are actually delivered and count as satisfying a service agreement.
+er"ve+ mea$/re +er"ve+ re=/"reme t$
Measure t$at is defined as a function of t'o or more values of )ase measures. ( ee also L)ase measure.M, !e/uirements t$at are not e5plicitl* stated in customer re/uirements )ut are inferred (1, from conte5tual re/uirements (e.+., applica)le standards, la's, policies, common practices, mana+ement decisions, or (", from re/uirements needed to specif* a product or service component. %erived re0uirements can also arise during analysis and design of components of the product or service. 2*ee also @product re0uirements.A3
+e$"! rev"ew
0 formal, documented, compre$ensive, and s*stematic e5amination of a desi+n to determine if t$e desi+n meets t$e applica)le re/uirements, to identif* pro)lems, and to propose solutions. To create a product or service s*stem )* deli)erate effort. &n some contexts, development can include the maintenance of the developed product.
+eve&o'me t
+o#/me t
0 collection of data, re+ardless of t$e medium on '$ic$ it is recorded, t$at +enerall* $as permanence and can )e read )* $umans or mac$ines. %ocuments include both paper and electronic documents.
7&o$$ar1
445
e + /$er
0 part* t$at ultimatel* uses a delivered product or t$at receives t$e )enefit of a delivered service. ( ee also Lcustomer.M, End users may or may not also be customers 2who can establish and accept agreements or authori6e payments3. &n contexts where a single service agreement covers multiple service deliveries, any party that initiates a service re0uest can be considered an end user. 2*ee also @service agreementA and @service re0uest.A3
e ter'r"$e
T$e full composition of a compan*. ( ee also Lor+ani-ation.M, " company can consist of many organi6ations in many locations with different customers.
e tr1 #r"ter"a e=/"va&e t $ta!" !
tates of )ein+ t$at must )e present )efore an effort can )e+in successfull*. 0 tar+et sta+in+, created usin+ t$e continuous representation t$at is defined so t$at t$e results of usin+ t$e tar+et sta+in+ can )e compared to maturit* levels of t$e sta+ed representation. ( ee also Lcapa)ilit* level profile,M Lmaturit* level,M Ltar+et profile,M and Ltar+et sta+in+.M, *uch staging permits benchmar1ing of progress among organi6ations, enterprises, projects, and wor1 groups, regardless of the C$$& representation used. (he organi6ation can implement components of C$$& models beyond the ones reported as part of e0uivalent staging. E0uivalent staging relates how the organi6ation compares to other organi6ations in terms of maturity levels.
e$tab&"$- a + ma" ta"
Create, document, use, and revise 'or2 products as necessar* to ensure t$e* remain useful. (he phrase @establish and maintainA plays a special role in communicating a deeper principle in C$$&: wor1 products that have a central or 1ey role in wor1 group, project, and organi6ational performance should be given attention to ensure they are used and useful in that role. (his phrase has particular significance in C$$& because it often appears in goal and practice statements 2though in the former as Restablished and maintainedR3 and should be ta1en as shorthand for applying the principle to whatever wor1 product is the object of the phrase.
e,am'&e wor? 'ro+/#t e,e#/t"ve
0n informative model component t$at provides sample outputs from a specific practice. ( ee Lsenior mana+er.M,
446
7&o$$ar1
e,"t #r"ter"a e,'e#te+ CMMI #om'o e t$
tates of )ein+ t$at must )e present )efore an effort can end successfull*. CMMI components t$at descri)e t$e activities t$at are important in ac$ievin+ a re/uired CMMI component. $odel users can implement the expected components explicitly or implement e0uivalent practices to these components. *pecific and generic practices are expected model components.
f" +" !$ forma& eva&/at"o 'ro#e$$ framewor? f/ #t"o a& a a&1$"$
( ee Lappraisal findin+s.M, 0 structured approac$ to evaluatin+ alternative solutions a+ainst esta)lis$ed criteria to determine a recommended solution to address an issue. ( ee LCMMI 1rame'or2.M, E5amination of a defined function to identif* all t$e su)functions necessar* to accomplis$ t$at functionI identification of functional relations$ips and interfaces (internal and e5ternal, and capturin+ t$ese relations$ips and interfaces in a functional arc$itectureI and flo' do'n of upper level re/uirements and assi+nment of t$ese re/uirements to lo'er level su)functions. ( ee also Lfunctional arc$itecture.M, T$e $ierarc$ical arran+ement of functions, t$eir internal and e5ternal (e5ternal to t$e a++re+ation itself, functional interfaces and e5ternal p$*sical interfaces, t$eir respective re/uirements, and t$eir desi+n constraints. ( ee also Larc$itecture,M Lfunctional anal*sis,M and Ldefinition of re/uired functionalit* and /ualit* attri)utes.M, 0 re/uired model component t$at descri)es c$aracteristics t$at must )e present to institutionali-e processes t$at implement a process area. ( ee also Linstitutionali-ation.M, 0n e5pected model component t$at is considered important in ac$ievin+ t$e associated +eneric +oal. (he generic practices associated with a generic goal describe the activities that are expected to result in achievement of the generic goal and contribute to the institutionali6ation of the processes associated with a process area.
f/ #t"o a& ar#-"te#t/re
!e er"# !oa&
!e er"# 'ra#t"#e
!e er"# 'ra#t"#e e&aborat"o
0n informative model component t$at appears after a +eneric practice to provide +uidance on $o' t$e +eneric practice could )e applied uni/uel* to a process area. (T$is model component is not present in all CMMI models.,
7&o$$ar1
448
-ar+ware e !" eer" !
T$e application of a s*stematic, disciplined, and /uantifia)le approac$ to transformin+ a set of re/uirements t$at represent t$e collection of sta2e$older needs, e5pectations, and constraints, usin+ documented tec$ni/ues and tec$nolo+* to desi+n, implement, and maintain a tan+i)le product. ( ee also Lsoft'are en+ineerin+M and Ls*stems en+ineerin+.M, &n C$$&, hardware engineering represents all technical fields 2e.g., electrical, mechanical3 that transform re0uirements and ideas into tangible products.
-"!-er &eve& ma a!eme t
T$e person or persons '$o provide t$e polic* and overall +uidance for t$e process )ut do not provide t$e direct da*to-da* monitorin+ and controllin+ of t$e process. ( ee also Lsenior mana+er.M, *uch persons belong to a level of management in the organi6ation above the immediate level responsible for the process and can be 2but are not necessarily3 senior managers.
" #om'&ete 'ro#e$$
0 process t$at is not performed or is performed onl* partiall*I one or more of t$e specific +oals of t$e process area are not satisfied. "n incomplete process is also 1nown as capability level >.
" format"ve CMMI #om'o e t$
CMMI components t$at $elp model users understand t$e re/uired and e5pected components of a model. (hese components can be examples, detailed explanations, or other helpful information. *ubpractices, notes, references, goal titles, practice titles, sources, example wor1 products, and generic practice elaborations are informative model components.
" $t"t/t"o a&"Aat"o " terfa#e #o tro&
T$e in+rained 'a* of doin+ )usiness t$at an or+ani-ation follo's routinel* as part of its corporate culture. In confi+uration mana+ement, t$e process of (1, identif*in+ all functional and p$*sical c$aracteristics relevant to t$e interfacin+ of t'o or more confi+uration items provided )* one or more or+ani-ations and (", ensurin+ t$at proposed c$an+es to t$ese c$aracteristics are evaluated and approved prior to implementation. ( ee also Lconfi+uration itemM and Lconfi+uration mana+ement.M, 0 partitionin+ of t$e life of a product, service, pro4ect, 'or2 +roup, or set of 'or2 activities into p$ases.
&"fe#1#&e mo+e&
44<
7&o$$ar1
ma a!e+ 'ro#e$$
0 performed process t$at is planned and e5ecuted in accordance 'it$ polic*I emplo*s s2illed people $avin+ ade/uate resources to produce controlled outputsI involves relevant sta2e$oldersI is monitored, controlled, and revie'edI and is evaluated for ad$erence to its process description. ( ee also Lperformed process.M, 0 person '$o provides tec$nical and administrative direction and control to t$ose '$o perform tas2s or activities 'it$in t$e mana+er;s area of responsi)ilit*. (his term has a special meaning in the C$$& 'roduct *uite besides its common standard English meaning. (he traditional functions of a manager include planning, organi6ing, directing, and controlling wor1 within an area of responsibility.
ma a!er
mat/r"t1 &eve&
De+ree of process improvement across a predefined set of process areas in '$ic$ all +oals in t$e set are attained. ( ee also Lcapa)ilit* levelM and Lprocess area.M, Varia)le to '$ic$ a value is assi+ned as a result of measurement. ( ee also L)ase measure,M Lderived measure,M and Lmeasurement.M, (he definition of this term in C$$& is consistent with the definition of this term in &*O =KN!N.
mea$/re : o/ ;
mea$/reme t
0 set of operations to determine t$e value of a measure. ( ee also Lmeasure.M, (he definition of this term in C$$& is consistent with the definition of this term in &*O =KN!N.
mea$/reme t re$/&t memora +/m of a!reeme t
0 value determined )* performin+ a measurement. ( ee also Lmeasurement.M, .indin+ document of understandin+ or a+reement )et'een t'o or more parties. " memorandum of agreement is also 1nown as a @memorandum of understanding.A
at/ra& bo/ +$
T$e in$erent ran+e of variation in a process, as determined )* process performance measures. 7atural bounds are sometimes referred to as @voice of the process.A (echni0ues such as control charts, confidence intervals, and prediction intervals are used to determine whether the variation is due to common causes 2i.e., the process is predictable or stable3 or is due to some special cause that can and should be identified and removed. 2*ee also @measureA and @process performance.A3
7&o$$ar1
443
o +eve&o'me ta& "tem
0n item t$at 'as developed prior to its current use in an ac/uisition or development process. *uch an item can re0uire minor modifications to meet the re0uirements of its current intended use.
o te#- "#a& re=/"reme t$
!e/uirements affectin+ product and service ac/uisition or development t$at are not properties of t$e product or service. Examples include numbers of products or services to be delivered, data rights for delivered CO(* and nondevelopmental items, delivery dates, and milestones with exit criteria. Other nontechnical re0uirements include wor1 constraints associated with training, site provisions, and deployment schedules.
ob0e#t"ve&1 eva&/ate
To revie' activities and 'or2 products a+ainst criteria t$at minimi-e su)4ectivit* and )ias )* t$e revie'er. ( ee also Laudit.M, "n example of an objective evaluation is an audit against re0uirements, standards, or procedures by an independent 0uality assurance function.
o'erat"o a& #o #e't
0 +eneral description of t$e 'a* in '$ic$ an entit* is used or operates. "n operational concept is also 1nown as @concept of operations.A
o'erat"o a& $#e ar"o
0 description of an ima+ined se/uence of events t$at includes t$e interaction of t$e product or service 'it$ its environment and users, as 'ell as interaction amon+ its product or service components. Operational scenarios are used to evaluate the re0uirements and design of the system and to verify and validate the system.
or!a "Aat"o
0n administrative structure in '$ic$ people collectivel* mana+e one or more pro4ects or 'or2 +roups as a '$ole, s$are a senior mana+er, and operate under t$e same policies. /owever, the word @organi6ationA as used throughout C$$& models can also apply to one person who performs a function in a small organi6ation that might be performed by a group of people in a large organi6ation. 2*ee also @enterprise.A3
or!a "Aat"o a& mat/r"t1
T$e e5tent to '$ic$ an or+ani-ation $as e5plicitl* and consistentl* deplo*ed processes t$at are documented, mana+ed, measured, controlled, and continuall* improved. Organi6ational maturity can be measured via appraisals.
450
7&o$$ar1
or!a "Aat"o a& 'o&"#1 or!a "Aat"o a& 'ro#e$$ a$$et$
0 +uidin+ principle t*picall* esta)lis$ed )* senior mana+ement t$at is adopted )* an or+ani-ation to influence and determine decisions. 0rtifacts t$at relate to descri)in+, implementin+, and improvin+ processes. Examples of these artifacts include policies, measurement descriptions, process descriptions, process implementation support tools. (he term @process assetsA is used to indicate that these artifacts are developed or ac0uired to meet the business objectives of the organi6ation and that they represent investments by the organi6ation that are expected to provide current and future business value. 2*ee also @process asset library.A3
or!a "Aat"o B$ b/$" e$$ ob0e#t"ve$
enior-mana+ement-developed o)4ectives desi+ned to ensure an or+ani-ation;s continued e5istence and en$ance its profita)ilit*, mar2et s$are, and ot$er factors influencin+ t$e or+ani-ation;s success. ( ee also L/ualit* and process performance o)4ectivesM and L/uantitative o)4ective.M, 0 repositor* used to collect and ma2e measurement results availa)le on processes and 'or2 products, particularl* as t$e* relate to t$e or+ani-ation;s set of standard processes. (his repository contains or references actual measurement results and related information needed to understand and analy6e measurement results.
or!a "Aat"o B$ mea$/reme t re'o$"tor1
or!a "Aat"o B$ 'ro#e$$ a$$et &"brar1
0 li)rar* of information used to store and ma2e process assets availa)le t$at are useful to t$ose '$o are definin+, implementin+, and mana+in+ processes in t$e or+ani-ation. (his library contains process assets that include process related documentation such as policies, defined processes, chec1lists, lessons learned documents, templates, standards, procedures, plans, and training materials.
or!a "Aat"o B$ $et of $ta +ar+ 'ro#e$$e$
0 collection of definitions of t$e processes t$at +uide activities in an or+ani-ation. (hese process descriptions cover the fundamental process elements 2and their relationships to each other such as ordering and interfaces3 that should be incorporated into the defined processes that are implemented in projects, wor1 groups, and wor1 across the organi6ation. " standard process enables consistent development and maintenance activities across the organi6ation and is essential for long5term stability and improvement. 2*ee also @defined processA and @process element.A3 ( ee Lac/uisition.M,
o/t$o/r#" !
7&o$$ar1
451
'eer rev"ew
T$e revie' of 'or2 products performed )* peers durin+ t$e development of 'or2 products to identif* defects for removal. ( ee also L'or2 product.M, (he term @peer reviewA is used in the C$$& 'roduct *uite instead of the term @wor1 product inspection.A
'erforma #e 'arameter$ 'erforme+ 'ro#e$$
T$e measures of effectiveness and ot$er 2e* measures used to +uide and control pro+ressive development. 0 process t$at accomplis$es t$e needed 'or2 to produce 'or2 productsI t$e specific +oals of t$e process area are satisfied. 0 process t$at is documented )* )ot$ a description and a plan. (he description and plan should be coordinated and the plan should include standards, re0uirements, objectives, resources, and assignments.
'&a
e+ 'ro#e$$
'o&"#1 'ro#e$$
( ee Lor+ani-ational polic*.M, 0 set of interrelated activities, '$ic$ transform inputs into outputs, to ac$ieve a +iven purpose. ( ee also Lprocess area,M Lsu)process,M and Lprocess element.M, (here is a special use of the phrase @the processA in the statements and descriptions of the generic goals and generic practices. @(he process,A as used in 'art (wo, is the process or processes that implement the process area. (he terms @process,A @subprocessA and @process elementA form a hierarchy with @processA as the highest, most general term, @subprocessesA below it, and @process elementA as the most specific. " particular process can be called a subprocess if it is part of another larger process. &t can also be called a process element if it is not decomposed into subprocesses. (his definition of process is consistent with the definition of process in &*O N>>>, &*O =<<>G, &*O =KK>L, and E&" G!=.
'ro#e$$ a#t"o '&a 'ro#e$$ a#t"o team 'ro#e$$ a + te#- o&o!1 "m'roveme t$
0 plan, usuall* resultin+ from appraisals, t$at documents $o' specific improvements tar+etin+ t$e 'ea2nesses uncovered )* an appraisal 'ill )e implemented. 0 team t$at $as t$e responsi)ilit* to develop and implement process improvement activities for an or+ani-ation as documented in a process action plan. Incremental and innovative improvements to processes and to process, product, or service tec$nolo+ies.
452
7&o$$ar1
'ro#e$$ ar#-"te#t/re
(1, T$e orderin+, interfaces, interdependencies, and ot$er relations$ips amon+ t$e process elements in a standard process, or (", t$e interfaces, interdependencies, and ot$er relations$ips )et'een process elements and e5ternal processes. 0 cluster of related practices in an area t$at, '$en implemented collectivel*, satisfies a set of +oals considered important for ma2in+ improvement in t$at area. 0n*t$in+ t$e or+ani-ation considers useful in attainin+ t$e +oals of a process area. ( ee also Lor+ani-ational process assets.M, 0 collection of process asset $oldin+s t$at can )e used )* an or+ani-ation, pro4ect, or 'or2 +roup. ( ee also Lor+ani-ation;s process asset li)rar*.M, 0 measura)le c$aracteristic of process capa)ilit* applica)le to an* process. T$e ran+e of e5pected results t$at can )e ac$ieved )* follo'in+ a process. T$e act of definin+ and descri)in+ a process. (he result of process definition is a process description. 2*ee also @process description.A3
'ro#e$$ area
'ro#e$$ a$$et
'ro#e$$ a$$et &"brar1 'ro#e$$ attr"b/te 'ro#e$$ #a'ab"&"t1 'ro#e$$ +ef" "t"o
'ro#e$$ +e$#r"'t"o
0 documented e5pression of a set of activities performed to ac$ieve a +iven purpose. " process description provides an operational definition of the major components of a process. (he description specifies, in a complete, precise, and verifiable manner, the re0uirements, design, behavior, or other characteristics of a process. &t also can include procedures for determining whether these provisions have been satisfied. 'rocess descriptions can be found at the activity, project, wor1 group, or organi6ational level.
7&o$$ar1
453
'ro#e$$ e&eme t
T$e fundamental unit of a process. " process can be defined in terms of subprocesses or process elements. " subprocess is a process element when it is not further decomposed into subprocesses or process elements. 2*ee also @processA and @subprocess.A3 Each process element covers a closely related set of activities 2e.g., estimating element, peer review element3. 'rocess elements can be portrayed using templates to be completed, abstractions to be refined, or descriptions to be modified or used. " process element can be an activity or tas1. (he terms @process,A @subprocess,A and @process elementA form a hierarchy with @processA as the highest, most general term, @subprocessesA below it, and @process elementA as the most specific.
'ro#e$$ !ro/'
0 collection of specialists '$o facilitate t$e definition, maintenance, and improvement of processes used )* t$e or+ani-ation. 0 pro+ram of activities desi+ned to improve t$e process performance and maturit* of t$e or+ani-ation;s processes, and t$e results of suc$ a pro+ram. 0 set of tar+et c$aracteristics esta)lis$ed to +uide t$e effort to improve an e5istin+ process in a specific, measura)le 'a* eit$er in terms of resultant product or service c$aracteristics (e.+., /ualit*, product performance, conformance to standards, or in t$e 'a* in '$ic$ t$e process is e5ecuted (e.+., elimination of redundant process steps, com)ination of process steps, improvement of c*cle time,. ( ee also Lor+ani-ation;s )usiness o)4ectivesM and L/uantitative o)4ective.M, 0 plan for ac$ievin+ or+ani-ational process improvement o)4ectives )ased on a t$orou+$ understandin+ of current stren+t$s and 'ea2nesses of t$e or+ani-ation;s processes and process assets. 0 set of operations used to determine values of measures of a process and its resultin+ products or services for t$e purpose of c$aracteri-in+ and understandin+ t$e process. ( ee also Lmeasurement.M,
'ro#e$$ "m'roveme t 'ro#e$$ "m'roveme t ob0e#t"ve$
'ro#e$$ "m'roveme t '&a
'ro#e$$ mea$/reme t
454
7&o$$ar1
'ro#e$$ ow er
T$e person (or team, responsi)le for definin+ and maintainin+ a process. "t the organi6ational level, the process owner is the person 2or team3 responsible for the description of a standard process8 at the project or wor1 group level, the process owner is the person 2or team3 responsible for the description of the defined process. " process can therefore have multiple owners at different levels of responsibility. 2*ee also @defined processA and @standard process.A3
'ro#e$$ 'erforma #e
0 measure of results ac$ieved )* follo'in+ a process. ( ee also Lmeasure.M, 'rocess performance is characteri6ed by both process measures 2e.g., effort, cycle time, defect removal efficiency3 and product or service measures 2e.g., reliability, defect density, response time3.
'ro#e$$ 'erforma #e ba$e&" e
0 documented c$aracteri-ation of process performance, '$ic$ can include central tendenc* and variation. ( ee also Lprocess performance.M, " process performance baseline can be used as a benchmar1 for comparing actual process performance against expected process performance.
'ro#e$$ 'erforma #e mo+e&
0 description of relations$ips amon+ t$e measura)le attri)utes of one or more processes or 'or2 products t$at is developed from $istorical process performance data and is used to predict future performance. ( ee also Lmeasure.M, One or more of the measureable attributes represent controllable inputs tied to a subprocess to enable performance of @what5ifA analyses for planning, dynamic re5planning, and problem resolution. 'rocess performance models include statistical, probabilistic and simulation based models that predict interim or final results by connecting past performance with future outcomes. (hey model the variation of the factors, and provide insight into the expected range and variation of predicted results. " process performance model can be a collection of models that 2when combined3 meet the criteria of a process performance model.
'ro#e$$ ta"&or" !
Ma2in+, alterin+, or adaptin+ a process description for a particular end. For example, a project or wor1 group tailors its defined process from the organi6ation9s set of standard processes to meet objectives, constraints, and the environment of the project or wor1 group. 2*ee also @defined process,A @organi6ation9s set of standard processes,A and @process description.A3
7&o$$ar1
455
'ro+/#t
0 'or2 product t$at is intended for deliver* to a customer or end user. (his term has a special meaning in the C$$& 'roduct *uite besides its common standard English meaning. (he form of a product can vary in different contexts. 2*ee also @customer,A @product component,A @service,A and @wor1 product.A3
'ro+/#t ba$e&" e
T$e initial approved tec$nical data pac2a+e definin+ a confi+uration item durin+ t$e production, operation, maintenance, and lo+istic support of its lifec*cle. ( ee also Lconfi+uration item,M Lconfi+uration mana+ement,M and Ltec$nical data pac2a+e.M, (his term is related to configuration management.
'ro+/#t #om'o e t
0 'or2 product t$at is a lo'er level component of t$e product. ( ee also LproductM and L'or2 product.M, 'roduct components are integrated to produce the product. (here can be multiple levels of product components. (hroughout the process areas, where the terms @productA and @product componentA are used, their intended meanings also encompass services, service systems, and their components. (his term has a special meaning in the C$$& 'roduct *uite besides its common standard English meaning.
'ro+/#t #om'o e t re=/"reme t$ 'ro+/#t &"fe#1#&e
0 complete specification of a product or service component, includin+ fit, form, function, performance, and an* ot$er re/uirement. T$e period of time, consistin+ of p$ases, t$at )e+ins '$en a product or service is conceived and ends '$en t$e product or service is no lon+er availa)le for use. *ince an organi6ation can be producing multiple products or services for multiple customers, one description of a product lifecycle may not be ade0uate. (herefore, the organi6ation can define a set of approved product lifecycle models. (hese models are typically found in published literature and are li1ely to be tailored for use in an organi6ation. " product lifecycle could consist of the following phases: 2=3 concept and vision, 2<3 feasibility, 2!3 designEdevelopment, 2L3 production, and 2K3 phase out.
456
7&o$$ar1
'ro+/#t &" e
0 +roup of products s$arin+ a common, mana+ed set of features t$at satisf* specific needs of a selected mar2et or mission and t$at are developed from a common set of core assets in a prescri)ed 'a*. ( ee also Lservice line.M, (he development or ac0uisition of products for the product line is based on exploiting commonality and bounding variation 2i.e., restricting unnecessary product variation3 across the group of products. (he managed set of core assets 2e.g., re0uirements, architectures, components, tools, testing artifacts, operating procedures, software3 includes prescriptive guidance for their use in product development. 'roduct line operations involve interloc1ing execution of the broad activities of core asset development, product development, and management. $any people use @product lineA just to mean the set of products produced by a particular business unit, whether they are built with shared assets or not. 4e call that collection a Rportfolio,R and reserve Rproduct lineR to have the technical meaning given here.
'ro+/#t re&ate+ &"fe#1#&e 'ro#e$$e$ 'ro+/#t re=/"reme t$
Processes associated 'it$ a product or service t$rou+$out one or more p$ases of its life (e.+., from conception t$rou+$ disposal,, suc$ as manufacturin+ and support processes. 0 refinement of customer re/uirements into t$e developers; lan+ua+e, ma2in+ implicit re/uirements into e5plicit derived re/uirements. ( ee also Lderived re/uirementsM and Lproduct component re/uirements.M, (he developer uses product re0uirements to guide the design and building of the product or service.
'ro+/#t $/"te 'ro0e#t
( ee LCMMI Product uite.M, 0 mana+ed set of interrelated activities and resources, includin+ people, t$at delivers one or more products or services to a customer or end user. " project has an intended beginning 2i.e., project startup3 and end. 'rojects typically operate according to a plan. *uch a plan is fre0uently documented and specifies what is to be delivered or implemented, the resources and funds to be used, the wor1 to be done, and a schedule for doing the wor1. " project can be composed of projects. 2*ee also @project startup.A3 &n some contexts, the term @programA is used to refer to a project.
7&o$$ar1
458
'ro0e#t '&a
0 plan t$at provides t$e )asis for performin+ and controllin+ t$e pro4ect;s activities, '$ic$ addresses t$e commitments to t$e pro4ect;s customer. 'roject planning includes estimating the attributes of wor1 products and tas1s, determining the resources needed, negotiating commitments, producing a schedule, and identifying and analy6ing project ris1s. &terating through these activities may be necessary to establish the project plan.
'ro0e#t 'ro!re$$ a + 'erforma #e 'ro0e#t $tart/'
6$at a pro4ect ac$ieves 'it$ respect to implementin+ pro4ect plans, includin+ effort, cost, sc$edule, and tec$nical performance. ( ee also Ltec$nical performance.M, 6$en a set of interrelated resources for a pro4ect are directed to develop or deliver one or more products or services for a customer or end user. ( ee also Lpro4ect.M, 0 preliminar* t*pe, form, or instance of a product, service, product component, or service component t$at serves as a model for later sta+es or for t$e final, complete version of t$e product or service. (his model of the product or service 2e.g., physical, electronic, digital, analytical3 can be used for the following 2and other3 purposes: "ssessing the feasibility of a new or unfamiliar technology "ssessing or mitigating technical ris1 ,alidating re0uirements %emonstrating critical features )ualifying a product or service )ualifying a process Characteri6ing performance or features of the product or service Elucidating physical principles
'rotot1'e
=/a&"t1 =/a&"t1 a + 'ro#e$$ 'erforma #e ob0e#t"ve$
T$e de+ree to '$ic$ a set of in$erent c$aracteristics fulfills re/uirements. Buantitative o)4ectives and re/uirements for product /ualit*, service /ualit*, and process performance. )uantitative process performance objectives include 0uality8 however, to emphasi6e the importance of 0uality in the C$$& 'roduct *uite, the phrase @0uality and process performance objectivesA is used. @'rocess performance objectivesA are referenced in maturity level !8 the term @0uality and process performance objectivesA implies the use of 0uantitative data and is only used in maturity levels L and K.
45<
7&o$$ar1
=/a&"t1 a$$/ra #e
0 planned and s*stematic means for assurin+ mana+ement t$at t$e defined standards, practices, procedures, and met$ods of t$e process are applied. 0 propert* of a product or service )* '$ic$ its /ualit* 'ill )e 4ud+ed )* relevant sta2e$olders. Bualit* attri)utes are c$aracteri-a)le )* some appropriate measure. )uality attributes are non5functional, such as timeliness, throughput, responsiveness, security, modifiability, reliability, and usability. (hey have a significant influence on the architecture.
=/a&"t1 attr"b/te
=/a&"t1 #o tro&
T$e operational tec$ni/ues and activities t$at are used to fulfill re/uirements for /ualit*. ( ee also L/ualit* assurance.M, Mana+in+ a pro4ect or 'or2 +roup usin+ statistical and ot$er /uantitative tec$ni/ues to )uild an understandin+ of t$e performance or predicted performance of processes in comparison to t$e pro4ect;s or 'or2 +roup;s /ualit* and process performance o)4ectives, and identif*in+ corrective action t$at ma* need to )e ta2en. ( ee also Lstatistical tec$ni/ues.M, *tatistical techni0ues used in 0uantitative management include analysis, creation, or use of process performance models8 analysis, creation, or use of process performance baselines8 use of control charts8 analysis of variance, regression analysis8 and use of confidence intervals or prediction intervals, sensitivity analysis, simulations, and tests of hypotheses.
=/a t"tat"ve ma a!eme t
=/a t"tat"ve ob0e#t"ve
Desired tar+et value e5pressed usin+ /uantitative measures. ( ee also Lmeasure,M Lprocess improvement o)4ectives,M and L/ualit* and process performance o)4ectives.M, ( ee L/uantitative mana+ement.M, 0 model t$at is used as a )enc$mar2 for measurin+ an attri)ute. 0 sta2e$older t$at is identified for involvement in specified activities and is included in a plan. ( ee also Lsta2e$older.M, T$e or+ani-ation, use, and presentation of a CMM;s components. Overall, two types of approaches to presenting best practices are evident: the staged representation and the continuous representation.
=/a t"tat"ve&1 ma a!e+ refere #e mo+e& re&eva t $ta?e-o&+er re're$e tat"o
7&o$$ar1
453
re=/"re+ CMMI #om'o e t$
CMMI components t$at are essential to ac$ievin+ process improvement in a +iven process area. *pecific goals and generic goals are re0uired model components. oal satisfaction is used in appraisals as the basis for deciding whether a process area has been satisfied.
re=/"reme t
(1, 0 condition or capa)ilit* needed )* a user to solve a pro)lem or ac$ieve an o)4ective. (", 0 condition or capa)ilit* t$at must )e met or possessed )* a product, service, product component, or service component to satisf* a supplier a+reement, standard, specification, or ot$er formall* imposed documents. (3, 0 documented representation of a condition or capa)ilit* as in (1, or (",. ( ee also Lsupplier a+reement.M, T$e determination of product or service specific functional and /ualit* attri)ute c$aracteristics )ased on anal*ses of customer needs, e5pectations, and constraintsI operational conceptI pro4ected utili-ation environments for people, products, services, and processesI and measures of effectiveness. ( ee also Loperational concept.M, :sin+ s*stematic tec$ni/ues suc$ as protot*pes and structured surve*s to proactivel* identif* and document customer and end-user needs. T$e mana+ement of all re/uirements received )* or +enerated )* t$e pro4ect or 'or2 +roup, includin+ )ot$ tec$nical and nontec$nical re/uirements as 'ell as t$ose re/uirements levied on t$e pro4ect or 'or2 +roup )* t$e or+ani-ation. ( ee also Lnontec$nical re/uirements.M, 0 discerna)le association )et'een re/uirements and related re/uirements, implementations, and verifications. ( ee also L)idirectional tracea)ilit*M and Ltracea)ilit*.M, T$e ratio of revenue from output (product or service, to production costs, '$ic$ determines '$et$er an or+ani-ation )enefits from performin+ an action to produce somet$in+. T$e evaluation, classification, and prioriti-ation of ris2s. 0n or+ani-ed, t$orou+$ approac$ used to see2 out pro)a)le or realistic ris2s in ac$ievin+ o)4ectives.
re=/"reme t$ a a&1$"$
re=/"reme t$ e&"#"tat"o re=/"reme t$ ma a!eme t
re=/"reme t$ tra#eab"&"t1 ret/r o " ve$tme t r"$? a a&1$"$ r"$? "+e t"f"#at"o
460
7&o$$ar1
r"$? ma a!eme t
0n or+ani-ed, anal*tic process used to identif* '$at mi+$t cause $arm or loss (identif* ris2s,I to assess and /uantif* t$e identified ris2sI and to develop and, if needed, implement an appropriate approac$ to prevent or $andle causes of ris2 t$at could result in si+nificant $arm or loss. (ypically, ris1 management is performed for the activities of a project, a wor1 group, an organi6ation, or other organi6ational units that are developing or delivering products or services.
$e "or ma a!er
0 mana+ement role at a $i+$ enou+$ level in an or+ani-ation t$at t$e primar* focus of t$e person fillin+ t$e role is t$e lon+-term vitalit* of t$e or+ani-ation rat$er t$an s$ort-term concerns and pressures. ( ee also L$i+$er level mana+ement.M, " senior manager has authority to direct the allocation or reallocation of resources in support of organi6ational process improvement effectiveness. " senior manager can be any manager who satisfies this description, including the head of the organi6ation. *ynonyms for senior manager include @executiveA and @top5level manager.A /owever, to ensure consistency and usability, these synonyms are not used in C$$& models. (his term has a special meaning in the C$$& 'roduct *uite besides its common standard English meaning.
$erv"#e
0 product t$at is intan+i)le and non-stora)le. ( ee also Lproduct,M Lcustomer,M and L'or2 product.M, *ervices are delivered through the use of service systems that have been designed to satisfy service re0uirements. 2*ee also @service system.A3 $any service providers deliver combinations of services and goods. " single service system can deliver both types of products. For example, a training organi6ation can deliver training materials along with its training services. *ervices may be delivered through combinations of manual and automated processes. (his term has a special meaning in the C$$& 'roduct *uite besides its common standard English meaning.
7&o$$ar1
461
$erv"#e a!reeme t
0 )indin+, 'ritten record of a promised e5c$an+e of value )et'een a service provider and a customer. ( ee also Lcustomer.M, *ervice agreements can be fully negotiable, partially negotiable, or non5 negotiable, and they can be drafted either by the service provider, the customer, or both, depending on the situation. " @promised exchange of valueA means a joint recognition and acceptance of what each party will provide to the other to satisfy the agreement. (ypically, the customer provides payment in return for delivered services, but other arrangements are possible. " @writtenA record need not be contained in a single document or other artifact. "lternatively, it may be extremely brief for some types of services 2e.g., a receipt that identifies a service, its price, its recipient3.
$erv"#e #ata&o!
0 list or repositor* of standardi-ed service definitions. *ervice catalogs can include varying degrees of detail about available service levels, 0uality, prices, negotiableEtailorable items, and terms and conditions. " service catalog need not be contained in a single document or other artifact, and can be a combination of items that provide e0uivalent information 2such as web pages lin1ed to a database.3 "lternatively, for some services an effective catalog can be a simple printed menu of available services and their prices. *ervice catalog information can be partitioned into distinct subsets to support different types of sta1eholders 2e.g., customers, end users, provider staff, suppliers3.
$erv"#e " #"+e t
0n indication of an actual or potential interference 'it$ a service. *ervice incidents can occur in any service domain because customer and end5user complaints are types of incidents and even the simplest of services can generate complaints. (he word @incidentA can be used in place of @service incidentA for brevity when the context ma1es the meaning clear.
$erv"#e &eve&
0 defined ma+nitude, de+ree, or /ualit* of service deliver* performance. ( ee also LserviceM and Lservice level measure.M,
462
7&o$$ar1
$erv"#e &eve& a!reeme t
0 service a+reement t$at specifies delivered servicesI service measuresI levels of accepta)le and unaccepta)le servicesI and e5pected responsi)ilities, lia)ilities, and actions of )ot$ t$e provider and customer in anticipated situations. ( ee also Lmeasure,M Lservice,M and Lservice a+reement.M, " service level agreement is a 1ind of service agreement that documents the details indicated in the definition. (he use of the term @service agreementA always includes @service level agreementA as a subcategory and the former may be used in place of the latter for brevity. /owever, @service level agreementA is the preferred term when it is desired to emphasi6e situations in which distinct levels of acceptable services exist, or other details of a service level agreement are li1ely to be important to the discussion.
$erv"#e &eve& mea$/re $erv"#e &" e
0 measure of service deliver* performance associated 'it$ a service level. ( ee also LmeasureM and Lservice level.M, 0 consolidated and standardi-ed set of services and service levels t$at satisf* specific needs of a selected mar2et or mission area. ( ee also Lproduct lineM and Lservice level.M, 0 communication from a customer or end user t$at one or more specific instances of service deliver* are desired. ( ee also Lservice a+reement.M, (hese re0uests are made within the context of a service agreement. &n cases where services are to be delivered continuously or periodically, some service re0uests may be explicitly identified in the service agreement itself. &n other cases, service re0uests that fall within the scope of a previously established service agreement are generated over time by customers or end users as their needs develop.
$erv"#e re=/e$t
$erv"#e re=/"reme t$
T$e complete set of re/uirements t$at affect service deliver* and service s*stem development. ( ee also Lservice s*stem.M, *ervice re0uirements include both technical and nontechnical re0uirements. (echnical re0uirements are properties of the service to be delivered and the service system needed to enable delivery. 7ontechnical re0uirements may include additional conditions, provisions, commitments, and terms identified by agreements, and regulations, as well as needed capabilities and conditions derived from business objectives.
7&o$$ar1
463
$erv"#e $1$tem
0n inte+rated and interdependent com)ination of component resources t$at satisfies service re/uirements. ( ee also Lservice s*stem componentM and Lservice re/uirements.M, " service system encompasses everything re0uired for service delivery, including wor1 products, processes, facilities, tools, consumables, and human resources. 7ote that a service system includes the people necessary to perform the service system9s processes. &n contexts where end users perform some processes for service delivery to be accomplished, those end users are also part of the service system 2at least for the duration of those interactions3. " complex service system may be divisible into multiple distinct delivery and support systems or subsystems. 4hile these divisions and distinctions may be significant to the service provider organi6ation, they may not be as meaningful to other sta1eholders.
$erv"#e $1$tem #om'o e t
0 resource re/uired for a service s*stem to successfull* deliver services. *ome components can remain owned by a customer, end user, or third party before service delivery begins and after service delivery ends. 2*ee also @customerA and @end user.A3 *ome components can be transient resources that are part of the service system for a limited time 2e.g., items that are under repair in a maintenance shop3. Components can include processes and people. (he word @componentA can be used in place of @service system componentA for brevity when the context ma1es the meaning clear. (he word @infrastructureA can be used to refer collectively to service system components that are tangible and essentially permanent. %epending on the context and type of service, infrastructure can include human resources.
$erv"#e $1$tem #o $/mab&e
0 service s*stem component t$at ceases to )e availa)le or )ecomes permanentl* c$an+ed )* its use durin+ t$e deliver* of a service. Fuel, office supplies, and disposable containers are examples of commonly used consumables. 'articular types of services can have their own speciali6ed consumables 2e.g., a health care service may re0uire medications or blood supplies3. 'eople are not consumables, but their labor time is a consumable.
464
7&o$$ar1
$-are+ v"$"o
0 common understandin+ of +uidin+ principles, includin+ mission, o)4ectives, e5pected )e$avior, values, and final outcomes, '$ic$ are developed and used )* a pro4ect or 'or2 +roup. (1, T$e application of a s*stematic, disciplined, /uantifia)le approac$ to t$e development, operation, and maintenance of soft'are. (", T$e stud* of approac$es as in (1,. ( ee also L$ard'are en+ineerin+,M and Ls*stems en+ineerin+.M, T$e process of preparin+ a pac2a+e to )e used in selectin+ a supplier. ( ee also Lsolicitation pac2a+e.M, 0 collection of formal documents t$at includes a description of t$e desired form of response from a potential supplier, t$e relevant statement of 'or2 for t$e supplier, and re/uired provisions in t$e supplier a+reement. 0 cause of a defect t$at is specific to some transient circumstance and is not an in$erent part of a process. ( ee also Lcommon cause of variation.M, 0 re/uired model component t$at descri)es t$e uni/ue c$aracteristics t$at must )e present to satisf* t$e process area. ( ee also Lcapa)ilit* level,M L+eneric +oal,M Lor+ani-ation;s )usiness o)4ectives,M and Lprocess area.M, 0n e5pected model component t$at is considered important in ac$ievin+ t$e associated specific +oal. ( ee also Lprocess areaM and Lspecific +oal.M, (he specific practices describe the activities expected to result in achievement of the specific goals of a process area.
$oftware e !" eer" !
$o&"#"tat"o $o&"#"tat"o 'a#?a!e
$'e#"a& #a/$e of var"at"o $'e#"f"# !oa&
$'e#"f"# 'ra#t"#e
$tab&e 'ro#e$$
T$e state in '$ic$ special causes of process variation $ave )een removed and prevented from recurrin+ so t$at onl* common causes of process variation of t$e process remain. ( ee also Lcapa)le process,M Lcommon cause of variation,M Lspecial cause of variation,M and Lstandard process.M, 0 model structure '$erein attainin+ t$e +oals of a set of process areas esta)lis$es a maturit* levelI eac$ level )uilds a foundation for su)se/uent levels. ( ee also Lmaturit* levelM and Lprocess area.M,
$ta!e+ re're$e tat"o
7&o$$ar1
465
$ta?e-o&+er
0 +roup or individual t$at is affected )* or is in some 'a* accounta)le for t$e outcome of an underta2in+. ( ee also LcustomerM and Lrelevant sta2e$older.M, *ta1eholders may include project or wor1 group members, suppliers, customers, end users, and others. (his term has a special meaning in the C$$& 'roduct *uite besides its common standard English meaning.
$ta +ar+ : o/ ;
1ormal re/uirements developed and used to prescri)e consistent approac$es to ac/uisition, development, or service. Examples of standards include &*OE&EC standards, &EEE standards, and organi6ational standards.
$ta +ar+ 'ro#e$$
0n operational definition of t$e )asic process t$at +uides t$e esta)lis$ment of a common process in an or+ani-ation. " standard process describes the fundamental process elements that are expected to be incorporated into any defined process. &t also describes relationships 2e.g., ordering, interfaces3 among these process elements. 2*ee also @defined process.A3
$tateme t of wor? $tat"$t"#a& a + ot-er =/a t"tat"ve te#- "=/e$
0 description of 'or2 to )e performed. 0nal*tic tec$ni/ues t$at ena)le accomplis$in+ an activit* )* /uantif*in+ parameters of t$e tas2 (e.+., inputs, si-e, effort, and performance,. ( ee also Lstatistical tec$ni/uesM and L/uantitative mana+ement.M, (his term is used in the high maturity process areas where the use of statistical and other 0uantitative techni0ues to improve understanding of project, wor1, and organi6ational processes is described. Examples of non5statistical 0uantitative techni0ues include trend analysis, run charts, 'areto analysis, bar charts, radar charts, and data averaging. (he reason for using the compound term @statistical and other 0uantitative techni0uesA in C$$& is to ac1nowledge that while statistical techni0ues are expected, other 0uantitative techni0ues can also be used effectively.
$tat"$t"#a& 'ro#e$$ #o tro&
tatisticall* )ased anal*sis of a process and measures of process performance, '$ic$ identif* common and special causes of variation in process performance and maintain process performance 'it$in limits. ( ee also Lcommon cause of variation,M Lspecial cause of variation,M and Lstatistical tec$ni/ues.M,
466
7&o$$ar1
$tat"$t"#a& te#- "=/e$
Tec$ni/ues adapted from t$e field of mat$ematical statistics used for activities suc$ as c$aracteri-in+ process performance, understandin+ process variation, and predictin+ outcomes. Examples of statistical techni0ues include sampling techni0ues, analysis of variance, chi5s0uared tests, and process control charts.
$/b'ra#t"#e
0n informative model component t$at provides +uidance for interpretin+ and implementin+ specific or +eneric practices. *ubpractices may be worded as if prescriptive, but they are actually meant only to provide ideas that can be useful for process improvement.
$/b'ro#e$$
0 process t$at is part of a lar+er process. ( ee also Lprocess,M Lprocess description,M and Lprocess element.M, " subprocess may or may not be further decomposed into more granular subprocesses or process elements. (he terms @process,A @subprocess,A and @process elementA form a hierarchy with @processA as the highest, most general term, @subprocessesA below it, and @process elementA as the most specific. " subprocess can also be called a process element if it is not decomposed into further subprocesses.
$/''&"er
(1, 0n entit* deliverin+ products or performin+ services )ein+ ac/uired. (", 0n individual, partners$ip, compan*, corporation, association, or ot$er entit* $avin+ an a+reement 'it$ an ac/uirer for t$e desi+n, development, manufacture, maintenance, modification, or suppl* of items under t$e terms of an a+reement. ( ee also Lac/uirer.M, 0 documented a+reement )et'een t$e ac/uirer and supplier. ( ee also Lsupplier.M, *upplier agreements are also 1nown as contracts, licenses, and memoranda of agreement.
$/''&"er a!reeme t
$/$ta" me t $1$tem of $1$tem$
T$e processes used to ensure t$at a product or service remains operational. 0 set or arran+ement of s*stems t$at results '$en independent and useful s*stems are inte+rated into a lar+e s*stem t$at delivers uni/ue capa)ilities.
7&o$$ar1
468
$1$tem$ e !" eer" !
T$e interdisciplinar* approac$ +overnin+ t$e total tec$nical and mana+erial effort re/uired to transform a set of customer needs, e5pectations, and constraints into a solution and to support t$at solution t$rou+$out its life. ( ee also L$ard'are en+ineerin+M and Lsoft'are en+ineerin+.M, (his approach includes the definition of technical performance measures, the integration of engineering specialties toward the establishment of an architecture, and the definition of supporting lifecycle processes that balance cost, schedule, and performance objectives.
ta"&or" !
T$e act of ma2in+, alterin+, or adaptin+ somet$in+ for a particular end. For example, a project or wor1 group establishes its defined process by tailoring from the organi6ation9s set of standard processes to meet its objectives, constraints, and environment. -i1ewise, a service provider tailors standard services for a particular service agreement.
ta"&or" ! !/"+e&" e$
7r+ani-ational +uidelines t$at ena)le pro4ects, 'or2 +roups, and or+ani-ational functions to appropriatel* adapt standard processes for t$eir use. (he organi6ation9s set of standard processes is described at a general level that may not be directly usable to perform a process. (ailoring guidelines aid those who establish the defined processes for project or wor1 groups. (ailoring guidelines cover 2=3 selecting a standard process, 2<3 selecting an approved lifecycle model, and 2!3 tailoring the selected standard process and lifecycle model to fit project or wor1 group needs. (ailoring guidelines describe what can and cannot be modified and identify process components that are candidates for modification.
tar!et 'rof"&e
0 list of process areas and t$eir correspondin+ capa)ilit* levels t$at represent an o)4ective for process improvement. ( ee also Lac$ievement profileM and Lcapa)ilit* level profile.M, (arget profiles are only available when using the continuous representation.
tar!et $ta!" !
0 se/uence of tar+et profiles t$at descri)es t$e pat$ of process improvement to )e follo'ed )* t$e or+ani-ation. ( ee also Lac$ievement profile,M Lcapa)ilit* level profile,M and Ltar+et profile.M, (arget staging is only available when using the continuous representation.
46<
7&o$$ar1
team
0 +roup of people 'it$ complementar* s2ills and e5pertise '$o 'or2 to+et$er to accomplis$ specified o)4ectives. " team establishes and maintains a process that identifies roles, responsibilities, and interfaces8 is sufficiently precise to enable the team to measure, manage, and improve their wor1 performance8 and enables the team to ma1e and defend their commitments. Collectively, team members provide s1ills and advocacy appropriate to all aspects of their wor1 2e.g., for the different phases of a wor1 product9s life3 and are responsible for accomplishing the specified objectives. 7ot every project or wor1 group member must belong to a team 2e.g., a person staffed to accomplish a tas1 that is largely self5contained3. (hus, a large project or wor1 group can consist of many teams as well as project staff not belonging to any team. " smaller project or wor1 group can consist of only a single team 2or a single individual3.
te#- "#a& +ata 'a#?a!e
0 collection of items t$at can include t$e follo'in+ if suc$ information is appropriate to t$e t*pe of product and product component (e.+., material and manufacturin+ re/uirements ma* not )e useful for product components associated 'it$ soft'are services or processes,% Product arc$itecture description 0llocated re/uirements Product component descriptions Product related lifec*cle process descriptions if not descri)ed as separate product components Ne* product c$aracteristics !e/uired p$*sical c$aracteristics and constraints Interface re/uirements Materials re/uirements ()ills of material and material c$aracteristics, 1a)rication and manufacturin+ re/uirements (for )ot$ t$e ori+inal e/uipment manufacturer and field support, Verification criteria used to ensure re/uirements $ave )een ac$ieved Conditions of use (environments, and operatin+&usa+e scenarios, modes and states for operations, support, trainin+, manufacturin+, disposal, and verifications t$rou+$out t$e life of t$e product !ationale for decisions and c$aracteristics (e.+., re/uirements, re/uirement allocations, desi+n c$oices,
7&o$$ar1
463
te#- "#a& 'erforma #e
C$aracteristic of a process, product, or service, +enerall* defined )* a functional or tec$nical re/uirement. Examples of technical performance types include estimating accuracy, end5user functions, security functions, response time, component accuracy, maximum weight, minimum throughput, allowable range.
te#- "#a& 'erforma #e mea$/re te#- "#a& re=/"reme t$ tra#eab"&"t1
Precisel* defined tec$nical measure of a re/uirement, capa)ilit*, or some com)ination of re/uirements and capa)ilities. ( ee also Lmeasure.M, Properties (i.e., attri)utes, of products or services to )e ac/uired or developed. 0 discerna)le association amon+ t'o or more lo+ical entities suc$ as re/uirements, s*stem elements, verifications, or tas2s. ( ee also L)idirectional tracea)ilit*M and Lre/uirements tracea)ilit*.M, 0n evaluation of alternatives, )ased on criteria and s*stematic anal*sis, to select t$e )est alternative for attainin+ determined o)4ectives. 1ormal and informal learnin+ options. (hese learning options can include classroom training, informal mentoring, web5based training, guided self study, and formali6ed on5the5 job training programs. (he learning options selected for each situation are based on an assessment of the need for training and the performance gap to be addressed.
tra+e $t/+1
tra" " !
/ "t te$t" ! va&"+at"o
Testin+ of individual $ard'are or soft'are units or +roups of related units. ( ee also Lacceptance testin+.M, Confirmation t$at t$e product or service, as provided (or as it 'ill )e provided,, 'ill fulfill its intended use. &n other words, validation ensures that @you built the right thing.A 2*ee also @verification.A3
ver"f"#at"o
Confirmation t$at 'or2 products properl* reflect t$e re/uirements specified for t$em. &n other words, verification ensures that @you built it right.A 2*ee also @validation.A3
480
7&o$$ar1
ver$"o #o tro&
T$e esta)lis$ment and maintenance of )aselines and t$e identification of c$an+es to )aselines t$at ma2e it possi)le to return to t$e previous )aseline. &n some contexts, an individual wor1 product may have its own baseline and a level of control less than formal configuration control may be sufficient.
wor? brea?+ow $tr/#t/re :>9S; wor? !ro/'
0n arran+ement of 'or2 elements and t$eir relations$ip to eac$ ot$er and to t$e end product or service. 0 mana+ed set of people and ot$er assi+ned resources t$at delivers one or more products or services to a customer or end user. ( ee also Lpro4ect.M, " wor1 group can be any organi6ational entity with a defined purpose, whether or not that entity appears on an organi6ation chart. 4or1 groups can appear at any level of an organi6ation, can contain other wor1 groups, and can span organi6ational boundaries. " wor1 group together with its wor1 can be considered the same as a project if it has an intentionally limited lifetime.
wor? '&a
0 plan of activities and related resource allocations for a 'or2 +roup. 4or1 planning includes estimating the attributes of wor1 products and tas1s, determining the resources needed, negotiating commitments, producing a schedule, and identifying and analy6ing ris1s. &terating through these activities can be necessary to establish the wor1 plan.
wor? 'ro+/#t
0 useful result of a process. (his result can include files, documents, products, parts of a product, services, process descriptions, specifications, and invoices. " 1ey distinction between a wor1 product and a product component is that a wor1 product is not necessarily part of the end product. 2*ee also @productA and @product component.A3 &n C$$& models, the definition of @wor1 productA includes services, however, the phrase @wor1 products and servicesA is sometimes used to emphasi6e the inclusion of services in the discussion.
wor? 'ro+/#t a + ta$? attr"b/te$
C$aracteristics of products, services, and tas2s used to $elp in estimatin+ 'or2. T$ese c$aracteristics include items suc$ as si-e, comple5it*, 'ei+$t, form, fit, and function. T$e* are t*picall* used as one input to derivin+ ot$er resource estimates (e.+., effort, cost, sc$edule,.
7&o$$ar1
481
wor? $tart/'
6$en a set of interrelated resources for a 'or2 +roup is directed to develop or deliver one or more products or services for a customer or end user. ( ee also L'or2 +roup.M,
482
7&o$$ar1
REPORT %OCUMENTATION PA7E
Form Approved OMB No. 0704-0188
Pu)lic reportin+ )urden for t$is collection of information is estimated to avera+e 1 $our per response, includin+ t$e time for revie'in+ instructions, searc$in+ e5istin+ data sources, +at$erin+ and maintainin+ t$e data needed, and completin+ and revie'in+ t$e collection of information. end comments re+ardin+ t$is )urden estimate or an* ot$er aspect of t$is collection of information, includin+ su++estions for reducin+ t$is )urden, to 6as$in+ton @ead/uarters ervices, Directorate for information 7perations and !eports, 1"19 Kefferson Davis @i+$'a*, uite 1"#8, 0rlin+ton, V0 """#"-83#", and to t$e 7ffice of Mana+ement and .ud+et, Paper'or2 !eduction Pro4ect (#=#8-#1HH,, 6as$in+ton, DC "#9#3.
=.
AGENCY USE ONLY
<.
REPORT DATE
!.
2-eave ;lan13 L. M. G.
TITLE AND SUBTITLE
7ovember <>=> K.
REPORT TYPE AND DATES COVERED
Final
FUNDING NUMBERS
C$$&S for %evelopment, ,ersion =.!

AUTHOR(S)
F"BG<=5>K5C5>>>!
C$$& 'roduct %evelopment (eam

PERFORMING ORGANIZATION NAME(S) AND ADDRESS(ES)
B.
*oftware Engineering &nstitute Carnegie $ellon :niversity 'ittsburgh, '" =K<=! N.

SPONSORING/MONITORING AGENCY NAME(S) AND ADDRESS(ES)
PERFORMING ORGANIZATION REPORT NUMBER
C$:E*E&5<>=>5(#5>!! =>. SPONSORING/MONITORING AGENCY

REPORT NUMBER
/) E*CEP'+ K Eglin *treet /anscom "F;, $" >=G!=5<==M ==. SUPPLEMENTARY NOTES =<" DISTRIBUTION/AVAILABILITY STATEMENT :nclassifiedE:nlimited, %(&C, 7(&* =!. ABSTRACT (MAXIMUM 200 WORDS)
E*C5(#5<>=>5>!!
=<; DISTRIBUTION CODE
C$$&S 2Capability $aturity $odelS &ntegration3 models are collections of best practices that help organi6ations to improve their processes. (hese models are developed by product teams with members from industry, government, and the Carnegie $ellonS *oftware Engineering &nstitute 2*E&3. (his model, called C$$& for %evelopment 2C$$&5%E,3, provides a comprehensive integrated set of guidelines for developing products and services. =L. SUBJECT TERMS C$$&, %evelopment, C$$& for %evelopment, ,ersion =.!, software process improvement, reference model, product development model, development model, C$$ =M. PRICE CODE =G. SECURITY CLASSIFICATION OF
REPORT
=K. NUMBER OF PAGES LMB
=B. SECURITY CLASSIFICATION OF

THIS PAGE
=N. SECURITY CLASSIFICATION

OF ABSTRACT
<>. LIMITATION OF
ABSTRACT
:nclassified
< < =98#-#1-"H#-99##
:nclassified
:nclassified
:-
tandard 1orm "FH (!ev. "-HF, Prescri)ed )* 0< I td. U3F-1H "FH-1#"
7&o$$ar1
483
484
7&o$$ar1

Cmmi For Development, Version 1.3

Încărcat de

Informații document

Titlu original

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Cmmi For Development, Version 1.3

Încărcat de

Drepturi de autor:

Formate disponibile

CMMI for Development, Version 1.

Improving processes for developing better products and services

Software E !" eer" ! Pro#e$$ Ma a!eme t Pro!ram

CMMI for %eve&o'me t( )er$"o 1*3

CMMI for %eve&o'me t( )er$"o 1*3

CMMI for %eve&o'me t( )er$"o 1*3

How to Use this Document

CMMI for %eve&o'me t( )er$"o 1*3

Rea+er$ E,'er"e #e+ w"t- Pro#e$$ Im'roveme t

1or a more complete and detailed list of improvements, see $ttp%&&'''.sei.cmu.edu&cmmi&tools&cmmiv1-3&.

CMMI for %eve&o'me t( )er$"o 1*3

Additional Information and Reader Feedback

CMMI for %eve&o'me t( )er$"o 1*3

CMMI for %eve&o'me t( )er$"o 1*3

U &"m"te+ +"$tr"b/t"o $/b0e#t to t-e #o'1r"!-t* -tt'2//www*$e"*#m/*e+/

Part O e2 Abo/t CMMI for %eve&o'me t 1 I tro+/#t"o

2 Pro#e$$ Area Com'o e t$

CMMI for %eve&o'me t( )er$"o 1*3

<otes E5amples !eferences <um)erin+ c$eme T*po+rap$ical Conventions

3 T1" ! It A&& To!et-er

4 Re&at"o $-"'$ Amo ! Pro#e$$ Area$

5 U$" ! CMMI Mo+e&$

CMMI for %eve&o'me t( )er$"o 1*3

7e er"# 7oa&$ a + 7e er"# Pra#t"#e$( a + t-e Pro#e$$ Area$

Part T-ree2 T-e A''e +"#e$

CMMI for %eve&o'me t( )er$"o 1*3

CMMI for %eve&o'me t( )er$"o 1*3

Part 7ne% Abo/t CMMI for %eve&o'me t

CMMI for %eve&o'me t( )er$"o 1*3

CMMI for %eve&o'me t( )er$"o 1*3

CMMI for %eve&o'me t( )er$"o 1*3

About Process Impro ement

Tools and e/uipment

Figure 1.1: The Three Critical Dimensions

CMMI for %eve&o'me t( )er$"o 1*3

About !apabilit" #aturit" #odels

CMMI for %eve&o'me t( )er$"o 1*3

INCOSE SECAM :1336;

CMMI for A#=/"$"t"o )1*2 :2008;

CMMI for A#=/"$"t"o )1*3 :2010;

Figure 1.2: The History of CMMs6

CMMI for %eve&o'me t( )er$"o 1*3

CMMI for %eve&o'me t( )er$"o 1*3

CMMI for %eve&o'me t( )er$"o 1*3

2 Pro#e$$ Area Com'o e t$

Pro#e$$ Area Com'o e t$

CMMI for %eve&o'me t( )er$"o 1*3

Figure 2.1: CMMI Model Components

T$e follo'in+ sections provide detailed descriptions of CMMI model components.

Pro#e$$ Area Com'o e t$

CMMI for %eve&o'me t( )er$"o 1*3

Pro#e$$ Area Com'o e t$

CMMI for %eve&o'me t( )er$"o 1*3

Pro#e$$ Area Com'o e t$

CMMI for %eve&o'me t( )er$"o 1*3

Pro#e$$ Area Com'o e t$

CMMI for %eve&o'me t( )er$"o 1*3

Pro#e$$ Area Com'o e t$

CMMI for %eve&o'me t( )er$"o 1*3

Pro#e$$ Area Com'o e t$

CMMI for %eve&o'me t( )er$"o 1*3

("pographical !on entions

Pro#e$$ Area Com'o e t$

U &"m"te+ +"$tr"b/t"o $/b0e#t to t-e #o'1r"!-t* -tt'2//www$e"#m/*e+/