Project+3

=toc= =SSE 674 Software Risk Management= Project 1: Part II: Risk Management Process

**Chapter 4: Identify Risk**

 * Objective: ** The first step in the risk management process starts with identifying risks when developing complex software project where reliability and performance of the software are crucial in delivering a project to a customer. The risk identification process defines what activities and methods can be used to identify risk.

** 4.1 Define the Risk Identification Process **
The following block diagram shows the goals that can be utilized to meet the risk identification process objectives. Integrated Computer-Aided Manufacturing Definition (IDEF0) --- it’s a standard model function for defining manufacturing processes and it is used to describe a reusable process component for risk identification. The following diagram in figure 4-2 shows the controls, inputs, outputs and mechanism that support the process as shown below: __ Process Controls __ --- These controls are located at the top which include project resources, project requirements and risk management plan in regulating the risk identification process. The project resources assist the risk identification process by analyzing the cost, time and number of people involved. The process effectiveness can be reduced if project resources are not utilized effectively; for instance if cost is an issue, inexpensive methods can be utilized to identify risk by ensuring that inexpensive methods are reliable and still effective. The project requirements are established by organization and they must meet the standard set by the customer to ensure the safety of the product. To perform risk identification, deriving requirements for risk identification from organizational standards can be helpful since project reviews discusses risks that are reported. The risk management plan documents the procedures and assign responsibility for risk management activities.
 * 4.1.2 Process Definition **

__ Process Inputs __ --- are inputs located on the left side in figure 4-2 which includes uncertainty, knowledge, concerns and issues. The uncertainty input involves assumptions; for instance, time frame of a project whose time of completion is not analyzed in the past contains uncertainty and would require an appropriate assumption for its completion. The knowledge of current project is important to better understand how complex a certain project is and utilizing the experience gained through past can be vital in identifying software risk. Concerns are caused by risks and if they are not resolved properly by following the procedures, they can cause problems in an operation of a project. Issues can be risk when it is hard to make some decisions that involve trade-offs due to time, cost, etc. __ Process Outputs __ --- In figure 4-2, it is located on the ride side which contains risk statement and risk context in the risk identification process. The value of the risk statement determines the understanding of a risk involved and it can determine if certain issue is a risk. The risk context provides information which involves events, conditions, constraints, assumptions, circumstances and related issues. __ Process Mechanisms __ --- Located at the bottom corner in figure 4-2 which includes risk checklist, risk assessment, risk management form and risk database. A risk checklist organizes risks by project size, development phase, application domain and etc and they assist in finding risk in a particular area. Risk assessment is a method for risk identification which uses a structured risk checklist in a meeting. A risk database logs the risk and maintains a record of identified risks.

The following steps in a block diagram in figure 4-3 are the activities of the risk identification process which can be utilized in any order.
 * 4.1.3 Process Activities **

__ Conduct a Risk Assessment __ --- It evaluates risk based on consequences, occurrences and it gives a baseline of assessed risks which are managed early in a project. Other risk assessments are done when changes occur in a project such as in cost, scheduling, limited resources etc. __ Identify Risk Systematically __ --- The following are seven steps to identify risk systematically as shown below: 1) Checklist --- easy to utilize to discover unknown risks that exist on a project and it can be used as a reminder of possible risk areas to check. 2) Interview --- utilizing people in identifying risks and more solutions are generated in a group setting. 3) Meeting --- are important since they keep team members current with organization objectives. These meetings are usually monthly team meeting, quarterly project status meetings and they can assist in discussing the risks. 4) Review --- they can help in identifying risks by reviewing project, processes and the work product. 5) Routine input --- consist of a template for daily input of identified risk. 6) Survey --- this method can identify risk faster before doing any preparation by reviewing people’s comment on a product. 7) Working group --- involves team work where simulation, brainstorming and other techniques can be utilized to identify risks. __ Define the Risk Attributes __ --- a simple way to describe the possibility of risk occurrence is through a subjective phrase where perceived probability can be utilized. The perceived probability is mapped to a quantitative scale where the probability is a number from 0 to 100 percent. Risk consequences can be cost, schedule and objectives must be clearly stated to develop accurate risk consequences. __ Document Identified Risk __ --- is an efficient way to have a brief description of the risk issue and by using a standard format, it increases the readability of a risk. Document identified risk is done by writing a risk statement and adding the associated risk context by using the keywords such as, what, where and why. __ Communicate Identified Risk __ --- it works best if it is done in verbal and written communication where verbal communication gives a chance to discuss issues clearly and written communication provides a document which keeps the record of past issues and discussion. Verbal communication is usually done face to face or over the telephone where written communication can be distributed through email, newsletters, etc.

