ATTM 016.pdf

Document number: PGM.PLAN.0003 Version: 6.0

Delivery of Automated Systems for Healthcare (DASH) Program

Risk Management Plan

ATTM 016

PGM.PLAN.0003 – Risk Management Plan Ver.6.0

Table of Contents

1. INTRODUCTION

1.1. PURPOSE

1.2. SCOPE

1.3. ASSUMPTIONS AND CONSTRAINTS

1.3.1. Assumptions

1.3.2. Constraints

1.4. STAKEHOLDERS

1.5. REFERENCES

2. RISK MANAGEMENT ROLES AND RESPONSIBILITIES

3. RISK MANAGEMENT PROCESS AND APPROACH

3.1. RISK IDENTIFICATION AND VERIFICATION

3.2. RISK ANALYSIS

3.2.1. Risk Timeframe

3.2.2. Risk Trigger Event

3.2.3. Risk Impact

3.2.4. Risk Probability

3.2.5. Risk Priority

3.3. RISK RESPONSE PLANNING

3.4. RISK MANAGEMENT AND CONTROL

3.5. RISK CLOSURE

4. RISK MANAGEMENT TOOL

5. RISK MANAGEMENT METRICS

6. RISK MANAGEMENT REPORTING

7. GOVERNANCE AND PLAN MAINTENANCE

APPENDIX A GLOSSARY OF TERMS

1. Introduction

1.1. Purpose

Risk is defined as “An uncertain event or condition that, if it occurs, has a positive or negative effect on one or more project objectives”. The purpose of a risk management process is to reduce uncertainty and avoid conditions that may increase costs, extend the project schedule, or negatively impact project quality. This is accomplished by developing strategies and responses that can reduce the probability of the identified events from occurring or reducing the impact if they do occur. The management of risks is accomplished by having a comprehensive plan that defines all aspects of the risk process, from risk identification to closure. By developing a comprehensive plan, the strategies and responses can reduce the probability of the identified events from occurring or reducing the impact if they do occur.

The Risk Management Plan:

• Provides a framework for the management of risks throughout the life of the project

• Provides a coordinated, defined, documented, repeatable and measurable process for successful risk management for the project

• Defines roles and responsibilities of team members in the risk management process

• Defines the risk management tools and techniques used to identify, analyze, communicate, mitigate, monitor, control and report the risks that could impact the project

1.2. Scope

The scope of the Risk Management Plan covers the complete risk life cycle from identification through monitoring and closure. This includes:

• Risk identification and management

• Risk analysis and prioritization

• Risk response strategies and Risk Owner responsibilities

• Identification of risk triggers and development of response plans

• Monitoring, communication, and escalation

• Risk management tools and templates

Note: Opportunities will be managed using the Change Management Plan.

1.3. Assumptions and Constraints

1.3.1. Assumptions

• SCDHHS and Vendor resources will be made available to participate in risk identification and risk response planning activities

• Project team members and assigned Risk Owners will have the appropriate skills to manage risks

• Project teams may engage resources external to the project to assist with risk analysis and response planning when required

• The SharePoint project Risk Logs will be maintained as the source of truth for project risks

1.3.2. Constraints

• There are limited resources available to conduct risk management

1.4. Stakeholders

This document is intended to provide information and guidance to the following SCDHHS/Vendor groups or individuals:

• Program Management

• Project Managers

• Risk Owners

• Independent Verification and Validation (IV&V)

• Vendor Project Teams

1.5. References

[1] A Guide to the Project Management Body of Knowledge – PMI – Seventh Edition

[2] The Standard for Risk Management in Portfolios, Programs, and Projects – PMI

[3] PGM.PROC.0002 – Documentation Management Process

[4] PGM.PLAN.0006 – Change Management Plan

2. Risk Management Roles and Responsibilities The following are the specific roles and responsibilities of team members involved in the risk management process. Roles and responsibilities are captured in Table 1.

Table 1: Roles and Responsibilities

Role Responsibility

