Welcome to Scribd, the world's digital library. Read, publish, and share books and documents. See more
Standard view
Full view
of .
Look up keyword
Like this
0 of .
Results for:
No results containing your search query
P. 1


Ratings: (0)|Views: 9|Likes:
Published by priyanka

More info:

Published by: priyanka on Nov 21, 2012
Copyright:Attribution Non-commercial


Read on Scribd mobile: iPhone, iPad and Android.
download as PDF, TXT or read online from Scribd
See more
See less





Risk Mitigation: Fixing a ProjectBefore It Is Broken
A comprehensive assessment of unforeseen risks in the projectlifecycle can prevent costly breakdowns at the testing stage.
Executive Summary
Many IT projects have a reputation for exceedingbudgets, missing deadlines, failing to realizeexpectations and/or delivering sub-par return oninvestment. Surveys and reports on the accept-ability of new IT systems reinforce the sameproblems and probable causes of failure; yetbusinesses, large and small, continually makemistakes when attempting to improve informa-tion systems, particularly investing in inappropri-ate or unworkable changes without proper con-sideration of the likely risks.Planning projects, establishing requirementsfor change, selecting, implementing and testingsuitable systems are important componentsof a superior business management process.Companies, however, often do not take adequateprecautions during the project lifecycle tominimize failures at the testing stage. Considerthe following:
Our assessment of 134 publicly tradedcompanies reveals that over half admittedto suffering a failed IT project in the past 12months due to issues encountered duringthe testing stage. Such failures come at anextremely high cost.
According to the Royal Academy of Engineer-ing and the British Computer Society, £3.5billion are wasted every year on badly managedIT system deployments, only discovered duringthe testing stage.
Only about 16% of overall IT projects can beconsidered successful; even conservativeestimates put the costs of failure into the £20billion range across the European Union (EU),in IT software development projects.
 As seen in Figure 1 (next page), the peak expen-diture of both time and money on IT support anddevelopment occurs at the testing stage. Thecosts of failure are not limited to the narrow con-siderations of budget and schedule. Companiesdo not pay adequate attention to conducting aproactive risk assessment of all projects duringtheir entire lifecycle in an effort to mitigate andminimize the risk of failure at the testing stage.Identifying and analyzing potential risks of failureduring the project lifecycle is fundamental toavoiding issues at the testing stage, as well asmassive rework. To do this, it is vital to set upan early-stage diagnosis. This approach includesanalyzing projects throughout the entire lifecycle,from the requirements gathering stage throughverication, when all potential variables andintermediate process steps are weighed in termsof risk. Taking this approach can help IT organi-zations understand and minimize the potentialimpact on testing activities.
Cognizant 20-20 Insights
 cognizant 20-20 insights|july 2012
cognizant 20-20 insights
In this whitepaper, we spell out our rigorousprocess for identifying and avoiding project issuesthat undermine many applications developmentprojects. It also offers proven ways for organiza-tions to minimize development delays and costs,while building systems that deliver exceptionalbusiness benets.
Test Risk Assessment Process
Cognizant Business Consulting developed astructured, proprietary process called the TestRisk Assessment for Project Improvement(TeRAPI), with the main objective of identifyingand minimizing risks that can occur at the testingstage across the entire product lifecycle.The process consists of three main phases:1.Measure the business criticality.2.Prole the risk level of projects.3.Design a risk mitigation plan.The purpose of measuring business criticality isto determine the importance of each businessfunction. After all the business processes areevaluated to determine their criticality to theproject, business functions can be prioritized todetermine which ones require a contingency planand which can be ignored and eliminated.Each function, system, interface and third partycan and should receive a risk rating. Probabili-ties are assigned to each failure that can occurfor each of these items. This means that anorder function (risk rating = 5) could be impairedbecause of a business partner failure (probabilityof 60%) or could fail due to a system failure (prob-ability of 20%). The same function would have adifferent criticality/probability score (see below),based on the fact that two different failures couldhit that business function.The business criticality evaluation process isstrictly related to the risk management processand is useful for any project stakeholder, at anyproject stage.
Measuring Business Criticality
To be successful, any test risk assessment hasto concentrate on the local identiable issuesrelated to the business. During the test riskassessment process, risks to business functionswill be identied and evaluated. The vulnerabil-ity of the business to these risks will be rated.Main actions to perform in a test risk assessmentinclude:
Alignment of testing with businessrequirements.
Test strategy and test environmentpreparation.
Test resourcing.
Test environment.
Test execution.
Production readiness preparation.
Project Costs Increase at Testing Stage
Late DefectDiscovery Results inSignificant ReworkDefectPreventionNew
   R   a   t   e   o   f   C   o   s   t   I   n   v   e   s   t   m   e   n   t   D   u   r   i   n   g   P   r   o   j   e   c   t   e   d   L   i   f   e   c   y   c   l   e
