Project+III

=toc= =**SSE 674 Software Risk Management**=

Project 3: Part IV: RISK MANAGEMENT IMPLEMENTATION Reference: __Managing Risk (methods for software systems Development)__ by Elaine M. Hall


 * Overview:** Planning for risk management is an important task for the organization to ensure the project risks are handled appropriately and therefore the main focus of this topic is to provide an effective approach for planning and performing risk management on a project.

=**Chapter 14 Establish the Initiative**= =**14.1 Review Risk Management Requirements**= Project requirements are a combination of contractual, organizational and derived requirements where contractual requirements for risk management are often contained in a statement of work which specifies planning risk management activities and implementing risk management on a project. Organizational standards for risk management start with a policy that sets expectations for project behavior; derived requirements for risk management can originate from the marketplace, competitive bids and the use of new technology or system complexity.
 * Objective:** The purpose of establishing a risk management initiative is to provide the context for performing risk management which is integrated within the project and it involves reviewing requirements from the customer and organization. The project manager is responsible for allocating resources for the risk management initiative and can assist the project participants in their involvement for risk management activities. This chapter contains a checklist of steps to establish risk management on the project.

A statement of work for a project contains contractual requirements for risk management and the vocabulary which describes risk management is often different from the organizational standard terminology. Contractors and customers use different words to describe similar concepts and therefore it is best to use consistent terminology whenever possible. The following figure 14-1 shows the table that can be utilized in translating customer requirements:
 * 14.1.1 Review Contractual Requirements**


 * **Contractor** || **Customer** ||
 * risk management initiative || risk management program ||
 * risk assessment || risk analysis ||
 * probability || likelihood of occurrence ||
 * consequence || impact of risk ||
 * risk resolution || risk reduction ||
 * risk control || risk management ||
 * Figure 14-1 Risk Management Terminology Translation **

The following specification from a statement of work outlines the project management plan and the risk management program required by the contract:

1) __Project management review__: At each review, the contractor shall report progress and work status to the customer and shall address risk management activities. 2) __Risk management plan__: The contractor shall indicate plans for engineering specialties such as, risk management. 3) __Risk management metrics__: The contractor shall describe the methods to be employed for software engineering planning which include the use of software management metrics for risk management. 4) __Risk management status__: The contractor shall conduct a general session to report progress and work status on all active task orders to the customer and shall address risk management activities.
 * Project management plan** --- Planning activities should include risk management practice and mechanisms for controlling resources and schedule.

1) __Risk analysis__: This analysis shall include identification and assessment of risk; the likelihood of occurrence, evaluation of the impact of risk on cost, schedule and technical performance; and the identification of alternatives to avoid or minimize risk. 2) __Risk reduction__: This activity shall involve the selection of risk reduction alternatives, definition of courses of action to implement risk reduction alternatives, commitment of staff, and report results of the risk management program to the customer. 3) __Risk management__: This activity shall establish a procedure to monitor progress of risk management activities and report results of the risk management program to the customer. 4) __Risk management progress__: The contractor document risk management activities and report progress to the customer in the monthly progress reports.
 * Risk management program** --- The contractor shall plan and implement a risk management program that includes a continuing analysis of the risks associated with the cost, schedule, and technical parameters and describes the reduction of those risks to an acceptable level through effective management. The contractor shall address risk analysis, risk reduction and risk management.

Organizational standard operating procedure need to contain requirements for risk management. The following is an example of a standard operating procedure for risk management that can serve as an organizational standard: The purpose of risk management is to assess and control risks. Risk management involves identifying potential problems throughout the project. Identified risks are analyzed to determine their probability and consequence. Risk resolution plans are developed to resolve risk. Risk management involves performing the tasks necessary to identify, analyze, plan, track and resolve risks using a defined risk management process. The risk management process may be the part of the project’s defined management or engineering process. 1) Goal 1: A risk management initiative is planned and implemented throughout the project. 2) Goal 2: Risks to the project are assessed and controlled according to a documented risk management process throughout the life cycle. 3) Goal 3: Risk management activities are documented, reviewed and reported. The project follows a written organizational policy for planning and implementing a risk management initiative which states: 1) The risk management plan is peer reviewed in order to promote commitment and understanding. 2) Risk management activities involve the project team, customer, end user and suppliers. 3) Risk management activities are reported and tracked. 4) A risk assessment is performed early in the project life cycle using a defined process. 5) Risk identification activities focus on the identification of risks, not placement of blame. 6) The results of risk identification activities are not used by management to evaluate the performance of individuals. 7) Each project routinely assesses and controls risk as part of project management tasks.
 * 14.1.2 Review Organizational Standards**