Vendor Project Manager • Validates and develops details of potential risks and reviews them with the DASH Program Manager and SCDHHS Project Manager

• Formulates risk response plans for assigned risks

• Monitors and reports on assigned risks in Risk and Issue Review

Meeting

DASH Program Management Office (PMO) Manager

• Creates and updates Risk Management Plan and risk processes

• Coordinates information as needed with project team members

• Validates potential risks with SCDHHS Project Manager and enters them into the Risk Log

• Facilitates Risk and Issue Review Meetings

• Produces risk information for status reports

• Provides coaching and guidance to Risk Owners as it relates to maintaining the Risk Log

DASH Program Manager • Participates in Risk and Issue Review Meetings

• Assesses, reports, and escalates critical risks to DASH Program

Director

• Reports to DASH Program Director for awareness and assistance in responding to risks as appropriate

DASH Program Director • Participates in Risk and Issue Review Meetings

• Reports to Chief Information Officer (CIO) or their designee on critical risks that require executive awareness and assistance

SCDHHS Project Manager • Validates and develops details of potential risks and reviews them with the DASH PMO Manager

• Escalates critical risks to the DASH Program Manager

• Ensures project conformance to risk policies and processes

• Reports to DASH Program Manager for awareness and assistance in responding to risks as appropriate

• Reviews and approves risk response plan proposals

• Reviews and approves risk response activities and results

Risk and Issue Review Team • Membership includes DASH Program Director, DASH Program Manager, DASH PMO Manager, Vendor Project Manager, SCDHHS Project Manager, DASH Requirements Manager, DASH Test Manager, DASH Technical Manager, Risk and Issue Owners, and other internal and external stakeholders as required

• Confirms or updates probability and impact assessments

• Confirms or reassigns Risk Owners

• Approves risk response plans

• Monitors status updates for risk response plans

Risk Owner • Conducts detailed risk analysis

• Formulates risk response plans

• Drives actions described in risk response strategies

• Monitors the risk triggers until the risk occurs or expires

• Ensures that triggers and risk response strategies are kept current as the project progresses

• Monitors the execution and effectiveness of risk response strategies that are executed

• Recommends the closure of risks

3. Risk Management Process and Approach The purpose of the Risk Management Process is to identify, analyze and monitor risks continuously. The Risk Management Process is a continuous process for systematically addressing risk throughout the life cycle of a system or software product or service. It can be applied to risks related to the acquisition, development, maintenance, or operation of a system.

The major activities of the risk management process are illustrated in Figure 1:

END

START

3.1

Risk Identification and Verification

Verify Risk Assign Risk OwnerCreate Risk Log

YES

YES

NO

NO

NO

3.4 Risk Management

and Control

Has the risk been triggered?

Risk confirmed by PMO Manager?

Risk Response Plan approved?

3.2 Risk Analysis

3.3 Risk Response Planning

Review Risk Response Plan with Leadership

Implement Contingency Actions

3.5 Risk Closure

Risk response complete?

YES

YES

NO

Initiate Issue Management

Process

Issue Management

Process

Notify Risk Owner

Risk converted to an Issue?

NO

YES

Notify Risk Owner

Risk and Issue Review Team

Risk Confirmed?NO

YES

Close Risk

Figure 1: Risk Management Process

3.1. Risk Identification and Verification

Whether a risk is identified informally or through a formal risk planning or review session, risk identification occurs. An ongoing practice will be to identify risks throughout the project and as part of the normal course of completing project work. All team members will be encouraged to identify risks within their subject areas. Two indicators of successful risk identification are the number of valid risks identified and that risks are documented in sufficient detail to enable effective management.

Risks may be identified through:

• Scheduled reviews at the beginning of each life cycle phase

• Weekly and/or bi-weekly risk management or status reviews

• Specific document reviews, including schedule and requirements reviews

• Stakeholder interviews

• Brainstorming for risks when discussing topics which present uncertainty or threats

• Reviewing assumptions

• Reviewing historical records and documents, including Lessons Learned documents

