J.3_Attachment_03.pdf

BUSINESS APPLICATIONS SOLUTION (BAS)

RISK MANAGEMENT PLAN

March 2019

V1.7

Department of Commerce Office of Financial Management

Business Applications Solution (BAS) DRAFT Risk Management Plan (RMP)

Version 1.7 Page 2 of 25 Last updated: 5/24/2019

DOCUMENT CONTROL

This section provides control for the development and distribution of revisions to the document.

CHANGE RECORD

VERSION DATE OF ISSUE AUTHOR(S) BRIEF DESCRIPTION OF CHANGE

0.6 10/29/2018 L. Hochberg 2018 Refresh of DRAFT Risk Management Plan

0.7 3/28/2019 L. Hochberg Final updates for escalation

1.0 5/24/2019 L. Hochberg Final Risk Management Plan for RFP

APPROVERS

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

EXECUTIVE SPONSOR – DEPARTMENT OF COMMERCE DEPUTY CFO/ASA

Stephen M. Kunze skunze@doc.gov

Signature: Date:

BAS PROGRAM MANAGER

Teresa Coppolino tcoppolino@doc.gov 301‐355‐5501

BAS PROJECT MANAGER

Lindsay Hochberg lhochberg@doc.gov 301‐355‐5517

Version 1.7 Page 3 of 25 Last updated: 5/24/2019

CONTENTS

DOCUMENT CONTROL

Change Record

Approvers

CONTENTS

1 INTRODUCTION

1.1 Purpose

1.2 Scope

1.3 Project Summary

2 PROJECT RISK MANAGEMENT STRATEGY

2.1 Definitions

2.1.1 Risk

2.1.2 Risk Event

2.1.3 Risk Category

2.1.4 Impact Time Frame

2.1.5 Timeframe

2.1.6 Likelihood / Probability of Occurrence (Po)

2.1.7 Risk Impact

2.1.8 Risk Severity

2.1.9 Risk Handling Approach

2.2 Roles and Responsibilities

2.3 Risk Planning

2.4 Risk Assessment

2.4.1 Risk Identification

2.4.2 Risk Analysis

2.4.3 Risk Severity (Risk Matrix)

2.4.4 Risk Prioritization

2.5 Risk Handling Approach

2.6 Risk Monitoring

2.6.1 Risk Reassessment

2.6.2 Risk Escalation

3 ENTERPRISE RISK MANAGEMENT STRATEGY

3.1 Definitions

3.1.1 Enterprise Risk Consequences

3.1.2 Enterprise Risk Consequences and Consequence Levels

3.1.3 Enterprise Risk Severity

3.2 Enterprise Risk Severity Assessment

3.2.1 Assess Consequence Risk Level

3.2.2 Determining the Overall Enterprise Risk Consequence

Version 1.7 Page 4 of 25 Last updated: 5/24/2019

3.2.3 Determine Enterprise Risk Severity (Enterprise Risk Matrix)

3.3 Enterprise Risk Monitoring

APPENDIX A – STANDARD OVERARCHING RISKS

APPENDIX B – RISK REGISTER DATA ELEMENTS

Version 1.7 Page 5 of 25 Last updated: 5/24/2019

1 INTRODUCTION

1.1 PURPOSE

This plan documents the processes, tools and procedures that will be used to manage and control risks for the Business Applications Solutions (BAS) project. It is the controlling document for managing and controlling all project risks and the activities outlined in this document will be applied to the BAS project and any sub‐projects that may develop during the implementation of BAS.

This Risk Management Plan (RMP) presents the process for implementing proactive risk management as part of the overall management of the Business Applications Solution (BAS) project. Risk management is a project management tool to assess and mitigate events that might adversely impact the project.

Successful implementation of risk management will increase the project’s likelihood of success. This RMP will:

Serve as a basis for identifying alternatives to achieve cost, schedule, and performance goals, Assist in making decisions on budget and funding priorities, Provide risk information for Project Reviews or Milestone decisions, and

Allow for monitoring the health of the project as it proceeds.

The RMP describes methods for identifying, analyzing, prioritizing, and tracking risk drivers; developing risk‐handling plans; and planning for adequate resources to handle risk. It assigns specific responsibilities for the management of risk and prescribes the documenting, monitoring, and reporting processes to be followed.

1.2 SCOPE

The BAS RMP applies to the management of risks associated with the BAS project and any sub‐projects that are initiated as part of the overall BAS effort. This includes all project activities undertaken by any of the Department of Commerce (DOC) bureaus and organizational units and risks that originate both internal and external to the DOC. The BAS RMP also includes all non‐DOC organizations, including contractors and Federal oversight organizations.

This plan does not apply to the management of project issues. An issue refers to a problem involving a significant choice between two or more alternatives for an event that is current happening and/or a risk that has been realized. Since an issue has already been realized, it can no longer be mitigated, and must instead be resolved. Management of project issues is covered in the BAS Project Management Plan (and detailed in the separate BAS Issue Management Plan).

1.3 PROJECT SUMMARY

The Office of the Chief Financial Officer and Assistant Secretary for Administration (CFO/ASA) is responsible for the continuous monitoring of DOC's financial management effectiveness and for aligning the strategic modernization efforts of the DOC's business systems. Determining the future direction of the DOC's business systems requires a thorough comprehension of the current‐state environment, possible operational alternatives, and an understanding of which systems and processes are in alignment with evolving Office of Management and Budget’s (OMB) and Treasury guidelines.