** 4.2 Develop Risk Checklists **
Risk checklists provide a systematic approach in identifying risk where SEI software risk taxonomy or project work breakdown structure can be utilized in developing efficient risk checklist. It is a structured checklist which provides a framework for identifying technical risk and taxonomy is organized into three classes which get divided further into element. The SEI software risk taxonomy consist of product engineering, development environment and program constraints along with their elements such as requirements, development process and resources where each element is characterized by its attributes such as stability, formality and schedule. The following sample of SEI taxonomy is shown below in figure 4-3: contractors || management ||  ||
 * 4.2.1 Software Risk Taxonomy **
 * ** Product Engineering ** || ** Development Environment ** || ** Program Constraints ** ||
 * ** 1. Requirement ** || ** 1. Development Process ** || ** 1. Resources ** ||
 * a. Stability || a. Formality || a. Schedule ||
 * b. Completeness || b. Suitability || b. Staff ||
 * ** 2. Design ** || ** 2. Development System ** || ** 2. Contract ** ||
 * a. Functionality || a. Capacity || a. Type of contract ||
 * b. Difficulty || b. Suitability || b. Restriction ||
 * ** 3. Code and Unit Test ** || ** 3. Management Process ** || ** 3. Project Interfaces ** ||
 * a. Feasibility || a. Planning || a. Customer ||
 * b. Unit test || b. Project organization || b. Associate
 * a. Feasibility || a. Planning || a. Customer ||
 * b. Unit test || b. Project organization || b. Associate
 * ** 4. Integration and Test ** || ** 4. Management Methods ** ||  ||
 * a. Environment || a. Monitoring ||  ||
 * b. Product || b. Personnel
 * b. Product || b. Personnel
 * ** 5. Engineering Specialties ** || ** 5. Work Environment ** ||  ||
 * a. Maintainability || a. Quality attitude ||  ||
 * b. Reliability || b. Cooperation ||  ||
 * Figure 4-3 A Portion of SEI Software Risk Taxonomy **
 * Figure 4-3 A Portion of SEI Software Risk Taxonomy **
 * Figure 4-3 A Portion of SEI Software Risk Taxonomy **

It provides a structure for identifying project risk and activities that are not on the project WBS can be a potential unknown risk. Working on unscheduled task can cause problems such as cost overrun and time lost from planned activities. Therefore only activities on the project WBS are valid activities and their costs are taken into consideration.
 * 4.2.2 Work Breakdown Structure **

** 4.3 Define the Risk Assessment Method **
The objectives of risk assessment include methods for risk identification which provide a baseline of assessed risks for continued risk management. An assessment team is trained in risk concepts, the risk assessment method and the risk management process which consist of designated leader to coordinate activities with the project. A project profile contains information on company organization, project data, system description and project history.
 * 4.3.1 Assessment Preparation **

__Company organization__: project profile for company organization includes number of engineers, types of systems developed and etc. __ Project data __ : project profile for project data includes scheduling, budget, number of people in function, organization chart, subcontractor, vendor responsibilities and much more. __ System description __ : project profile for system description includes application description, major function and software block diagram. __ Project history __ : project profile for project history includes unexpected events occurred, technical issues not resolved, current issues of concern and etc.

The project profile provides current project status along with issues that are put off until later and it is normally given by project manager during risk assessment preparation. The assessment preparation consists of six steps:

1) Select and train the assessment team. 2) Review the project profile. 3) Select the interview participants. 4) Prepare the risk assessment schedule. 5) Coordinate the meeting logistics. 6) Brief the project participants.

The interviewer conducts the group discussion by following question and answer approach and project participants answer questions posted by the interviewer in identifying risks. The recorder documents risk statements and the results of the risk analysis where the observer keep track of time and writes detail of the discussion. The assessment team uses the SEI taxonomy based questionnaire which is a risk identification mechanism that is utilized throughout the project. The interview session consist of the following four steps:
 * 4.3.2 Interview Session **

1) Interview the peer group. 2) Record the risks. 3) Clarify the risk statements. 4) Observe and document the process results. The assessment team evaluates the interview results by reviewing the risk statements thoroughly and classifying them according to the SEI risk taxonomy. The preliminary risk analysis consists of the following four steps:
 * 4.3.3 Preliminary Risk Analysis **

1) Evaluate the identified risks. 2) Evaluate the interview session. 3) Categorize the risks. 4) Enter the risks in the risk database. The project manager gets information about the findings of the interview sessions and the risk assessment process is presented to the entire project team for questions from the team. Feedback is written down on the risk assessment evaluation forms that are obtained from the interview participants after the result briefing. The following are the steps followed for result and retrospective process:
 * 4.3.4 Result and Retrospective **

1) Prepare the results briefing. 2) Debrief the project manager. 3) Brief the project team. 4) Evaluate the risk assessment. 5) Distribute the risk management form.

** 4.4 Develop the Risk Management Form **
A risk management form’s main purpose is that anyone can use the form and submit it for identifying risks. The person just has to enter his or her name, the date and a brief description of the risk.

** 4.5 Establish the Risk Database Schema **
The risk database contains data fields and the database design should include links to requirements and pointers for related risks. It is the design of the fields such as log number, risk resolution strategy, phase risk action plan, risk statement and etc.

** 4.6 Summary **
Identifying risk is a first important process element in risk management process where the five process definition steps are fundamental in identifying risk as shown below:

1) Define the risk identification process. 2) Develop risk checklists. 3) Define the risk assessment method. 4) Develop the risk management form. 5) Establish the risk database schema.

Unknown risks can occur easily in software development and these risks are discovered by the work breakdown structure, critical success factors, critical path activities and external interfaces. Unplanned activities can easily steal time from planned activities and cost can over run; therefore it is important to follow WBS and other components properly. A risk checklist is an important factor in process mechanism since it can organize risks by contract type, life cycle, project size, etc. They help to identify risks in a given area and using risk assessment method and risk management form they can further identify risk and provide an efficient way of presenting the information.

** Chapter 5: Analyze Risk **

 * Objective: ** The second process element in risk management process is called analyze risk which contain the activities and methods in evaluating risk and it can be used to manage uncertainty by utilizing risk analysis tools which incorporate uncertainty in the estimates obtained and it then generate results that show all possible outcomes.