• Independent Validation and Verification (IV&V) activities

• Other risk management identification techniques

Any stakeholder or project team member at any time during the project life cycle may identify a risk.

The person identifying a risk will submit it through the InBox process, outlined in PGM.PROC.0002 - Document Management Process.docx.

The information required for initial entry of a potential risk includes a title and description.

Clear articulation of the risk description is important to allow consistent communication about risks.

• The risk description must clearly identify the area of uncertainty

• Risks should be stated as “IF (something happens or doesn’t happen) THEN (something else happens or doesn’t happen as a result)”

Verified risks from the InBox process in SharePoint are reviewed by the DASH PMO Manager. If the DASH PMO Manager determines the item is not actually a risk, the person submitting the risk is notified and the entry is closed in the InBox. If more information is needed or the risk statement is not clear, the item is returned to the originator for clarification.

If the item is confirmed to be a valid risk, the DASH PMO Manager records the risk in the Risk Log with a status of DRAFT.

The risk is discussed at the next meeting of the Risk and Issue Review Team. At that time, the risk may be rejected by the team, in which case the DASH PMO Manager would change the status of the risk in the Risk Log to CLOSED, with reason REJECTED and explanatory comments. If the risk is not rejected, the Risk and Issue Review Team will confirm or assign an owner and the risk status changes to ASSIGNED. The Risk Owner is someone who understands the cause, the risk, and its impacts and owns the risk response plan and execution.

3.2. Risk Analysis

The purpose of risk analysis is to determine relative project risk exposures in terms of scope, time, and cost. When the Risk Owner begins analyzing the risk, they will change the status to PLANNING. During this step, the Risk Owner will analyze the following for the risk and update the risk in the Risk Log accordingly:

• Timeframe

• Trigger Event

• Impact

• Probability

• Priority

3.2.1. Risk Timeframe

The risk timeframe captures the urgency of responding to a risk, focusing on the timeframe that the risk might impact the project. Timeframes are categorized in Table 2.

Table 2: Risk Trigger Timeframes

Timeframe Description

Long-Term The risk might impact the project more than six months after identification.

Mid-Term The risk might impact the project from one month to six months after identification.

Near-Term The risk might impact the project within one month of identification.

On-Going The risk might impact the project at any time during the duration of the project.

3.2.2. Risk Trigger Event

The risk trigger event is an observable event that indicates a risk has either occurred or is about to occur and is used in monitoring risk status. The risk trigger event is generally associated with a risk trigger date when the trigger event might occur or be observed;

this date is typically associated with the value of the risk timeframe listed in Table 2.

3.2.3. Risk Impact

Risk impact represents the potential impact of the risk on the project. Where possible, this assessment is guided by specific estimates or other objective measurements; in other cases, it is guided by the experience and judgment of the project team members.

The Risk Owner and project team members may use their experience from other projects to help determine the severity of the impact. Risk impact is established based on the definitions shown in Table 3.

Table 3: Risk Impact Definitions

Schedule Cost Quality*

Im pa ct L ev el

Critical > 6 months or critical path impact

> 500K Critical impact on project objective or overall functionality

Major 4 - 6 months 101K – 499K Major impact to project objective or overall functionality

Moderate 2 - 4 months 51K – 100K Moderate impact to a project objective

Minor 1 - 2 months 10K – 50K Minor impact to project objective

Negligible < 1 month < 10K No impact to project objectives

* As determined by SCDHHS PM – Schedule/Cost variances may vary by project

3.2.4. Risk Probability

Risk probability values describe the likelihood that an event will occur and are defined using percent values. These probabilities are shown in Table 4.

Table 4: Risk Probability Definitions

Probability Description

Remote Less than 10 percent probability the event will occur

Highly Unlikely 10-34 percent probability the event will occur

Probable 35-60 percent probability the event will occur

Highly Likely 61-89 percent probability the event will occur

Certain 90 percent or above probability the event will occur

3.2.5. Risk Priority

