Identification, Projection, RMMM

Identification, Projection, RMMM

 Stakeholders (SH) are people or organizations (legal entities such as companies, standards bodies) which have a valid interest in the system. They may be affected by it either directly or indirectly. A major new emphasis in the 1990s was a focus on the identification of stakeholders. It is increasingly recognized that stakeholders are not limited to the organization employing the analyst. Other stakeholders will include:

·        anyone who operates the system (normal and maintenance operators)

·        anyone who benefits from the system (functional, political, financial and social beneficiaries)

·        anyone involved in purchasing or procuring the system. In a mass-market product organization, product management, marketing and sometimes sales act as surrogate consumers (mass-market customers) to guide development of the product

·        organizations which regulate aspects of the system (financial, safety, and other regulators)

·        people or organizations opposed to the system (negative stakeholders; see also Misuse case)

·        organizations responsible for systems which interface with the system under design

·        those organizations who integrate horizontally with the organization for whom the analyst is designing the system

Projection

Risk Projection (aka Risk Estimation)

Attempts to rate each risk in two ways

·        · The probability that the risk is real

·        · The consequences of the problems associated with the risk, should it occur.

Project planner, along with other managers and technical staff, performs four risk projection activities:

(1) (1) establish a measure that reflects the perceived likelihood of a risk

(2) (2) delineate the consequences of the risk

(3) (3) estimate the impact of the risk on the project and the product

(4) (4) note the overall accuracy of the risk projection so that there will be no misunderstandings.

Developing a Risk Table

Risk table provides a project manager with a simple technique for risk projection

Steps in Setting up Risk Table

(1) (1) Project team begins by listing all risks in the first column of the table. Accomplished with the help of the risk item checklists.

(2) (2) Each risk is categorized in the second column

(e.g., PS implies a project size risk, BU implies a business risk).

(3) (3) The probability of occurrence of each risk is entered in the next column of the table. The probability value for each risk can be estimated by team members individually.

(4) (4) Individual team members are polled in round-robin fashion until their assessment of risk probability begins to converge.

Assessing Impact of Each Risk

(1) (1) Each risk component is assessed using the Risk Charcterization Table (Figure 1) and impact category is determined.

(2) (2) Categories for each of the four risk components—performance, support, cost, and schedule—are averaged to determine an overall impact value.

1.     1. A risk that is 100 percent probable is a constraint on the software project.

2.     2. The risk table should be implemented as a spreadsheet model. This enables easy manipulation and sorting of the entries.

3.     3. A weighted average can be used if one risk component has more significance for the project.

(3) (3) Once the first four columns of the risk table have been completed, the table is sorted by probability and by impact.

·        · High-probability, high-impact risks percolate to the top of the table, and low-probability risks drop to the bottom.

(4) (4) Project manager studies the resultant sorted table and defines a cutoff line.

·        · cutoff line (drawn horizontally at some point in the table) implies that only risks that lie above the line will be given further attention.

·        · Risks below the line are re-evaluated to accomplish second-order prioritization.

·        · Risk impact and probability have a distinct influence on management concern.

o   o Risk factor with a high impact but a very low probability of occurrence should not absorb a significant amount of management time.

o   o High-impact risks with moderate to high probability and low-impact risks with high probability should be carried forward into the risk analysis steps that follow.

·        · All risks that lie above the cutoff line must be managed.

·        · The column labeled RMMM contains a pointer into a Risk Mitigation, Monitoring and Management Plan

Assessing Risk Impact

·        · Three factors determine the consequences if a risk occurs:

o  o Nature of the risk - the problems that are likely if it occurs.

o o e.g., a poorly defined external interface to customer hardware (a technical risk) will preclude early design and testing and will likely lead to system integration problems late in a project.

o o Scope of a risk - combines the severity with its overall distribution (how much of the project will be affected or how many customers are harmed?).

o  o Timing of a risk - when and how long the impact will be felt.

·        · Steps recommended to determine the overall consequences of a risk:

1.     Determine the average probability of occurrence value for each risk component.

2.     Using Figure 1, determine the impact for each component based on the criteria shown.

3.     Complete the risk table and analyze the results as described in the preceding sections.

Overall risk exposure, RE, determined using:

RE = P x C

P is the probability of occurrence for a risk

C is the the cost to the project should the risk occur.

Example

Assume the software team defines a project risk in the following manner:

Risk identification.

·        · Only 70 percent of the software components scheduled for reuse will be integrated into the application.

·        · The remaining functionality will have to be custom developed.

Risk probability. 80% (likely).

Risk impact.

·        · 60 reusable software components were planned.

·        · If only 70 percent can be used, 18 components would have to be developed from scratch (in addition to other custom software that has been scheduled for development).

·        · Since the average component is 100 LOC and local data indicate that the software engineering cost for each LOC is $14.00, the overall cost (impact) to develop the components would be 18 x 100 x 14 = $25,200.

Risk exposure. RE = 0.80 x 25,200 ~ $20,200.

Risk Assessment

·        · Have established a set of triplets of the form:

[r_i, l_i, x_i]

where r_i is risk