** 5.1 Define the Risk Analysis Process **
Risk analysis process consists of both external and internal perspective where external view specifies the process controls, inputs, outputs and mechanisms. The internal view specifies the process activities which transform inputs to outputs by using the mechanisms. The figure 5-1 shows activities of the process encapsulated by analysis risk process. In figure 5-1 above, the inputs enter the process from the left side where control which regulates the process is located on the top. Mechanisms which support the process are located on the bottom and the outputs which exit the process is located on the right side. The following goals satisfy the risk analysis process and they can also be used as a checklist to ensure the process quality is produced by following them properly.
 * 5.1.1 Process Goals **

1) Analyze risk in a cost-efficient manner. 2) Refine the risk context. 3) Determine the source of risk. 4) Determine the risk exposure. 5) Determine the time frame for action. 6) Determine the highest-severity risks.
 * 5.1.2 Process Definition **

__ Process Controls __ --- include project resources, project requirements and the risk management plan which regulate the risk analysis process. __ Process Inputs __ --- include a risk statement which provides a declaration of risk in a standard notation and it covers the issue, probability and consequences of the risk. Risk statement can be improved by following the risk analysis activities and by stating the probability and consequences more quantitatively. The risk context provides the information about events, conditions, constraints, circumstances and related issues and thus collecting information surrounding the risk statement. __ Process Outputs __ --- include prioritized risk list and refined risk context where a prioritized risk list is an inventory of risks which contains the relative ranking of all identified risks and the refined risk context add information obtained from risk analysis such as the source of risk into the database. __ Process Mechanisms __ --- mechanisms are located at the bottom in figure 5-1 and they can be methods, techniques, tools or other instruments which provide structure to the process activities. Evaluation criteria for probability, consequences and time frame for action help to measure risk exposure and analysis techniques help in structuring decisions and determine the limits of acceptable outcomes. The risk database is utilized in maintaining information about evaluated risk and refined risk context where individuals update the risk database with current and previous priority. These are the tasks necessary to transform statements of risk into a prioritized risk list. The following are six activities of the risk analysis process which can be followed in any order:
 * 5.1.3 Process Activities **

1) Group similar and related risks. 2) Determine risk drivers. 3) Determine source of risk. 4) Use risk analysis techniques and tools. 5) Estimate the risk exposure. 6) Evaluate risk against criteria. 7) Rank risks relative to other risks. __ Group similar and related risks __ ---Similar risks can be grouped by sorting the risk database based on risk category and a redundant risk should be closed since the same risk is identified more than once due to its importance. Related risks can be combined and dependent risks can be linked together also but it depends on the task itself and if it makes sense to combine or linked them together. __ Determine Risk Drivers __ --- these are the variables that can cause the probability and consequence of software risk to fluctuate significantly. In determining the risk drivers, one can refine the risk context and helps in determining the significance of the risk. There are several risk drivers such as performance drivers and they can be found in technical specification; cost drivers are found in software cost-estimation models and schedule drivers include the items on critical path. __ Determine Source of Risk __ --- this process uses a question (Why?) five times in determining the root causes of the risk since answers may change often until the root cause is determined. __ Use Risk Analysis Techniques and Tools __ --- Risk analysis techniques deal with conflicting cost and performance goals, uncertainty and risk preference. The risk analysis techniques are utilized in the following:

1) __ Structure __ --- it states the decision, alternatives, uncertainties, value of outcomes and specifies their relationships; influence diagrams and decision trees are useful in structuring a decision model. 2) __ Analyze __ --- this is a decision model which determine the important variables and define their relationship through probability. 3) __ Evaluate __ --- this is a decision model which is obtained by calculating possible outcomes to determine risk profiles and the optimal decision policy. 4) __ Communicate __ --- risk analysis results by understanding and sharing ideas to facilitate in decision making.

Automated risk analysis tools use different decision algorithms and can give different conclusions; they can be grouped into six categories as shown below:

1) __ Multiattribute utility __ --- these models measure the performance of alternatives against objectives that are being challenged. These tools support sophisticated preference models to evaluate situations and their outcomes are difficult to compare. Example of this utility can be cost and environmental considerations. 2) __Multicriteria optimization__ --- provides a framework for finding an appropriate solution by weighting or sorting multiple criteria. 3) __ Multicriteria partial ordering __ --- limited weighting information is accepted to separate some opinions from those that should remain important given the information is provided. 4) Inference --- To support probabilistic analysis of nested or sequential events. 5) __ Decision tree or influence diagram __ --- risky decisions are evaluated which consist of both uncertainties and conflicting objectives. 6) __ Group process __ --- utilized in supporting decision making in a group or team environment where decision makers provide inputs and view the results as part of a group session. __ Estimate the Risk Exposure __ --- risk exposure is calculated by multiplying the probability and consequence if the risk occurred. Probability is defined as greater than zero but less than 100 and consequence is determined in relation to cost, schedule and technical goals. Quantifying risks by risk exposure provides a relative priority order to all the identified risk. The following are several examples utilized in estimating the risk exposure:

1) __ Product __ --- some functionality not ready for the next release. (RE = 3.5 x Cost of missing functionality) 2) __ Time __ --- test will most likely continue for several months. (RE = .80 x Cost of 3 months testing) 3) __ Range __ --- Testing will likely cost between $10,000 and $20,000. (RE = (.70 x $10,000) to (.70 x $20,000)) Therefore the formula of estimating the risk exposure is as follows:

Risk exposure (RE) = P x C

P --- stands for primary risk and it is the probability of unsatisfactory result. C ---stands for loss and it is a consequence of unsatisfactory result. __ Evaluate Risk Against Criteria __ --- It’s a predefined criteria which ensure that all risks will be judged properly against the standard set for them. Risk Severity determines relative priority by mapping categories of risk exposure against the criteria of time and the time frame checks how fast an action is required in order to prevent the risk from occurring. The following figure 5-2 shows risk severity which is determined by risk exposure, time frame and it groups the risk such that the highest priority risks are set to 1.
 * || ** Low ** || **Moderate** || **High** ||
 * **Short** || 5 || 2 || 1 ||
 * **Medium** || 7 || 4 || 3 ||
 * **Long** || 9 || 8 || 6 ||
 * Figure 5-2 Risk Exposure (low, Moderate, High) and Time Frame (short, Medium, Long) **

__ Rank Risks Relative to Other Risks __ --- Risks can be sorted by evaluation criteria where the risks with the highest risk exposure and a short time frame for action are evaluated first. Ranking the risks is effective in focusing the project resources properly and utilizing time frame to arrive at a final prioritize list of assessed risks is also efficient. The Top-N Risk List is a report of the significant risks which is utilized often with current, previous priority. The following sample table in figure 5-3 shows a sample of this report.
 * ** Risk ** || ** Current Priority ** || ** Previous **
 * Priority ** || ** Weeks on Top 10 ** || ** Action Plan Status ** || ** Risk Rating ** ||
 * High software productivity rate || 1 || 1 || 2 || Capturing requirements into requirements database tool. || High ||
 * Off-site software development || 2 || 9 || 2 || Increasing the travel budget for additional site reviews. || High ||
 * Delivery schedule for hardware || 10 || N/A || 1 || No action assigned || Moderate ||
 * Figure 5-3 Sample of Top-N Risk List **

** 5.2 Define Risk Analysis Techniques **
The risk statement and risk context can further be refined under risk analysis techniques: Its focus is to prevent problems by determining the problem’s root cause and it shows relation between an effect and its possible causes. The philosophy of causal analysis is that if an error has occurred once, than it will most likely happen again unless something is done to fix it. The following is a three step process:
 * 5.2.1 Causal Analysis **

1) Determine the cause of the error. 2) Determine the actions that will prevent the error in the future. 3) Implement these corrective actions.

For instance, if a cruise control in a car doesn’t work properly on turns then error can be located at the turns by further testing of the system. Testing can now be done to figure out the cause of the error and what action can be taken to prevent the error in future. In this example once the problem is fixed, car can be tested many times again to ensure cruise control is working properly on turns. It is utilized in structuring decisions and in representing real-world problems by models that can be analyzed to gain insight and understanding. The elements of a decision model are the uncertain events and values of outcomes and once they are identified, two techniques influence diagram and decision tree can be used for structuring decision model. __ Influence diagram __ --- provides a graphical representation of the elements of a decision model and the following four notations are commonly used: 1) Squares represent decisions nodes. 2) Circle represent chance events. 3) Rectangles with rounded corners represent values. 4) Double circles represent outcomes known when the inputs are given. Arcs are nodes connected by arrows which show the relationship between the elements of a decision model and the node at the beginning and end of an arc is called a predecessor and successor. The following is a sample of influence diagram which shows the relationship of the elements of a decision model. __ Decision tree __ --- provides a graphical representation of the elements of a decision model and include the following common notation: 1) Squares represent decisions. 2) Branches emanating from a square represent choices. 3) Circles represent chance events. 4) Branches emanating from a circle represent possible outcomes. 5) The ends of the branches specify values of outcomes. It determines the difference between two variables which shows the need for improvement in risk management practices and it is therefore utilized to determine the need for improvement of risk management practices. Radar charts show gaps among a number of current and ideal performance areas and these chart displays the important categories of performance and defines full performance in each category. The highest number on the scale denotes full performance and zero at the center denotes no performance. It is 80/20 rule, in which 20 percent of the sources cause 80 percent of the problems; its main focus is on the risks that have the greatest potential for reducing problems. Knowing the most frequent risks and the greatest cost can help to determine the most important issues since the highest number risks are identified and a Pareto chart is utilized to display the distribution of identified risks. It helps to determine the sensitivity of the model to variations in input variables by setting each variable to its extreme points or holding all other variables at nominal values. Variables that are not sensitive to variation can be set to their nominal values and treated as known variables rather than unknown variables. Its main focus is on the variables that have the greatest significance and it helps to prioritize data collection. The following are two helpful techniques for sensitivity analysis: 1) __Tornado diagrams__ --- checks the most sensitive variables first where most sensitive variable is located at the top and the least sensitive variable is located at the bottom. The data required to plot a tornado diagram are a list of variables and their range of possible values where high and low values of each variable determine how much effect the variable might have. 2) __Utility functions__ --- incorporate the decision maker’s risk attitude in maximizing expected utility. It represents an individual attitude about risk and different people are willing to accept different levels of risk. An exponential utility function uses a parameter known as the risk tolerance in determining how risk opposes the utility function. Larger values of risk tolerance means an individual is less oppose to risk.
 * 5.2.2 Decision Analysis **
 * 5.2.3 Gap Analysis **
 * 5.2.4 Pareto Analysis **
 * 5.2.5 Sensitivity Analysis **