Version 1.7 Page 6 of 25 Last updated: 5/24/2019

In the summer of 2009, the Department of Commerce (DOC) began the Business Application Solutions (BAS) project1 to assess the long‐term viability of DOC’s legacy financial management and business systems, as well as to define, plan, and prioritize DOC’s systems modernization efforts. The detailed analyses and the evaluation of multiple modernization alternatives was completed in August 2011 and approved by the CBS Executive Board. The results of these analyses, as well as the qualitative and quantitative justification for the BAS project, are documented separately in the ERP & Hybrid Analysis report and BAS Alternatives Evaluation report. After a strategic pause in 2015, the BAS project was re‐ initialized in 2018. The BAS Project received from OMB an M‐13‐08 waiver (mandate to utilize a federal shared service provider) and received department and government approval to move forward with the BAS modernization effort.

The BAS project will provide comprehensive business system modernization support services for a wide range of legacy applications. The following functional areas (and the supporting systems) are currently within the scope of the BAS systems modernization effort:

Core Financials (CBS)

Data Warehouses (various)

Acquisition (CSTARs/CSUITE)

Personal Property (various)

Real Property (RPMS)

Fleet (various)

Financial Statements (Hyperion)

Archiving (various)

Interfaces (various)

It is anticipated that the RMP will be updated as the project proceeds through each phase to incorporate new information applicable to the management of BAS project risks.

2 PROJECT RISK MANAGEMENT STRATEGY

The BAS RMP describes the process for the management of project risks. The BAS project will use a centrally developed risk management strategy throughout the project as well as centralized risk planning, assessment, handling, and monitoring. The BAS will follow the BAS RMP to proactively identify, analyze, track, mitigate and escalate risks to ensure they do not adversely impact project objectives.

2.1 DEFINITIONS

2.1.1 RISK

Risk is a measure of the inability to achieve overall program objectives within defined program requirements and constraints and has three components: (1) the probability of occurrence, (2) the impact of the risk on the program, and (3) the time horizon during which the consequences will occur if the risk is not mitigated.

1 The BAS project was originally known as the Financial Management Business & Technical Analysis (FMBTA) project.

Version 1.7 Page 7 of 25 Last updated: 5/24/2019

2.1.2 RISK EVENT

Risk events are those events within the BAS project that, if they occur, could result in problems in the development, production, and fielding of the BAS system. Risk events should be defined to a level such that the risk and causes are understandable and can be accurately assessed in terms of probability (likelihood) and consequences (impacts) to establish the level of risk. For processes, risk events are assessed in terms of process variance from known best practices and potential consequences/impacts of the variance.

2.1.3 RISK CATEGORY

The risk categories and definitions used for the BAS project are provided in the following table.

RISK CATEGORY DESCRIPTION

Budget / Cost Risks associated with:

Errors in budget estimation

Lack of funding availability Realized unit costs (labor rates, acquisition costs) in excess of budgeted cost These risks may lead to either a delay in the delivery of the project or incomplete closure of the project.

Business These are generally risks that are beyond the operational limits, and therefore outside the control of the program. Examples include:

Changes in strategy and priorities Government mandate/rule changes

Delays in establishment of budgets

Poorly written contracts Reliance on a single vendor Reliance on a single point of failure

Organizational and Change Management

Risks associated with:

Business process reengineering acceptance by users and management

Time and commitment managers will need to spend overseeing the change

Lack of participation by business process owners in the reengineering process Necessary changes in manuals and handbooks

Personnel management issues

Labor relations issues Ability of the organization to change

Security and Privacy

Risks related to the security of information including:

Confidentiality or integrity of data Access rights / privileges failure Leakage of confidential data Project does not conform to the requirements of OMB Circular A‐130: Management of Federal Information Resources

Version 1.7 Page 8 of 25 Last updated: 5/24/2019

RISK CATEGORY DESCRIPTION

Operational This includes risks of loss due to:

Failure of or changes to a process Failure of a system

Non‐availability of contracts or purchases orders when required Delay in receiving input from stakeholders or

Breakdowns in communication

Lack of an adequate contingency plan for System Failure

Scope Risks that impact the defined scope of the project (that could lead to Budget / Cost and Schedule Risks). Examples include:

Scope creep Hardware defects Software defects Scope gap (ill defined scope) Dependency changes (unexpected legal, regulatory, etc.)

Integration defect (change due to unexpected behavior)

Schedule and Resources

Risks that impact the start/end date(s) and duration of project tasks and planned resources for the project including outsourcing delays, attrition of resources, people joining the team late, training inadequacies, or scarcity of skills. Examples include:

Missed project dependencies

Delay in completion of activity

Estimation errors

Delays in decision‐making

Software and hardware delays Requirement changes

Insufficient or unavailable resources Overly optimistic/pessimistic task durations

Unnecessary activities in the schedule Critical deliverables not planned or missed

Reviews not planned into the schedule

Technology Risks related to the environment under which both DOC and any providers work. For example, constantly changing development or production or testing environment can lead to this risk.

Examples include:

Lack of expertise Software and Hardware maturity or immaturity

Installation requirements

Customization

Integration with other systems

Operations and Maintenance (O&M) requirements

Component delivery schedule/availability

Uncertain and changing requirements

Design errors and/or omissions

Technical obsolescence

