Project Risk Register Instructions

Field Instructions

Risk Number List the Risk Number in sequential order.

Date Identified Enter the date the risk was first identified.

Describe the risk - an event or condition, which if it occurs, has a positive or negative affect
Risk Description on a project's objectives (e.g. The technology that is being purchased will not be supported by
the manufacturer in 2 months).

Risk Categories are sources of potential risk for classification. Choose the appropriate risk
Category categories: Project Management Risk, Resource Risk, Client Risks, Technical Risks, External
Risks, Vendor Risks. (Refer to the Risk Identification Leading Questions for memory joggers).

State how the risk would affect the project if it occurs, (i.e. not having vendor support for this
Potential Impact product would have an adverse affect to the roll out).

Risk Owner List the name of the person that has ownership of this risk, and the ownership to make
certain the response plan is implemented.

Probability of Occurrence Indicate the chance that the risk will occur using the scale of 1-5 (1 = low 5 = high).

State how the risk would affect the project if it occurs, using a numerical scale of
Impact of Risk
1 - 5 (1= low 5= high)

Automatically calculated by by multiplying the probability of occurrence by the impact of risk.

Risk Level (The threshold for completing a Detailed Response Form is 15. If the Risk Level is 15 or above
complete the Detailed Risk Response Form.)

Choose from one of the responses below.

Acceptance: Accept the consequences, will not hurt the overall project success, but may delay
a milestone.
Avoidance: Eliminate the cause of the risk - change the project direction to protect the
Response project objectives from this impact.
Mitigation: Take action to reduce probability that the risk will occur to an acceptable
threshold.
Transference: Transfer the responsibility of managing the risk, including ownership, and
acceptance of consequences. Transference does not eliminate the risk.

Status Choose from the list the status of the risk: New, Under Review, In Progress, Complete.

Date of Invoked Response Enter the date the response strategy was invoked/implemented.

Contingency Plan
Developed? Enter Yes if a contingency plan was developed. Enter No if one was not developed.

ã SAP AG 2005
1 of 7
May 2005 Release 31-May-05
 Leading Questions for Risk Identification
Purpose

Use the following as examples of project risks to assist in identification of risks. This is not an all-inclusive list, but rather to
serve as memory joggers for Project Management Phases. Review the risks below. Once you have identified the risk, then
document on the Risk Log.

Project Management Phases

Initiating Phase
Are the deliverables clearly understood by all?
Are the critical success factors clear and measurable?
Is the business sponsor / business team committed to the success of the project?
Are the expectations of the teams involvement clearly laid out?
Has the business sponsor changed during the project?
Does the business and/or IT senior leadership believe in the business case for the project?

Planning Phase
Is the schedule realistic or are activities and tasks set in overly optimistic?
Is the budget realistic or based on unrealistic estimates?
Does the project involve a large number of users?
Is the project heavily reliant on third party resources to complete key deliverables on time?
Does the team have prior experience with this company?
Is there a high level of turnover in the business area affected? Is there a contingency plan?
Are team members' roles clearly laid out and documented?
Is there a clear assignment of tasks and ownership among team members?
Is there any slack time or contingency built into the plan?
Is there adequate Change Enablement / Communication plan in place?
Does the project manager have enough time to focus on this project?

Executing/Monitoring/Controlling Phase
Are there multiple third party companies involved in the project?
Does the current team have prior experience with this type of project?
Are there geographical constraints that will inhibit the success of the project?
Is risk being managed?
Is the budget being managed?
Is the schedule being managed?
Have key project resources turned over or changed during the course of the project?

Closing Phase
Have all deliverables been met?
Are the customers satisfied with the product / service?

ã SAP AG 2005
2 of 7 31-May-05
May 2005 Release
 Project Risk Identification Checklist

The Project Risk Identification Checklist provides checklist items in categories that serve as memory
Purpose joggers during risk identification. Once identified, the risk is documented in the Project Risk Log.

Project Management Risks

Scheduled activities and tasks are The project scope, vision, objectives, and
documented but not set in realistic ✘ deliverables are not clearly defined or
timeframes understood.

Schedule was based on the use of specific

team members, but those team members
were not available. Cannot build a Requirements development lacks user
involvement.
product of the size specified in the time
allocated

Project does not have senior management

Product is larger than estimated. ✘
support.

Similar projects have been delayed or

Effort is greater than estimated. ✘
canceled

