Assessment of Project Benefits and Risks

Benefits: 
What value will be derived from this solution?

• Increase Revenues
• Cost Savings or Avoidance
• Cost Reduction
• Cycle Time Reduction
• Improve Productivity
• Labor Reduction
• Head Count Reduction
• Improved Performance
• Improved Cash Flow
• Improve Customer Satisfaction
• Enable Teamwork
• Enable Quality Improvement
• Supplier Relationship
• Establish Competitive Barrier
• Establish Competitive Advantage
• Create or Enable a New Product or Service or Capability
• Improve Planning Effectiveness

Risks: 
What are the environmental impacts and requirements?

• Can failure interrupt or damage critical daily business operations?
• Can failure in this effort damage the company's reputation?
• Can this effort incur or cause significant other financial losses?
• Is this effort in search of a clear champion?
• Is this effort in search of a clear project leader or manager?
• Will this effort be on an accelerated or tight time schedule?
• Does this address a longstanding difficult issue or problem?
• Has this problem or issue been unsuccessfully addressed in the past?
• Is more than one organization involved (not including IS)?
• Will more than one organization be impacted by the outcome?
• Are any stakeholders opposed to/highly skeptical of this proposal?
• Is the outcome dependent on experimental technology?
• If so, will more than one supplier of critical components be involved?
• Is a high level of technical complexity involved?
• Is this a first-time effort at this company for a project of this kind?
• Does a project plan or list of responsibilities still need to be established?
• Does the project team lack needed skills or related experience?
• Is this a large project effort? (more than 6 months or $100,000)
• Is the project team matrix managed or controlled by many managers?
• Do key team members reside in separate departments or buildings?
• Will outside contractors lead or provide key project deliverables?
• Will more than 5 persons be on the project team or Steering Committee?
• Will implementation require significant formal user training?
• Will this require implementation and training at more than one site?
• Are there doubts about commitment or availability of key participants?

Methods of Mitigating Project Risks

Schedule Risk

1. A project plan indicating the approximate order and time frame of the following deliverables:
   • proposal and cost-benefit analysis
   • budget for acquisition of assets and resources needed
   • resource commitments
   • project planning, tracking and oversight processes
   • project team partnering agreement
   • product quality assurance plan
   • preliminary project schedule
   • business requirements document
   • functional specification document
   • functional prototype
   • release candidate #1
   • functional test results for release candidate #1
   • release candidate #2
   • functional test results for release candidate #2
2. Refusing to quote delvery dates that are not based on a detailed project schedule in which the project team has buy-in
3. Refusing to quote delivery dates that assume a fixed scope of work and a fixed resource budget
4. Using estimates of effort based on historical data for this team in this environment
5. Keeping actual hours spent enroute as a gauge of the quality of the estimates up ahead
6. An issues tracking system
7. A change request tracking system and a process that involves the customer organization in prioritizing changes to the product specification
8. Business process documentation
9. Robust communication between customers and the project team
10. Robust communication between members of the project team
11. Freedom from the Dilbert Factor: Interference or intervention by managers in the dynamics of the project without being invited by the whole team

Scope Risk

1. An issues tracking system
2. A change request tracking system and a process that involves the customer organization in prioritizing changes to the product specification
3. Business process documentation
4. Robust communication between customers and the project team
5. Robust communication between members of the project team
6. Freedom from the Dilbert Factor: Interference or intervention by managers in the dynamics of the project without being invited by the whole team
   

Cost Risk

1. An issues tracking system
2. A change request tracking system and a process that involves the customer organization in prioritizing changes to the product specification
3. Business process documentation
4. Robust communication between customers and the project team
5. Robust communication between members of the project team
6. Freedom from the Dilbert Factor: Interference or intervention by managers in the dynamics of the project without being invited by the whole team

Manage Risk: Risk Management Process

Project managers need to manage risk effectively on their project. The following high-level process can be used.

1. When you are defining the project, perform a complete assessment of project risk. One technique is for the project manager to create an initial draft circulate it for adds/changes/comments. Another technique is to gather all the key stakeholders and discuss potential risks in a facilitated meeting

2. Assign a risk level to each risk identified. The risk level should be high, medium, or low, depending on the severity of impact and the probability of the event occurring. Use the following table as a way to determine the overall risk. For instance, the highly likely / high impact factors are obviously high risk. However, if you have an event that is not likely to occur, but the impact, if it occurred, would be devastating (i.e. someone could get killed), you would still want to consider it a high risk and put together a risk plan accordingly.

3. For each high-level risk that you identified, create a risk response plan. There are five major responses to a risk - leave it, monitor it, avoid it, move it to a third party or mitigate it. Your plan should include steps to respond to the risk, including the people who are assigned, completion dates and periodic review dates to monitor progress.

4. Evaluate the medium-level risks to determine if the impact is severe enough that they should have a risk mitigation plan created for them as well. If the impact is severe enough, put together a risk response plan for them as well.

5. Look at any low risk items, and see whether they should be listed as assumptions. In this way you recognize that there is a potential for problems, but because the risk is low, you are 'assuming' that the condition will not occur.

6. Move the activities associated with the risk plans to the Project Work Plan. Moving the activities to the work plan should help ensure that the work is actually completed and keeps the work plan the primary focus of all work planning and monitoring.