Version 1.7 Page 9 of 25 Last updated: 5/24/2019

2.1.4 IMPACT TIME FRAME

There are two dates that are specified for each BAS risk. The first is the earliest date the risk impact could materialize and the second is the latest date it could materialize. These two dates are used to track when the risk may begin to impact the program and when the risk has been overcome by events.

2.1.5 TIMEFRAME

The timeframe is an assessment of the impact horizon; the time period within which the impact of realizing the risk could be felt The BAS has defined three timeframes as defined in the table below.

TIMEFRAME DEFINITION

Near Impact felt this fiscal year

Mid Impact felt next fiscal year

Far Impact felt in 2 or more fiscal years

2.1.6 LIKELIHOOD / PROBABILITY OF OCCURRENCE (PO)

The probability of occurrence ranges and definitions used for the BAS project are provided in the following table. The value field is used to support charting and graphing of risks by probability.

LIKELIHOOD / PROBABILITY DEFINITION VALUE

1‐20% Extremely Unlikely 1

21‐40% Not Likely 2

41‐60% Moderately Likely 3

61‐80% Likely 4

81‐100% Extremely Likely 5

2.1.7 RISK IMPACT

The risk impact categories and definitions used for the BAS project are provided in the following table.

IMPACT CATEGORY DEFINITION VALUE COST

IMPACT

Critical An event that, if it occurred, would cause project failure (inability to achieve minimum acceptable requirements).

5 50%

Serious An event that, if it occurred, would cause major cost/schedule increases. Secondary requirements may not be achieved.

4 40%

Moderate An event that, if it occurred, would cause moderate cost/schedule increases, but important requirements would still be met.

3 30%

Minor An event that, if it occurred, would cause only a small cost/schedule increase. Requirements would still be achieved.

2 20%

Negligible An event that, if it occurred, would have minimal to no effect on the project.

1 10%

Version 1.7 Page 10 of 25 Last updated: 5/24/2019

2.1.8 RISK SEVERITY

The risk severity is the value that is given to a risk event based on the analysis of the probability (likelihood) and consequences (impacts) of the event. The table below identifies the risk severity based on the values corresponding to the likelihood of occurrence and impact.

RISK

SEVERITY

DEFINITION

LIKELIHOOD IMPACT

Low

Has little or no potential for increase in cost, disruption of schedule, or degradation of performance. Actions within the scope of the planned program and normal management attention should result in controlling acceptable risk.

Extremely Unlikely (1) Negligible (1)

Minor (2)

Not Likely (2) Negligible (1)

Moderately Likely (3) Negligible (1)

Medium

May cause some increase in cost, disruption of schedule, or degradation of performance. Special action and management attention may be required to control acceptable risk.

Extremely Unlikely (1) Moderate (3)

Serious (4)

Not Likely (2) Minor (2)

Moderate (3)

Serious (4)

Moderately Likely (3) Minor (2)

Moderate (3)

Likely (4) Negligible (1)

Minor (2)

Extremely Likely (5) Negligible (1)

High

Likely to cause significant increase in cost, disruption of schedule, or degradation of performance. Significant additional action and high priority management attention will be required to control acceptable risk.

Extremely Unlikely (1) Critical (5)

Not Likely (2) Critical (5)

Moderately Likely (3) Serious (4)

Likely (4) Moderate (3)

Serious (4)

Extremely Likely (5) Minor (2)

Moderate (3)

Critical Would cause extreme negative impact to cost, schedule or performance. Significant additional action and high priority management attention will be required to control acceptable risk.

Moderately Likely (3) Critical (5)

Likely (4) Critical (5)

Extremely Likely (5) Serious (4)

Critical (5)

2.1.9 RISK HANDLING APPROACH

The risk handling approaches and definitions used for the BAS project are provided in the following table.

RISK HANDLING

APPROACH

DEFINITION

Mitigation Control the risk via risk mitigation plans, action plans, etc.

Version 1.7 Page 11 of 25 Last updated: 5/24/2019

RISK HANDLING

APPROACH

DEFINITION

Avoidance Avoid the risk by taking action that will prevent the risk from impacting the program

Acceptance Accept the risk (this is usually done when risk is external and involves circumstances outside the program’s control)

Transfer Transfer the risk to the party best equipped to analyze and resolve the risk

Investigate More research is required to understand the risk and handling approaches

Watch Monitor the risk for growth in risk severity above an established threshold

Elevate Elevate the risk to higher level within the organization for treatment, decision‐making, coordination, etc.

Delegate Delegated to an external organization for management.

2.2 ROLES AND RESPONSIBILITIES

The BAS Program Manager has primary responsibility for risk management, however all project participants will play a role in ensuring the project’s risk management processes and procedures are followed throughout the project’s execution.

ROLE RESPONSIBILITIES

BAS Executive Sponsor Approve the risk management plan

Approve any bureau‐level variances from the approved risk management plan and associated processes and procedures

BAS Program Manager and Deputy Program Manager

Define overall scope and direction regarding Risk Management

BAS Project Manager(s) Create and maintain overall risk management plan

Create and maintain risk tracking processes and procedures

Document risk management and risk mitigation milestones in the project plan as they are identified

Create and maintain risk tracking processes and procedures

Review and provide input to risk tracking processes and procedures (tailor to each bureau, if necessary)

Identify risks, document and report risks and mitigation strategies using the issue log

Participate in risk tracking and monitoring activities

DOC Project Management team

