《OSI Risk Management Plan TemplateCalifornia.doc》由会员分享，可在线阅读，更多相关《OSI Risk Management Plan TemplateCalifornia.doc（43页珍藏版）》请在三一文库上搜索。
1、 Risk Management Plan Health and Human Services Agency, Office of Systems Integration Revision History REVISION HISTORY REVISION/WORKSITE #DATE OF RELEASEOWNERSUMMARY OF CHANGES SID Docs #3164v406/23/2004SID - PMOInitial Release OSIAdmin 328308/29/2008OSI - PMOMajor revisions made. Incorporated tail
2、oring guide information into this template Remove template revision history and insert Project Risk Management Plan revision history. Approvals NAME ROLEDATE Insert Project Approvals here. Template Instructions: This template is color coded to differentiate between boilerplate language, instructions
3、, 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 fin
4、alized. 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 boil
5、erplate 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 languag
6、e 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
7、following the on-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 Contents 1.INTRODUCTION .1 1.1PURPOSE.1 1.2SCOPE.1 1.
8、3REFERENCES.1 1.3.1Best Practices Website.1 1.3.2External References .1 1.3.3Project Risk Database (PRD) .1 1.4ACRONYMS.1 1.5DOCUMENT MAINTENANCE.2 2.PARTICIPANTS ROLES AND RESPONSIBILITIES.2 2.1OFFICE OF SYSTEMS INTEGRATION (OSI).2 2.1.1Project Director.2 2.1.2Project Manager (PM).2 2.1.3Risk Manag
9、er.3 2.1.4Risk Analyst.3 2.1.5Project Stakeholders and Vendors .3 3. PROJECT RISK MANAGEMENT .3 3.1RISK MANAGEMENT PROCESS.3 4.RISK MANAGEMENT TOOL PROJECT RISK DATABASE (PRD).19 4.1RISK RADAR .19 4.2RISK CATEGORIZATION.19 4.2.1Risk Area .19 4.2.2Current Status.19 4.2.3Control .20 4.3RISK RATINGS.20
10、 5.PROJECT CLOSEOUT.20 5.1RISK REVIEW.20 5.2LESSONS LEARNED.21 5.3ARCHIVE AND STORAGE.21 APPENDIX A : LIST OF SEI RISK TAXONOMY QUESTIONNAIRE TOPICS.A-1 APPENDIX B : PROJECT RISK DATABASE DATA ELEMENTS .B-1 APPENDIX C : RISK CANDIDATE IDENTIFICATION FORM .C-1 APPENDIX D : SOFTWARE INTEGRITY LEVEL SC
11、HEME.D-1 APPENDIX E : MITIGATION STRATEGY however it may be performed more frequently on an as-needed basis. 5-4 Report Risk Status The Risk Analyst will report risk status as part of the weekly Project Risk Reports (summary and detailed ranked risks) to the Project Director, Functional Managers, an
12、d other designated parties. Risk status reporting will focus on high severity risks. Information presented will include the status of risk mitigation and contingency action plans, changes in risk severity for known risks, new risks identified, and any risks scheduled for retirement. At a minimum, th
13、e Risk Manager and Risk Analyst will meet with the Project Director to review all risks on a monthly basis. If required by TA, the Independent Project Oversight Contractor (IPOC) will report High Severity/High Criticality project risks on a monthly basis to the OSI, CHHSA, and TA as part of its Inde
14、pendent Project Oversight Report. 5-5 Maintain the Project Risk Database The Risk Analyst will maintain the risk information in the Project Risk Database. A description of data elements to be maintained in the Project Risk Database is provided in Appendix B. 5-6 Escalation of Project Risk The determ
15、ination of risk escalation is tailored from the TA Information Technology Project Oversight Framework (Section 2). Determination of risk escalation is a function of project criticality and risk severity. Not all risks require escalation, and escalation of project risks will not necessarily result in
16、 a change in project criticality. will use Table 8 as a guide in determining the escalation of individual risks. Table 8: Guide for Determination of Risk Escalation Risk Escalation Risk Severity HighMediumLow HighCHHSACHHSASponsor/OSI MediumCHHSACHHSASponsor/OSI Project Criticality LowCHHSASponsor/O
17、 SI Sponsor/OSI The weekly Project Risk Reports will be used to report all risks (Low, Medium and High Severity) to the Project Sponsor. These risks are discussed at the monthly Executive Committee Meeting. The Project Director is a member of the Office of Systems Integration (OSI) Executive Team. D
18、uring the weekly OSI Executive Team Meeting, the OSI Executive Team will use these reports to escalate enterprise level risks (for example, risks that affect more than one OSI project). Risks that have a High Severity determination as well as Medium Severity/High Criticality and Medium Severity/Medi
19、um Criticality risks are reported and escalated to the CHHSA by the OSI Director at the monthly meeting. 5-7 Risk Retirement When a risk is ready for retirement the Risk Analyst will send a risk closure analysis to the Risk Manager for review. The Risk Manager will forward the risk closure analysis
20、along with his own analysis to the Project Director for final approval. Once approved the risk is updated and retired in the project risk database. Communicate Continuous Process: Effective risk management requires ongoing communication throughout the project life cycle. will include communication o
21、f project risks as an ongoing activity throughout each of the above 5 steps (Identify, Analyze, Plan, Implement, Track and Control). As the primary contact between the Risk Management process and the Risk Owners, the Risk Manager and Risk Analyst bear the responsibility of ensuring that members of t
22、he project team understand the value of their input in the process and feel free to submit risks in a forum and format with which they are most comfortable. 4. RISK MANAGEMENT TOOL PROJECT RISK DATABASE (PRD) 4.1 Risk Radar The project uses Risk RadarTM to help manage project risks. Risk RadarTM is
23、a risk management database designed to identify, organize, prioritize, track and display project risks. The application provides standard database functions to add and delete risks, as well as specialized functions for prioritizing and retiring project risks, as well as maintain a log of historical
24、events. Project management uses this tool to characterize, rank and communicate project risks. 4.2 Risk Categorization 4.2.1 Risk Area tracks risk area(s) using the three areas of cost, schedule and performance. 4.2.2 Current Status Risks will be assigned a status in order to facilitate review of pr
25、oject risks that may need to have the mitigation and/or contingency plan implemented. The risk manager assigns each risk to one of the following categories: Candidate Risk possible risk has been identified, but full analysis has not been done to determine if it should be tracked and mitigated. Ident
26、ified Risk A candidate risk becomes an identified risk when it has been determined that it can be described and measured. Then the identified risk is input to the Project Risk Management process and recorded in the Project Risk Database (PRD) as a risk item. Confirmed Risk risk has been fully analyz
27、ed and determined to be a true risk to the project. Mitigation and contingency plans have been developed. The risk will be monitored or tracked on an ongoing basis. Watch risk will be reviewed frequently to determine if the risk needs to be mitigated, retired, or if the risk is out of project manage
28、ments sphere of influence but outcome needs to be recorded. Retired risk is either no longer applicable or the risk has been closed. 4.2.3 Control In order to track those project risks under project managements oversight verses those risks that are external, risks will be identified by one of the fo
29、llowing control categories: External control of the risk is outside the oversight/authority of OSI and management. Internal control of the risk is the responsibility of OSI and/or management. Internal and External OSI and/or management and an external entity are responsible for control of the risk.
30、4.3Risk Ratings The following ratings will be assigned to each risk: Probability likelihood (percentage) the risk will occur over the identified time frame. (1 percent is very low, 99 percent is very high.) Impact the impact the risk will have on the project if the risk occurs. (Impact is rated as:
31、1=very low, 2=low, 3=moderate, 4=high, and 5=very high.) Exposure Risk Radar computes the exposure rating (probability times impact; .01=very low, 4.95=very high). Impact Time Frame earliest and latest dates of time frame over which the risk could occur (beginning and end). Risk Radar also measures
32、the number of Days to Impact Time Frame. Impact Horizon customized values used to compare the impact time frame of a risk to classify its impact horizon as: -Short-term (potential impact in less than 180 days). -Medium-term (potential impact in 180 to 360 days). -Long-term (potential impact beyond 3
33、60 days). 5. PROJECT CLOSEOUT 5.1 Risk Review At the completion of the project or retirement of the system, the Risk Manager will lead a final risk review to document the final status and results of mitigation and contingency actions. The results of the risk actions (whether successful or unsuccessf
34、ul) will be documented in the PRD. 5.2 Lessons Learned The Risk Manager and the management team will develop a set of Lessons Learned based on the results of the final risk review. The results of the lessons learned sessions will be shared with the OSI Project Management Office for inclusion in offi
35、ce-level lessons learned and the OSI Risk List, as appropriate. 5.3 Archive and Storage Once the final documentation of risks and outcomes is completed, the PRD will be archived and stored with all other project related documentation. APPENDICES LIST APPENDICES AS NEEDED Appendix A : LIST OF SEI RIS
36、K TAXONOMY QUESTIONNAIRE TOPICS A. Product EngineeringB. Development EnvironmentC. Program Constraints 1. Requirements1. Development Process1. Resources a. Stabilitya. Formalitya. Schedule b. Completeness b. Suitabilityb. Staff c. Clarityc. Process Controlc. Budget d. Validityd. Familiarityd. Facili
37、ties e. Feasibilitye. Product Control2. Contract f. Precedent2. Development Systema. Type of Contract g. Scalea. Capacityb. Restrictions 2. Designb. Suitabilityc. Dependencies a. Functionalityc. Usability3. Program Interfaces b. Difficultyd. Familiaritya. Customer c. Interfacese. Reliabilityb. Assoc
38、iate Contractors d. Performancef. System Supportc. Subcontractors e. Testabilityg. Deliverabilityd. Prime Contractor f. Hardware Constraints3. Management Processe. Corporate Management g. Non-Developmental Software a. Planningf. Vendors 3. Code and Unit Testb. Project Organizationg. Politics a. Feas
39、ibilityc. Management Experience b. Testing d. Program Interfaces c. Coding/Implementation4. Management Methods 4. Integration and Testa. Monitoring a. Environmentb. Personnel Management b. Productc. Quality Assurance c. Systemd. Configuration Management 5. Engineering Specialties5. Work Environment a. Maintainabilitya. Quality Attitude b. Reliabilityb. Cooperation c. Safetyc. Communication d. Securityd. Morale e. H