Software Project Management Lecture 9 Outline n n

Software Project Management Lecture # 9

Outline n n Chapter 25 – risk management (contd) Risk Identification ¡ n Risk Projection ¡ ¡ n n n Risk Components and Drivers Developing a Risk table Assessing risk impact Risk Refinement What is RMMM? RMMM Plan

Risk Components and Drivers (1) n n n The U. S. Air force has published an excellent guideline for software risk identification and abatement. Their approach requires project manager to identify risks drivers that affect software risk components Following are the Risk Components ¡ ¡ Performance Cost Support Schedule

Risk Components and Drivers (2) n These risk components are defined as follows in context of these guidelines: ¡ Performance risk n ¡ Cost risk n ¡ The degree of uncertainty that the project budget will be maintained Support risk n ¡ The degree of uncertainty that the product will meet its requirements and be fit for its intended use The degree of uncertainty that the resultant software will be easy to correct, adapt and enhance Schedule risk n The degree of uncertainty that the project schedule will be maintained and that the product will be delivered on time

Risk Components and Drivers (3) n The impact of each risk driver on the risk component is determined. This impact can be any of these four impact categories ¡ ¡ Negligible Marginal Critical Catastrophic

Risk Projection (1) n n Risk Projection is also known as Risk Estimation Risk projection rates each risk in two ways: ¡ ¡ n the probability that the risk is real and the consequences of the problems associated with the risk, should it occur 4 Risk projection steps performed by project planner along with other managers & tech staff 1. 2. 3. 4. Establish a scale that reflects the perceived likelihood of a risk Delineate the consequences of the risk Estimate the impact of the risk on the project and the product Note overall accuracy of the risk projection so that there will be no misunderstandings

Risk Projection (2) n n The aim of these steps is to eventually determine prioritization of the risk By prioritizing risks, the software team can allocate resources where they will have the most impact.

Developing a Risk Table (1) n n n n A risk table provides a project manager with a simple technique for risk projection (estimation) The risk table can be implemented as a spread sheet model (enabling easy manipulation & sorting of entries) The table has the following content: 1 st column: list of all risks 2 nd column: categorization of risks, e. g. , PS (Project Size risk), BU (Business risk) 3 rd column: probability of risk occurrence 4 th column: risk impact category ¡ determined by averaging the impact categories of the 4 risk components – performance, support, cost, schedule)

Developing a Risk Table (2) n n n After the first four columns are completed, the table is sorted by probability and by impact. High probability and high impact risks move to the top of the table and low ones drop to bottom Project Manager studies the resultant (1 st order risk prioritization) table and defines a cutoff line. Risks above the cutoff line must be managed Risks below cutoff line are reevaluated for 2 nd order prioritization. 5 th column: contains a pointer into a Risk Mitigation, Monitoring and Management Plan (RMMM) or alternatively, a collection of risk information sheets developed for all risks above the cutoff

Assessing Risk Impact n If a risk does occur, then the consequences (that are likely) are affected by 3 factors ¡ ¡ ¡ n Following are the recommended steps to determine overall consequences of risk ¡ ¡ ¡ n nature of risk scope (severity & its distribution) of risk timing of risk Determine the avg probability of occurrence value for each risk component Using impact assessment (fig. 25. 1), determine impact for each component based on the criteria. Complete the risk table & analyze the results as described in the preceding sections. The overall risk exposure RE is determined using the following relationship: ¡ RE = P x C where P = probability of occurrence for risk C = cost to the project, if risk occurs

Risk Refinement (1) n n During early stages of the project, a risk is stated generally As time passes, learning about project work and related risks improves Hence, risks stated earlier can be refined, making them more detailed so that they are easier to handle Risk can be represented in condition-transitionconsequence (CTC) format ¡ Given that <condition> then there is a concern that (possibly) <consequence>

Risk Refinement (2) n Example: ¡ n Given that all reusable components must conform to specific design standards and that some do not conform, then there is a concern that possibly only 70 percent of the planned reusable modules may actually be integrated into the as-built system, resulting in the need to custom engineer the remaining 30 percent of components Refinement: ¡ Subcondition 1 n ¡ Subcondition 2 n ¡ The design standard for component interfaces has not been solidified and may not conform to certain existing reusable components Subcondition 3 n n Certain reusable components were developed by a third party with no knowledge of internal design standards Certain reusable components have been implemented in a language that is not supported on target environment The consequence (of custom engg of 30% components) remains same for all refined subconditions but refinement helps in easy risk analysis

