《OSI Risk Management Plan TemplateCalifornia.doc》由会员分享，可在线阅读，更多相关《OSI Risk Management Plan TemplateCalifornia.doc（43页珍藏版）》请在三一办公上搜索。
1、Risk Management PlanHealth and Human Services Agency, Office of Systems IntegrationRevision HistoryRevision HistoryRevision/WorkSite #Date of ReleaseOwnerSummary of ChangesSID Docs #3164v406/23/2004SID - PMOInitial ReleaseOSIAdmin 328308/29/2008OSI - PMOMajor revisions made. Incorporated tailoring g
2、uide information into this templateRemove template revision history and insert Project Risk Management Plan revision history.ApprovalsName RoleDateInsert Project Approvals here.Template Instructions: This template is color coded to differentiate between boilerplate language, instructions, sample lan
3、guage, 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.Stand
4、ard 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 langu
5、age, 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 identifie
6、d 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 o
7、n-screen instructions. To return to the original document after accessing a hyperlink, click on the back arrow in your browsers toolbar. The “File Download” dialog box will open. Click on “Open” to return to this document. Table of Contents1.INTRODUCTION11.1Purpose11.2Scope11.3References11.3.1Best P
8、ractices Website11.3.2External References11.3.3Project Risk Database (PRD)11.4Acronyms11.5Document Maintenance22.PARTICIPANTS ROLES AND RESPONSIBILITIES22.1Office of Systems Integration (OSI)22.1.1Project Director22.1.2Project Manager (PM)22.1.3Risk Manager32.1.4Risk Analyst32.1.5Project Stakeholder
9、s and Vendors33. PROJECT RISK MANAGEMENT33.1Risk Management Process34.RISK MANAGEMENT TOOL PROJECT RISK DATABASE (PRD)194.1Risk Radar194.2Risk Categorization194.2.1Risk Area194.2.2Current Status194.2.3Control204.3Risk Ratings205.PROJECT CLOSEOUT205.1Risk Review205.2Lessons Learned215.3Archive and St
10、orage21APPENDIX A : LIST OF SEI RISK TAXONOMY QUESTIONNAIRE TOPICSA-1APPENDIX B : PROJECT RISK DATABASE DATA ELEMENTSB-1APPENDIX C : RISK CANDIDATE IDENTIFICATION FORMC-1APPENDIX D : SOFTWARE INTEGRITY LEVEL SCHEMED-1APPENDIX E : MITIGATION STRATEGY & CONTINGENCY PLANNING MEASURESE-1APPENDIX F : SOF
11、TWARE ENGINEERING INSTITUTE RISK TAXONOMY CATEGORIESF-1APPENDIX G : KEY TERMSG-1Figure 1: Project Risk Management Paradigm3Figure 2: Risk Management Responsibilities at a Glance5Table 1: Criteria for Risk Identification7Table 2: Risk Identification Components8Table 3: Criteria for Risk Impact10Table
12、 4: Criteria for Risk Probability11Table 5: Criteria for Risk Timeframe12Table 6: Guide for Determination of Risk Exposure13Table 7: Guide for Determination of Risk Severity13Table 8: Guide for Determination of Risk Escalation181. Introduction1.1 PurposeThe purpose of this Risk Management Plan (RMP)
13、 is to describe the methodology for identifying, tracking, mitigating, and ultimately retiring Project risks. This document defines the risk management roles and responsibilities of the Team1.2 ScopeThe scope of this document pertains to the Project and its internal and external risks. The risk mana
14、gement methodology identified in this document will be primarily used by and is to be used during the entire Project. The Vendors risk management methodology will be provided as a contractual deliverable and will develop a separate Risk Management Plan. The Vendor will be responsible for managing th
15、eir project risk and reporting to Project Managers.1.3 References1.3.1 Best Practices WebsiteFor 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 ReferencesPMBOK Guide,
16、3rd Edition, Section 11 - Project Risk Management Office of the Chief Information Officer Information Technology Project Oversight Framework- Section 5: Risk Management and Escalation ProceduresIEEE Standard 1012-1998: IEEE Standard for Software Verification and Validation, 1.3.3 Project Risk Databa
17、se (PRD)Refer to the Risk Radar Database located at . If the project is not using Risk Radar, indicate the name and location of the Project Risk Database the Project is employing. Update the document as appropriate to reflect the name of the PRD.1.4 AcronymsList only acronyms that are applicable to
18、this document.BPWebOSI Best Practices Website http:/www.bestpractices.osi.ca.govCHHSACalifornia Heath and Human Services AgencyIEEEInstitute of Electrical and Electronics EngineersIPOCIndependent Project Oversight ContractorMTSIIManagement Tracking System IIOSIOffice of Systems IntegrationPMIProject
19、 Management InstitutePMOProject Management OfficePRDProject Risk DatabaseRMPRisk Management PlanSEITASoftware Engineering InstituteCalifornia Technology Agency1.5 Document MaintenanceThis document will be reviewed annually and updated as needed, as the project proceeds through each phase of the syst
20、em 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 documents revision history log will reflect an updated versio
21、n 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 staff with regard to the Risk Management Plan. Note
22、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 m
23、ay perform multiple roles in the process. 2.1 Office of Systems Integration (OSI)2.1.1 Project DirectorThe 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 sta
24、keholders, on an as needed basis.2.1.2 Project Manager (PM)The role of the Project Manager is to write and approve the 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
25、 ManagerThe 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
26、 current. The Risk Manager is responsible for providing the Project Manager with recommendations and statuses on risk actions. 2.1.4 Risk AnalystThe Risk Analysts role is to evaluate risks, maintain the Risk Management database, and facilitate communication throughout the execution of the process.2.
27、1.5 Project Stakeholders and VendorsThe role of 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 Risk Management3.1 Risk Management ProcessThe Project Risk
28、Management Paradigm, depicted in Figure 1, summarizes the Risk Management process for the 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 Co
29、mmunicateFigure 1: Project Risk Management ParadigmCommunication is an essential part of the Risk Management and occurs at every step of the process among the stakeholders and contractors.A key component of the Risk Management Process is the Risk Management Database (RMD). team will use this databas
30、e as a repository for Project risk information. The proposed Risk Management Database field descriptions in Table XXX identify and describe the proposed data elements to be incorporated into the RMD. Risk Manager is responsible for maintaining the RMD. Figure 2 depicts the Risk Management Process fl
31、ow. Figure 2: Risk Management Process Step 1 IdentifyThe 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 b
32、e described and measured. A detailed discussion of the identification process is provided in the sub-paragraphs below. 1-1 Identify and Collect Candidate RisksThrough the use of risk identification methods and the application of industry standards (e.g., TA, IEEE, PMI), the Risk Manager and Risk Ana
33、lyst 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
34、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 participants. Project participants include the Project team,
35、stakeholders, vendors, and the Project team. 1-2 Identify and Provide Candidate Risk Input to the Risk Manager/Risk AnalystThe Project participants, including the project team, stakeholders, and vendors, are key sources for identifying issues and concerns and submitting these as candidate risks to i
36、nput to the Risk Management process. The Project participants voluntarily submit candidate risks to the Risk Manager/Risk Analyst as input to Step 1-3.The methods used by the Project participants to submit candidate risks to the Risk Manager include, but are not limited to, the following: verbal, em
37、ail, or written communication.Project participants may submit candidate risks to the Risk Manager using the 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
38、 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 RisksThis step involves coll
39、ecting candidate risk input from 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 Director and/or designee to achieve consensus on deci
40、ding 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 Appendi
41、x G: Key Terms), and applying the Criteria for Risk Identification provided in Table 1 as a guide. Table 1: Criteria for Risk Identification1. 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 foll
42、owing 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
43、 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 repre
44、sent 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
45、by the 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 ComponentsComponentDescriptionOriginatorName and organization of the person who identified and submit
46、ted the candidate risk to the Risk Manager/Risk Analyst. This information will not be required for risk identification methods, which allow anonymous candidate risk input.Origination DateDate the candidate risk was either identified or submitted to the Risk Manager/Risk Analyst (will vary due to the risk ident