=**14.2 Plan Risk Management Activities**= Risk management activities are planned after risk management requirements are organized; specific project requirements help to define the tasks to plan and implement risk management. The activities consist of project attributes of size, budget, complexity and it is adjusted to fit project constraints. The figure 14-2 below shows a sample project planning process where project elements budget, schedule, staff and plan are the major tasks that transform requirements into cost estimates, a project schedule and project plans.



=**14.3 Budget Risk Management Activities**= Risk is a potential loss and the only way to minimize or eliminate risk is to utilize risk management. Budgeting for risk management activities is the initial investment required for future payoff. One should add a line item for each risk management activity on the project schedule and utilize the assessment method to cost the baseline risk assessment for the project.

=**14.4 Schedule Risk Management Activities**= The project master schedule consist of risk management activities such as, developing the risk management plan, training the people, baselining the risk and verifying risk management practices. It is important to allocate more time on the schedule for a high risk area to ensure an appropriate delivery time; if budget is inflexible, then scheduling a lower level of effort over an extended period can provide the time needed to handle a high risk area.

=**14.5 Staff Risk Management Activities**= The project manager is responsible for software risk, but most of it should be delegated by assuring people take responsibility for risk management of their project. One way to coordinate risk management activities is to create a special assignment to the role of risk manager. This role is often filled by a senior technical person but is not required to be a full time position.

=**14.6 Coordinate Risk Management Training**= Coordinating risk management training can be beneficial for project staff to develop their ability to manage risk. With training, individuals will be prepared to perform risk management activities and training should be specific to the project procedures that are used to implement the risk management plan. Just-enough is a recommended approach for training material that builds on current knowledge and with this approach; people will not feel over-whelmed by the amount of information. Just-in-time is another important concept which trains the project team so they can apply the concepts immediately. There should also be time for answer-questions that arise when people practice new methods.

=**14.7 Summary**= A checklist can facilitate in respond to project requirements for risk management which consist of risk management activities such as reviewing, planning, budgeting, scheduling, staffing and coordinating risk management training. Risk management is a derived requirement for all projects due to the increasing rate of change in the software industry. Risk is a potential loss and the only way to turn that around is through risk management. Budgeting for risk management activities is the initial investment required for future payoff. It is important to add a line item for risk management activity on the project master schedule. The recommended approach for risk management training is to build on the team’s current knowledge and apply the concepts appropriately.

=**Chapter 15 Develop the Plan**=


 * Objective:** A risk management plan uses the documented goals, strategy, and methods for performing risk management on a project. The purpose of this plan is to determine the approach for performing risk management cost effectively on the project and the plan should be long enough to convey the information to project participants. For a small project, the risk management plan might be only 5 pages and for a large project, the plan can be 20 pages long. The plan can also be a separate document or part of a larger plan. Feedback from the reviewers can assist in developing a better plan; the objective of this chapter is to provide a good understanding of the contents of a comprehensive risk management plan.

=**15.1 Outline the Risk Management Plan**= An outline for a risk management plan contained within a project plan describes the budget, schedule and staffing aspects of project planning for risk management requirements. The following figure 15-1 below shows the section 1.0, Goals, which explains why the project needs risk management and what can project gain from the use of risk management and how the risk management plan responds to risk management requirements. Section 2.0, Strategy contains guiding principles of risk management as well as how people will organize to manage risk. Section 3.0, Process, describes a better version of the standard risk management process. Section 4.0, Verification, shares the evaluation criteria for practice compliance and section 5.0, Mechanisms, describes examples of the methods that project team can in risk management process.


 * **1.0** || **GOALS** ||
 * 1.1 || Purpose ||
 * 1.2 || Objectives ||
 * 1.3 || Scope ||
 * **2.0** || **STRATEGY** ||
 * 2.1 || Policy ||
 * 2.2 || Approach ||
 * 2.3 || Project Roles ||
 * **3.0** || **Process** ||
 * 3.1 || Identify Risk ||
 * 3.2 || Analyze Risk ||
 * 3.3 || Plan Risk ||
 * 3.4 || Track Risk ||
 * 3.5 || Resolve Risk ||
 * **4.0** || **Verification** ||
 * 4.1 || Review Criteria ||
 * 4.2 || Audit Procedure ||
 * 4.3 || Audit Report ||
 * **5.0** || **Mechanisms** ||
 * 5.1 || Risk Checklist ||
 * 5.2 || Risk Management Form ||
 * 5.3 || Risk Database Structure ||
 * Figure 15-1 Risk Management Plan Outline **

