Perfect_Writer Only

New folder (4)/Template.doc

<Project Name> Risk Management Plan Version: 1.0 Error! Unknown document property name.

<Project Name>

Risk Management Plan

Version Number: 1.0

Version Date: <mm/dd/yyyy>

Notes to the Author

[This document is a template of a Risk Management Plan document for a project. The template includes instructions to the author, boilerplate text, and fields that should be replaced with the values specific to the project.

· Blue italicized text enclosed in square brackets ([text]) provides instructions to the document author, or describes the intent, assumptions and context for content included in this document.

· Blue italicized text enclosed in angle brackets (<text>) indicates a field that should be replaced with information specific to a particular project.

· Text and tables in black are provided as boilerplate examples of wording and formats that may be used or modified as appropriate to a specific project. These are offered only as suggestions to assist in developing project documents; they are not mandatory formats.

When using this template, the following steps are recommended:

1. Replace all text enclosed in angle brackets (e.g., <Project Name>) with the correct field document values. These angle brackets appear in both the body of the document and in headers and footers. To customize fields in Microsoft Word (which display a gray background when selected) select File->Properties->Summary and fill in the appropriate fields within the Summary and Custom tabs.

After clicking OK to close the dialog box, update all fields throughout the document selecting Edit>Select All (or Ctrl-A) and pressing F9. Or you can update each field individually by clicking on it and pressing F9.

These actions must be done separately for any fields contained with the document’s Header and Footer.

2. Modify boilerplate text as appropriate for the specific project.

3. To add any new sections to the document, ensure that the appropriate header and body text styles are maintained. Styles used for the Section Headings are Heading 1, Heading 2 and Heading 3. Style used for boilerplate text is Body Text.

4. To update the Table of Contents, right-click on it and select “Update field” and choose the option - “Update entire table”.

5. Before submission of the first draft of this document, delete this instruction section “Notes to the Author” and all instructions to the author throughout the entire document.

VERSION HISTORY

[Provide information on how the development and distribution of the Risk Management Plan will be controlled and tracked. Use the table below to provide the version number, the author implementing the version, the date of the version, the name of the person approving the version, the date that particular version was approved, and a brief description of the reason for creating the revised version.]

Version Number	Implemented By	Revision Date	Approved By	Approval Date	Description of Change
1.0	<Author name>	<mm/dd/yyyy>	<name>	<mm/dd/yy>	<description of change>

TABLE OF CONTENTS

4 1.0 INTRODUCTION

4 1.1 Purpose Of The Risk Management Plan

4 2.0 risk management Procedure

4 2.1 Process

4 2.2 ROLES AND RESPONSIBILITIES

5 2.3 Risk Identification

5 2.3.1 Methods for Risk Identification

6 2.4 Risk Analysis

6 2.4.1 Qualitative Risk Analysis

6 2.4.2 Quantitative Risk Analysis

6 2.5 Risk Response Planning

7 2.6 Risk Monitoring, Controlling, And Reporting

8 2.7 Risk Contingency Budgeting

8 3.0 Tools And Practices

8 4.0 Closing a Risk

9 5.0 Lessons Learned

10 Appendix A: Risk Management Plan Approval

11 APPENDIX B: REFERENCES

12 APPENDIX C: KEY TERMS

1.0 INTRODUCTION

1.1 Purpose Of The Risk Management Plan

A risk is an event or condition that, if it occurs, could have a positive or negative effect on a project’s objectives. Risk Management is the process of identifying, assessing, responding to, monitoring and controlling, and reporting risks. This Risk Management Plan defines how risks associated with the <Project Name> project will be identified, analyzed, and managed. It outlines how risk management activities will be performed, recorded, and monitored throughout the lifecycle of the project and provides templates and practices for recording and prioritizing risks by the Risk Manager and/or Risk Management Team.

Risks related to IT systems or applications must be identified and documented based on the methodology in NIST SP 800-30, Risk Management Guide for Information Technology Systems. IT system or application weaknesses must be identified on an associated plan of action and milestones (POA&M) and tracked in accordance with HHS POA&M guidelines. Appropriate protective measures must be taken to safeguard sensitive IT system or application weaknesses or vulnerabilities from unauthorized disclosure.

2.0 risk management Procedure

2.1 Process

[Summarize the steps necessary for responding to project risk.]

The project manager working with the project team and project sponsors will ensure that risks are actively identified, analyzed, and managed throughout the life of the project. Risks will be identified as early as possible in the project so as to minimize their impact. The steps for accomplishing this are outlined in the following sections. The <project manager or other designee> will serve as the Risk Manager for this project.

A distinction may need to be made between overall project risk management and IT system or application risk management. Risks related to IT systems or applications must be identified and documented based on the methodology in NIST SP 800-30, Risk Management Guide for Information Technology Systems.

2.2 ROLES AND RESPONSIBILITIES

Role	Responsibilities
Business SME (BSME)	The BSME assists in identifying and determining the context, consequence, impact, timing, and priority of the risk.
Risk Manager or Project Manager (PM)	The Risk Manager or PM is a member of the Integrated Project Team (IPT). The Risk Manager or PM determines if the Risk is unique, identifies risk interdependencies across projects, verifies if risk is internal or external to project, assigns risk classification and tracking number. During the life of the project, they continually monitor the projects for potential risks.
Integrated Project Team	The IPT is responsible for identifying the risks, the dependencies of the risk within the project, the context and consequence of the risk. They are also responsible for determining the impact, timing, and priority of the risk as well as formulating the risk statements.
Risk Owner(s)	The risk owner determines which risks require mitigation and contingency plans, he/she generates the risk mitigation and contingency strategies and performs a cost benefit analysis of the proposed strategies. The risk owner is responsible for monitoring and controlling and updating the status of the risk throughout the project lifecycle. The risk owner can be a member of the project team.
Other Key Stakeholders	The other stakeholders assist in identifying and determining the context, consequence, impact, timing, and priority of the risk.

2.3 Risk Identification

Risk identification will involve the project team, appropriate stakeholders, and will include an evaluation of environmental factors, organizational culture and the project management plan including the project scope, schedule, cost, or quality. Careful attention will be given to the project deliverables, assumptions, constraints, WBS, cost/effort estimates, resource plan, and other key project documents.

2.3.1 Methods for Risk Identification

The following methods will be used to assist in the identification of risks associated with <Project Name>:

· Brainstorming

· Interviewing

· SWOT (Strengths, Weaknesses, Opportunities and Threats)

· Diagramming

· Etc.

A Risk Management Log will be generated and updated as needed and will be stored electronically in the project library located at <file location>.

2.4 Risk Analysis

All risks identified will be assessed to identify the range of possible project outcomes. Risks will be prioritized by their level of importance.

2.4.1 Qualitative Risk Analysis

The probability and impact of occurrence for each identified risk will be assessed by the project manager, with input from the project team using the following approach:

Probability

· High – Greater than <70%> probability of occurrence

· Medium – Between <30%> and <70%> probability of occurrence

· Low – Below <30%> probability of occurrence

Impact

Impact	H
	M
	L
		L	M	H
	Probability

· High – Risk that has the potential to greatly impact project cost, project schedule or performance

· Medium – Risk that has the potential to slightly impact project cost, project schedule or performance

· Low – Risk that has relatively little impact on cost, schedule or performance

Risks that fall within the RED and YELLOW zones will have risk response plan which may include both a risk response strategy and a risk contingency plan.

2.4.2 Quantitative Risk Analysis

Analysis of risk events that have been prioritized using the qualitative risk analysis process and their affect on project activities will be estimated, a numerical rating is applied to each risk based on quantitative analysis, and then documented in this section of the risk management plan.

2.5 Risk Response Planning

Each major risk (those falling in the Red & Yellow zones) will be assigned to a risk owner for monitoring and controlling purposes to ensure that the risk will not “fall through the cracks”.

For each major risk, one of the following approaches will be selected to address it:

· Avoid – Eliminate the threat or condition or to protect the project objectives from its impact by eliminating the cause

· Mitigate – Identify ways to reduce the probability or the impact of the risk

· Accept – Nothing will be done

· Contingency –Define actions to be taken in response to risks

· Transfer – Shift the consequence of a risk to a third party together with ownership of the response by making another party responsible for the risk (buy insurance, outsourcing, etc.)

For each risk that will be mitigated, the project team will identify ways to prevent the risk from occurring or reduce its impact or probability of occurring. This may include prototyping, adding tasks to the project schedule, adding resources, etc. Any secondary risks that result from risk mitigation response will be documented and follow the risk management protocol as the primary risks.

For each major risk that is to be mitigated or that is accepted, a course of action will be outlined in the event that the risk does materialize in order to minimize its impact.

2.6 Risk Monitoring, Controlling, And Reporting

The level of risk on a project will be tracked, monitored and controlled and reported throughout the project lifecycle. [Describe the methods and metrics that will be used to track the project’s risk status throughout the lifecycle as well as how this status will be reported to the stakeholders/ management.]

Risks will be assigned a risk owner(s) who will track, monitor and control and report on the status and effectiveness of each risk response action to the Project Manager and Risk Management Team on a <insert timeframe>.

A “Top 10 Risk List” will be maintained by the PM/Risk Manager or IPT and will be reported as a component of the project status reporting process for this project.

All project change requests will be analyzed for their possible impact to the project risks.

As Risk Events occur, the list will be re-prioritized during weekly reviews and risk management plan will reflect any and all changes to the risk lists including secondary and residual risks.

Management will be notified of important changes to risk status as a component to the Executive Project Status Report. [State timeframe, i.e., every two weeks]

The Risk Manager (PM) will:

· Review, reevaluate, and modify the probability and impact for each risk item [timeframe, as needed, every two weeks, etc.]

· Analyze any new risks that are identified and add these items to the risk list (or risk database).

· Monitor and control risks that have been identified

· Review and update the top ten risk list [timeframe, as needed, every two weeks, etc.]

· Escalate issues/ problems to management [List factors that would need to be escalated to management. Examples: documented mitigation actions are not effective or producing the desired results; the overall level of risk is rising.]

The Risk Owner will:

· Help develop the risk response and risk trigger and carry out the execution of the risk response, if a risk event occurs.

· Participate in the review, re-evaluation, and modification of the probability and impact for each risk item on a weekly basis.

· Identify and participate in the analysis of any new risks that occur.

· Escalate issues/problems to PM that,

· Significantly impact the projects triple constraint or trigger another risk event to occur.

· Require action prior to the next weekly review

· Risk strategy is not effective or productive causing the need to execute the contingency plan.

Risk activities will be recorded in the <Document Name/ Risk Database Name> located on <full network path location>.

2.7 Risk Contingency Budgeting

A risk contingency budget can be established to prepare in advance for the possibility that some risks will not be managed successfully. The risk contingency budget will contain funds that can be tapped so that your project doesn't go over budget.

There is a total of <$X> in the <Project Name> Project budget allocated for Risk Management activities. These activities may include, but are not limited to, identifying, analyzing, tracking, controlling, managing, and planning for risks. This also includes creating and updating the risk response strategies and contingency plans.

[Above is only an example of text that could be used. Enter whatever information is appropriate to outline/ define the budget associated with the Risk Management activities on the project.]

3.0 Tools And Practices

A Risk Management Log will be maintained by the project manager and will be reviewed as a standing agenda item for project team meetings.

Risk activities will be recorded in the <Document Name/ Risk Database Name> located on <full network path location>.

4.0 Closing a Risk

A risk will be considered closed when it meets the following criteria:

· <List the criteria when a risk can be closed>

· <Who has the authority to close a risk? >

Examples:

· Risk is no longer valid

· Risk Event has occurred

· Risk is no longer considered a risk

· Risk closure at the direction of the Project Manager

5.0 Lessons Learned

The lessons learned will be captured and recorded in the <Document Name/ Risk Database Name/Lessons Learned document or folder> located on <full network path location>.

Appendix A: Risk Management Plan Approval

The undersigned acknowledge that they have reviewed the <Project Name> Risk Management Plan and agree with the information presented within this document. Changes to this Risk Management Plan will be coordinated with, and approved by, the undersigned, or their designated representatives.

[List the individuals whose signatures are desired. Examples of such individuals are Business Owner, Project Manager (if identified), and any appropriate stakeholders. Add additional lines for signature as necessary.]

Signature:		Date:
Print Name:
Title:
Role:

Signature:		Date:
Print Name:
Title:
Role:

Signature:		Date:
Print Name:
Title:
Role:

APPENDIX B: REFERENCES

[Insert the name, version number, description, and physical location of any documents referenced in this document. Add rows to the table as necessary.]

The following table summarizes the documents referenced in this document.

Document Name	Description	Location
<Document Name and Version Number>	<Document description>	<URL or Network path where document is located>

APPENDIX C: KEY TERMS

The following table provides definitions and explanations for terms and acronyms relevant to the content presented within this document.

Term	Definition
[Insert Term]	<Provide definition of term and acronyms used in this document.>