The overall risk priority is used by the Risk Owner and the project manager for prioritization of risks. The risk priority is based on two intersecting factors: the likelihood that the risk event will occur, and the potential impact of the risk, as shown in Figure 2.

Figure 2: Risk Priority Metrics

Risk Priority Metrics Impact Negligible Minor Moderate Major Critical

Pr ob ab ili ty Certain Low Medium Medium High High

Highly Likely Low Low Medium Medium High Probable Low Low Medium Medium Medium Highly Unlikely Low Low Low Low Medium Remote Low Low Low Low Low

Each risk is assigned a risk priority that represents the overall criticality of each risk and the planning approach that should be taken for it, as shown in Table 5.

Table 5: Risk Priority Approach

Risk Priority Planning Approach

Low Risk is less significant and may not require a response plan

Medium Risk is significant and will generally require a response plan

High Risk is very significant and must have a response plan

3.3. Risk Response Planning

Risk response planning is the process of developing strategies and defining actions to reduce threats to the project and developing contingency plans to reduce the impact if the risk becomes a reality.

The general approach documented in this process is:

• Develop one or more strategies for addressing the risk

• Develop one or more contingent actions to take if the risk becomes a reality

• Secure approval of strategies and actions from the Risk and Issue Review Team

• Develop plans to implement the strategies and actions

• Execute the risk response plan

The following are risk response strategies:

• Accept. Project team acknowledges the existence of a threat, but no proactive action is taken. Contingent actions may be identified.

• Avoid. Project team acts to eliminate a threat or protect activity from risk impact

• Mitigate. Project team takes action to reduce the probability of occurrence and/or impact of a threat

• Transfer. Project team with coordination with leadership shifts responsibility of a threat to a third party to manage the risk and bear the impact if the threat occurs

• Escalate. Risk and Issue Review Team communicates the risk to the Chief Information

Officer (CIO) or their designee for resolution

The determination of risk response strategies and contingent actions is guided by multiple factors including the priority of the specific risk and the availability of project or organizational resources or budget to support response plans.

When the Risk Owner determines that analysis and planning are complete, and the risk and responses are ready to be reviewed by the Risk and Issue Review Team, he or she changes the status to PENDING APPROVAL.

Risk response strategies and contingent actions are reviewed at regular Risk and Issue Review Meetings. This is an iterative process. Strategies and contingent actions may be revised throughout the life of the risk.

When the specific strategies have been approved, changes will be made to the affected project documents, which may include scope, schedule, or budget documents along with others, and the strategies will be implemented by the assigned parties. Changes to approved documents will be made according to PGM.PLAN.0006 - Change Management Plan.docx. At this point the Risk Owner changes the status to MONITORING.

3.4. Risk Management and Control

Once the risk response plans have been approved by the Risk and Issue Review Team, risks are monitored on an ongoing basis by their respective Risk Owners, and updates are provided at regular Risk and Issue Review Meetings. The DASH PMO Manager oversees the monitoring process and follows up with Risk Owners to confirm updates as necessary.

Following specific details outlined in the approved risk response plan, the Risk Owner maintains awareness of the status of the risk, including attention to any specific risk triggers. The Risk Owner reports changes in risk status either at the Risk and Issue Review Meetings or through written communication (such as email). If the Risk Owner observes that either a defined risk trigger or the risk itself has occurred, the Risk Owner will initiate the previously agreed set of contingency actions.

3.5. Risk Closure

Risks are monitored until they are no longer risks, i.e., there is no remaining uncertainty about the item. Reasons for closure include:

• The risk occurs (i.e., the probability is 100%), in which case the concern is generally converted to an issue for ongoing management

• The risk can no longer occur (i.e., probability is zero), generally because the time period during which the risk could occur has passed

• The risk was withdrawn

• The risk can no longer occur (i.e., probability is zero), because the risk response activities caused the risk to be avoided

• The risk has been accepted and the decision made that no monitoring is required

• The risk has been transferred to a third party

• The risk trigger date or trigger event expired, and the risk was not realized and can no longer occur (i.e., probability is zero)