=**15.2 Define Risk Management Goals**=

Goals should provide direction and focus for the project team members where purpose describes what to accomplish by following the risk management results. The statement of purpose provides the motivation and expectation for risk management results; objectives are specific action that help achieve a goal.

=**15.3 Define the Risk Management Strategy**=

The risk management strategy is an approach in which people implement the plan and it should comply with a written organizational risk management policy. The recommended risk management approach is proactive, integrated, systematic and disciplined. __Proactive risk management__ --- this approach is for action where a plan should describe this approach for assessing and controlling risks. The project plan can be proactive by establishing a system of rewards for early identification of risks. __Integrated risk management__ --- consist of incorporating awareness of risk into routine work activities and one way to integrate risk management into regular activities is to centralize a database for recording issues and actions associated with risk. __Systematic risk management__ --- consist of establishing a set of checks and balances, such as procedures for verification and improvement which facilitate the process. Mechanisms that help address issues systematically are the risk checklist, risk management form, and risk database. __Disciplined risk management__ --- this process grows in capability through knowledge and experience in following six basic disciplines: Envision Plan, Work, Measure, Improve and Discover. There’s a development path in managing risk and the proficiency is developed through the study and practice of risk management principles, methods and tools. Individual inherit risk by assuming one of the project roles and each role has both internal and external interfaces where known risk must be addressed. The following figure 15-2 shows how a project role determines in delegating responsibility and authority for managing risk:


 * **Project Roles** || **Responsibilities** || **Interfaces** ||
 * Project manager || Provide project leadership, maintain strategic plan || Sponsors, contractors, managers, system engineering ||
 * Risk manager || Facilitate risk management, maintain risk database || Project manager, sponsor, project team, contractors, customers ||
 * Software engineering || Perform software requirements analysis, design, code, peer review || System engineering, quality manager, test engineering ||
 * Hardware engineering || Oversee hardware cost estimation, procurement, integration || System engineering, quality manager, test engineering ||
 * Quality manager || Enforce standards and procedures, conduct independent review || Project manager, project team ||
 * Figure 15-2 A sample Project Organization Chart **

=**15.4 Define the Risk Management Process**= The risk management process is a structured way to manage risks which include the activities and mechanisms used to transform project knowledge into decision making information. The risk management plan can point to a documented risk management process and the separation of process and enables the flexibility for change.

=**15.5 Define Risk Management Verification**= Risk management verification is the method to ensure that project practices adhere to the documented risk management plan. The purpose of review criteria is to understand the activities, agents and artifacts of the risk management plan to prepare for a compliance audit. An audit procedure verifies if planned activities are conducted and whether there is adherence to the risk management plan. The audit report is generated to summarize implementation performance and it details any discrepancies against the plan.

=**15.6 Define Risk Management Mechanisms**= The risk management mechanisms are the techniques and tools used by a process to transform inputs to outputs and they can be included in the risk management plan to help people visualize the organization of risk information. The following are three important mechanisms of risk management form: 1) __Risk checklist__ --- organizes areas of concern into categories to understand the nature of the risk. It helps to identify risks in a given area where items on the critical path create a checklist of schedule risk that need to be managed. 2) __Risk management form__ --- The risk management form documents risk information essential for managing risk where one approach is to record risk information systematically and track it to closure. 3) __Risk database structure__ --- The risk database structure shows the organization of identified risks and associated information where it organizes risk information to generate report and track status.