What is RMMM? n n RMMM = Risk Mitigation, Monitoring and Management An effective strategy to deal with risks must consider issues such as: ¡ ¡ ¡ n Risk avoidance Risk monitoring Risk management and contingency planning RMMM steps incur additional project cost

Example Scenario of a RISK… n Scenario ¡ ¡ n Assume that high staff turnover is a project risk r 1. Based on past history, the likelihood l 1, of high turnover is estimated to be 70% The impact x 1, is projected as critical So, high turnover will have a critical impact on project cost and schedule Steps to mitigate r 1: ¡ ¡ ¡ Meet the staff to find the causes of turnover (poor working conditions, low pay, etc. ) Try to reduce the causes of turnover (if possible) before project starts Once project starts, assume turnover will occur and develop techniques to ensure continuity when people leave

Example Scenario of a RISK… ¡ ¡ n Organize project teams so that information about each development activity is widely dispersed. Define documentation standards & establish mechanisms to ensure that documents are timely developed. Conduct peer reviews of all work. Assign backup staff member for every critical technologist. Risk Monitoring for r 1: ¡ ¡ As project proceeds, risk monitoring activities commence to find indications whether the risk is becoming more or less likely. Following factors are considered for r 1: General attitude of team members based on project pressures. The degree to which the team is jelled.

Example Scenario of a RISK… ¡ ¡ ¡ n Interpersonal relationships among team members. Potential problems with compensation and benefits. The availability of jobs within or outside the company. Risk Management & Contingency Planning: ¡ ¡ ¡ This stage comes into play when mitigation efforts have failed and risk has become a reality. Considering again scenario for r 1. The project is underway and a number of people announce that they will be leaving. If mitigation strategy has been followed, backup is available, information is documented and knowledge is dispersed across the team.

Example Scenario of a RISK… ¡ ¡ Project manager may refocus resources to those functions that are fully staffed and re-adjust schedule accordingly. The newcomers can “get up to speed” in the mean time. Individuals who are leaving are asked to stop all work and spend their last weeks in “knowledge transfer mode”. This may include n n n video-based knowledge capture, development of “commentary documents”, And / or meeting with other team members who will stay on the project team

Example Scenario of a RISK… n Cost/benefit analysis: ¡ ¡ ¡ Since RMMM steps incur additional cost, the project managers & planners must consider if the benefit of these steps are outweighed by costs associated in implementing them. If risk management steps are projected to increase costs by 5% and duration by only 3%, then there is no harm in putting them in place. If these steps increase both project cost and duration by 15%, then they may not be undertaken.

Risk Management n For a large project, 30 to 40 risks can be identified. If between 3 & 7 risk management steps are identified for each risk, risk management may become a project itself! n For this reason, we adapt the Pareto 80 -20 rule to software risks ¡ Experience indicates that 80% of overall project risk (potential for failure) can be accounted for by 20% of the identified risks (the critical 20 risks with highest project priority). n Risks can even occur after the software has been successfully developed & delivered to the customer. n Software safety and hazard analysis (SQA activities) focus on identification & assessment of potential hazards that have negative affect and may cause entire system to fail.

The RMMM Plan n n The RMMM plan documents all work performed as part of risk analysis. It is used by project manager as part of overall project plan. Some software teams do not develop formal RMMM document. Rather, each risk is documented individually using a risk information sheet (RIS). In most cases, RIS is maintained using a database system so that creation & information entry, priority ordering, searches, and other analysis may be accomplishes easily.

The RMMM Plan n RIS contains the following information (Fig. 25. 4) ¡ ¡ ¡ ¡ n Risk ID, Date, Probability & Impact Description Refinement/context Mitigation/monitoring Management/Contingency Plan/trigger Current Status Originator & Assigned (to whom) information Once RMMM has been documented & project has begun, risk mitigation and monitoring steps commence.

The RMMM Plan n n Risk mitigation is problem avoidance activity Risk monitoring has three main objectives: ¡ ¡ ¡ n To assess whether predicted risks do, in fact, occur To ensure that risk aversion steps defined for the risk are properly applied To collect info that can be used for future risk analysis A part of monitoring is to find causes (origin) of risks.