The DASH PMO Manager monitors status updates from the Risk Owners to understand situations where risks can be closed, and ensures that any required actions (e.g., creation of an associated issue) are completed before closing the risk in the Risk Log with a status of

CLOSED.

4. Risk Management Tool Risks will be tracked and monitored in the Risk Log within the project SharePoint site. Details are entered in the risk form incrementally as the risk is identified, analyzed, and response plans developed and revised. Updates to the Risk Log is controlled by the Risk Owner. The Risk Log form field definitions are listed in Table 6.

NOTE: Some column values are subject to change depending on the project.

Table 6: Risk Form Field Definitions

Field Values Risk Title A short and descriptive name for the risk

Risk Description Detailed description of the item in “IF” and “THEN” statements

Category • Schedule

• Scope

• Budget

• Resources

• Communication

• Quality

• Fed Cert

• OCM

Functional Area • Claims

• Member

• Provider

• Program Integrity

Field Values

• Reference

• PA/QIO

• Finance

• Legacy MMIS

• Reporting

• Non-Functional

Originator The individual who initiated and raised the risk

Risk Owner Individual responsible for ensuring the item is resolved.

Monitors risk status and provides updates

Risk Status • Draft: Risk has been submitted by the Risk Originator and verified by the DASH PMO Manager but has not yet been accepted by the Risk and Issue Review Team. All risks are created in the Draft status

• Assigned: Risk and Issue Review Team has reviewed the risk and assigned a Risk Owner, but analysis and resolution has not begun

• Planning: Risk Owner is in the process of actively formulating or reworking the response plan for this risk

• Monitoring: Risk Owner is actively monitoring the risk and ensuring that response strategies approved by the Risk and Issue Review Team are being executed

• Pending Approval: Plans have been completed and are ready for Risk and Issue Review Team review and approval

• Closed: Risk has been closed by the Risk and Issue Review Team. The DASH PMO Manager or Risk Owner will set the State of the risk to “Closed” and will enter the closure reason in SharePoint

Current Status Long text description of the history of status of the item.

New entries should be at the top, and preceded with Date and Initials

InBox# The system assigned InBox number from the risk initiation process

Risk Timeframe • Long Term: The risk might impact the project within six months or longer

• Mid Term: The risk might impact the project within one to six months

• Near Term: The risk might impact the project in less than one month

• On-Going: The risk might impact the project at any point in time

Risk Impact • Negligible: There are no or negligible impacts to schedule, cost, or quality

• Minor: Minor impact to schedule, cost, or quality

• Moderate: Moderate impact to schedule, cost, or quality

Field Values

• Major: Major impact to schedule, cost, or quality

• Critical: Critical path impact; or critical impact to schedule, cost, or quality Risk Probability • Remote: Less than 10 percent probability the trigger event will occur

• Highly Unlikely: 10 – 34 percent probability the trigger event will occur

• Probable: 35 - 60 percent probability the trigger event will occur

• Highly Likely: 61 - 89 percent probability the trigger event will occur

• Certain: Greater than 90 percent probability the trigger event will occur

Risk Priority • High: Risk is very significant and must have a response plan

• Medium: Risk is significant and will generally require a response plan

• Low: Risk is less significant and may not require a response plan

Risk Trigger Date Date when the trigger event might occur or be observed; this date is typically associated with the value of the Risk Timeframe

Risk Trigger Event An observable event that indicates a risk has either occurred or is about to occur, is used in monitoring risk status

Risk Response Strategy • Accept: Project team acknowledges the existence of a threat, but no proactive action is taken

• Avoid: Project team acts to eliminate a threat or protect activity from risk impact

• Escalate: The Risk and Issue Review Team will communicate to CIO or designee for resolution

• Mitigate: Project team takes action to reduce the probability of occurrence and/or impact of a threat

• Transfer: Project team with coordination with leadership shifts responsibility of a threat to a third party to manage the risk and bear the impact if the threat occurs

Risk Response Plan Response plans are free form text entries that address:

• Actions to be taken (if any)

• Cost (optional)

• Timeline (optional)

• Resources needed (optional)

• Expected impact of actions (optional)

Contingency Action Action that needs to occur when a risk has been triggered, such as schedule impact

Next Review Date The date of the next risk review at the Risk and Issue Review Meeting

Vendor Tracking ID Number assigned from Vendor project tracking system, if applicable

Field Values Risk Closure Date Date the risk was closed

Closure Reason • Accepted: The Risk and Issue Review Team has decided to accept the risk, i.e., to deal with the consequences of the risk when it is triggered

• Avoided: Risk response activities nullified the risk

• Expired: The exposure window of the risk has closed; that is, the risk is no longer possible

• Overtaken by Events: Some non-mitigation event/activity changed the risk probability and/or impact to zero

• Rejected: The Risk and Issue Review Team rejected the risk

• Not Applicable – Open Risk: The risk item is open and actively being worked or monitored

• Triggered: One or more of the documented risk events occurred

• Transferred: The Risk and Issue Review Team has decided to transfer the risk to another party. An example of this would be to purchase insurance to cover the occurrence of some event

• Withdrawn: The risk was withdrawn by the Risk Originator

Project Phase If used, this field will have a project-specific list of values

Attachments Separate document(s) or file(s) related to the action item

5. Risk Management Metrics The following metrics will be used to assess the risk management process.

Counts of open risks by Priority/Status (status values of Closed/Rejected excluded)

Open Risks by Priority and Status

[Insert Data Only from Pivot Table]

Open Risks Priority

High Medium Low Grand Total

St at us

Assigned 1 1

Draft 1 1

Monitoring 1 1

Pending Approval 1 1

Planning 1 1

Grand Total 1 2 2 5

* Follow instructions in “How To Export Risk Metrics.docx” in Project SharePoint site at Documents/Project Documents/How To.

Open Risks

Open Risks*

[Insert Data Only from “Status Report Open Risks” View] ID Risk Title Risk Owner Risk

Priority Risk

Response Strategy

Risk Trigger Date

Risk Status

* Excludes Closed Status

• Use the view “Status Report Open Risks”

• Export the data in the view to Excel

• Verify the table in the Status Report has the correct number of data rows

• Copy the data only into the status report table (the tables are formatted differently than an entire table from Excel)

• Verify the count of data rows

Risks Closed Since Last Report

Risks Closed Since Last Report*

[Insert Data Only from “Status Report Closed Risks” View] ID Risk Title Risk Owner Risk

Priority Risk

Response Strategy

Risk Closure Date

Closure Reason

* Includes Closed with Risk Closure Date since last report

• Use the view “Status Report Closed Risks”

• Export the data in the view to Excel

• Remove all rows included in previous status reports

• Verify the table in the status report has the correct number of data rows

• Copy the data only into the status report table (the tables are formatted differently than an entire table from Excel)

• Verify the count of data rows

6. Risk Management Reporting Risk metrics will be created weekly and monthly by the DASH PMO Manager at the direction of the DASH Program Director and DASH Program Manager based on the metrics listed in Section 5.

7. Governance and Plan Maintenance The DASH Program Director is the owner of this plan and has the ultimate decision-making authority to update and approve the plan. As a part of process improvement (e.g., assessments, lessons learned), this plan and the overall approach will continue to evolve. At a minimum, this plan will be reviewed annually and updated as needed.

Appendix A Glossary of Terms

Term Definition Assumption A factor in the planning process that is considered to be true, real, or certain, without proof or demonstration

Constraint A limiting factor that affects the execution of a project, program, portfolio, or process

Contingency Action An action which will be taken if the trigger event occurs, which indicates that the risk is or is becoming a reality.

Impact A measure of the effect of a risk on one or more objectives if it occurs

Risk Probability A measure of how likely a risk is to occur Risk An uncertain event or condition that, if it occurs, has a positive or negative effect on one or more project objectives

Trigger Event A condition or situation that indicates that a risk is about to occur and become an issue