Software Engineering Project ManagementSE603Unit 6: Risk Management Egypt, 15.6.2015
Introduction Each software project is subject to various risks that might hinder its progress. This risk might result in severe consequences that could be huge financialloss. In order to manage these risks, risk management framework is adopted. firstlywe identify the possible risks that might pop up along the project execution. Secondly, risk are assessed and prioritized according to many attributes such as impact and probability of occurrence. That is done through Risk Analysis and prioritization. Thirdly, certain responses should be considered to mitigate the impact of each risks though Risk Planning. Risk planning must be completed early during the project planning. Finally, along the development life cycle, risks are monitored and updated to make sure they are in control and the steps taken in the risk planning phase are effective and efficient. In this unit, we investigate the risk management framework across its different phases and examine the indicators used to prioritize and asses risks. Besides, going through the 3-point AON Estimation - the modified version of AON illustrated in unit 4 – where this version consider risks in calculations.
Objectives To get acquainted with the risk management framework Going through various risk response techniques Be familiar with the modified versions of AON that consider risk in their estimations (3-point AON Estimation)
Unit 6: List of topics 1. Risk Types 2. Risk Management Framework 2.1. Risk Identification 2.1.1. Checklists 2.1.2. Brainstorming 2.1.3. Causal Mapping 2.2. Risk Analysis 2.3. Risk Response 2.3.1. Risks Acceptance 2.3.2. Risks Avoidance 2.3.3. Risks Reduction 2.3.4. Risk Transfer 2.3.5 Risk Mitigation 2.3.6. Risk Escalation 2.4. Risk Monitoring 3. 3-point AON Estimation 4
Risk Management Step 0 Initiation • In order to handle project risks, step 6 of Step Wise Planning, introduced in Unit 2, is investigated. • Step 6 aims to enable project managers to have their risk management plans tuned to their software projects. The managers go through the risk identification process, followed by analyzing these risks. Once they are done of the analysis, they investigate the best possible response for each risk and finally keep an eyes on all risks make sure they are in control. Step 1: Defining Scope and Objectives Step 2: Understanding Client infrastructure Step 3 Project Characteristics Analysis review Step 4 Identifying deliverables Lower level detail Step 5 Effort Estimation For Each activity Step 6 Handling risks Step 10 Low-Level Planning Step 7 Resources Allocation Step 9 Plans Execution Step 8 Plans Review Figure: STEP WISE Planning Steps 
1. RiskTypes (1/3) Risk is unplanned event causing adverse effect on the project course resulting in extending the completion time, amplifying costs and confusing schedules of resources. There are 3 major types of risks :
1. RiskTypes (2/3) Risks could be positive or negative. Negative risks are unwanted event causing adverse effects. Examples of Negative Risk is the main programmer is quitting the job or the unavailability of certain software tool or equipment. Whilst, positive risks, are opportunities that positively affect the project, such as increasing ROI or finishing the project ahead of time. Example of Positive Risks: having number of subscribers on the launch date of a telecom service than expected.
1. RiskTypes (3/3) Positive risks could create negative risks. In the case of the telecom service, negative risks may arise the time switches were unable to handle the loador the billing system couldn’t process all the calls. Such negative risks can cause the whole service to fail resulting in low customer satisfaction.  Negative risks have to be managed to mitigate their effects. However, positive risks are managed to take advantage of their occurrence. 
2. Risk Management Framework • The management framework is tailored to meet the scope of the software project of interest. The stages of the framework are : • Risk Identification • Risk Analysis • Risk Response ( Risk Acceptance / Avoidance / Transfer / Escalation / Mitigation) • Risk Monitor and Control
Risk Management Flow Risk management continues by new owners of the risk Enter Identify Risk Close Risk Continue Risk Management When risks occur they become issues and are managed as issues Due to continuous monitoring is the risk still valid? Yes Initial Acceptance Has Risk been mitigated Has risk occurred No Reject Risk Transfer or Escalate No Yes No Yes Risk Still Valid Yes Transfer Escalate No Conduct Risk Analysis Execute Mitigation Strategies Go to issue Management Yes No Accept Risk Consequences Mitigation Strategies Required Is Risk Valid Develop Contingency Strategies Yes No Do contingency strategies exist Yes No Yes Yes No Reject Risk Contingencystrategies required Develop Mitigation Strategies Yes Close Risk No Continuous Monitor and control Risk Alfred (Al) Florence The MITRE Corporation 
2.1. Risk Identification • The precaution actions are highly recommended to mitigate and avoid the impact of risks. Therefore, we firstly identify all possible risks that might occur throughout the project course to make sure they are in control. There are many approaches to identify risks such as : • Checklists • Brainstorming • Causal mapping
2.1.1. Checklists • Risk checklists include all risks with highprobability of occurrence collected throughout years of experience in the domain of software development. Such checklists are organized and categorized by the development phases [3,8]: • System Requirements Phase • Software Planning Phase • Software design phase • Implementation phase.
2.1.1. Checklists Most technical and managerial related project members such as project manager, system engineer, software technical lead and developers, and the software engineers fill and review these checklists. Checklist must be revisited in each lifecycle stage to make sure that the listed risks are in control and no new risks were developed [3,8]. The following 4 slides display the (SEI) Software Risk Checklist , the most famous Software Project Risks  and Sample of Boehm’s top 10 development risks .
Example of Software Engineering Institute (SEI) Software Risk Checklist – Taxonomy (1/2) 
Example of Software Engineering Institute (SEI) Software Risk Checklist – Taxonomy (2/2) 
2.1.2. Brainstorming Project Stakeholdersmeet to identifythe potential risks powered by by their extensiveknowledge regarding the project and suggest the risk reduction solutions. A popular approach for brainstorming is the facilitatedworkshop. It isaworkshop to identify the potential risks where its members are those with full-time engagements in the project with considerable responsibilities and covering critical technologies and commercial issues. Clients and suppliers should be aboard as well.
2.1.2. Brainstorming This workshop is managed by a facilitator who ensures that everyone is participant, manage discussionthreads and compileoutputs into risk list. If the Project Manager has the facilitation skills then he could be a candidate, however, the workshop members may be steered as discussions could go toward certain direction in favor of the PM preferences. It is more convenient to have an independent person of the Project with much knowledge about the nature of such projects to be the facilitator.
2.1.3. Causal Mapping (1/4) A causal map is a network diagram depicts causes and effects. Events are the (nodes) and causalrelationships are the (links) between nodes representing causality or influence. Events affect each other through positiveor negativecausal relationship and effect . In the example  blow the low staff turnover is a indication that we hire experienced staff (causality relation is positive). The more experienced staff are available, the higher productivity rate is developed (causality relation is positive). Consequently, the deadlines are met (causality relation is positive) and the management pressure tends to be low (causality relation is negative). On the other side, if we don’t have clear user requirements, that would cause running operations in unstable environment (causality relation is positive). Consequently, we hardly meet the deadline (causality relation is negative).
2.1.3. Causal Mapping (2/4) High productivity Low staff turnover + Experienced Staff + Heavy Management pressure + - Uncertain user requirements Unstable environment Deadlines met + - 
2.1.3. Causal Mapping (3/4) The simple cause-risk-effect structure depicts the cause that drives a probability of having risk. Once this risk emerged, it will drive the impact of the effect. The impact of the effect is variable depending on the influence of the risk . Cause Drives probability Risk Drives Variable impact Effect simple cause-risk-effect structure
2.1.3. Causal Mapping (2/2) A further modification of this structure is the Causal map showing cause–risk–effect multiple relationships - a more complex but more flexible approach to describing composite risks. It expands each element into a network of links, recognizing that cause–risk–effect relationships are usually not singular (1:1:1) but multiple (many : many : many) as shown in the figure behind . This causal map can be useful in generating improved understanding of project risks. Based on maps, policies to reduce the likelihood of undesirable outcomes to the project could be developed . Cause Drives probability Risk Drives Variable impact Effect simple cause-risk-effect structure
Causal map of cause–risk–effect multiple relationships  Cause Cause Cause Cause Risk Risk Risk Effect Effect Effect Effect(s) 
2.2. Risk Analysis (1/4) To analyze risks, the probability of occurrence, impact and priority should be assessed for each risk. The probability attribute is the possibility degree that risk could occurs. The probability value is between 0 (very low) and 1 (very high) estimated by subject-matter experts. (Probability Table)  The impact attribute is the consequences or the damage of the risk. The impact value is between 1 (very low) and 5 (very high) assessed against four categories: Cost, Schedule, Scope, Performance. (Impact table).
2.2. Risk Analysis (2/4) Impact Table 
2.2. Risk Analysis (3/4) Probability Table 
2.2. Risk Analysis (4/4) To assess the priority of risk, Risk exposure (Risk Priority) is used. Risk Exposureis the result of multiplying the probability of a risk to occur by the impact of occurrence. Prioritizing risksenables project manager to determine the capacity in terms of time and resources needed to manage and monitor the risks. Risk Exposure (Risk Priority) = Impact of Risk x Probability of Occurrence  Two ways of calculating the impact of a risk, either by estimating the financial loss in term of cash or on scale of 1 (very low) to 5 (vey high) assessed against four categories: Cost, Schedule, Scope, Performance . (Impact table)on the previous slide. Estimating the impact value is difficult as it isn’t easy to predict the potential loss in the event of risk occurrence; it could be limited or dramatic. The same for the probability as it is difficult to have a unified opinion from various experts to estimate the probability of a risk to occur due to different backgrounds and experiences ; but we could take the average.
Risk Exposure (Calculation Method 1) Composite Risk Index valuestend to be high at the inception of the project as the probability of expecting risks to occur is high. As soon as we approach finalizing the project, the values drop gradually as the possibility of having risks decrease. Risk Exposure (Risk Priority) = Impact of Risk x Probability of Occurrence Potential damage in terms of financial loss. For example a severe earthquake causes a damage of £0.5million. Probability 0 (0% chance to happen) to 1 (100% sure of occurrence). For example: 0.01 means one in hundred chance. (check probability of occurrence table) CRI = £0.5m x 0.01 = £5,000 the amount needed for an insurance premium
Risk Exposure (Calculation Method 2)  Impact Risk Priorities Very High High Medium Low Very Low Probability of occurrence Very High High Medium Low Very low Very Low Priority Low Priority Medium Priority High Priority Very High Priority Risk Watch List Monitor Develop Mitigation strategy Monitor Develop Contingency strategy Monitor Monitor
2.3. Risk Response Risk response is the process of selecting the best possible response for each risk. Responses for negative risks [2, 14]: Risk acceptance Risk avoidance Risk reduction Risk transfer Risk Escalation Risk Mitigation Responses for positive risks : Exploit Share Enhance
2.3.1. Risks Acceptance Risk acceptance is a response technique for unavoidable risks or risks we could deal with its impact and keep it in control. Besides the cost of mitigating this risk is accepted. There are two types of risk acceptance strategies: Passive and Active. Passive is about accepting risks that can’t be avoided where project team deal with such risk with no adequate response strategy. Whilst, the active is the same but the project team has a contingency plan to deal with the risk .
2.3.1. Risks Acceptance Example of the risk acceptance: the risk of purchasing a defective CD of a ready-made software product. Replacing this copy would cause a delay of 5 days to a task having 25 days slack time. The Passive acceptance is used in this case as It does not worth exerting efforts to anticipate the problem and do something about it. It is simpler to wait and check if something goes wrong with the CD, then, we take corrective action.
2.3.2. Risks Avoidance It is the opposite of risk acceptance. It is a response technique that avoids exposure to any risk. Risk Avoidance is the most expensive response as it might make changes to the project management plan to eliminate risks and mitigate their impacts [16,9]. Example of Risk avoidance: purchasing a ready made software product to avoid risks associated with the in-house development such as poor effort and time estimates, availability of resources, compatibility issues, etc.
2.3.3. Risks Reduction Risk avoidance avoids exposure to any risk. Whilst Risk reduction reduces the likelihood and severity of a possible loss, in other words, it limits the exposure to risk by taking some actions. Risk reduction employs a bit of risk acceptance along with a bit of risk avoidance. Example of risk limitation: A company accepts that a hard drive may fail and avoids a long period of failure by having backups . Risk Reduction Leverage (RRL) is an index compares the exposure of a single event BEFORE and AFTER managing the risk. The higher the Leverage, the better the solution .
2.3.3. Risks Reduction Risk Reduction Leverage (RRL) = Risk Exposure Before - Risk Exposure After cost of risk reduction Consider the following example: the impact of having severe compatibility issue might add 10,000$ to expenses. The probability of having this risk is 30% before risk reduction and 10% after risk reduction. The cost of making updates to overcome the compatibility issue is 1000$ The Risk Reduction Leverage (RRL) = (0.3x 10,000) – (0.1x x 1000) / 1000 = (3000 - 1000) / 1000 = 2. If RRL > 1.00 then it worth doing the reduction otherwisethe cost of the risk reduction activity outweighs the probable gain from implementing the action 
2.3.4. Risk Transfer Risk is outsourced to another entity. This is the case of companies outsourcing some of the their operations like cloud computing platforms, backup solutions, infrastructure management, customer service, payroll services, etc. Transferring such risks let entities focus on their core competencies [16,9].
2.3.5. Risk Mitigation While risk reduction reduces the likelihood of a risk to occur, the risk mitigation is concerned with taking early actions to minimize the probability and/or impact of a risk when it occurs. It is far effective than trying to repair the damage after the occurrence of a risk [16,9]. Examples of Risk Mitigation: Adapting less complex processes, conducting more tests, or choosing a more stable suppliers .
2.3.6. Risk Escalation Risk escalation is transferring the ownership and accountability of a risk to the seniormanagement, whereas reporting, is about maintaining the ownership and accountability for that risk @ your level, but keep informing the senior management of the current situation and the way of handling .
2.3.6. Risk Escalation The reasons to escalate a risk : The risk is above your target level of risk and there is nothing to do to reduce that to your target. Risk is escalated to the senior management that has the authority and the accountability to accept that risk on behalf of the organization. When the treatments you need to do around that risk are outside of the delegation of the original risk. For example If the decision is taken not to spend the money on that, then, risk is going to be accepted at a higher level. Shared risk with other organizational functions or with external entities where you can’t approach an agreement.
2.4. Risk Monitoring Risk monitoring and updating is a process concerned with tracking the identified risks and make sure they are in control. It also keeps identifying any new risks that might popup across the project while managing the contingency plans in case they are needed. On top of that, this process collects and captures lessons learned during managing and mitigating risk for the upcoming risk assessments and efforts allocation. This process continues throughout the life of the project.
3. 3-point AON Estimation • The 3-point AON estimation has an advantage over the previously discussed AON mentioned in unit 4 for the following reasons : • An increased accuracy estimation over the single point estimates • Better commitment from project team members as estimate considers risk in the assignment • Useful information on the risks of each task. 
3. 3-point AON Estimation • To evaluate the impact of risk in AON (mentioned in unit 4), firstly, we create the network of activities. Secondly, we estimate the early and late start of tasks by applying forward and backward path. Thirdly, we calculate the total float time and identify the critical path. Fourthly, we calculate (Most Optimistic, Most pessimistic, Most likely) estimates for each activity and derive the expected task duration, besides calculating the standard Deviation and variance. Finally, we determine probability of meeting expected date
3. 3-point AON Estimation  • The Expected Task Duration (TE) = (TO + TL x 4 + TP ) / 6  • Most Optimistic (TO) – the most optimistic estimate of the task duration • Most Likely (TP) - the most pessimistic estimate of the task duration • Most Pessimistic (TL) - = the most likely time • TE is an estimate from three estimates the team member assigned for their task. It reflects the amount of risk in the task and the severity of the impact of the optimistic and pessimistic risks. • Standard deviation (SD) is the average deviation from the estimated time = (TP-T0)/6 • The higher SD the greater the amount of uncertainty Probability of finishing a task in time t t TO TL TP TE