Risk management plan for Human Resource Software

David Bustin
[Company Address]
Tel:
Fax:
706 555 - 0100
706 555 - 0199
[Company E-mail]
July 14, 2017 Version 1.0
David D. Bustin
Risk Management Plan
Human Resource Software Implementation

Risk
Dav id D. Bustin Version 1.0 II
REVISIONS AND DISTRIBUTION
Revision Release date
Distributed to*
Client
Consultant
DBMainoffice(s)
Allprojectmgmt.dept.
Sub-contractors
Suppliers
Rev. 0 (draft) 14/07/2017
*) Detailed distribution lists will beprepared for each distribution event. Further details as per the project
communication plan
Amendments
Changes to this plan may periodically occur. Any amendment(s) to this plan shall be
communicated to the change control board. When submitting changes to the change control
board, a change request form must be used. Once approved by the change control board, only
the update will be distributed and the complete revised document will be located internally.

Risk
Dav id D. Bustin Version 1.0 III
PROJECT SPONSOR APPROVAL
Prepared by: Reviewed by: Approved by Proj. Sponsor:
14/07/2017 Place, dd/mm/yyyy Place, dd/mm/yyyy
David D. Bustin
Designation
Name
Designation
Name
Designation

Risk
Dav id D. Bustin Version 1.0 IV
TABLE OF CONTENTS
Revisions and Distribution……………………….………………..…………………………………………………..II
Amendments……………………..…………………..………………………………………………………....II
Project Sponsor Approval……………………………..…………………….…………………………………..……III
Table of Contents………………………………………………………………….……………………………………..IV
1. Introduction
1.1 Purpose................................................................................................................1
1.2 Intended Audience..............................................................................................1
1.3 Risk Management Approach...............................................................................2
1.3.1 Risk Identification........................................................................................2
1.3.2 Risk Analysis ................................................................................................2
1.3.3 Response Planning ......................................................................................2
1.3.4 Risk Monitoring and Control .......................................................................2
2. Roles and Responsibilities
2.1 Project Manager..................................................................................................3
2.2 Project Team .......................................................................................................3
2.3 Software Quality Assurance Lead…...……………………………………………………………...3
2.4 Project Sponsors..................................................................................................3
2.5 Project Stakeholders……………………………………………………………………………………….3
3. Risk Identification
3.1 Background…………………………………………………………………………………………………….4
3.2 Risk Categories…………………….…………………………………………………………………………4
3.2.1 People………………………………………………………………………………………….......……4
3.2.2 Security………………………………………………………………………………………......……..4
3.2.3 Technical..……………………………………………………………….…………………….………..4
3.3 Sources…………………………………………………………………………………..…………….………..4
3.4 Documentation…………………………………………………………………………………......………4
3.5 Risk Categories Table………………………………………………………………………………………5
4. Risk Analysis
4.1 Background…………………………………………………………………………………………………….6
4.1.1 Qualitative Analysis…………………………………………………………………………………6

Risk
Dav id D. Bustin Version 1.0 V
4.2 Documentation……..............................................................................................6
4.3 Probability and Impact Matrix………………………...………………………………………………7
5. Response Planning
5.1 Background.……………………………….…………………………………………………………………...8
5.2 Risk Strategies......................................................................................................8
5.2.1 Risk Avoidance.............................................................................................8
5.2.2 Risk Transference........................................................................................8
5.2.3 Risk Mitigation.............................................................................................8
5.2.4 Risk Acceptance...........................................................................................8
5.3 Documentation...………………………………………………………….………………………………….8
6. Risk Monitoring and Control
6.1 Background..........................................................................................................9
6.2 Timing..................................................................................................................9
6.3 Documentation……………………………………………………………………………………………….9
List of Tables and Figures
Figure 1 - Risk Management Model……………………………….………………………………………...….…2
Table 1 - Risk Categories……………………………………………….…………………………………………….….5
Table 2 - Risk Probability Definitions….…………………....….………………………………………….….….6
Table 3 - Risk Impact Definitions…....……….......…………….………………………………………….….….6
Table 4 - Probability and Impact Matrix..............................................................................7

Risk
Dav id D. Bustin Version 1.0 P a g e | 1
INTRODUCTION
The risk management plan is an element of the project management plan that provides a view of
the risks and the organizations structured approach to handling them.
Purpose
The purpose of this plan is to prioritize and document risk through identification, categorization,
analysis, response planning, and risk definitions for integrating new human resources software.
Introducing new software brings challenges not only for the IT staff but also end users in the
human resources department. Identifying all potential risks is impossible. The risk management
plan will provide a guidance for handling known risks before they occur and unknown risks as they
occur.
Intended Audience
This risk management plan is intended to provide guidance for the IT staff, project and functional
managers, executives, project team members, contractors and subcontractors, and other project
sponsors or stakeholders.