Review and provide input to risk tracking processes and procedures (tailor to each bureau, if necessary)

Identify risks, document and report risks using the project risk register

Support the development of risk mitigation strategies

Support DOCs enterprise risk management activities

Assist in mitigating and resolving risks

Participate in risk tracking and monitoring activities

Monitor and identify risk occurrence

Version 1.7 Page 12 of 25 Last updated: 5/24/2019

ROLE RESPONSIBILITIES

Vendor/Contractor Project Management team

Review and provide input to risk tracking processes and procedures (tailor to each bureau, if necessary)

Identify risks, document and report risks using the project risk register

Support the development of risk mitigation strategies

Support DOCs enterprise risk management activities

Assist in mitigating and resolving risks

Participate in risk tracking and monitoring activities

Monitor and identify risk occurrence

Teaming Partners Review and provide input to risk tracking processes and procedures (tailor to each bureau, if necessary)

Identify risks, document and report risks using the project risk register

Support the development of risk mitigation strategies

Support DOCs enterprise risk management activities

Assist in mitigating and resolving risks

Participate in risk tracking and monitoring activities

Monitor and identify risk occurrence

Bureau Project Representatives

Review project risk log on regular basis and communicate risk status to bureau stakeholders

Identify risks, document and report risks and mitigation strategies using the risk log

Submit revisions/additions/deletions to risk log

Participate in risk tracking and monitoring activities

Project Team Leads and Team Members (SMEs, etc)

Identify risks, document and report risks using the project risk register

Assist in mitigating and resolving risks

Participate in risk tracking and monitoring activities

Monitor and identify risk occurrence

2.3 RISK PLANNING

Risk planning consists of the up‐front activities necessary to execute a successful risk management program. It is an integral part of normal program planning and management. The planning should address each of the other risk management functions, resulting in an organized and thorough approach to assess, handle, and monitor risks. It should also assign responsibilities for specific risk management actions and establish risk reporting and documentation requirements.

This RMP serves as the basis for all subsequent detailed risk planning that will continue throughout the life of the project. The BAS Project Manager will document the initial planning activities in this RMP and make the appropriate revisions to this plan when required to reflect significant changes to the project’s risk management approach. The RMP will be updated, if necessary, based on the following events:

Modification to the implementation strategy, Major change in the project goals and objectives, In preparation for major decision points / lifecycle gates, Version 1.7 Page 13 of 25 Last updated: 5/24/2019

In preparation for and immediately following major milestones as defined in the project schedule, Concurrent with the review and update of other project plans, and

In preparation for a briefing to the BAS Executive Oversight group.

2.4 RISK ASSESSMENT

The risk assessment process includes the identification of risks, which could have an adverse impact on the program, and the analyses of these risks to determine: the consequences, the probability of occurrence, the impact of the consequences on the program, and the time frame during which the consequences are likely to occur. It is the most demanding and time‐consuming activity in the risk management process. Risk assessment is an iterative process, with each assessment building on the results of previous assessments.

2.4.1 RISK IDENTIFICATION

Risk identification involves searching through the entire BAS project to determine those internal and external sources of risk that would prevent the project from achieving its objectives. There are standard overarching risks that are generally found in all programs and projects. These risks, listed in Appendix A – Standard Overarching Risks, should be reviewed for inclusion as part of the risk identification process.

The BAS Project Manager will lead the initial efforts to identify project‐specific risks through a structured brainstorming session. Risks may be identified throughout the project lifecycle by any member of the BAS project team or governance framework and can arise from a variety of sources including:

Status meetings, New risks previously missed, Unforeseen requirements, Review of project documentation, Group interview sessions, Project ‐developed risk identification checklists/questions, Resource constraints, An approved change request that implies changes to the critical path including cost, schedule, and scope, Major issues escalated from the team or project levels, Current risks whose response requires investigation, and The outcome or consequence of a separate identified risk occurrence.

The identified risks are entered into the project risk register along with basic identifying information, including the risk category (see Appendix B – Risk Register Data Elements). Risks with the same risk category should be grouped together. Risk categories are defined in Section 2.1.3. After similar risks are grouped, the Project Manager should review the listing of risks and remove redundant risks, combine similar risks (where applicable) and link dependent risks.

2.4.2 RISK ANALYSIS

Analysis of the identified risks will include both an identification of the time frame for each risk as well as an assessment of the impact and probability of the risk.

Version 1.7 Page 14 of 25 Last updated: 5/24/2019

2.4.2.1 DETERMINE THE IMPACT HORIZON

After all the risks are identified and basic information is captured for each risk, the impact horizon is determined. The impact horizon is based on the impact time frame for each risk. The impact time frame in bound by the earliest date and the latest date the risk impact could materialize as defined in Section

2.1.4. These dates are compared with the present date to determine impact horizon and to identify those risks that have been overcome by events. The BAS will use three impact horizon periods as defined in Section 2.1.5.

2.4.2.2 ESTIMATE LIKELIHOOD (PROBABILITY) OF OCCURRENCE

Each risk is assigned a likelihood (1‐100%) based on the likelihood (probability) it will occur. The probability that a risk will be realized (if no mitigation action is taken) for each risk is estimated using the probability of occurrence definitions defined in Section 2.1.6.

The likelihood for each risk is entered into the risk register. When agreement cannot be reached regarding likelihood, the Program Manager will provide a value.

2.4.2.3 ASSESS IMPACT