** 5.3 Define Risk Evaluation Criteria **
These are defined to measure each risk against a known risk and their criteria to measure consist of probability, consequence and time frame for action. Probability can be defined as a percentage, a phrase or a relative number and it can be a helpful in providing the chances of risk. The following is a sample table of probability:
 * 5.3.1 Probability **
 * ** Probability ** || ** Uncertainty Statement ** || ** Evaluation ** ||
 * Greater than 80% || Almost certainly, highly likely || 5 ||
 * 61-80% || Probable, likely, probably || 4 ||
 * etc || etc || etc ||
 * Figure 5-4 Sample table of Probability Evaluation Criteria **

The effect of a risk occurrence need to be specific to a project itself and project goals can help to refine the evaluation criteria. The following table shows a sample consequence table for cost, schedule and technical goals.
 * 5.3.2 Consequence **


 * ** Criterion ** || ** Cost ** || ** Schedule ** || ** Technical ** ||
 * ** Low ** || Less than 1% || Slip 1 week || Slight effect on performance ||
 * ** Moderate ** || Less than 5% || Slip 2 week || Moderate effect on performance ||
 * etc || etc || etc || etc ||
 * Figure 5-4 Sample table of Consequence Evaluation Criteria **

The time frame for action to prevent risk occurrence should be specific to a project itself. The following sample table shows the time frame:
 * 5.3.3 Time Frame **
 * ** Time Frame ** || ** Evaluation ** ||
 * 1 Month || Short ||
 * 2 Months || Medium ||
 * etc || etc ||
 * Figure 5-5 Time Frame Evaluation Criteria **

** 5.4 Establish the Risk Prioritization Scheme **
It provides focus for important risks and it uses nominal group technique and weighted multivoting in planning and improving process. It’s a prioritization scheme which allows a team to come to a consensus quickly on the relative importance of risk by combining individual priorities into team priorities. The summation of all rankings is the risk score where the lowest score is the most important risk. It is a consensus based prioritization scheme used to rate risks and team members rate the relative importance of risks. Each team member is given the equal number of tokens to distribute among the risks and tokens could be of any value.
 * 5.4.1 Nominal Group Technique **
 * 5.4.2 Weighted Multivoting **

** 5.5 Summary **
The process definition steps for analyzing risk are important since they provide clarity and help in utilizing risk analysis techniques among other risk process. The risk analysis process defines the activities and methods to evaluate risk and they can be used to group similar risks, determine risk drivers and the main source of risk. Use of risk analysis techniques and tools are also helpful in providing accurate evaluation of risk. Other tools such as automated analysis tools are also available such as multiattribute utility, multicriteria optimization, multicriteria partial ordering, etc which assist in evaluating risk.

** Chapter 6 Plan Risk **

 * Objective: ** Planning is an important factor especially when working with managing risk and developing risk management policy and procedures. Technical staff develops detailed action plans to resolve risk within the organization; the risk planning process defines the activities and methods to develop alternatives for risk resolution. The focus of this chapter is to determine when to execute the risk action plan properly.

** 6.1 Define the Risk Planning Process **
Risk planning process can be described in terms of the process goals where it has external and interview views. The external view consists of process controls, inputs, outputs and mechanisms. The internal view consists of process activities that transform inputs to outputs using the mechanisms. The following are the goals that can satisfy the risk planning process when followed appropriately:
 * 6.1.1 Process Goals **

1) Provide visibility for key events and conditions. 2) Reuse successful risk resolution strategies. 3) Optimize selection criteria. 4) Understand the next action for each high-severity risk. 5) Establish automatic triggering mechanisms. The risk planning process definition is covered in an IDEF0 diagram which is a standard process notation used to describe a reusable process component for predictable risk action planning. The block diagram shown below has the top level process by its controls, inputs, outputs and mechanism.
 * 6.1.2 Process Definition **



__ Process Controls __ --- Project resources, project requirements and the risk management plan control the risk planning process. __ Process Inputs __ --- The following are input to the risk planning process: 1) Risk List --- is a list containing the priority order of all identified risks. 2) Refined risk context --- consist of information surrounding the risk statement and it is accessed through the risk database. 3) Measures --- is a unit to determine the dimensions, quantity or capacity and they are usually input from the project tracking system. 4) Metrics --- They are guidelines that useful in planning and they are often input from the project tracking system. 5) Triggers --- is a device which activate, deactivate, or suspend a risk action plan and the can also be set by the project tracking system. __ Process outputs __ --- They consist of scenarios, a risk action plan and thresholds as shown in above block diagram.

1) Risk scenario --- is the projection of events and conditions that can lead to an unsatisfactory result where an event describes what must take place for the risk to occur. 2) Threshold --- is a value which defines the risk occurrence and predefined thresholds act as a warning level which indicates the need to execute the risk action plan. 3) The risk action plan --- it documents the selected approach, checks for resources and gain approval authority for risk resolution. __ Process Mechanisms __ --- Located at the bottom on the block diagram shown above and they can be methods, techniques, tools, etc to provide structure to the process activities.

1) Quantitative targets --- express the goals and objectives quantitatively. 2) Resolution strategies --- help to determine alternative ways to resolve a risk. 3) Selection criteria --- formulate guidelines to help decide on a course of action. 4) Risk database --- contains the risk action plan, associated scenarios and threshold values. These are the tasks necessary to transform a prioritized risk list into a plan for risk resolution. The following are the activities of this process:
 * 6.1.3 Process Activities **