=**15.7 Summary**= The contents of a comprehensive risk management plan consist of goals, strategy, process, verification and mechanisms. By defining project roles, one can delegate responsibility for risk management and individual can be held accountable for managing risk. Risk is a function of a project role, and individual inherit risk when they are assigned a project role. The effective approach for risk management plan is a proactive which favor change, integrated approach which brings awareness of risk, systematic establishes a set of checks and balances, and disciplined risk management brings capability through knowledge and experience.

=**Chapter 16 Tailor the Standard Process**=


 * Objective:** Standard processes are defined and utilized by projects with minor modifications where these modifications are considered tailoring options. Tailoring provides the flexibility required to modify a standard process to adjust for differences among projects. Together, they reduce the risk of developing software that satisfies different requirements. The standard process provides a common understanding of processes, roles and responsibilities. The purpose of tailoring the standard process is to define the risk management process for a specific project. The focus of this chapter is to provide suggestions for tailoring the standard process to custom-fit a particular project.

=**16.1 Review the Standard Process**=

A defined software process provide a minimum standard process and tailoring suggestions where a minimum standard risk management process provides a common set of metrics that enable project comparisons. At the organization level, project comparisons provide visibility into progress so that intelligent decisions can be made such as, allocation of staff resources among projects. The following risk management process outputs should be standardized: 1) __Risk statement__ --- The standardization of how to communicate a risk can provide understanding between the project team and the organization. 2) __Risk list__ --- The format of a risk list shows the key issues facing a project which can help management see common themes to address on projects. 3) __Risk action plan__ --- The attribute of an action plan should be consistent to promote completeness and reuse of successful plan. 4) __Risk measures__ --- The standard definitions of risk measures enable organizational risk metrics and consistent communication to senior management. 5) __Risk database__ --- The project risk database should easily merge into an organizational database to retain lessons learned.

=**16.2 Examine Tailoring Options**=

Once the minimum standard part of the process cannot be compromised, tailoring option then needs to be examined where recommendations for tailoring are often defined in the standard process. The following table provides several tailoring suggestions for each process element:

=**16.3 List Unique Project Factors**= Customizing the risk management process can be done by an understanding of the unique aspects of the project. A high risk projects need a more rigorous process and the following factors are utilized in differentiating risk management on projects: 1) __Size__ --- If there are less than ten individual working on a project, then the risk is low since the size is small. 2) __Budget__ ---Risk is high if the budget is tight or the contract is on a fixed budget. 3) __Structure__ --- Risk increases as a function of the number of interfaces within the project organization structure; for instance, the risk higher if the project has no organization chart that defines the channels of communication. 4) __Life cycle model__ ---The Grand Design (a do-each-step-once strategy) project has a high risk since requirements are not written well enough to deliver all capabilities at once. If the model is Incremental (a strategy that adds functionality to the existing system), the risk is high since requirements may not be clear. If the model is Evolutionary (a strategy that iteratively refines the total system), the risk is moderate if user prefers all capabilities at the first delivery. 5) __Software development process__ --- If project doesn’t follow this process or is a new process, then the risk high. 6) __Level of automation__ --- The risk is high if the development tool set is new or not integrated throughout the life cycle and a lack of automation on large systems is also high risk. =**16.4 Recommend Process Changes**= Project personnel can recommend process changes which can optimize their risk management and it also provide the following enhancements: 1__) A better process__ ---This process is preferred since it is more suitable to the project needs; for instance, a method may be preferred because it is familiar and will not require time for training. 2) __A faster process__ --- This process takes less time to implement such as, an automated tool might speed up the process. 3) __A cheaper process__ ---This process is reduced in cost and when a process is economical, the return increases. =**16.5 Document Standard Process Deviations**= A waiver for deviations must be obtained from the standard risk management process; a waiver form is a mechanism to help projects customize standard processes where time spent in negotiation and compromise up front is better than implementing a time consuming process. Approved waiver forms facilitate in promoting support and commitment from the organization management; for instance highlighted changes from the standard process on a waiver form can assist these activities. =**16.6 Summary**= Tailoring provides the flexibility required to modify a standard process to adjust for differences among projects. Together, they reduce the risk of developing software that satisfies different requirements. The steps to tailor the standard process include reviewing the standard process, examining tailoring options, listing unique project factors, recommending process changes and documenting standard process deviation. The activities performed within each process can vary between projects if standardization occurs at the process output. The risk management process which include risk statement, risk list, risk action plan, risk measures and risk database outputs should be standardized. A waiver for deviations can facilitate in promoting support and commitment from the organization management.
 * **Process Element** || **Tailoring Options** ||
 * Identify risk || When to use the risk assessment method? When to use the risk appraisal survey? How often the project team will meet to identify risk? Management form Addition of fields in the risk database to support risk identification. Implementation of the risk database etc. ||
 * Analyze risk || How to delegate the responsibility for identified risk? Who has the authority for identified risk? How to prioritize the risks? Modification of the analysis section of the risk management form. Addition of fields in the risk database to support risk analysis. etc. ||
 * Plan risk || How to generate risk action plans? Modification of the planning section of the risk management form. Addition of fields in the risk database to support action planning. etc. ||
 * Track risk || How to track risk action plans? Modification of the tracking section of the risk management form. Addition of fields in the risk database to support risk tracking. How to collect risk measures for risk tracking? etc. ||
 * Resolve risk || How to implement risk action plans? Additional techniques and tools for risk resolution. Modification of the resolution section of the risk management form. ||