The impact the risk will have on the project, if no mitigation action is taken and the risk is realized, is assessed for each risk using the risk impact category definitions defined in Section 2.1.7.

The impact category for each risk is entered into the risk register. When agreement cannot be reached on the impact, the Program Manager will decide the impact category.

2.4.2.4 CALCULATE RISK EXPOSURE

Based on the probability and impact values assigned to a risk, project should then calculate the risk exposure. The risk exposure is a calculated value that is the product of probability of occurrence and impact.

Risk exposure = Likelihood (Value) * Impact (Value)

The use of the Risk Exposure calculation (as with the Impact Time Frame assessment) is limited to the ranking of risks as part of the risk prioritization process. The values range from:

1 – Low exposure = low likelihood (extremely unlikely) and low impact (negligible) to

25 – Critical exposure = high likelihood (extremely likely) and high impact (critical)

2.4.3 RISK SEVERITY (RISK MATRIX)

The risk severity for a risk is a function of likelihood (probability) of its occurrence and the impact to the project if the risk occurs. The risk severity definitions are defined in Section 2.1.8.

The risk severity ranking that can be plotted on a 5x5 matrix as illustrated in the example figure below.

Version 1.7 Page 15 of 25 Last updated: 5/24/2019

5X5 PROJECT RISK MATRIX

IMPACT

NEGLIGIBLE MINOR MODERATE SERIOUS CRITICAL

LI

K

EL

IH

O O D

EXTREMELY LIKELY 5 10 15 20 25

LIKELY 4 8 12 16 20

MODERATELY LIKELY 3 6 9 12 15

NOT LIKELY 2 4 5 8 10

EXTREMELY UNLIKELY 1 2 3 4 5

The level of management participation in the monitoring and handling of identified risks is a function of the assessed risk severity. While the determination of the level of management participation should be risk specific, the following guidelines are provided.

SEVERITY PROJECT RISK MANAGEMENT ACTION

Critical Management Intervention Required

High Management Monitoring Required

Medium Management Attention Required

Low Normal Monitoring

2.4.4 RISK PRIORITIZATION

Determining the priority of risks is based on the risk exposure calculation; the higher the risk exposure, the higher the priority of risk. The risk register should be sorted first by risk severity (Critical, High, Medium, Low) and then by the calculated risk exposure. In this manner, the risks with the highest risk exposure receive the highest priority.

After the sorting by risk exposure has been performed, the impact horizon should be considered and the priorities adjusted. The impact horizon is an important consideration when prioritizing risks. For example, Risk A may have a lower risk exposure when compared to Risk B; however, Risk A may have a shorter timeframe in which to mitigate the risk.

The prioritization results should be reviewed for reasonableness and supportability. The Program Manager, or any team member participating in the risk analysis, should identify any exceptions to the prioritization rankings. If exceptions are noted, the rankings should be reordered accordingly and the exception noted in the risk register.

2.5 RISK HANDLING APPROACH

After the project’s risks have been identified and assessed, the approach to handling each significant risk must be developed. The risk handling approaches and definitions used for the BAS project are provided in Section 2.1.9.

For all identified risks, the various handling approaches will be evaluated in terms of feasibility, expected effectiveness, and cost and schedule implications. The following process will be used to determine the approach to each identified risk:

Version 1.7 Page 16 of 25 Last updated: 5/24/2019

Develop risk scenarios for high priority risks – This is done by:

o Thinking about the risk as if it had occurred.

o Stating the risk scenario as if the risk had already happened.

o Listing the events and conditions that would precede the risk occurrence. This should be noted in the risk register.

Select the risk handling approach

Establish thresholds for early warning by identifying risk triggers and documenting the trigger(s) in the project risk register

The results of the evaluation and selection will be entered into the risk register. For risks with a high risk exposure and for which mitigation is the selected approach, a risk mitigation plan will be created. The mitigation plan will include:

What must be done, The level of effort and materials required, The estimated cost to implement the plan, A proposed schedule showing the proposed start date, The time phasing of significant risk reduction activities, The completion date, The relationship to significant project activities/milestones, Recommended metrics for tracking the action, A list of all assumptions, and

The person responsible for implementing and tracking actions against the plan.

2.6 RISK MONITORING

Risks will be monitored on a regular basis to determine whether action is required. On a weekly basis, project risks are reviewed to determine whether triggers have been met and to update the risk (as applicable). Risk owners are expected to provide updates regarding risk status and the status of activities in application risk mitigation plans. Risks that have been realized will be closed in the risk register, entered into the Issue Log and handled in accordance with the BAS Issue Management Plan.

The BAS Project Manager is responsible for ensuring the risk register is updated to reflect any updates/changes to the risk.

2.6.1 RISK REASSESSMENT

Risk assessment is an iterative process, with each assessment building on the results of previous assessments. The initial baseline assessment should be performed early in the planning phase of the project. The BAS Program Office will perform a reassessment of risks at least quarterly during the months of December, March, June, and September during the Pre‐Planning / Initiation and Detailed Planning and Acquisition Phases. Once deployment activities have commenced, the risk registered will be reviewed and updated monthly.

Unless otherwise directed in individual tasking, project level risk assessments will be presented at each Project Review meeting and Executive Steering Committee briefings and not later than 6 months before any scheduled Milestone decision. Departmental level risk assessments will be presented at each

Version 1.7 Page 17 of 25 Last updated: 5/24/2019

