**Project Risk**

**Management Plan**

Version: 2.0

November 2003

**TABLE OF CONTENTS**

**SectionPage**

**31****Introduction**

1.1Purpose3

1.2Objectives3

1.3Scope & Context4

1.4Guiding Principles5

1.5Reference Documents6

**2.0****Risk Management Organization7**

2.1Process Responsibility7

2.1.1PMO Risk and Issue Manager/RIM Team8

2.1.2Risk Originator8

2.1.3Risk Owner8

2.1.4Project Management Office (PMO)9

2.1.5Steering Committee9

2.1.6Independent Risk Auditors10

**3.0****Risk Management Information11**

3.1Detail Risk Attributes11

3.2Risk Reference Model16

**4.0****Risk Management Process18**

4.1Risk Management Planning18

4.2Risk Management Execution18

4.2.1Risk Management Execution Process Steps19

4.2.2Risk Escalation Procedures26

4.2.3Risk and Issue Management (RIM) Team Meeting26

4.2.4Feedback and Reporting Processes27

4.3Risk Management Closeout28

**5.0****Risk Management Tool29**

5.1Accessing the Risk-Tracking Database29

5.2Using the Risk Input Form29

5.2.1Accessing the Risk Input Form29

5.2.2Creating a Risk29

5.2.3Viewing/Updating a Risk29

5.2.4Create New Action Items29

5.2.5Viewing/Updating an Action Items29

5.3Contact & Administrative Information29

5.3.1Program Risks Information29

5.3.2Risk-Tracking Database29

**6.0****Performance Measures30**

**Table of TABLes**

**TablePage**

9Table 1 – PMO Risk and Issue Management Decision Authority based on severity

Table 2 – Risk Data Elements11

Table 3 – SEI Software Risk Taxonomy16

Table 4 – Risk Assessment Severity Level Matrix21

Table 5 – Risk Response Strategies/Techniques22

Table 6 - Standard Risk Notices and Reports27

**Table of Figures**

**FigurePage**

4Figure 1 – Risk profile of a typical modern project across its life cycle

Figure 2 – Risk Management Organization7

Figure 3a – Risk Management Planning7

Figure 3b – Risk Management Execution7

Figure 3c – Risk Management Closeout7

Figure 4 – Risk Management Execution Process Steps19

Figure 5 – Risk Assignment Matrix24

# 

# 1Introduction

## 1.1 Purpose 

This ***<project name>*** Risk Management Plan (RMP) provides the Program a consistent method to manage risks to ensure success. Unlike issues, risks relate to events that could occur and may impact the Program’s scope, schedule, budget, business performance, or change management objectives. Risks are measured in terms of their likelihood of occurrence and their impact, as they relate to the program.  Risk is defined as any concern that could impact the ability of the Program to meet its scope, schedule, budget, change management, or business performance objectives.  

Risk management involves the process for identification, assessment, mitigation, and management of the Program's risks.  It drives decisions that affect the development of the business capability and the management of the program. This RMP serves as a guide to all team members on managing program-wide and team level risks. The risk management process will enable the Program to create strategies to effectively address potential barriers to program success.

Note that throughout this template document sections marked with bold, italicized text that are demarked by leading and trailing right-brackets, ***<bold, italic>***, are directions to the author to revise the section.

## 1.2 Objectives

Successful management of the Program requires informed, proactive, and timely management of risks.   The specific objectives of this program risk management plan and approach are listed below.

· Ensure critical risks impacting scope, schedule, budget, business performance, and/or change management are proactively identified, communicated, mitigated, and escalated in a timely manner.

· Facilitate attention to key risks impacting the program and individual teams.

· Produce meaningful information that allows program management to focus efforts on the “right” (e.g., high likelihood and high impact) risks with an effective coordination of effort.

· Ensure appropriate stakeholders are informed and, if applicable, participate in the mitigation.

· Record an audit trail of discussions and mitigation of program risks.

The goal of this Risk Management Plan is to proactively identify and address risks early in the Program and throughout the program’ lifecycle in order to avoid surprises.  Refer to Figure -1 below which illustrates that proactive risk management programs used today reduce and control risks better than in the past. 

**Figure 1 – Risk profile of a typical modern project across its life cycle**

Reprinted from *Software Project Management, A Unified Framework*, by Walker Royce (Addison Wesley:  1998), p. 229.