=**Chapter 17 Assess Risk**=

=**17.1 Conduct a Risk Assessment**=
 * Objective:** Risk assessment is a method which informs individuals about the risk and individuals can then take appropriate decisions. The focus of this chapter is to identify and analyze the possibilities in the project plan and the remaining work to ensure unknown risks are discovered and how to use team environment appropriately in assessing risk.

The project manager is responsible for delegating the task of conducting a risk assessment which provides a baseline of assessed risks. A risk baseline should be determined for a project as early as possible since risk is associated with the work. Risk assessment involves all levels of the project and it facilitate in training the risk assessment methods that will be used in the project. The following are three main objectives of a risk assessment: 1) __Identify and assess risks__ --- Individual can identify and assess risk using different risk assessment methods where project requirements may call for a less formal or analytical approach. 2) __Train methods__ --- Individual can use the techniques that they learned during risk assessment training throughout the project. 3) __Provide a baseline__ --- There is a risk aware project team and a risk baseline for continues risk management is the result of a risk assessment. There are many ways to assess risk such as, through phase readiness review where the team identifies the top five risks on a risk appraisal form. The risk appraisal gathers individual perspective without requiring collaboration. Team building sessions can identify the top three risks to their success and this exercise is a way to experience collaboration on risks and it provides focus for team goals. The technical proposal can describe technical risk using a risk management for which organizes risk information to facilitate in determining the risk action plan. The project start up method of formal risk assessment gathers information by interviewing people in peer groups and this uses a risk taxonomy checklist.


 * 17.1.1 Activities of a Formal Risk Assessment**

The activities of an interview based risk assessment changes project knowledge into risk assessment results such as assessed risks, lessons learned and a risk database. The following formal risk assessment contains five important activities: 1) __Train team__ --- consist of identifying and training assessment team, reviewing project profile, selecting interview participants, preparing risk assessment schedule and coordinating meeting logistics. 2) __Identify risk__ --- consist of interviewing participants, recording perceived risks, clarifying risk statements and observing record results. 3) __Analyze risk__ --- consist of evaluating identified risks and categorizing the risks 4) __Abstract findings__ --- consist of sorting risks in risk database and preparing findings of the risk. 5) __Report results__ --- consist of debriefing project manager, project team and it assist in evaluating risk assessment.


 * 17.1.2 Cost of a Formal Risk Assessment**

The number of individuals involved affects the cost of a formal risk assessment. Three individuals are recommended on the risk assessment team and a minimum of three peer group interview session where the first interview session should be with project managers, second for technical leaders and the third for engineering staff. For project teams over 50 individuals, require more interview sessions to maintain a minimum of one-third team involvement. Team representatives should bring input from the other interview sessions. The formal risk assessment is more expensive than other assessment methods because it provides the most time for communication between project members.

=**17.2 Develop a Candidate Risk List**=

A list of risks can be developed by reviewing a risk checklist, work breakdown structure, or a previously developed a successful risk list. These lists facilitate in identifying set of risks from known risk areas. The focus is on identification of risk and source of risk in both management and technical areas.


 * 17.2.1 List Known Risks**