1) Develop risk scenarios for high-severity risks. 2) Develop risk resolution alternatives. 3) Select the risk resolution approach. 4) Develop a risk action plan. 5) Establish thresholds for early warning. __ Develop Risk Scenarios for High-Severity Risks __ --- It is the project of events and conditions which can lead to risk occurrence. They are found on the Top-N Risk List and the following are three steps to develop a risk scenario: 1) Think about the risk as it had occurred. 2) State the risk scenario as if the risk had already happened. 3) List the events and conditions that would precede the risk occurrence. __ Develop Risk Resolution Alternatives __ --- These are set of options that can resolve risk if implemented where it uses acceptance, avoidance, protection, reduction, etc to develop alternatives for risk resolution and each strategy contain objectives, constraints and alternatives. __ Select the Risk Resolution Approach __ --- This approach focus on the best alternative for resolving risk. Several risk resolution strategies can be combined into one approach; for instance, to perform market research to obtain demographics, the risk can be transferred to a third party or in developing a new technology. __ Develop a Risk Action Plan __ ---This plan details the selected approach to risk resolution and it consists of the following elements: 1) Approval authority. 2) Responsible person. 3) Resources required. 4) Start date. 5) Activities. 6) Due date. 7) Actions taken. 8) Results achieved. __ Establish Thresholds for Early Warning __ --- Quantitative targets provide best objectives that can be determined by metrics. A minimum performance value defines the warning level, or threshold and every measurement should have a value that defines the quantitative goal. A threshold is a warning level which is associated with a quantitative target and it establish the minimum acceptable value with respect to the quantitative target.

** 6.2 Define Risk Resolution Strategies **
There are several strategies utilized for risk resolution such as risk acceptance, risk avoidance, risk protection, risk reduction, risk research, risk reserves and risk transfer. 1) Cost risk 2) Schedule risk 3) Performance risk 4) Operability risk
 * 6.2.1 Risk Acceptance ** --- is a strategy for risk resolution of choosing to live with the risk consequence and it is normally selected if the loss is not significant.
 * 6.2.2 Risk Avoidance ** --- is a strategy for risk resolution to eliminate the risk completely. Avoidance is a strategy to use when nothing can be done to change the situation. To determine if the situation is lose-lose when reviewing the risk, several factors can be considered:
 * 6.2.3 Risk Protection ** --- is a strategy to employ redundancy to reduce the ability or consequence of a risk. If some part of the system for instance processor doesn’t function well, it can be replaced and switched by Tandem to another processor.
 * 6.2.4 Risk Reduction ** --- is a strategy to decrease risk through prevention and it is reduced by decreasing either the probability of the risk occurrence or the consequence when the risk is realized. It is utilized when risk leverage exists and one way to use this is through peer a review which reduces the consequences of detects.
 * 6.2.5 Risk Research ** --- is a strategy to obtain more information through investigation and one way to use this is to do trade studies which helps in making better decisions when buying information.
 * 6.2.6 Risk Reserves ** --- is a strategy to use funds and it is often utilized when uncertainty exists in cost or time and one way to use this is by identifying the high risk systems and by specifying where the risk is in the system, risk reserves can then be utilized.
 * 6.2.7 Risk Transfer ** --- is a strategy to shift the risk to another group or organization and it is utilized when another group has control and one example of this risk is outsourcing where risk of high cost software is transferred to a group with more competitive wages.

** 6.3 Define Selection Criteria **
Selection criteria determine the best alternative way to resolve a risk and defined selection criteria provides a common basis to understand the characteristics of a good alternative. The following are two policies that are utilized as selection criteria:
 * 6.3.1 Risk Leverage ** --- is a measure of the relative cost of performing various candidate risk resolution activities. It is a rule for risk resolution which reduces risk by decreasing the risk exposure (RE). Risk resolution cost is the cost of implementing the risk action plan. The following equation is for risk leverage:

Risk leverage = __RE__ __(before)__ __ – RE __ __(after)__ Risk resolution cost

Risk leverage at project completion is shown below:

Risk leverage = __(100 percent x cost overrun) – (25 percent x cost overrun)__ Cost of claim
 * 6.3.2 Risk Diversification ** --- is a rule for risk resolution which reduces risk by distributing and it advises not to rely heavily on one customer, vendor, method or tool to fulfill project needs.

** 6.4 Develop the Risk Action Plan Template **
It’s a template which is used to capture the risk resolution strategy in a standard format. The template contains the following fields. 1) Risk resolution strategy. 2) Objectives. 3) Approach. 4) Approval authority and etc.

** 6.5 Summary **
The process definition steps are important for risk resolution planning and these steps define the planning process, resolution strategies, define selection criteria and risk action plan template. Other strategies such as acceptance, avoidance protection, reserves and transfer are utilized in planning process and each strategy depend on the situation and significance of the risk involved. Scenario risk is helpful since they monitor risk; the events and conditions of the risk scenario and serve as a checklist to determine if the progress is being made; it then shows the chances of risk occurrence decreased.


 * Objective: ** Risk tracking defines the activities and methods to monitor risk status. In this chapter techniques and tools are used to compare risk status with planned thresholds in order to determine when to trigger risk action plan execution.

** 7.1 Define the Risk Tracking Process **
The risk tracking process also have external and internal view where external view consist of process controls, inputs, outputs and mechanisms and the internal view specifies the process activities that transform inputs to outputs using the mechanisms. The following figure 7-1 shows the risk tracking process definition:

The following are the goals that can be utilized in risk tracking progress:
 * 7.1.1 Process Goals **