Estimates ignore project history. Project benefits are not defined.

Target date has moved up with no Performance standards are unrealistic or

corresponding adjustment to the product
scope or available resources. absent.

Requirements are not under control. No appropriate contingency plans have been
developed.

The project has a high chance of success but

Financial budget is not realistic and based at the expense of burning out the team
on ad hoc estimates. members which could cause excessive staff
turnover.

Inaccurate progress tracking results in not

knowing if the project is on, ahead of, or Customer is not committed to the project
behind schedule.

Resource Risks

Friction exists between project team New personnel are added late in the project,
✘
members and clients. and additional training is required.

ã SAP AG 2005 12/08/2021

3 of 7
May 2005 Release 48606777.xls
 The personnel most qualified to work on
the project are not available for the Team member assignments do not match
their strengths.
project.

Team members do not buy into the project

Personnel need extra time to learn and consequently do not provide the level of
unfamiliar processes and procedures.
performance estimated.

Hiring takes longer than expected.

Customer Risks

Customer does not participate in reviews Customer response time to answer

resulting in unstable requirements and clarification questions is slower than
time-consuming changes. expected.

Customer will not accept the project Customer has expectations project team
deliverables even though they meet ✘
cannot meet.
acceptance criteria

Quality Risks (Technical)

Overly simplified approach fails to address Inaccurate quality tracking results in not
knowing about problems until late in the
major project issues. project.

Quality-assurance and quality

management activities are shortchanged. Project Management tools are not in place.

End Risks (Technical)

End-user ultimately finds product to be End-user input is not solicited, so product

unsatisfactory, requiring redesign and ultimately fails to meet user expectations
rework. and must be reworked.

Requirements Risks (Technical - Change Control Management)

Requirements have not been baselined

and continue to change without formal ✘
Requirements take longer to satisfy than
✘
Change management control. expected.

Requirements for interfacing with others

are not under the team’s control and Unfamiliar and unproven procedures cause
result in unforeseen implementation unforeseen problems.
considerations.

External Environment Risks

Regulations change unexpectedly. Technical standards change unexpectedly.

ã SAP AG 2005 12/08/2021

4 of 7
May 2005 Release 48606777.xls
 Vendor Risks

✘
Contractors do not deliver components
when promised.

ã SAP AG 2005 12/08/2021

5 of 7
May 2005 Release 48606777.xls
 Risk Register

Purpose The Risk Register is used by the project team to document the description and assessment of risks and to offer action plans to respond to risks. The Risk Register provides a reference for the project team and supports
their need to be apprised of and evaluate the risks. (A risk is an uncertain event or condition, which if it occurs, has a positive or negative affect on a project’s objectives. )

Project Identification
Project Name CPI/Project NumbeProject Type

Customer Name Customer Number Project Start/Finish Date

Project Sponsor Program Manager Project Manager (Customer)

Project Manager (SAP) SAP Service Partner(s) Project Manager (Service Partner)

Probability
Impact Risk Date of Contingency
Date of Response
Risk # Risk Description Category Potential Impact Risk Owner Risk Response Status Invoked Plan
Identified Occurrence of Risk Level Strategy
Response Developed?
(1 - 5) (1 - 5) (1 - 25)
2 5 10
List for Categories
3 3 9

5 3 15
Project Management Risk
0
Resource Risk
0
Customer Risk
0
Technical Risk
0
External Risk
0
Vendor Risk
0

0
Occurrence Prob.
0

0
###
0
###
0
###
0
###
0
###
0

ã SAP AG 2005 12/08/2021

6 of 7
May 2005 Release 48606777.xls
 Risk Analysis Matrix

Probability Levels
1 Improbable (1 - 20%)
5
2 Possible (21-40%)
3 Probable (41-60%)
4 Highly Probably (61-80%)
5 Almost Certain (81-100%)
4
Impact Levels
(If Risk Occurs)

1 Minimal
Impact

2 Small
3
3 Average
4 Large
5 Very Large

1
Contingency Planning
A Contingency Plan should be developed for risks that fall
into the “Red Zone." Development of a Contingency Plan
should be considered for risks that fall into the "Orange
1 2 3 4 5 Zone."

Probability The Contingency Plan will be executed when the risk event
(That the Risk will occur) occurs and is intended to reduce the impact of the risk
event on the project.

ã SAP AG 2005 12/08/2021

7 of 7
May 2005 Release