Executive‐level governance meeting. The primary source of information for each subsequent assessment will be the current assessment baseline, existing documentation, feedback from groups participating in the governance framework, discussions with subject matter experts, external oversight organizations and best practices adopted by the project.

2.6.2 RISK ESCALATION

When risks are reviewed, the Project Manager will determine if the risk needs to be escalated. Risks are escalated when it is not possible to manage them at the level it was identified or the impact has wider implications than just for the team or project at which it was identified. Once it is determined a risk needs to be escalated, the escalation is communicated to the project team members (as applicable), the new risk owner is notified, and the risk register is updated.

3 ENTERPRISE RISK MANAGEMENT STRATEGY

Project risk management is the evaluation of the negative influences a risk event will have on the goals and objectives of a project. Enterprise risk management takes a broader perspective and evaluates whether the identified risk events can have negative influences on DOC’s goals and objectives. The BAS project’s Enterprise Risk Management (ERM) strategy describes the project’s implementation of the DOC Enterprise Risk Management (ERM) framework in the management of enterprise‐level risk.

The following sections identify how the ERM strategy will be incorporated into the project’s overall risk management activities and applicable ERM concepts and definitions.

3.1 DEFINITIONS

3.1.1 ENTERPRISE RISK CONSEQUENCES

In addition to the risk categories that are specific to project risk management, the BAS project will include an evaluation of the consequence or outcomes/impacts of a risk event from an enterprise perspective. At the Department‐level, each of the following enterprise risk consequences will be evaluated:

Version 1.7 Page 18 of 25 Last updated: 5/24/2019

ENTERPRISE RISK CONSEQUENCES DESCRIPTION

Performance Impact on DOC goals and objectives as found on the Balanced Scorecard.

Performance includes costs and schedule.

Reputation Takes into consideration a stakeholder’s level of confidence in the organization. Includes damage to the reputation of the Department or the Administration.

Budget Monetary impact if the risk event occurs. This is the immediate impact at the time the risk is realized and not impact over the entire lifecycle of the project, program, or area.

Compliance Risk of non‐compliance with a DOC policy or procedure, regulation or statute.

Safety and Security (including IT Security)

Includes impacts ranging from minor injury to a person or loss of DOC assets to Death or permanent injury of a person or complete loss of a DOC asset. DOC assets include facilities, vehicles, equipment, inventories, information, and data.

3.1.2 ENTERPRISE RISK CONSEQUENCES AND CONSEQUENCE LEVELS

ERM is concerned with the consequence of realizing risk and the impact of the realization within each of the enterprise risk consequence types. The following table shows the guidelines for determining the enterprise risk consequence level to the Department for each of the consequence types.

CONSEQUENCE

TYPE

CONSEQUENCE LEVELS

1 2 3 4 5

Performance (Including Cost & Schedule)

No impact on DOC goals2 or on Mission Critical Area

(MCA).

Significant impact to any single DOC objective but does not impact

MCA.

Significant impact to multiple DOC objectives or minor impact to

MCA.

Failure to meet multiple DOC objectives or major impact to

MCA.

Failure to meet DOC Goal or significant impact to MCA.

Reputation No damage to DOC or Administration reputation.

Reputation questioned but easily recovered.

Reputation diminished but recoverable at moderate price.

Reputation diminished but recoverable at heavy price.

Reputation damaged and never fully recoverable.

Budget Minimal Impact (<$100K)

Moderate Impact ($100K up to $1M)

Significant Impact ($1M up to $10M)

Major Impact ($10M up to $50M)

Severe Impact (>$50M)

Compliance Non‐compliance with DOC policy or procedure.

Regulatory non‐ compliance (e.g., OMB).

Mild corrective action required.

Moderate Regulatory non‐ compliance.

Corrective action required.

Major regulatory or statutory non‐ compliance (e.g., OMB) Corrective action required.

Major regulatory or statutory non‐ compliance.

Corrective actions are unknown.

2 DOC goals and objectives are those found in the DOC Balanced Scorecard.

Version 1.7 Page 19 of 25 Last updated: 5/24/2019

CONSEQUENCE

TYPE

CONSEQUENCE LEVELS

1 2 3 4 5

Safety and Security (Includes IT Security)

No harm. Minor first aid treatment or minor loss of DOC asset.3

Medical treatment required or moderate loss of DOC asset.

Serious injury or major loss of DOC asset.

Death or permanent injury or complete loss of DOC asset.

3.1.3 ENTERPRISE RISK SEVERITY

Similar to project risk severity, enterprise risk severity is the value that is given to a risk event based on the analysis of the probability (likelihood) and enterprise risk consequence level of the event. The table below identifies the enterprise risk severity based on the values corresponding to the likelihood of occurrence and the consequence level.

ENTERPRISE RISK

SEVERITY

DEFINITION LIKELIHOOD CONSEQUENCE LEVEL(S)

Low

Minimum oversight needed to ensure that the enterprise risk remains low.

Extremely Unlikely (1) 1, 2, 3, 4

Not Likely (2) 1, 2, 3

Moderately Likely (3) 1, 2

Likely (4) 1

Medium

Additional management attention may be needed.

Extremely Unlikely (1) 5

Not Likely (2) 4, 5

Moderately Likely (3) 3, 4

Likely (4) 2, 3

Extremely Likely (5) 1, 2

High Priority management attention required.