1) Monitor the events and conditions of risk scenarios. 2) Track risk indicators for early warning. 3) Provide notification for triggering mechanisms. 4) Capture results of risk resolution efforts. 5) Report risk measures and metrics regularly. 6) Provide visibility into risk status. The diagram in figure 7-1 describes the top-level process by its controls, inputs, outputs and mechanism. __ Process Controls __ --- include project resources, project requirements and the risk management plan. __ Process Inputs __ --- Scenarios, thresholds and risk status are input to the tracking process where scenario monitor the events and conditions that can lead to an unsatisfactory result. Thresholds define the inception of risk occurrence and act as a warning to indicate the need to send notification to execute the plan. Risk status captures the results of implementing the risk action plan in the risk database __ Process Outputs __ --- include measures, metrics and triggers as shown in figure 7-1 above where measures determine the dimensions; metrics are a composite measure that serves as a guideline and triggers are devices to activate or deactivate. __ Process Mechanisms __ --- These can be methods, techniques, or tools and they provide structure to the process activities. Moreover, they help to monitor risk status over time. The following activities of the risk tracking process are as follows: 1) Monitor risk scenario 2) Compare thresholds to status 3) Provide notification for triggers. 4) Report risk measures and metrics. __ Monitor Risk Scenarios __ --- Risk scenarios are like threads that string a risk to a problem where events and conditions in it are the checkpoints along the road to a problem. These scenarios are monitored to determine if the probability of risk occurrence is increasing. __ Compare Thresholds to Status __ --- A trigger is a device to control the implementation of a risk action plan and it can be set through the monitoring of status indicators, planned thresholds, quantitative targets and the project schedule. For thresholds that change at discrete points throughout the life cycle, triggers can be utilized to put risk resolution activity on hold. __ Provide Notification for Triggers __ --- When a trigger is set, notification is sent to the appropriate personnel through communication channels. __ Report Risk Measures and Metrics __ ---A measure is a standard unit of measurement to determine dimensions, quantity, etc. A metric uses historical measure to provide guidelines that can help manage the future and it is determined from a composite of measurement data taken overtime.
 * 7.1.2 Process Definition **
 * 7.1.3 Process Activities **

** 7.2 Define Risk Tracking Techniques **
These techniques are often driven by the availability of tools where project’s level of automation depends on the tool set used. Tracking a minimum set of programmatic and technical performance measures is essential to monitoring risk. Technical performance measures describe the quantitative targets for system performance. The following are three steps to monitor risk using static measures:

1) Define warning levels of unacceptable status as thresholds. 2) Monitor status indicators in terms of measures and metrics. 3) Regulate the risk action plan execution using triggers. It is a visualization of key project indicators that serves as the status display for management and technical metrics. A project is on course when the gauges of the control panel are kept within accepted ranges. A gauge is a graphic display of a status indicator, a quantitative target and a threshold warning level. Software measurement determines how well project process and product goals are being done and it is essential to know how far a project is being completed. The following are three guidebooks on proved software measurement techniques:
 * 7.2.1 Project Control Panel **
 * 7.2.2 Software Measures **

1) __ Metrics Guidebook for Integrated Systems and Product Development __ --- describes a metrics framework for functions commonly represented on product development teams systems, test, software, hardware and manufacturing. The guidebook covers the measurement process and how to select correct metrics to manage by the data.

2) __ Practical Software Measurement __ --- is a guidebook for project managers and it uses measurement indicators to deal with risks that cannot be measured directly. Using multiple indicators to analyze a software issue is encouraged.

3) __ Software Measures and the Capability Maturity Model __ --- is applied to the goals of each CMM key process area where indicators are grouped into categories that provide visibility for status and insight into process effectiveness.

** 7.3 Define Risk Measures and Metrics **
The following figure 7-2 shows measures that can be used to determine risk management metrics:

** 7.4 Define Triggering Devices **
Trigger provides three basic control functions and to activate triggers which provide a wake-up call for a risk action plan. To deactivate, triggers can be used to put the execution of risk action plans on hold. There are four types of triggers which provide notification of unacceptable risk level as shown below:

1) Periodic events --- is a notification for activities and project schedule events such as project reviews, technical design reviews and monthly management reports are the basis for periodic event triggers. 2) Elapsed time --- notification for dates for example calendar with thirty days from today or end of the quarter is the basis for elapsed time triggers. 3) Relative variance --- notification outside a range of acceptable values where relative variance is the difference between a predetermined quantitative target and the actual value. A deviation of a specified percentage either above or below a planned quantitative target will set a trigger. 4) Threshold value --- notification for values that cross a predetermined threshold where a comparison of a status indicator to a threshold values is the basis for threshold value triggers. A trigger is set when a status indicator crosses a threshold value.

** 7.5 Summary **
Risk tracking defines the activities and methods to monitor risk status such as monitor risk scenarios, comparing thresholds to status, providing notification for triggers and reporting risk measures and metrics. Static measures can indicate dynamic risks where a overtime status is tracked to determine trends and when measurement fall below acceptable values, action plans get triggered. Techniques and tools are utilized to compare risk status with planned thresholds in order to determine when to trigger action plan execution. A project control panel is a tool which displays all the controls and key project indicators. A project is on course when the gauges of the control panel are kept within accepted ranges.

** Chapter 8 Resolve Risk **

 * Objective: ** Risk resolution process defines the activities and methods to reduce risk at an acceptable level and the process goals are utilized in satisfying the risk resolution process.