Risk
RISK MANAGEMENT APPROACH
Risk Identification
All known risks and their associated strategies should be communicated in the beginning of the
project or as soon as possible. Continuous attention must be given to potential risks and once
identified, that risks will be categorized. Risk owners and appropriate strategies will be assigned.
Risk identification will include the source of risk, risk events, and risk indicators. Strategies to
handle individual risks will be incorporated into the response planning and monitoring procedures.
Risk Analysis
In risk analysis, a qualitative risk analysis will be conducted to determine the probability of
occurrence and impact to the project if the risk materialized.
Response Planning
During response planning, risk management and contingency plans will be developed. Strategies
for handling each risk will be developed by the assigned risk owner. The approaches used in risk
response are avoidance, transference, mitigation, and acceptance.
Risk Monitoring and Control
Action plans will be created, integrated, and monitored during the response planning phase.
During risk monitoring and control, corrective action plans are developed, implemented, and
monitored.
Figure 1 RiskManagement Model

Risk
ROLES AND RESPONSIBILITIES
CEO
The CEO approves or disapproves investments and funding for projects. Also, he/she decides the
project organization structure.
Steering Committee
The steering committee ensures the quality and timeliness of the project. They provide advice and
often decisions on project alterations. Specifically, they will align the IT strategy with
organizational goals.
Project Manager
The project manager is responsible for approval of the risk management plan (this document),
leads and participates in the risk management process, and takes ownership of risk
mitigation/contingency planning and execution. The project manager is ultimately responsible for
the final decision on risk actions, in coordination with the project sponsors.
Project Team
Project team members (analysts/product managers, developers, testers, and deployment team
members) participate in the risk identification process and discuss risk monitoring and mitigation
activities at team meetings. Carries out the activities for project completion
Software Quality Assurance Lead
The software quality assurance (SQA) lead is responsible for ensuring identified risks are being
managed per the risk management plan. The SQA lead also assist in identifying new risks and/or
proposing mitigation strategies and contingency plans, along with proposing improvements to the
risk management plan and processes.
Project Sponsors
Project sponsors participate in risk identification and risk activities, as necessary. Project sponsors
also receive escalated risks and assist with mitigation and contingency actions for escalated risks.
Project Stakeholders
Stakeholders assist in monitoring risk action effectiveness and participate in risk escalation, as
necessary.
Audit Team
The audit team determines the level of compliance with the defined processes, regulatory
mandates, and industry standards.

Risk
RISK IDENTIFICATION
Background
Sources of risks and risk events are developed in the risk identification process. Some risks are
known and pre-defined in order to form an orderly process in risk identification throughout the
project. Categories of risks may evolve and new risks are developed over the course of the
project. After identifying and categorizing the risk event, it is entered into the risk register.
Risk Categories
The following categories will identify risks.
 People: Inadequate skilled end users, Senior management support, IT staff capability of
maintenance and operations
 Security: Confidentiality, Integrity, Availability
 Technical: Compatibility with existing systems, Vendor support and customer service,
Configuration tailored to specific organizational policy and procedures
Sources
The following tools and techniques will be employed for risk identification:
 Team meetings
 Expert interviews
 Analogy comparisons
 Assumptions analysis
 SWOT analysis
 Checklists
Documentation
All identified risks should be documented and entered into the risk register. During risk
identification, the following information is required for documentation:
 Risk category
 Risk trigger
 Potential outcome
 Source

Risk
Table 1 – Risk Categories
Reference
Number Risk
Risk
Category Risk Trigger
Potential
Outcome Source
1
non-compliance
in reporting Technical
System failed in
compliance
reporting to
regulatory
agencies
Sarbanes-Oxley
Compliance Audit
ExpertInterviews,
Analogy
Comparisons
2
No application
security
Security Network Breach
Employee’s
personal data
stolen
Expert Interviews
Team Meetings
SWOT Analysis
3
Performance
reviews not
submitted
Technical
Notification
failures
Employees
receive late
performance
evaluations
Team Meetings
4
Inadequately
skilled staff
People
Unable to
complete task
accurately and
on time
Employee morale
Team Meetings,
Analogy
Comparisons,
Assumptions
Analysis
5
Financial abuse
People
Improper
separation of
duties
Fraud
Analogy
Comparisons
6
Discriminatory
practices,
unsuitable
candidates
selected
People Unethical hiring
Potential lawsuits,
negative public
relations, loss of
business, fines.
Checklists