Communication facilitates in understanding known risks in the following ways: 1) Separate individual from issues 2) Report risks 3) Report problems
 * 17.2.2 Discover Unknown Risks**

Unknown risks are those which exist without any awareness, but communication can still assist in discovering unknown risk in the following ways: 1) __Share knowledge__ --- A team can discover risks when individuals contribute appropriately by putting pieces of a puzzle they could not resolve by working alone. 2) __Recognize importance__ --- Discovering the magnitude of the risk helps in prioritizing it correctly and when time elapse, it can facilitate in discovering risk importance if and only if individuals pay attention. 3) __Cumulate indicators__ --- A status indicator that is 10 percent off target is usually considered as low risk and the summation of a small variance in several indicators can add up to a critical risk.

=**17.3 Define Risk Attributes**=

For each issues specified in the candidate risk list, it should qualify the issue as a risk and if the probability of it is zero or one, then the issue is not considered a risk. Moreover, if there is no consequence of the risk’s occurring in the future, the issue is not a risk.


 * 17.3.1 Bound the Primary Attributes**

Words or numbers can be used to bound the primary risk attribute of probability. The range can be utilized to provide room for error (e.g., 40 to 60 percent). To bound the primary risk attribute to consequence, individual can list the effect on specific objectives; for instance, if unsecured email attachment is opened at workplace, malware can spread to the computer and effect the whole email system. The table 17-1 provides the mapping from subjective phrases to quantitative numbers as shown below:


 * **Five-Point Score** || **Perceived Likelihood** || **Numerical Percentage** ||
 * 1 || Almost no chance || Less than 20 percent ||
 * 2 || Little chance || Less than 40 percent ||
 * 3 || Improbable || Less than 60 percent ||
 * 4 || Probably || Less than 80 percent ||
 * 5 || Almost certainly || Less than 100 percent ||
 * Figure 17-1 Risk Probability Map **

Risk drivers are the variable that causes either probability or consequence to increase significantly for instance, constraints, resources, technology and tools. The process and environment can cause risk to change anytime; for instance SEI level 3 processes can be reduced to an ad hoc SEI level 1 process over time due to the risk driver of schedule. =**17.4 Document Identified Risk**= A risk management form for document the risk provides a familiar mechanism that structures how individuals think about risk.
 * 17.3.2 Categorize the Risk**

=**17.5 Communicate Identified Risk**= Communicating identified risk to appropriate project personnel can increase awareness of project issues; for instance, individuals can communicate identified risk by submitting the risk management form. Logging risks in a risk database can facilitate communication of identified risks.

=**17.6 Estimate and Evaluate Risk**= Once the risk is clearly communicated, an estimate of risk exposure, the product of risk probability and consequence can be established. Risk severity can be established by estimating risk exposure and time frame for action. Risk severity determines the relative risk priority by mapping categories of risk exposure against the time frame for action.

=**17.7 Prioritize Risk**= Prioritizing risk list is unique to the role on a specific project and prioritizing risk provides a focus for what is crucial. The challenges of managing software development can be understood by reviewing the current list of prioritized risks reported by the software community. The government role is that of a consumer, while industry is the primary developer. By understanding the risks of each sector, individuals can work better together as a software community.

The following risk content is provided by the project participants: 1) Funding 2) Roles and Responsibilities 3) Staff expertise 4) Development process 5) Project planning 6) Project Interfaces 7) System Engineering 8) Requirements 9) Schedule 10) Testing
 * 17.7.1 Government Top Ten**

The project participants and the independent risk assessment team both rated the issues that were used to develop the industry Top Ten Risk List. 1) Resources 2) Requirements 3) Development Process 4) Project Interfaces 5) Management Process 6) Development System 7) Design 8) Management Methods 9) Work Environment 10) Integration and Test
 * 17.7.2 Industry Top Ten**

=**17.8 Summary**= This chapter focuses on identifying and analyzing the possibilities in the project plan and rest of the work. The following checklist can be utilized which consist of conducting a risk assessment, developing a candidate risk list, defining risk attributes, documenting identified risk, and communicating identified risk activities to assess risk. Progress has been made by identifying process as a new risk and further comparison reveals that risk priorities have increased in the past decade.