RequirementsDesign and BuildReleaseto TestReleaseto Field
100x Increase in Cost of Removing Defects
Sources: Barry Boehm, “Software Engineering Economics,” Prentice Hall, Inc., 1981.Basili Boehm, “Software Management,” IEEE Computer, January 2001.
Figure 1
cognizant 20-20 insights
Each of these business functions representsa dimension to be analyzed in setting up a riskmanagement process.
Profiling Risk Level of Projects
After having dened main dimensions and sub-dimensions as a core part of the TeRAPI method-ology, each project must be assessed to weigh therisk associated with each sub-dimension in eachstage of the project lifecycle.A business criticality score is determined basedon the business purpose of the project. The resultis a business risk index (BRI), which offers acomposite view and comparison of risks based onthe business criticality of the projects that requireimmediate management attention, as well as thepriorities of these projects.All dimensions are quantitatively determined,from business requirements alignment, to testresult analysis and mitigation plan design — anda qualitative index is assigned. Frequency of riskacross each action step must be determined andgraphed.For each dimension and its specic sub-dimen-sions, a qualitative measure of risk importanceneeds to be identied and quantied. This must bedone across all projects where TeRAPI is applied.This data is placed in a qualitative table thatsummarizes all quantied risk-level results foreach assessed project in an effective way andin relation to each dimension and relative sub-dimensions (see Figure 2).The TeRAPI risk assessment identies two typesof risks for testing:
High-level risks:
Risks that are likely to impactthe schedule or the quality of the deliverable.The root causes for these risks need to beidentied and addressed through initiatives atthe higher level.
Medium-level risks:
Risks that can beaddressed by the testing team with minimalimpact on schedule or quality. These risks canbe addressed by project managers throughtactical initiatives.Once the test risk assessment is completed, thenext step is to analyze and present the results sothat executive management can get the most usefrom the data. Data analysis will be the foundationfor planning actions to mitigate risk impact andprovide recommendations.The recovery strategies that need to be developedshould be based on the ndings of the riskassessment survey and interviews, as well as thebusiness impact analysis.
Designing the Risk Mitigation Plan
Each TeRAPI dimension must be developed andrisk causes determined and analyzed to create
TeRAPI: Project Test Risk Evaluation
#1 #2 #3 #4 #5 #6 #7 #8 #9 #10 #11 #12 #13 #14 #15
Sub-dimension #1
Sub-dimension #2
Sub-dimension #3
Sub-dimension #4
Sub-dimension #5
Sub-dimension #6
Sub-dimension #1Sub-dimension #2Sub-dimension #3Sub-dimension #4Sub-dimension #5Sub-dimension #6HighMedium
High (H)
Risks that are likely to impact the schedule orquality of the deliverable 
Medium (M)
Risks that can be addressed by the project managerwith minimal impact on schedule and quality0246810
Figure 2
Frequency of Risk forIndividual Projects
      P     r     o       j     e     c       t     s
0 5 10 15 2024562620256627612281288126812847267327102776c2776b281529122817

You're Reading a Free Preview

/*********** DO NOT ALTER ANYTHING BELOW THIS LINE ! ************/ var s_code=s.t();if(s_code)document.write(s_code)//-->