Moderately Likely (3) 5

Likely (4) 4, 5

Extremely Likely (5) 3, 4 5

3.2 ENTERPRISE RISK SEVERITY ASSESSMENT

The purpose of the enterprise risk severity assessment is to leverage the project risk management activities and information to determine the severity of the risk from an enterprise perspective. The enterprise risk severity assessment process is described in the following sections.

3.2.1 ASSESS CONSEQUENCE RISK LEVEL

Assess the consequence to the Department and consequence level if no mitigation action is taken and the risk is realized. Use the enterprise risk consequences defined in Section 3.1.1 and the enterprise risk consequence levels defined in Section 3.1.2.

3 DOC assets include facilities, vehicles, equipment, inventories, information, and data.

Version 1.7 Page 20 of 25 Last updated: 5/24/2019

3.2.2 DETERMINING THE OVERALL ENTERPRISE RISK CONSEQUENCE

From an enterprise risk perspective, five broad consequences have been defined. When a risk is realized, it may have more than one consequence and each consequence may have a different severity. The overall enterprise risk consequence level, that is then used to determine the enterprise risk severity, is the maximum of the risk consequence levels in each of the five consequences. In the example below, the overall enterprise risk consequence level is 5.

PERFORMANCE REPUTATION BUDGET COMPLIANCE SAFETY AND

SECURITY

OVERALL ENTERPRISE RISK

CONSEQUENCE VALUE

1 2 2 3 NA 3

3.2.3 DETERMINE ENTERPRISE RISK SEVERITY (ENTERPRISE RISK MATRIX)

The BAS project will determine the enterprise risk severity of each risk based on the likelihood determined in the project risk assessment and overall enterprise risk consequence level. The enterprise risk severity will be plotted on the Enterprise Risk Matrix illustrated in the following figure.

5X5 ENTERPRISE

RISK MATRIX

OVERALL ENTERPRISE RISK CONSEQUENCE

1 2 3 4 5

LI

K

EL

IH

O O D

EXTREMELY LIKELY ‐5

LIKELY – 4

MODERATELY LIKELY – 3

NOT LIKELY – 2

EXTREMELY UNLIKELY ‐ 1

Risks that fall within the red area are considered "high" severity enterprise risks while those which fall in the yellow and green areas are considered "medium" and "low" severity enterprise risks, respectively. The level of management attention in the monitoring and handling of identified risks is a function of the assessed enterprise risk severity. While the determination of the level of management attention should be risk specific, the following guidelines are provided.

ENTERPRISE RISK SEVERITY ENTERPRISE RISK MANAGEMENT ACTION

High Priority management attention required

Medium Additional management attention may be needed

Low Minimum oversight needed to ensure risk remains low

3.3 ENTERPRISE RISK MONITORING

Enterprise risk consequence levels will be reassessed at the same time and with the same frequency as the monitoring processes described for the Project Risk Management Strategy in Section 2.6.

Version 1.7 Page 21 of 25 Last updated: 5/24/2019

APPENDIX A – STANDARD OVERARCHING RISKS

Below is a list of risks that are overarching, standard on most if not all projects, and should be included and tracked in all DOC programs and projects (P/P), along with a description of how to identify if the risk is occurring within a P/P.

RISK NAME RISK DESCRIPTION RISK CATEGORY

Changes to project scope may not adequately define the project

Modification and implementation of projects may be more difficult, time‐consuming, and expensive than originally anticipated.

Budget / Cost

Initial cost estimates may not be sufficient to fund planning and maintenance

Initial projections of project costs were unrealistically low as it was assumed that there would be a substantial decrease in spending after the project was implemented. If proper funding is not available the project may not meet the needs of the Department and Bureaus.

Budget / Cost

The Department will need the appropriate funding and resources in order to manage this investment

The funding for IT assets and personnel has been decreasing while requirements have been increasing.

Budget / Cost

Purchase of customized software

Purchase of customized software from one vendor may lead to total reliance on that vendor for future customization.

Business

The solution may not meet required standards

Due to changes to government requirements the solution no longer meets the applicable standards the Department of Commerce would have to acquire and move to another system. If this occurs before the end of system’s useful life the cost and disruption to the Department would be significant.

Business

Vendor may be unable to provide appropriate solution

Contractor may not have adequate staff or expertise to provide appropriate solutions to ongoing problems.

Business

Loss of data Natural disaster, systems failure or terrorist act may result in the loss of data.

Operational

Inadequate management controls may allow changes to occur beyond original scope and budget

Appropriate policies and procedures, and checks and balances, must be in place and operational for effective governance and change control.

Organizational and Change Management

Management of projects may be insufficient to ensure project goals and objectives are realized

Without proper management techniques the project may not be able to meet costs and schedule goals.

Project Management

Version 1.7 Page 22 of 25 Last updated: 5/24/2019

RISK NAME RISK DESCRIPTION RISK CATEGORY

Changes in Bureau or Department requirements may make the project unable to meet milestone schedules

The availability of the bureau personnel for requirements development, testing and implementation of updates may be impacted by changes in bureau needs, delaying or postponing milestones.

Project Schedule and Resources

Personnel resources may not be sufficient for completion of the project

Changes in system and maintenance requirements may result in the need for personnel either contractor or government that may not be available.

Schedule and Resources

Privacy of data in system System contains information of a sensitive nature. If security were breached, personally identifiable information (PII), financial, and vendor information could be accessed.