=**Chapter 18 Control Risk**=


 * Objective:** This chapter focuses on planning, tracking and resolving the risk in the project plan and remaining work. Individuals must think ahead or anticipate the worst case outcome while developing software systems. Team environment can facilitate in controlling risk since process can be discussed and created appropriately.

=**18.1 Develop Risk Resolution Alternatives**= The most create aspect of risk control is determining the possibilities to resolve risk and in order to develop risk resolution alternatives, individuals need goals and a list of assessed risks and they should be prioritized. Resources should be divided equally when goals or risk share the same priority. The team can utilize objectives which address technical design risk and with the help of a facilitator, the team can perform a risk assessment to identify and analyze technical design risks. Risk analysis includes evaluation of design objectives, constraints, alternatives and assumptions prior to developing risk resolution alternatives for the proposal team. The design team works in a small groups often two and they sometimes work individually to determine the events and conditions of a scenario for assigned risk.

=**18.2 Select the Risk Resolution Strategy**= For the risk scenario that the system did not meet real time performance requirement, the team discusses potential risk resolution strategies. To prevent the risk from occurring, they could improve their analysis, contain overhead, or buy additional hardware. They determine how each strategy might help resolve the risk and for each strategy the team writes down a possible approach to resolve the risk. The following factors cause decisions to be difficult: 1) Complexity 2) Uncertainty 3) Multiple objectives 4) Different perspectives The team puts effort for each potential strategy to determine the risk leverage and uses the criterion to rank the risk resolution strategies.

=**18.3 Develop the Risk Action Plan**= Selection criteria include minimization of impacts to cost, schedule, performance and customer satisfaction. Improved analysis assists other aspects of the technical design and the risk action plan they develop include objectives, approach, start date, milestones, due dates and other resources. The responsible person documents the risk resolution strategy and recommend action plan which is viewed by the decision makers. =**18.4 Monitor Risk Status**= When the risk action plan was presented at the review meeting, the managers were impressed. One wanted to know if the design team thought about using more than one strategy. They debated whether the customer had more funding sources than originally thought by the marketing consultant. In the end a trigger plan was established that would activate the risk action plan with the established time frame for action.

Few months later, notification of the activated trigger came as an email message from the proposal manager to the design team leader. The design competition in Phase 1 is clearly cost constrained and hardware cost should not increase. Adding cost might jeopardize the entire phase 2 contract. The designed team leader composed a brief message to the system analyst and the subject stated real time performance risk and therefore approval was given. Risk measure provides object and subjective data that can be used to indicate the level of project risk. Objective data consist of actual counts of items including risk identified. These counts may cause managers to question their subjective understanding. Metric are the quantitative result of a measure taken by use of a measurement process. A measurement process consists of the activities to define, collect, analyze, report and interpret metrics. Metrics provide a means for monitoring the status of an ongoing project while also providing indications of process improvements for future projects. It is important to have a consistent set of metrics that can utilize as status comparisons to reduce confusion on the information represented by the metrics. The following are three risk metrics: 1) Risk Forecast --- It is a project of risk exposure for all risks whose time frames for action are short. 2) Risk Index --- It is a measure that moves up the risk being monitored by the project and it is calculated by the summation of risk exposure values as a percentage of project cost. 3) Risk Management ROI --- they grow as project risks are resolved and they have many uses such as, planning benchmark for risk leverage, planning benchmark for management reserve, etc.
 * 18.4.1 Send Notification for Triggers**
 * 18.4.2 Report Measures and Metrics**

=**18.5 Execute the Risk Action Plan**= It would be a competitive advantage to be able to show the customer the increase in performance by simulating the improved hardware.

=**18.6 Take Corrective Action as Required**= When you have the ability to manage risk, it means that one will have a measure of control over one’s outcome. With the ability to manage risk, one can choose to control existing risk, take on additional risk for potentially high return. The software industry always need risk management and the form of risk management will become specialized in industries.

=**18.7 Summary**= This chapter focuses on planning, tracking and resolving the risk in the project plan and remaining work. The following checklist consist of developing risk resolution alternatives, selecting the right resolution strategy, developing the risk action, monitoring risk status, executing the risk action plan and taking corrective action are required to control risk. The purpose of developing and executing risk action plans and tracking risk status is to manage software risk and with the ability to manage risk, one can choose to control risk, or maximize long term opportunities.