Office of Systems Integration / Risk Management Plan
<Date>
<Project Name>
Risk Management Plan
<Insert Project Logo here>
<Month, Year>
Health and Human Services Agency, Office of Systems Integration<OSIAdmin # XXXXv1 > i
<Project Name>Office of Systems Integration / Risk Management Plan
<Date>
Revision History
Revision HistoryRevision/WorkSite # / Date of Release / Owner / Summary of Changes
SID Docs #3164v4 / 06/23/2004 / SID - PMO / Initial Release
OSIAdmin 3283 / 08/29/2008 / OSI - PMO / Major revisions made. Incorporated tailoring guide information into this template
Remove template revision history and insert Project Risk Management Plan revision history.
Approvals
Name / Role / DateInsert Project Approvals here.
Template Instructions:
This template is color coded to differentiate between boilerplate language, instructions, sample language, and hyperlinks. In consideration of those reviewing a black and white hard copy of this document we have also differentiated these sections of the document using various fonts and styles. Details are described below. Please remove the template instructions when the document is finalized.
Standard boilerplate language has been developed for this management plan. This language is identified in black Arial font and will not be modified without the prior approval of the OSI Project Management Office (PMO). If the project has identified a business need to modify the standard boilerplate language, the request must be communicated to the PMO for review.
Instructions for using this template are provided in purple Arial font and describe general information for completing this management plan. All purple text should be removed from the final version of this plan.
Sample language is identified in red italic Arial font. This language provides suggestions for completing specific sections. All red text should be replaced with project-specific information and the font color replaced with black text.
Hyperlinks are annotated in blue underlined Arial text and can be accessed by following the on-screen instructions. To return to the original document after accessing a hyperlink, click on the back arrow in your browser’s toolbar. The “File Download” dialog box will open. Click on “Open” to return to this document.
<OSIAdmin #3283 > i
<Project Name>Office of Systems Integration / Risk Management Plan
<Date>
Table of Contents
1. Introduction 1
1.1 Purpose 1
1.2 Scope 1
1.3 References 1
1.3.1 Best Practices Website 1
1.3.2 External References 1
1.3.3 Project Risk Database (PRD) 1
1.4 Acronyms 1
1.5 Document Maintenance 2
2. Participants Roles and Responsibilities 2
2.1 Office of Systems Integration (OSI) 2
2.1.1 Project Director 2
2.1.2 Project Manager (PM) 2
2.1.3 Risk Manager 3
2.1.4 Risk Analyst 3
2.1.5 Project Stakeholders and Vendors 3
3. <Project Name> Project Risk Management 3
3.1 Risk Management Process 3
4. Risk Management Tool – Project Risk Database (PRD) 19
4.1 Risk Radar™ 19
4.2 Risk Categorization 19
4.2.1 Risk Area 19
4.2.2 Current Status 19
4.2.3 Control 20
4.3 Risk Ratings 20
5. Project Closeout 20
5.1 Risk Review 20
5.2 Lessons Learned 21
5.3 Archive and Storage 21
Appendix A : List of SEI Risk Taxonomy Questionnaire Topics A-1
Appendix B : <Project Name> Project Risk Database Data Elements B-1
Appendix C : <Project Name> Risk Candidate Identification Form C-1
Appendix D : <Project Name> Software Integrity Level Scheme D-1
Appendix E : Mitigation Strategy & Contingency Planning Measures E-1
Appendix F : Software Engineering Institute Risk Taxonomy Categories F-1
Appendix G : Key Terms G-1
<OSIAdmin 3283 > ii
<Project Name>Office of Systems Integration / Risk Management Plan
<Date>
Figure 1: <Project Name> Project Risk Management Paradigm 3
Figure 2: Risk Management Responsibilities at a Glance 5
Table 1: Criteria for Risk Identification 7
Table 2: Risk Identification Components 8
Table 3: Criteria for Risk Impact 10
Table 4: Criteria for Risk Probability 11
Table 5: Criteria for Risk Timeframe 12
Table 6: Guide for Determination of Risk Exposure 13
Table 7: Guide for Determination of Risk Severity 13
Table 8: Guide for Determination of Risk Escalation 18
<OSIAdmin 3283 > iii
<Project Name>Office of Systems Integration / Risk Management Plan
<Date>
1. Introduction
1.1 Purpose
The purpose of this Risk Management Plan (RMP) is to describe the methodology for identifying, tracking, mitigating, and ultimately retiring <Project Name> Project risks. This document defines the risk management roles and responsibilities of the <Project Name>Team
1.2 Scope
The scope of this document pertains to the <Project Name> Project and its internal and external risks. The risk management methodology identified in this document will be primarily used by <Project Name> and is to be used during the entire <Project Name> Project. The <Project Name> Vendor’s risk management methodology will be provided as a contractual deliverable and will develop a separate Risk Management Plan. The <Project Name>Vendor will be responsible for managing their project risk and reporting to <Project Name> Project Managers.
1.3 References
1.3.1 Best Practices Website
For guidance on the Office of Systems Integration (OSI) risk management methodology refer to the OSI Best Practices website (BPWeb) (http://www.bestpractices.osi.ca.gov).
1.3.2 External References
PMBOK Guide, 3rd Edition, Section 11 - Project Risk Management
Office of the Chief Information Officer Information Technology Project Oversight Framework- Section 5: Risk Management and Escalation Procedures
IEEE Standard 1012-1998: IEEE Standard for Software Verification and Validation,
1.3.3 Project Risk Database (PRD)
Refer to the Risk Radar Database located at <path or server>. If the project is not using Risk Radar, indicate the name and location of the Project Risk Database the <Project Name> Project is employing. Update the document as appropriate to reflect the name of the PRD.
1.4 Acronyms
List only acronyms that are applicable to this document.
BPWeb / OSI Best Practices Website http://www.bestpractices.osi.ca.govCHHSA / California Heath and Human Services Agency
IEEE / Institute of Electrical and Electronics Engineers
IPOC / Independent Project Oversight Contractor
MTSII / Management Tracking System II
OSI / Office of Systems Integration
PMI / Project Management Institute
PMO / Project Management Office
PRD / Project Risk Database
RMP / Risk Management Plan
SEI
TA / Software Engineering Institute
California Technology Agency
1.5 Document Maintenance
This document will be reviewed annually and updated as needed, as the project proceeds through each phase of the system development life cycle. If the document is written in an older format, the document should be revised into the latest OSI template format at the next annual review.
This document contains a revision history log. When changes occur, the document’s revision history log will reflect an updated version number as well as the date, the owner making the change, and change description will be recorded in the revision history log of the document.
2. Participants Roles and Responsibilities
This section describes the roles and responsibilities of the <Project Name> staff with regard to the Risk Management Plan. Note that these are roles, not positions or titles. One person may fulfill more than one role. Avoid listing specific names as this will lead to frequent maintenance updates to the plan.
There are various staff resources and stakeholders involved in managing project risks. In some cases, one individual may perform multiple roles in the process.
2.1 Office of Systems Integration (OSI)
2.1.1 Project Director
The Project Director is involved in monitoring risk action effectiveness and participating in risk escalation. The Project Director also has the responsibility to communicate to certain project stakeholders, on an as needed basis.
2.1.2 Project Manager (PM)
The role of the <Project Name> Project Manager is to write and approve the <Project Name> Project Risk Management Plan, define the Risk Management process, participate in the Risk Management process, and take ownership of risk mitigation planning and execution.
2.1.3 Risk Manager
The Risk Manager is responsible for leading the risk management effort, sponsoring risk identification activities, facilitating communication throughout the execution of the risk management process, and ensuring the PRD is maintained and the statuses assigned to risks and risk activities are current. The Risk Manager is responsible for providing the Project Manager with recommendations and statuses on risk actions.
2.1.4 Risk Analyst
The Risk Analyst’s role is to evaluate risks, maintain the Risk Management database, and facilitate communication throughout the execution of the process.
2.1.5 Project Stakeholders and Vendors
The role of <Project Name> Project stakeholders and vendors is to participate in the Risk Management process by providing candidate risk input, and supporting risk mitigation planning and execution activities.
3. <Project Name> Project Risk Management
3.1 Risk Management Process
The <Project Name> Project Risk Management Paradigm, depicted in Figure 1, summarizes the Risk Management process for the <Project Name> Project. This paradigm portrays the high-level process steps of the Risk Management process, which are:
· Step 1 – Identify· Step 2 – Analyze
· Step 3 – Plan / · Step 4 – Implement
· Step 5 – Track and Control
· Continuous Process – Communicate
Figure 1: <Project Name> Project Risk Management Paradigm
Communication is an essential part of the Risk Management and occurs at every step of the process among the <Project Name> stakeholders and contractors.
A key component of the Risk Management Process is the Risk Management Database (RMD). <Project Name> team will use this database as a repository for <Project Name> Project risk information. The proposed <Project Name> Risk Management Database field descriptions in Table XXX identify and describe the proposed data elements to be incorporated into the RMD. <Project Name> Risk Manager is responsible for maintaining the RMD.
Figure 2 depicts the Risk Management Process flow.
1
<OSIAdmin 3283
<Project Name<Project Name>Office of Systems Integration / Risk Management Plan
<Date>
Figure 2: Risk Management Process
<OSIAdmin 3283 > 5
<Project Name>Office of Systems Integration / Risk Management Plan
<Date>
Step 1 – Identify
The objective of Step 1 – Identify is to search and find risks before they become problems using risk identification. Risk identification involves a process where concerns about a project are transformed into identified risks. Identified risks can be described and measured. A detailed discussion of the identification process is provided in the sub-paragraphs below.
1-1 Identify and Collect Candidate Risks
Through the use of risk identification methods and the application of industry standards (e.g., TA, IEEE, PMI), the Risk Manager and Risk Analyst search for and identify potential issues and concerns which could impact the overall success of the project. Methods to identify risks may include: monitoring project activities, examining artifacts and documentation, observing, interviewing, polling, surveying, brainstorming, participating in discussions and meetings, conducting focus sessions, and applying the OCIO Oversight guidelines. These potential issues and concerns result in candidate risks.
Risk identification methods will collect candidate risk inputs from the <Project Name> Project participants. <Project Name> Project participants include the <Project Name> Project team, stakeholders, vendors, and the Project team.
1-2 Identify and Provide Candidate Risk Input to the Risk Manager/Risk Analyst
The <Project Name> Project participants, including the project team, stakeholders, and vendors, are key sources for identifying issues and concerns and submitting these as candidate risks to input to the Risk Management process. The <Project Name> Project participants voluntarily submit candidate risks to the Risk Manager/Risk Analyst as input to Step 1-3.
The methods used by the <Project Name> Project participants to submit candidate risks to the Risk Manager include, but are not limited to, the following: verbal, email, or written communication.
Project participants may submit candidate risks to the Risk Manager using the <Project Name> Risk Candidate Identification Form provided in Appendix B, ensuring the key risk identification components identified in Table 2 are captured.
While this form will be the primary tool used for this process, any communication method is acceptable. If this form is not used for submission, the Risk Manager/Risk Analyst will enter the risk data directly into Risk Radar and provide a copy of the data entered to the originator for verification.
1-3 Review Candidate Risks
This step involves collecting candidate risk input from <Project Name> Project participants and reviewing these candidate risks. Candidate risks that can be described and measured become “identified risks”. The Risk Manager/Risk Analyst will work with risk originators and the <Project Name> Project Director and/or designee to achieve consensus on deciding whether or not candidate risks become identified risks.
Reviewing candidate risks includes defining the risk and capturing appropriate information about the candidate risk to support risk analysis in Step 2 – Analyze. “Defining the risk” involves understanding the definition of a risk (see Appendix G: Key Terms), and applying the Criteria for Risk Identification provided in Table 1 as a guide.
Table 1: Criteria for Risk Identification
1. Is it a risk? Is the concern a risk? A risk is a potential event that would have an impact on the success of the project if the event were to occur. The following considerations support the question “Is it a risk?”2. Impact: This step identifies consequences of the risk materializing. Is the impact of the potential risk event on the project significant enough to warrant inclusion in the Risk Management process? This is an initial, informal determination of the risk impact. A formal assessment of the risk impact is done in Step 2 – Analyze.
3. Potential Event. What is the minimum likelihood of the potential risk event occurring? This question considers the degree of uncertainty of the potential risk event. Risk events which have already occurred represent issues, not risks. However, if there is little or no likelihood of the risk event occurring, the risk may not warrant inclusion in the Risk Management process. Potential risk events that have an extremely low likelihood of occurring do not necessarily require the risk to be formally recognized by the <Project Name> Risk Management process. This is an initial, informal determination of the risk probability. A formal assessment of the risk probability is done in Step 2 – Analyze.
Table 2: Risk Identification Components