l_i is the likelihood (probability) of the risk x_i is the impact of the risk.

·        · During risk assessment :

o   o further examine the accuracy of the estimates that were made during risk projection

o   o attempt to rank the risks that have been uncovered

o   o begin thinking about ways to control and/or avert risks that are likely to occur.

·        · Must Define a risk referent level

o   o performance, cost, support, and schedule represent risk referent levels.

o   o There is a level for performance degradation, cost overrun, support difficulty, or schedule slippage (or any combination of the four) that will cause the project to be terminated.

o   o A risk referent level has a single point, called the referent point or break point, at which the decision to proceed with the project or terminate it are equally weighted.

·        · Referent level rarely represented as a smooth line on a graph.

·        · Most cases - a region in which there are areas of uncertainty

·        · Therefore, during risk assessment, perform the following steps:

1.     1. Define the risk referent levels for the project.

2.     2. Attempt to develop a relationship between each (r_i, l_i, x_i) and each of the referent levels.

3.     3. Predict the set of referent points that define a region of termination, bounded by a curve or areas of uncertainty.

4.     4. Try to predict how compound combinations of risks will affect a referent level.

Risk Refinement

·        · A risk may be stated generally during early stages of project planning.

·        · With time, more is learned about the project and the risk

o   o may be possible to refine the risk into a set of more detailed risks

·        · Represent risk in condition-transition-consequence (CTC) format.

o   o Stated in the following form:

Given that <condition> then there is concern that (possibly) <consequence>

·        · Using CTC format for the reuse we can write:

Given that all reusable software components must conform to specific design standards and that some do not conform, then there is concern that (possibly) only 70 percent of the planned reusable modules may actually be integrated into the as-built system, resulting in the need to custom engineer the remaining 30 percent of components.

·        · This general condition can be refined in the following manner:

Subcondition 1. Certain reusable components were developed by a third party with no knowledge of internal design standards.

Subcondition 2. The design standard for component interfaces has not been solidified and may not conform to certain existing reusable components.

Subcondition 3. Certain reusable components have been implemented in a language that is not supported on the target environment.

Risk Mitigation, Monitoring, and Management

Effective strategy must consider three issues:

·        risk avoidance

·        risk monitoring

·        risk management and contingency planning

·        · Proactive approach to risk - avoidance strategy.

·        · Develop risk mitigation plan.

·        · e.g. assume high staff turnover is noted as a project risk, r₁.

·        · Based on past history

o o the likelihood, l₁, of high turnover is estimated to be 0.70 o o the impact, x₁, is projected at level 2.

o  o So… high turnover will have a critical impact on project cost and schedule.

· · Develop a strategy to mitigate this risk for reducing turnover. · · Possible steps to be taken

o  Meet with current staff to determine causes for turnover (e.g., poor working conditions, low pay, competitive job market).

o  Mitigate those causes that are under our control before the project starts.

o  Once the project commences, assume turnover will occur and develop techniques to ensure continuity when people leave.

o Organize project teams so that information about each development activity is widely dispersed. o Define documentation standards and establish mechanisms to be sure that documents are

developed in a timely manner.

o Conduct peer reviews of all work (so that more than one person is "up to speed"). o Assign a backup staff member for every critical technologist.

·        · Project manager monitors for likelihood of risk

·        · For high staff turnover, the following factors can be monitored: o General attitude of team members based on project pressures. o The degree to which the team has jelled.

o Interpersonal relationships among team members. o Potential problems with compensation and benefits.

o  The availability of jobs within the company and outside it.

·        · Project manager should monitor the effectiveness of risk mitigation steps.

·        · Risk management and contingency planning assumes that mitigation efforts have failed and that the risk has become a reality.

e.g., the project is underway and a number of people announce that they will be leaving.

·        · Mitigation strategy makes sure:

§  § backup is available

§  § information is documented

§  § knowledge has been dispersed across the team.

·        · RMMM steps incur additional project cost

e.g. spending time to "backup" every critical technologist costs money.

·        · Large project - 30 or 40 risks.

·        · 80 percent of the overall project risk (i.e., 80 percent of the potential for project failure) can be accounted for by only 20 percent of the identified risks.

·        · Work performed during earlier risk analysis steps will help the planner to determine which of the risks reside in that 20 percent (e.g., risks that lead to the highest risk exposure).

The RMMM Plan

·        · Risk Mitigation, Monitoring and Management Plan (RMMM) - documents all work performed as part of risk analysis and is used by the project manager as part of the overall project plan.

·        · Alternative to RMMM - risk information sheet (RIS)

RIS is maintained using a database system, so that creation and information entry, priority ordering, searches, and other analysis may be accomplished easily.

Pppppppppppppppppp

1.     Risk monitoring is a project tracking activity

2.     Three primary objectives:

1.     assess whether predicted risks do, in fact, occur

2.     ensure that risk aversion steps defined for the risk are being properly applied

3.     collect information that can be used for future risk analysis.

·        Problems that occur during a project can be traced to more than one risk.

o   Another job of risk monitoring is to attempt to allocate origin (what risk(s) caused which problems throughout the project).