Security and Privacy

Security issues may be discovered in the underlying technology

Security issues are being found frequently in applications.

Unless these issues are addressed quickly it may place any application built upon this technology at risk.

Security and Privacy

Potential complexity of interfaces (either standard or customized) may prohibit potential agency efficiencies

The increase use of government wide applications requiring interface into and out of the system increases the potential that data cannot be easily transferred. If application cannot be interfaced, expensive and time consuming manual data exchanged may be required.

Technology

Technology may be outdated before replacement of the system

Changes in hardware and software technology are occurring at an ever‐increasing rate. As hardware and software becomes obsolete because of either outdated technology or maintenance and support is no longer available, replacement technology may no longer support continued operations.

Technology

Version 1.7 Page 23 of 25 Last updated: 5/24/2019

APPENDIX B – RISK REGISTER DATA ELEMENTS

The table below identifies the minimum data elements included in the risk register.

FIELD NAME DESCRIPTION

LOOKUP

VALUES

ID Enter the unique identifier for the risk.

Risk Category Enter the category used to group risks. Y

Risk Short Name Provide a 2‐3 word short name by which to reference the risk on reports and in communications.

Risk Statement Enter a description of the risk in the If… then… format Y

Related Risks Enter the ID number(s) of related risk(s).

Status Enter the risk status. Y

Risk Applicability Risk Applicability (Common or Unique) indicates whether the risk is germane only to the project identifying the risk (unique to the project) or if it could apply to other areas within DOC (common). Common risks are elevated to the Department level and added to the Department’s Catalog of Risks.

Y

Span of Control Span of Control indicates whether the risk can be managed by the Bureau, by DOC, or is external to DOC. It is used to identify the appropriate risk owner and treatment option. For example, a “reduction in budget appropriation” is a risk that is out of the span of control of a bureau or the DOC. A risk of this nature should be captured in the inventory but there is little in the way of treatment that a bureau or the agency can do. Rather, the bureau or department should focus on risks associated with the adjusted strategy as a result of a budget reduction.

Y

Impacted Bureaus Enter the bureaus that are impacted by the risk.

Impact Category Enter the impact category of the risk. Y

Impact Value Calculated: The value associated with the selected impact category. Y

Impact Earliest Date Enter the earliest date the risk impact could materialize.

Impact Days Calculated: Calculated # of days between earliest impact date and present date.

Timeframe Indicates how soon the risk is expected to be realized. “Near” means within the current fiscal year, “Mid” means during the next fiscal year, and “Far” means after than next fiscal year.

Y

Likelihood Enter the likelihood (probability) the risk will occur (value from 1‐100%). Y

Likelihood Text Calculated: The text associated with the selected likelihood.

Likelihood Value Calculated: The value associated with the selected likelihood. Y

Exposure Calculated: Exposure = Impact Value * Likelihood Value

Severity Calculated: The severity associated with the assigned impact and likelihood. Y

Risk Rank Calculated: The priority assigned given the severity and time horizon.

Version 1.7 Page 24 of 25 Last updated: 5/24/2019

FIELD NAME DESCRIPTION

LOOKUP

VALUES

Trend Direction the risk is trending given changes to likelihood and/or assessment of impact.

1 = Trending up

0 = Stable

‐1 = Trending down

Y

ERM Risk Category Enter the ERM Risk Category used to group risks. Y

ERM Consequence Levels

Performance

Reputation

Budget

Compliance

Safety and Security

Enter the consequence level (1 to 5) for each of the enterprise risk consequences (e.g., Performance, Reputation, etc.)

Y

Max Cons. Value Calculated: The maximum consequence level assigned to the enterprise risk consequences.

ERM Risk Score Calculated: The selected Likelihood and ERM Consequence values

ERM Severity Calculated: The ERM severity associated with the max ERM consequence value and likelihood.

Y

Trigger Enter the event that will trigger the risk.

Risk Handling Approach

Enter how the risk is being handled. Y

Strategy / Key Controls

Enter a description or steps describing how the risk will be mitigated (or comments regarding other risk handling approaches). Key Controls are existing policies, procedures, or tools that reduce the risk.

Contingency Plan Enter the steps or plan to handle the risk should the mitigation strategy not work.

Risk Realized Calculated: Yes (Status = Realized) or No (the risk has not been realized). If yes, an issue should be entered in the Issue Log.

Y

Date Realized Enter the date (mm/dd/yy) the risk was realized, if applicable, this field will be highlighted if a date is required.

Realized Comment Provide comments regarding the realization of the risk.

Date Closed Enter the date (mm/dd/yy) the risk was closed.

Closed Comments Provide comments regarding the closure of the risk.

Owner(s): Name Enter the name of the person(s) responsible for tracking, updating, mitigating the risk.

Owner(s): Bureau Enter the owner's bureau. Y

Version 1.7 Page 25 of 25 Last updated: 5/24/2019

FIELD NAME DESCRIPTION

LOOKUP

VALUES

Date Entered Enter the date the risk was entered in the log.

Entered By: Name Enter the name of person who entered the risk in the log.

Entered By: Bureau Enter the bureau of the person who entered the risk in the log. Y

Last Reviewed Enter the date the risk was last reviewed.

Last Updated Enter the date the risk was last updated.

Update Comments Provide a running list of the updates made to the assessment of this risk by date.

Next Review Date Enter the date the risk will next be reviewed.