** 8.1 Define the Risk Resolution Process **


Risk resolution process has external and internal perspective where the external view consist of process controls, inputs, outputs and mechanisms and internal view specifies the process activities that transform inputs to outputs using the mechanisms. The following figure 8-1 shows risk resolution process definition:

The risk resolution process has the following goals shown below: 1) Assign responsibility and authority to the lowest possible level. 2) Follow a documented risk action plan. 3) Report results of risk resolution efforts. 4) Provide for risk aware decision making. 5) Determine the cost-effectiveness of risk management. 6) Is prepared to adapt to changing circumstances. 7) Take corrective actions within the team. 8) Improve communication within the team. 9) Systematically control software risk. The risk resolution process definition is shown above in figure 8-1 which has a top-level process by its controls, inputs, outputs, and mechanisms. __ Process Controls __ --- consist of project resources, project requirements and the risk management plan. __ Process Inputs __ --- The risk action plan is input to the risk resolution process and it contains the objectives, constraints, and strategy for risk resolution and approval authority.  __ Process Outputs __ --- consist of risk status which provides the progress made against a risk action plan. Acceptable risk means when one has to live with the risk consequence. Rework is the cost of not doing something right the first time; corrective action is an activity required to solve a problem and problem prevention occurs when one avoid problems and therefore eliminate problem detection cost, rework cost, and opportunity cost. __ Process Mechanism __ --- Risk resolution techniques are ways to help with the details of risk resolution. Risk resolution tools use computers to automate techniques for risk resolution such as prototyping and simulation. The risk database contains the name of the responsible person and it also contains a completion date for significant results. The activities for the risk resolution process are the tasks necessary to execute the risk action plan to reduce risk to an acceptable level: The following are four steps that can be followed in any order for process activities: 1) Respond to notification of triggering event. 2) Execute the risk action plan. 3) Report progress against the plan. 4) Correct for deviation from the plan. __ Respond to notification of triggering event __ --- Triggers provide notification to appropriate personnel where an individual with authority must respond to the triggering event. Triggers should provide a reasonable time for response and should cause a crisis situation. Factors such as availability and skill level help to determine who should be responsible for executing the risk action plan. __ Execute the Risk Action Plan __ --- Written risk action should be followed to resolve risk and if the plan is not documented, chances are this is a miscommunication. Utilizing the engineering model of requirements, design, and testing should be helpful in executing the project. The following are few principles to follow that can help in resolving any risk: 1) Think about working smarter. 2) Challenge yourself to find a better way. 3) Exploit opportunities. 4) Be prepared to adapt when circumstance changes. 5) Use common sense. __ Report Progress Against the Plan __ --- Reporting the results of risk resolution is very important and reporting just status is not sufficient to manage risk. The team must review risk status, measures and metrics regularly to provide for risk aware decision making. __ Correct for Deviation from the Plan __ --- this is alternative approach and using the corrective action procedures are recommended.
 * 8.1.1 Process Goals **
 * 8.1.2 Process Definition **
 * 8.1.3 Process Activities **

** 8.2 Define Risk Resolution Techniques **
It is important to understand the two fundamental components of risk resolution as covered below: __ 8.2.1 Creativity __ ---New ideas may be required in implementing the risk action plan and the creative process helps in generating new ideas. An innovation style is an approach to the creative process and there are four innovation styles that can help in using the creative process efficiently: 1) __ Envisioning __ --- This style focuses on the result and it provide teams with direction and inspiration. 2) __ Experimenting __ ---This style uses the scientific method of trial and error to obtain repeatable and practical results. 3) __ Exploring __ --- This style adds a sense of adventure by its unpredictable nature by using analogies and metaphors to generate new ideas. It provides a team with the potential for breakthroughs by approaching problems with different angles. 4) __ Modifying __ --- This style moves forward one step at a time by building on what is accurate and proven through methods and experience. __ 8.2.2 Collaboration __ --- it is where two or more people with complementary skills interact to create a shared understanding that’s previously not obtained or acquired. Risks are rarely resolved in isolation and it is the lack of understanding among people which causes risk. As working with others, there are several problems that can come up in communication: 1) Sending the wrong message. 2) Receiving the wrong message. 3) A break in the communication link.

** 8.3 Define Risk Management Return on Investment **
Risk management is the savings for all managed risks divided by the total cost of risk management activities. Cost of risk management is the total investment in resources where time spent in risk management meetings, the cost of reporting risk information and the staff to develop a risk action plan. There are two types of savings: 1) __ Cost avoidance __ --- is the difference between possible cost without risk resolution and the actual cost with risk resolution. 2) __ Cost reduction __ --- is the difference between planned and actual costs and through cost reduction, it is possible to underrun the budget.

** 8.4 Develop a Corrective Action Procedure **
This procedure helps to correct for variations in the process or the product. The risk action plan is an intermediate product that may require corrective action in terms of modifying an approach that not produced satisfactory results. The following are four steps in corrective action procedure: 1) Identify the Problem. 2) Assess the problem 3) Plan action 4) Monitor progress

** 8.5 Summary **
Risk resolution process defines the activities and methods to reduce risk at an acceptable level and the goals are utilized in resolving risks appropriately. Team communication is another important aspect in resolving risks where team communication can be improved by repeating back the information received and the time spent in clarifying questions and documents will be small compared to the work that might have caused more problems. When there is sufficient progress in risk resolution, project status indicators will improve and within acceptable ranges they will trigger the suspension of risk resolution activity.