Risk
RISK ANALYSIS
Background
The risk score can be calculated after the risk impact and probability are identified. The
risk probability and impact matrix is shown below on page 7 of this risk management plan. The
matrix illustrates a combination of impact and probability that produce a risk priority.
Qualitative Analysis consists of the probability of a risk occurring and that risk’s impact on
the project. The potential likelihood that a given risk will occur is assessed, and an appropriate risk
probability is selected from the chart below.
Probability Category Probability Description
Very High 0.90 Risk event expected to occur
High 0.70 Risk event more likely than not to occur
Probable 0.50 Risk event may or may not occur
Low 0.30 Risk event less likely than not to occur
Very Low 0.10 Risk event not expected to occur
Table 2 – Risk Probability Definitions
The below chart displays risk impact definitions for each project area.
Project Objective Very Low
0.05
Low
0.10
Moderate
0.20
High
0.40
Very High
0.80
Cost Insignificant cost
impact
< 10% costimpact 10-20% cost
impact
20-40% cost
impact
> 40% costimpact
Schedule Insignificant
schedule impact
< 5% schedule
impact
5-10% schedule
impact
10-20% schedule
impact
> 20% schedule
impact
Scope Barely noticeable Minor areas
impacted
Major areas
impacted
Changes
unacceptableto
sponsor
Product becomes
effectively useless
Quality Barely noticeable Only very
demanding
applications
impacted
Sponsor must
approve quality
reduction
Quality reduction
unacceptableto
sponsor
Product becomes
effectively useless
Table 3 – Risk Impact Definitions
Documentation
Risk analysis results are documented in the risk register. Information shall be entered in the
register:
 Risk impact
 Risk probability
 Risk matrix score
 Risk priority – computed by the risk register spreadsheet after impact and probability are
entered
 Qualitative impact – descriptive comments about the potential risk impact

Risk
PROBABILITY AND IMPACT MATRIX
Different levels of risk probability and impact should be specific to the individual project. The risk
probability and impact matrix illustrate a combination of risk impact and probability. The result of
the matrix enables risks prioritization. Red cells in the matrix are the highest priority which should
receive the most of the risk management resources during response planning and risk
monitoring/control. Risks located in the yellow cells are the next highest priority, followed by
lowest priority risks in the green cells.
Probability
Very High
.90
High
.70
Probable
.50
Low
.30
Very Low
.10
.05
Very Low
.10
Low
.20
Moderate
.40
High
.80
Very High
Impact
Table 4 – Probability and Impact Matrix

Risk
RESPONSE PLANNING
Background
Response planning includes strategies and plans to manage risks to an acceptable level.
Risk Strategies
Risk Avoidance - Parts of the overall project management plan may need to be eliminated
to alleviate the threat, segregate objectives from the risk’s impact, or
alter the schedule. By early identification of risks, they can be avoided
much more easily.
Risk Transference – Directing the negative risks toward a third party would relieve the
organization from the burden brought about by risks. Alternatives
include insurance, vendors, or contractors.
Risk Mitigation - Reducing risks to acceptable levels when possible. Consulting subject
matter experts and the project manager is required.
Risk Acceptance – Reserves for time and costs should be set aside for unforeseen risks that
are encountered.
Documentation
Response planning results will be documented in the risk register. The following information will
be included in the register:
 Response strategy (avoid, transfer, mitigate, or accept)
 Response notes (description of plan)
 Risk owner

Risk
RISK MONITORING AND CONTROL
Background
Monitoring for identified risks, identify new risks, and ensuring execution of planned risk
responses and evaluating overall effectiveness of the risk management plan in order to reduce risk
to the lowest possible level is the ongoing process for the entire project. Risks should be assigned
an owner which will report on the status during weekly meetings until resolved. All risks will be
entered into the risk register. Re-prioritization of risks may be necessary upon discovery and
evaluation of the particular risks. The new risk will be categorized, assigned a risk score, and
entered into a probability-impact matrix. Monitoring and control tasks will include the following:
 Maintain a record of identified risks and monitor trigger conditions
 Examine project performance
 Re-evaluate predefined risks to determine if the probability, impact, or
proper response plan has changed
 Assess the execution of risk responses and analyze their effectiveness
 Ensure organizational risk management policies are applied
 Identify, analyze, and plan for undiscovered risks
Timing
The risk monitoring and control process will continue throughout the lifetime of the project.
Specifically, the schedule of risk reporting, re-evaluation, and review will occur no less than at the
end of each implementation phase for the human resource information systems. In the event
major risk, cost, or schedule delays occur, a project re-evaluation will be conducted immediately.
Documentation
The results of risk monitoring and control should be documented in the risk register. The
following information shall be entered in the register:
 Status – valid statuses are:
 Identified – Risk documented, but analysis not performed
 Analysis Complete – Risk analysis done, but response planning not
performed
 Planning Complete – Response planning complete
 Triggered – Risk trigger has occurred and threat has been realized
 Resolved – Realized risk has been contained
 Retired – Identified risk no longer requires active monitoring

Risk management plan for Human Resource Software

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Was ist angesagt?

Was ist angesagt? (20)

Ähnlich wie Risk management plan for Human Resource Software

Ähnlich wie Risk management plan for Human Resource Software (20)

Mehr von David Bustin

Mehr von David Bustin (8)

Kürzlich hochgeladen

Kürzlich hochgeladen (20)

Risk management plan for Human Resource Software