## 1.3 Scope & Context

The plan consists of the process and timing for identifying and managing risks, mitigation actions required and organizational responsible for monitoring and managing the risks throughout the entire lifecycle (Initiation, Acquisition and Implementation).  The Risk Reference Model and a tracking database, explained in detail below, serve as tools to support the RMP.

Risk management starts at the very beginning of the project (Initiation Phase per the EI Toolkit) with initial planning and assessing.   Risks identified early should be addressed immediately.   Risks and potential risk areas are monitored and managed throughout the remainder of the project.   Scope of the Risk Management Plan (RMP) is not limited to those risks identified early.  Rather, all areas should be monitored throughout.  

Risk management is carried out at all levels within the program: program, team, and sub team.  The risk management process ensures that risks are mitigated at the appropriate level and communicated as appropriate. While this plan provides guidance on managing all levels of risks, the primary focus is on risks at the program level; assuming that similar processes are in effect within the individual teams and sub-teams that comprise the program. 

While risks must be identified and effective mitigations tailored for each project, there are standard risk factors, standard assessment criteria to identify and evaluate risks, and standard mitigation approaches that have been defined for software engineering projects in general, and enterprise application implementation projects specifically.  These risk factors, assessment criteria, and mitigation approaches are referred to as a ‘Risk Reference Model’.  

This Risk Management Plan must ensure that both individual risks and risks that are common to the class of application of the Program are both identified and mitigated.  Risk management is an integral part of overall project planning and management.  Effective project planning and management requires effective identification and assessment of risks and determining what mitigating actions are required.  Managing the effective completion of mitigation actions should be integrated with overall project tasks and assignments.  

Risk management also works in concert with issue management.  The key difference between issue management and risk management is the element of uncertainty inherent in risks.  Uncertain events that could impact the Program should be identified and managed through this RMP.  Note that risks could lead to identification of issues and issues could drive identification or resolution of risks.

In addition to addressing identified risks through this risk management process, it is expected that the project planning process will also include quantitative risk assessment processes to validate project schedule and budget estimates.  These techniques, including Monte Carlo simulation and decision tree analysis, are beyond the scope of this document.  

## 1.4 Guiding Principles

In order to be successful, the principles listed below guide the use and implementation of the overall Risk Management Process that is described in detail in section 3.0 of this document. 

· Decisions will not be revisited once made (unless substantively new facts become available).

· Escalation of risks follows the defined process identified below. 

· A single owner is assigned responsibility for a risk even if several people work to mitigate it.

· Work and communicate progress on most severe risks first.

· Set realistic due dates and then work to meet the dates.

· Mitigate risks at the appropriate level (i.e., program, team, sub-team).

· Responsible team leads determine and agree on the risk severity level.

· Document the planned risk mitigation history and actual mitigation of a risk. This documentation serves as a key input to root cause analysis, key learning, metrics, and risk analysis.

· For high impact, unanticipated risks, a 24-hour decision turnaround may be required or as determined by the PMs. In such cases, available applicable team members will make the decision.

## 1.5 Reference Documents

This Risk management Plan builds on general project and risk management references including:

**A Guide to the Project Management Body of Knowledge (PMBOK( Guide) 2000 Edition** (Project Management Institute, 2000)

**Assessment and Control of Software Risks**, Capers Jones (Prentice Hall, 1994)

**Chaos Report** and other publications, Standish Group

**Managing Risk, Methods for Software Systems Development**, Elaine M. Hall (Addison Wesley, 1998)

**Project & Program Risk Management, A Guide to Managing Project Risks & Opportunities**, R. Max Wideman, Editor (Project Management Institute, 1992)

**Software Engineering Risk Management**, Dale Walter Karolak (IEEE, 1996)

**Software Project Management, A Unified Framework**, Walker Royce (Addison Wesley, 1998)

***<Include Program specific references such as Issue management Plan, etc.>***

# 2.0 Risk Management Organization

The following figure depicts the ***<project name>*** organization involved in risk management.  Roles and responsibilities are delineated in the subsequent sections.

***<insert risk organization chart for Program>***

**Figure 2 – Risk Management Organization**

## 2.1 Process Responsibility

***<assign roles and responsibilities mapping to specific titles as used in Program organization chart updating this section>***

The Program Management Office (PMO) Risk and Issue Manager is responsible for the Risk Management Plan, its effective implementation throughout the Program, trends and metric analysis, and training Program personnel on risk management.  The Risk and Issue Manager is also responsible for selecting risk tracking software, for identifying whether the Program warrants an independent risk assessment, and for identifying any risk reference model to use as a basis for assessing Program risks or identifying candidate mitigation approaches.  

An overview of the risk management process is depicted in Figure 3a, 3b, and 3c.  Key roles and responsibilities are then defined in the following subsections.   A Risk Management Checklist which supports the process and below and the appropriate signoffs is also included in the EI Toolkit.

**Figure 3a – Risk Management Planning**

**Figure 3b – Risk Management Execution**

**Figure 3c – Risk Management Closeout**

### 2.1.1 PMO Risk and Issue Manager/RIM Team

The PMO Risk and Issue Manager has overall facilitative responsibility for the risk management process.  The RIM Team is comprised of the Risk and Issue Manager and the Risk and Issue Management Staff.  Specific responsibilities include the following activities.

· Develop the Risk Mitigation Plan by customizing this template.

· Select Risk Tracking tool.

· Identify Risk Reference Model if applicable for the application class.

· Assist in determining need for independent risk assessment, support sourcing if required.

· Maintain the Risk Management Plan in line with configuration management procedures.

· Plan and coordinate RIM meetings.

· Plan and manage RIM training.

· Generate risk reports, including trends and metric analysis, for risk meetings and ad-hoc requests.

· Clarify, consolidate and document risks.

· Maintain and monitor data in the risk-tracking tool.

· Establish initial priority, owner, and target due date.

· Monitor the status of risk mitigation.

· Communicate status to risk originators and risk owners.

· Escalate communication if expected mitigation action deadlines are not met.

· Execute the risk closure process.

· Work with the Risk and Issue Management team to facilitate risk mitigation.

### 2.1.2 Risk Originator

The Risk Originator is any person in the Program who identifies a Program risk.  Specific responsibilities include the following activities.

· Identify any significant risk to the Program.

· Complete “Create Risk” form.

· Present new risks at Risk and Issue Management (RIM) team meetings. 

· Verify that the risk is eventually mitigated.

### 2.1.3 Risk Owner

The Risk Owner is the person to whom the RIM team assigns primary responsibility for mitigating the risk.   This assignment is based on the type of risk and should be assigned to the team member who is empowered to assure this risk is mitigated.   This will typically be a team lead and/or their respective co-lead.   Program sponsors, directors and/or managers may also need to be aligned with a risk to assure adequate support. The Risk Owner has the following responsibilities:

· Assess the risk and create a risk mitigation plan that meets RIM team approval.

· Update risk information in risk database as described below.  

· Mitigate risk per the risk mitigation plan.

· Recommend risk closure to RIM team.

· Present risk status at RIM team meetings as required

### 2.1.4 Project Management Office (PMO)

The Project Management Office (PMO) has the authority to approve the risk mitigation proposed by the Risk Owner.  This authority varies by the severity of the risk, as noted in Table 1 below.  Additionally, the PMO members are notified of risk mitigation, as noted in Table 1 below.   It is anticipated that the majority of risk mitigation will take place at the project team level.  

**Table 1 – PMO Risk and Issue Management Decision Authority based on severity**

Specific responsibilities include the following.

· Accountable for ensuring timely mitigation of risks and escalating risks to the Steering Committee for support as needed.  

· Champion mitigation implementation.

· Review status, severity, ownership, and completeness of risks.

· Determine risks to be returned to the appropriate project teams.

· Establish severity of risks and define target dates.

· Establish ownership of risk and confirm target dates.

· Identify risks for escalation to the Steering Committee.

· Work with project teams, subject matter experts, and the Risk and Issue Manager to facilitate solutions to risks.

### 2.1.5 Steering Committee

The Steering Committee has overall responsibility for ensuring the Risk Management Plan is executed fully.  Specific responsibilities include the following activities.

· Approve the mitigation of very high severity level risks.

· Support mitigation implementation.

· Assist in cross-organization and controversial risk mitigation to include determining the involvement of senior management and other organizational resources.

***<Optionally include the use of independent auditors if project complexity and staff availability / capability warrant the use of 3rd party risk identification.***

***A third party should be engaged if:***

· ***Project resources have inadequate experience with the type or size of project;***

· ***Project resources have inadequate capacity to complete a risk assessment;***

· ***There is inadequate objectivity in identifying or assessing risks across different business units or development organizations;***

***Benefits of using a third party to conduct an independent risk audit include:***

· ***Access to a risk reference model – a set of risk factors and effective mitigation plans that have been relevant for similar projects;***

· ***Trained skills in conducting structured interviews to identify and assess risks;***

· ***Effective change management skills to drive the project team to execute mitigation plans.***

### 2.1.6 Independent Risk Auditors

The independent auditor is responsible for identifying Program risks based on conducting objective review of project documents and interviewing key project personnel.  The independent auditor should have proven experience in assessing similar class projects in size, scope, and process domain.   The independent auditor should have a specific risk reference model that they can provide to the Program.  Specific responsibilities include the following activities.

· Conduct interviews with key project personnel including stakeholders, steering committee, process owners, project managers, and team leads.

· Review project documents including charter, project plans, organizational roles and responsibilities, testing, training, and change management strategy, architectural design and blueprint documents as they exist, etc.

· Identify and assess Program risks and capture risk scorecard and mitigation approach / actions.

· Communicate risk report to project managers and sponsors.

# 3.0 Risk Management Information

To effectively manage risks standard information must be captured about each identified risk.  This section outlines the key attributes captured in the risk-tracking database.  In addition, this section describes the elements of an effective Risk Reference Model.

## 3.1 Detail Risk Attributes

The following data fields along with their defined list of values should be updated for the Program and captured as the key Risk Information in the risk database.  When a new risk is identified, the initial risk information is completed by the Risk Originator and documented on the “Create Risk” form (as referenced in section 2.1.2 above)

***<The following table is a partial list of risk data elements – it should be revised based upon the actual elements supported by the selected risk-tracking software.***

***In addition, the impact definitions for project schedule and budget should be revised based on specific project goals and thresholds.>***

**Table 2 – Risk Data Elements**

## 3.2 Risk Reference Model

A Risk Reference Model captures common risk conditions from similar classes of projects.  It contains risk factors organized into categories for ease of administration and reporting.  A major goal of having this defined taxonomy of risk factors is to support an overall Program risk assessment that ensures a comprehensive review of likely causes of risks.  For example, the following table presents standard risks across custom software engineering projects.

**Table 3 – SEI Software Risk Taxonomy**

Reprinted from *Managing Risk, Methods for Software Systems Development*, by Elaine M. Hall (Addison Wesley:  1998), pp. 76, 77.

In addition, to the risk taxonomy, many risk reference models also provide assessment criteria to determine the existence of risks on a project and to evaluate the severity of these risks.  A full-featured Risk Reference Model also contains standard mitigation approaches and actions that have been proven to address risks in other projects.

There are numerous sources for Risk Reference Models, including the Software Engineering Institute, IEEE, and various academic and commercial sources.  In assessing which model is best for the Program, chose a model that is built on similar projects in size, scope, complexity, industry, and application class.  Note that some of the models are specifically targeted to enterprise applications.

# 4.0 Risk Management Process

Risk management involves three major phases:  risk management planning, risk management execution, and risk management closeout.  

## 4.1 Risk Management Planning

Risk management planning activities for the Program involve establishing the infrastructure to support effective risk management.  The primary activities are described below.

· Establish the risk management organization and assign roles and responsibilities as outlined in section 2 above.  It is essential for effective execution of the risk management plan that the PMO Risk and Issue Management Team be given adequate authority and visibility.   

· Select a risk-tracking tool.  There are a number of commercial and open source tools available which support the collection, management, and reporting of risks.  It is essential to select a tool that adequately supports risk description, assignment of severity scores, and capture of mitigation actions, plan, and results.  Ideally the tool integrates easily into the suite of PMO supporting tools.  This document should be updated to reflect detailed guidelines for the use of the selected risk-tracking tool.

· Determine if a Risk Reference Model is relevant for the project and select the specific model if appropriate.  A Risk Reference Model captures common risk conditions from similar classes of projects.  It contains risk factors organized into categories for ease of administration and reporting.  Frequently there are pre-defined assessment criteria that can be used to determine the existence of risks on a project and to evaluate the severity of the risk.  A full-featured Risk Reference Model also contains standard mitigation approaches and actions that have been proven to address risks in other projects.

· Evaluate the capability and availability of project staff to perform a risk assessment to determine whether an independent risk audit is advised.  If so indicated, source the independent auditor task.  Plan to have an initial assessment and periodic monitoring/audits. These periodic audits should be proactively aligned with key project checkpoints where audits will uncover highest severity risks.   

· Validate risk management metrics that will be used to assess performance of the risk management process.  Document these metrics and ensure they are reported regularly.

## 4.2 Risk Management Execution

This section describes, step-by-step, the risk management process from identification to completion.  The risk management process is a continuous cycle.  It is performed initially during program planning and thereafter following newly identified risks.  

These new risks may arise from a variety of sources:

· New risks previously missed or unforeseen,

· New risks arising as a result of a change in circumstances (such as sponsorship involvement, resource turnover, resource availability, new initiatives/distractions, etc)

· New risks arising from an approved change request, where cost, scope, or schedule may be amended, impacting the critical path,

· New risks arising as a result of escalation of major project issues,

· New risks arising from current risks whose response requires investigation, and

· New risks arising from the 'outcome' or consequence of a separate risk occurrence.

Figure 4 depicts the risk management process steps.  Subsequent sections detail each process step, the escalation procedure, the Risk and Issue Management meeting schedule, and an overview of the feedback and reporting process.

**Figure 4 – Risk Management Execution Process Steps**

### 4.2.1 Risk Management Execution Process Steps

This section describes each step in the risk management execution process depicted in Figure 4 above. 

#### 4.2.1.1 Submit Risk

The Risk Originator identifies and submits a potential risk via completing the “Create Risk” form and updating the risk-tracking database.

Note:  every risk is automatically initialized as a, "New" risk. The risk remains in its "New" status until the RIM team evaluates the risk (see Section 4.2.1.2 below).

#### 4.2.1.2 Assess Risk

The Risk Originator is responsible for the initial risk assessment.  The risk assessment activity includes filling in the **recommended** information (see Table 2):

· Risk description

· Risk area  

· Probability of Occurrence 

· Probability of Impact 

· Risk Owner

· Risk Mitigation Plan and due date, and Action Item due dates (as applicable or appropriate by the Risk Originator

In assessing the risk, the Risk Originator first assesses the Probability of Occurrence using Table 2 as a reference.  Then the Risk Originator assesses the Probability of Impact in each of the 5 impact areas noted in Table 2.  The overall Probability of Impact equates to the highest of the individual assessed areas.  For example: An identified risk is assessed to having the following impact properties:

Scope = Low

Budget = Low

Schedule = ****High

Change Management = Medium

Business Performance = Medium

The overall Probability of Impact is "High", as "High" is the highest of the individual assessed areas.

Once the Risk Originator determines the Probability of Occurrence and the Probability of Impact, the Risk Originator determines the Risk Severity Level  based on the following table. 

**Table 4 – Risk Assessment Severity Level Matrix**

For example, a risk has been identified and assessed with a Probability of Occurrence of 'medium' and a Probability of Impact of 'high'.  The Risk Severity Level is 'high'.

Once the risk is identified and assessed, the RIM Team performs a check on the risk to ensure the risk fits the RMP definition of a risk.  Should the RIM Team have any questions or need further clarification, the Risk Originator is contacted to provide the necessary information.  If the risk does not fit within the risk definition or is a duplicate of another risk, the RIM Team cancels the risk and notifies the Risk Originator of the cancellation.  In addition, the RIM Team updates risk status in the risk-tracking database to, "Cancelled".  

#### 4.2.1.3 Evaluate Risk

The RIM team evaluates the information suggested by the Risk Originator (ie. Risk Owner, Risk Mitigation Due Date, Risk Mitigation Plan, Risk Area).  The RIM Team changes the risk's status in the risk-tracking database to "Open".  The RIM Team then notifies the Risk Owner of their assignment and instructs the Risk Owner to develop a Risk Mitigation Plan that will successfully mitigate the risk to a target severity level. The target severity level is determined by the Risk Owner as part of the Risk Mitigation Plan development.  It represents the expected result of implementing the risk mitigation plan for the risk.  Note that it is frequently the case that the effect of mitigating a risk will not be to eliminate the possibility that a risk could occur, but instead to reduce the likelihood and / or impact to an acceptable level.  

#### 4.2.1.4 Plan Risk Mitigation

Once the RIM team assigns the risk to a Risk Owner, the Risk Owner is responsible for timely risk mitigation.  Should the Risk Owner have any questions or need further clarification, the Risk Owner contacts the Risk Originator to provide the necessary information.  Should this happen, the Risk Owner is encouraged to update the risk in the risk-tracking database with the information by using the "Risk Owner Rational/Comments" field.  Additionally, the Ris k Owner is encouraged to research mitigation strategies/techniques (see Section 4.2.1.4.1 below). 

The Risk Owner is also responsible for providing mitigation progress to the RIM team. 

##### 4.2.1.4.1  Risk Response Strategies/Techniques

The first step the Risk Owner takes in Risk Mitigation is to adopt a Risk Response Strategy/Technique.  The following table contains a listing of the strategies/techniques employed on the Program along with a description to help in defining the term.

**Table 5 – Risk Response Strategies/Techniques**

##### 4.2.1.4.2 Developing and Documenting a Risk Mitigation Plan

The second step the Risk Owner takes in Risk Mitigation is to document their Risk Response Strategy/Technique in a step-by-step, sequential plan.  The sequential plan contains those steps that when completed, will lead to the risk being successfully mitigated.  When the Risk Owner completes this plan, it becomes the Risk Mitigation Plan.

At a minimum, every Risk Mitigation Plan contains Action Item steps that will successfully mitigate the risk to the risk's targeted severity level by the risk's targeted due date.  Each Action Item step contains the following elements in addition to the Action Item step to ensure the risk is successfully mitigated:

· The Action Item Start Date (the date the Action Item is scheduled to start),

· The Action Item Due Date (the date the Action Item will be completed),

· The Action Item Target Severity Level (the severity level that will be obtained when the Action Item is completed),

· The Action Item Owner (the person responsible for performing the Action Item step), and

· The Program's Work Breakdown Structure (WBS) number that corresponds with the Action Item step (if applicable).  Tying the Program's WBS number that corresponds to each Action Item step typically avoids or mitigates the identified risk. 

Should the Risk Owner need assistance in formulating the Risk Mitigation Plan, the Risk Owner should contact the Risk and Issue Manager or any member of the RIM Team for assistance.  Further, examples of appropriate Risk Mitigation Plans are available from the Risk and Issue Manager.

The Risk Owner updates the risk-tracking database with the Risk Mitigation Plan and associated action items and supporting details to achieve targeted severity level.  The status is updated to: Mitigation Plan Created.  

##### 4.2.1.4.3 Obtaining Approval of the Risk Mitigation Plan

The final step the Risk Owner takes in Risk Mitigation Planning is to obtain approval of the Risk Mitigation Plan.   Upon the Risk Owner’s completion of documenting the Risk Mitigation Plan in the risk-tracking database, the RIM Team members review the plan.  The Risk Owner is contacted should the RIM Team have any questions or need further clarification.  At the next Risk and Issue Management Meeting, the Risk Mitigation Plan is presented to the RIM team for final review and approval.  Figure 5 shows the decision making body for each risk profile.  The Steering Committee makes decisions regarding Very High severity level risks.  The Program Managers make decisions regarding High and Medium severity level risks.  The Deputy PM and Team Leads make decisions on Low and Very Low severity level risks.  In all cases the Risk Owner coordinates the decision with the respective decision-maker, and upon approval, status in the risk-tracking database is updated to:  Mitigation Plan Approved.

**Figure 5 – Risk Assignment Matrix**

#### 4.2.1.5 Performing the Risk Mitigation

Upon approval of the Risk Mitigation Plan by the RIM Team, the RIM Team updates the risk-tracking database for the respective risk and the Risk Owner commences the risk mitigation. If the Risk Owner is not able to mitigate the risk, they are to contact the RIM team immediately and provide the reason for not resolving the risk.  The RIM team may do the following, in addition to updating the risk-tracking database:

· Notify program management of the reason, or

· Re-assign the risk to another Risk Owner who is capable of resolving the risk. In this event, the RIM Team contacts the Risk Originator and informs them of the decision.

The Risk Owner provides status updates as they occur via the risk-tracking database and always prior to the next RIM meeting.  Statuses in the risk-tracking database include:  Mitigating Risk – green, Mitigating Risk – yellow and Mitigating Risk – red.   Additional updates to the database and RIM team include:

· All status and progress on actions

· Any mitigation schedule slippage

When the Risk Owner has mitigated the risk, the Risk Owner updates the action items and provides adequate detail that describes the final status in the risk-tracking database and changes the risk status to, "Mitigation Complete". Should the RIM Team have any questions or need further clarification, the RIM Team contacts the Risk Owner to provide the necessary information.

#### 4.2.1.6 Complete Risk

At the next RIM meeting, the “Mitigation Complete” risks are discussed and a decision is made whether or not to complete (meaning the risk is considered to be successfully mitigated) the risk.  If the RIM team agrees that the risk is completed, the RIM Team changes the risk status to, “Completed”. When the risk status is "Completed", the RIM Team notifies the Risk Originator and Risk Owner that the risk is completed through the use of a weekly Risk and Issue Meeting Report.  

If the RIM Team decides the risk mitigation is not satisfactory, the RIM Team returns the status to "Open" and the Risk Owner repeats the process described in Section 3.2.2.4.  This includes reviewing the mitigation strategies/techniques and the Risk Mitigation Plan to determine what additional steps need to be taken to mitigate the risk to its targeted severity level. 

Once a risk is completed, the risk remains in the risk-tracking database indefinitely in its "Completed" status.   This status does not mean the risk is "closed" or "not applicable anymore" or "unimportant" or "inactive".  Rather, the opposite is true.  As noted above, the risk management process is a continuous process.  This means all risks identified and successfully mitigated remain successfully mitigated because each risk is continuously assessed by the assigned Team Lead/Co-Lead to ensure that the risk remains at its mitigated severity level.   

In the event a mitigated risk is assessed to be at a higher severity level than previously reported, the Risk Owner is responsible for "re-opening" the risk management process.  If approved by the RIM Team, the RIM Team flags the risk on the risk-tracking database as "Re-opened" and the Risk Owner further mitigates the risk as needed (see Sections 3.2.2.2 through Section 3.2.2.5 above).  Once the re-opened risk is mitigated, and if the RIM Team approves the re-opened risk's mitigation, the RIM Team updates the risk's status on the risk-tracking database to "Completed (after Re-Open)".

Additionally, if a stakeholder does not agree with the RIM Team over the mitigation, the stakeholder may request to have the risk re-opened if substantive information is presented by the stakeholder.  If approved by the RIM Team, the RIM Team flags the risk on the risk-tracking database as "Re-opened" and notifies the Risk Owner that further mitigation is needed, as noted above.  Once the re-opened risk is mitigated, and if the RIM Team approves the re-opened risk's mitigation, the RIM Team updates the risk's status to "Completed (after Re-Open)".

### 4.2.2 Risk Escalation Procedures

Most decisions are made at the Team Lead level, as delineated in Figure 5 above.  The RIM Team escalates only those risks to the Program Management Office that significantly (Very High Severity Level) impact the program's scope, budget, schedule, change management, technical performance, and business performance objectives.  Additionally, the RIM Team escalates to the Program Management Office, those issues determined to need cross-organization involvement, are controversial, or require Steering Committee involvement and/or decisions.  

### 4.2.3 Risk and Issue Management (RIM) Team Meeting 

The RIM Team meeting is conducted 

***<define meeting schedule, for example, every two weeks, and any coordination with other project status meeting schedules>***

and is facilitated by the Risk and Issue Manager.  For meeting attendees who are unable to attend in person and for those Program personnel outside the Program’s home base location, a dial-up telephone number is available for their participation. Meeting attendees include:

***<complete based on organizational responsibilities>***

· Program Managers and Deputy Program Managers (Co-Chairs)

· Team Leads

· Business Manager (RIM Team Co-Chair)

· PMO Business and Performance Management Lead

· PMO Risk and Issue Manager

· PMO Risk and Issue Management Team

During the RIM Team meeting new and past due risks are discussed. The risk originators present the new risk and provide the necessary detail. The risk owners provide updates for all other risks.

In addition to the RIM Team meeting, the Risk and Issue Manager and the Risk and Issue Management Team will brief the Program Managers on a weekly basis of the status of risks. 

### 4.2.4 Feedback and Reporting Processes

The RIM Team generates standard reports as part of the risk management process.  In preparation for the Risk and Issue Management meeting, the RIM Team prepares a Risk Watch List (see following table) listing the risks for review (i.e., new, open, and ready-to-complete risks).  After the RIM Team meets, the RIM Team notifies the Risk Originators and Risk Owners of the results of the meetings (i.e., status of new risks submitted, new risk assignments, and risks approved for closure) through the Risk and Issue Meeting Report.  A summary of standard notices and reports are listed below.

**Table 6 - Standard Risk Notices and Reports**

In addition, a variety of views are available to all Program personnel at any time through the risk-tracking database.  

#### 4.2.4.1 Risk Watch List

The RIM Team produces a weekly Risk Watch List depicting a point-in-time view of the status of all documented risks and summary-level statistics.  Special emphasis is on risks that are:

· New;

· Past due (in all severity levels);

· Very High and High severity risks that are due within the next month;

· Medium, Low, and Very Low severity risks that are due within the next month.

#### 4.2.4.2 Risk & Issue Meeting Report

The RIM Team publishes, via email; a Risk & Issue Meeting report summarizing all actions taking place at the Risk & Issue Management meeting.  This report is published within 24 hours of the meeting.

## 4.3 Risk Management Closeout

At the completion of the Program, the RIM Manager and Team are responsible for ensuring successful transition of any open risks and for capturing and harvesting lessons learned for future project work.  The primary activities are described below.

· Validate the completion of identified risks.  For any open risks assess whether there is ongoing operational risks that warrant communication of these risks to the operational transition team.  Document remaining open risks and provide access to final report.

· Produce final risk management metrics and evaluate process effectiveness against established benchmarks.

· Capture risk factors and risk mitigation plans for inclusion in Risk Reference Models.  

# 5.0 Risk Management Tool

***<This section should be substantially revised based on details of the selected risk-tracking tool.  Alternatively, reference should be made to documentation and training for the selected tool.>***

This section briefly describes the risk-tracking management tools, the forms that are used to “Create Risks”, “Create Action Items”, and how to access this tool to open, view and update a risk or an action item. The Risk and Issue Management (RIM) Team maintains the risk-tracking database. Program members are able to access and edit risk information in the tool using various views. The Risk and Issue Managers regularly monitor the risk-tracking database for any new risks. The RIM Team takes the risks it receives, initiates the process of assigning Risk Ownership and oversees the mitigation process as described above.

## 5.1 Accessing the Risk-Tracking Database

## 5.2 Using the Risk Input Form

### 5.2.1 Accessing the Risk Input Form

### 5.2.2 Creating a Risk

### 5.2.3 Viewing/Updating a Risk

### 5.2.4 Create New Action Items

### 5.2.5 Viewing/Updating an Action Items

## 5.3 Contact & Administrative Information

### 5.3.1 Program Risks Information

### 5.3.2 Risk-Tracking Database

# 6.0 Performance Measures

***<Performance measures should be revised as part of the Risk Management Planning process.  Benchmark measures for evaluating process effectiveness should be established at the same time. >***

The following performance measurements are established for the risk management process.  The RIM Team, as part of the program's continuous improvement process, periodically evaluates these performance measures.  Changes and additions are made on an "as needed" basis.

We should/ could insert a generic one that we recommend here.

Identify Risk Reference Model

Determine need for Independent Risk Assessment

Select Risk Tracking Software

Identify Risks

Assess Risks

Mitigate Risks

Manage

Risks

Close

Risks

Transition any Open Risks

Produce final risk metrics

Harvest results into Reference Model

ASSESSMENT

MITIGATION

MANAGEMENT

IDENTIFICATION

Evaluate Risk

Complete Risk

Submit Risk

Assess Risk

Mitigate Risk

Simulation

Modeling

Trade Studies

Team Workshops

Advance design models

Reduce Dependencies

Customer involvement

Joint Applications development groups

Rapid Prototyping

Early multi-discipline involvement

Consultant and/or specialist reviews

Steering Committee

Med  		High	Very High

Low		Med	High

Very Low	Low	Med

Med  		High	Very High

Low		Med	High

Very Low	Low	Med

Program Managers

Deputy PMs and Team Leads

Med  		High	Very High

Low		Med	High

Very Low	Low	Med

# _1066736196.doc