7. The project manager needs to monitor the risk plans to ensure they are being executed successfully. If it looks like the risk is not being mitigated successfully, new risk plan activities should be added.

8. The project manager also needs to periodically evaluate risks throughout the project based on current circumstances. New risks may arise as the project is unfolding and some risks that were not identified during the Define Project step may become visible at a later date. This ongoing risk evaluation should be performed on a regular basis, say monthly, or at the completion of major milestones.

A Risk Management Process

1.  Introduction

This document presents:

• A definition of what is to be considered a risk

• A risk management process

• A criteria for quantifying risks

• A template for tracking risks

2.  Definition of a Risk

Many situations will arise that have a wide range of potential impacts to the successful implementation of a project.  A risk is an undesirable situation which has both the likelihood of occurring and a potential consequence to the program’s success.  Risk is limited to a potential future event and does not pertain to events that have already occurred.

A risk event is stated as an assumed reality and the anticipated consequence if that reality should occur.  Good risk management begins with precise and comprehensive definition of a risk.  The following table provides examples of poorly written and improved risk statements:

Risk potentially affects the cost, quality or delivery dates of deliverables as well as the overall project.

Risk management concentrates on identification and control of the areas or events that have a potential of causing unwanted change.

3.  Risk Management Process

There are four key components of the Risk Management Process:

1. Risk Identification

2. Risk Quantification

3. Risk Response Development

4. Risk Tracking

3.1. Risk Identification

Risk identification is an organized, thorough approach to finding real risks associated with a project.  The focus should be on potential likely occurrences.  Avoid creating highly unlikely scenarios, as this tends to reduce the effectiveness of planning for eventualities.  Some ways of identifying risks include interviews with experts or prior projects of a similar nature, and determining events that may threaten project goals.

3.2.Risk Quantification

The quantification of risks is the activity of analyzing each risk and prioritizing the order in which they should be handled.  The first step in the analysis process is to categorize the risks.  The two factors considered in categorization are likelihood of occurrence and severity of consequence.  The following tables define the categories for each factor.

Determining the likelihood of occurrence is a subjective process.  It is based on the assessment team’s experience, judgement and past project histories.  Likelihood is generally expressed as a probability percentage and must be more than 0 and less than 100.  For the purposes of risk quantification, use the probability percentage to categorize the likelihood.

Likelihood:

Severity of consequence will be categorized using the following indicators: (Note: Approved baselines for both schedule and effort estimates must exist in order to quantify the impact.)

Severity of Consequence:

After the risks have been categorized, the project manager will use these factors to determine the potential risk impact.  Now the project manager has  sufficient information to prioritize the risks. 

3.3. Risk Response (Mitigation)

Once the risk has been categorized and prioritized, the project manager and other appropriate parties (usually determined by type and nature of the risk) can begin to develop the response to that particular risk.  The primary goal in most risk responses is to reduce the negative impact of a risk from a higher quantification level to a lower one. Responses may take several forms, but two of the most common are avoidance and control.

3.3.1.      Risk Avoidance

In many risk situations, the risk may be due to one of several alternative scenarios.  In this case, the project manager must determine if the potential benefit of a chosen path justifies the associated risk.  If the benefit is not sufficiently high or the risk is too great, then one of the alternative paths should be considered.  This approach is called risk avoidance because by eliminating the most risky path, the associated consequences have been avoided.

3.3.2.      Risk Control

Risk control, or mitigation, represents the most common approach to risk response.  In this approach, a course of action is defined which reduces the impact or reduces the probability of risk occurrence.  A project manager approaches this strategy using reviews, risk reduction milestones, fallback positions and other management strategies.  These strategies may involve inclusion of risk activities and tasks into the work breakdown structure (WBS) and thus into the project schedule.  But, regardless, the risk response activities must be tracked and monitored.

3.4. Risk Tracking

3.4.1. Risk Management Tracking Guidelines

The risks identified having a likelihood of occurrence less than 3 or a consequence of severity less than 3 are usually not tracked at the Director Review level. These risks are tracked at the project level, and are with in the Project Manager’s prerogative to resolve.

 Risks with likelihood and consequences of 3 or greater are tracked as follows:

• All IC project managers  will report risks using this process and common format.  (Get URL address for IC0003 Risk Worksheet template & procedures IC PAL.)

• Risk management documents are to reside in the project notebook in a common share on a server accessible by the project team.

• Risk management activities are reported to the project’s steering committee on an interval as defined in the project statement (002)

• As risks are identified or as they are being worked, it will sometimes require the active involvement of the IC Director.  The criteria for determining director-level involvement varies, therefore it is best to check with your immediate manager to determine if your project falls under this requirement.  When the risks of your project have been reduced to lower levels of likelihood and consequence, director involvement may no longer be required. This decision will be at the discretion of the IC Director.

3.4.2. Measurements

We have not identified a meaningful metric to monitor and improve this process.

Risk Worksheet

Risk Number:    01

Risk Title:         Cost Allocation

Team:                Process Improvement

Team Leader:    < leader >  

Release:             N/A

Origination Date: June 2001 
Report Date:  July 2001

Risk Statement:  In order to meet the requirement of completing this year the cost allocation had to increase from the customer agreed to 5% to 10%.  Customers have not agreed to the increase.

Quantify the Risk:

Risk Reduction Plan: