What is Sftware Risk Management? (And why shuld I care?) Peter Kulik, KLCI, Inc. 1 st Editin, Octber 1996 Risks are schedule delays and cst verruns waiting t happen. As industry practices have imprved, recgnitin f Sftware Risk Management has grwn dramatically. Prven results frm Sftware Risk Management include higher prductivity, mre cnsistent attainment f custmer cmmitments, and imprved business results. The practice f Sftware Risk Management includes bth tp-dwn and bttm-up perspectives. Prjects that implement Sftware Risk Management becme simpler and mre fcused. Further, a variety f tls are available fr easier implementatin. This white paper presents an verview f Sftware Risk Management practices and tls. Accrding t Edward Yurdn, high-prductivity sftware develpment grups are as much as 600 times mre prductive than lw-prductivity grups [1]. Key factrs driving prductivity imprvements in the mst prductive grups have been adptin f advanced tls and sftware management prcesses. Lw prductivity grups, n the ther hand, cntinue t repeat sftware develpment mistakes f the past. Why shuld yu care abut risk management? Risks are schedule delays and cst verruns waiting t happen. Failure t manage prject risks makes a business less cmpetitive, by causing unnecessary quality, schedule, and functinality tradeffs and cst verruns. If yu are nt managing prject risks, yur rganizatin will mst likely be relegated t sub-par prductivity and abve-average rates f prject failure. Sftware Risk Management is a key cmpnent f the advanced sftware prcesses adpted by the highest prductivity sftware grups. It invlves assessing verall prject risk and identifying, priritizing, and practively managing specific risks. Risk management practices blck schedule delays and cst verruns befre they can impact a prject. A number f very gd publicatins n the subject are available [2, 3, 4, 5]. In additin, the Sftware Engineering Institute (SEI) hlds annual cnferences devted t Sftware Risk Management [6]. Prjects using Sftware Risk Management t manage their risks have realized benefits including: Increased prgrammer prductivity Fewer surprises Better attainment f custmer cmmitments If yur rganizatin has prjects larger than 10 t 15 peple and yu are nt implementing Sftware Risk Management yu are missing pprtunities t imprve yur prductivity and bttm-line business results. Page 1
Early Warning System Identify & Analyze Prjects that finish sner cst less, plus risk mitigatin actins can further reduce prject cst. Prjects using Sftware Risk Management experience fewer surprises, since they have identified (and in many cases, eliminated) rt causes f surprises befre they can ccur. Definitin f Sftware Risk Management As shwn in Figure 1, Sftware Risk Management includes the fllwing aspects: Identify and Analyze Mitigate and Cntrl Early Warning System Mitigate & Cntrl Figure 1 Identifying and analyzing risks includes tp-dwn and bttm-up aspects. Tp-Dwn Risk Management measures verall prject risk, while Bttm-Up Risk Management identifies the specific risks that drive the verall prject. An example f a tp-dwn risk prfile is shwn in Figure 2 [7]. Mitigating and cntrlling risks invlves practive actins t blck risks befre they impact a prject. Best practice rganizatins cntrl risk mitigatin by including specific tasks right in their prject schedule. An early warning system allws new risks t be identified and risk mitigatin actins put in place fr these risks [8]. Why Sftware Risk Management? At first glance, Sftware Risk Management might appear t just add cmplexity t an already cmplex undertaking. In reality, hwever, the activities listed abve make sftware prjects less cmplex: Identifying and priritizing risks enables prject managers and prject staff t fcus n the areas with the mst impact t their prject. Apprpriate risk mitigatin actins reduce verall prject risk which actually accelerates prject cmpletin. Level f Cnfidence 100% 90% 80% 70% 60% 50% 40% 30% 20% 10% 0% 1-Jan In sum, Sftware Risk Management helps prjects secure their custmer cmmitments. Further, managers and prject staff utilizing Sftware Risk Management have a better verall understanding f their prject and make better business decisins. Identify and Analyze - Tp-Dwn This step prvides a tp-dwn perspective n prject risk, and determines an verall risk framewrk fr a prject. Mdels such as Figure 2 enable infrmed decisins abut schedule cmmitments and cntingency. Example tls t develp a risk framewrk include: 1. TDM schedule metric [6] 2. SLIM frm QSM [http://www.qsm.cm] 3. Prject schedule simulatin [2] An example f the TDM schedule metric is shwn in Figure 2. In this example, a schedule cmmitment f 12- Feburary wuld be nly 10% % likely t cmplete n time. A cmmitment f 18-June, hwever, wuld be 90% likely t be successfully met. Given this risk prfile, what custmer cmmitment wuld yu be willing t make n this prject? Tp-dwn risk estimates can als reflect the impact f risk management actins; as risk mitigatin actins 15-Jan 29-Jan Overall Prject Risk Prfile 12-Feb 26-Feb 12-Mar 26-Mar 9-Apr 23-Apr 7-May 21-May 4-Jun 18-Jun 2-Jul "Ready fr Deplyment" Date Figure 2 16-Jul 30-Jul 13-Aug 27-Aug Page 2
Tls fr Risk Management KLCI s Prject Self-Assessment Kit Applies t all prjects with 7 r mre team members. Includes: Tp-Dwn Schedule Prfile Risk Identificatin Custmized Mitigatin Actins Risk Assessment Checklists Detailed Assessment ffered by a variety f independent vendrs Generally applies t prjects f greater than US $750,000 ttal budget SEI Taxnmy f Risks [6] Others [3, 4, 5] Figure 3 reduce prject risk, the risk prfile will shift up reflecting greater cnfidence in achieving earlier cmpletin dates! The SLIM tl frm QSM [http://www.qsm.cm] uses histrical data n literally hundreds f sftware prjects as an aid t estimatin and management. Results include risk-weighted prfiles fr schedule and effrt t cmplete a particular prject. Simulating the prject schedule can be accmplished using a tl such Risk+ frm Prgram Management Slutins, Inc. Based n prbability distributins fr individual tasks, simulatin will cnstruct a statistical mdel f prject risk [2]. Fr simulatin t prvide useful results the prject schedule must be accurate and cmplete; missing tasks, underscped r verscped tasks, and missed r invalid task r resurce dependencies will result in GIGO (Garbage In, Garbage Out) results. Identify and Analyze - Bttm-Up After the tp-dwn perspective has been develped, the underlying reasns fr the risk prfile need t be determined. This is accmplished by identifying and priritizing individual risks fr the prject. Individual risks can be identified using a variety f appraches: Reviewing published lists f prject risk surces Evaluating requirements specificatins, prject plans and schedules, etc. Surveying prject staff Brainstrming Risks can be priritized thrugh a number f methds. Sme prjects have used A-B-C r High- Medium-Lw lists. Others have estimated individual risk likelihd f ccurring and ptential schedule impact t prduce an verall rating fr each risk. By definitin, risks that may impact the prject s critical path r critical chain shuld always have highest pririty. Risk identificatin and priritizatin can ften be cmpleted mre quickly and cmprehensively with the help f a facilitatr skilled in Sftware Risk Management practices. This strategy can als prvide training fr rganizatins and prject staff nt familiar with Sftware Risk Management practices. Mitigate and Cntrl Risk identificatin and priritizatin is nly useful if actins are defined and executed t mitigate risks. Aggressive, practive risk mitigatin actin fr tp pririty risks is essential t achieve the benefits f Sftware Risk Management. Risk mitigatin actins are defined individually fr prject risks. In sme cases, immediate actin will be called fr; in thers, future cnsideratin will be mre apprpriate. Fr example, user interface requirements may be a risk n a particular prject. Develping prttypes and using iterative develpment can mitigate this risk. Anther risk might be establishing hst cmmunicatin fr the test envirnment. This risk culd be re-evaluated during the later phases f develpment, at which pint a preliminary test envirnment can be cnstructed. Planning fr risk mitigatin actins shuld nt be cnfused with cntingency planning. Risk mitigatin actins are implemented practively, t prevent a risk frm impacting a prject. Cntingency plans are executed after a risk impacts a prject. Fr mst sftware prject risks, cntingency planning is best executed reactively; the selectin f gd alternative actins will change as a prject evlves. Page 3
Early Warning System Sftware Risk Management is an integral part f prject executin. As a prject prceeds, sme risks will be eliminated, but sme new risks may als ccur. Sme risk mitigatin actins will wrk well, but sme may nt wrk and new actin will need t be taken. As the prject prceeds, pririties will change and new risk management planning will need t be undertaken. Fr example, a hst cmmunicatin prtcl risk may be eliminated, but end-user system capacity may becme a new risk fr initial deplyment. Prttypes may slidify user interfaces, but testing with unskilled peratrs may nt wrk and alternative strategies need t be implemented. Setting up sftware develpment envirnments may be a high pririty risk early in a prject, but testing envirnments will becme much mre imprtant as the prject prceeds. Mnitring prject risks can be accmplished thrugh the fllwing mechanisms: Scheduling risk mitigatin tasks and review milestnes n the prject schedule Hlding frmal prject risk management review meetings Cnducting regular annymus surveys f prject staff Cllecting key sftware metrics that give insight int aspects f prject prgress. The prject schedule is an excellent early-warning tl fr risk management. By scheduling explicit risk mitigatin tasks, their prgress and effectiveness can be reviewed n a timely basis at prject status meetings. Further, schedule milestnes can serve as a reminder f frmal prject risk management review meetings, which prvide a frum fr evaluatin f prject risks and the effectiveness f risk mitigatin actins. At prject risk management review meetings, new risks can be identified, all prject risks can be repriritized, and new risk mitigatin actins can be planned. This review shuld take a hlistic apprach t a prject, cnsidering all cre and supprting areas fr effective prject executin. Regular, annymus surveys prvide a mechanism t gather feedback frm all prject staff, efficiently allwing them t prvide input n current prject risks. In large prjects, surveys are ften the nly practical way t gather input frm all staff. After cnslidatin, survey results can be used as a basis fr evaluating risk mitigatin actins and planning new actins t address risks. Finally, well-chsen sftware metrics can be a leading-indicatr t future prject prblems. Fr example, defect discvery rates can be used t highlight test prcedure changes needed early in the test cycle. Risk Assessment Risk Assessments are used regularly by experienced sftware develpment rganizatins t ptimize prject executin. Risk assessment methdlgies include SEI s Taxnmy-Based Risk Identificatin, PMI s Risk Management Practices, and KLCI s Detailed Risk Assessment SM. Risk assessments are typically perfrmed by utside agents expert in Sftware Risk Management. Risk assessments generally fcus n tp-dwn and bttm-up identificatin f prject strengths and risks. The results are used t develp an actinable framewrk f risk mitigatin actins based n assessr experience and individual prject characteristics. Risk assessment is mst effective fr relatively experienced sftware develpment rganizatins. An rganizatin fr which a prject is being assessed needs t have sufficient prject management infrastructure t be able t take actin based n the results. The rganizatin als needs t have a cmmitment t imprving their prject executin effectiveness. Why Shuld I Care? Prject Risks are schedule delays and cst verruns waiting t happen. Sftware Risk Management includes structured techniques t blck these surprises befre they ccur. Because f prven results, Sftware Risk Management has becme widely implemented in sftware rganizatins with the highest relative levels f prductivity in the industry. Further, Sftware Risk Management is n lnger cst prhibitive. Several excellent, affrdable tls enable smaller prjects and sftware rganizatins t implement risk management with little up-frnt investment. Risk Management practices can be implemented at any pint in a prject and will ften have immediate, psitive payback in increased prductivity. Page 4
References 1. Yurdn, Edward, Rise & Resurrectin f the American Prgrammer, Yurdn Press, 1996. 2. Hewlett, David T., Prject Schedule Risk Analysis: Mnte Carl Simulatin r PERT, PM Netwrk, February 2000. 4. Karlak, Dale, Sftware Engineering Risk Management, IEEE Cmputer Sciety Press, 1996. 5. Kulik, Peter, Team-Based Risk Management in Sftware Develpment, AT&T GIS Jurnal, December 1994. 6. Behm, Barry, Sftware Risk Management, IEEE Cmputer Sciety, 1989. 7. Kulik, Peter, Hw t Prevent Surprises in Sftware Prjects, August 1998. Available fr dwnlad at. 8. Fr infrmatin abut the Sftware Engineering Institute (SEI) cnference n Sftware Risk r Risk Taxnmy, visit the SEI website at http://www.sei.cmu.edu, r cntact SEI Custmer Relatins at 412-268-5000. 9. Kulik, Peter, Team-Driven Schedule Metrics, March 1996. Available fr dwnlad at. Peter Kulik is Managing Partner f KLCI, Inc. With mre than 14 years experience in all aspects f sftware develpment, he hlds an MS in Engineering Management with the thesis Practical Quantitative Methds fr Sftware Develpment Prcess Management, a Certificate in Ecnmics and Finance, and a BS in Electrical Engineering. He can be reached via e-mail at pkulik@klci.cm. KLCI, Inc. helps sftware develpment rganizatins implement risk management, sftware metrics, and ther prcess imprvement initiatives. With innvative tls including the Prject Self-Assessment Kit, KLCI applies apply prven practices in an actin-riented framewrk. Services enable clients t imprve their prductivity and meet custmer cmmitments n sftware prjects 10 t 100 peple. KLCI can be cntacted at 888-664-0484 (Tll Free, US/Canada) r +1-937-433-5502, r n the Wrld Wide Web at. Page 5