CPI/Project Number

Customer Number
Project Sponsor
SAP Service Partner(s)
Probability of Impact Risk
Occurrence of Risk Level
(1 - 5) (1 - 5) (1 - 25)
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
Contingency Plan
Developed?
Potential Impact Risk Owner Response Strategy Status Risk Response
Date of Invoked
Response
Risk #
Date
Identified
Risk Description Category
Project Manager (Service Partner)
SAP Field
Services
Project Risk Register
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 projects objectives. )
Project Name
Customer Name
Project Manager (SAP)
Purpose
ProgramManager Project Manager (Customer)
Project Type
Project Start/Finish Date
Project Identification

SAP AG 2005
May 2005 Release
1 of 7
5/22/2014
229975771.xlsx.ms_office
Field Instructions
Risk Number List the Risk Number in sequential order.
Date Identified Enter the date the risk was first identified.
Risk Description
Describe the risk - an event or condition, which if it occurs, has a positive or negative
affect on a project's objectives (e.g. The technology that is being purchased will not be
supported by the manufacturer in 2 months).
Category
Risk Categories are sources of potential risk for classification. Choose the
appropriate risk categories: Project Management Risk, Resource Risk, Client Risks,
Technical Risks, External Risks, Vendor Risks. (Refer to the Risk Identification
Leading Questions for memory joggers).
Potential Impact
State how the risk would affect the project if it occurs, (i.e. not having vendor support
for this 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).
Impact of Risk
State how the risk would affect the project if it occurs, using a numerical scale of
1 - 5 (1= low 5= high)
Risk Level
Automatically calculated by by multiplying the probability of occurrence by the impact
of risk. (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 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.
Project Risk Register Instructions
Response
SAP AG 2005
May 2005 Release
2 of 7
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
May 2005 Release
3 of 7
31-May-05
The personnel most qualified to work on the
project are not available for the project.
Team member assignments do not match their
strengths.
Friction exists between project team members
and clients.
New personnel are added late in the project, and
additional training is required.
Estimates ignore project history. Project benefits are not defined.
Target date has moved up with no
corresponding adjustment to the product scope
or available resources.
Performance standards are unrealistic or absent.
Requirements are not under control.
No appropriate contingency plans have been
developed.
Financial budget is not realistic and based on
ad hoc estimates.
The project has a high chance of success but at
the expense of burning out the team members
which could cause excessive staff turnover.
Inaccurate progress tracking results in not
knowing if the project is on, ahead of, or behind
schedule.
Customer is not committed to the project
Resource Risks
Schedule was based on the use of specific
team members, but those team members were
not available. Cannot build a product of the size
specified in the time allocated
Requirements development lacks user
involvement.
Product is larger than estimated. Project does not have senior management support.
Effort is greater than estimated. Similar projects have been delayed or canceled
Purpose
The Project Risk Identification Checklist provides checklist items in categories that serve as memory joggers
during risk identification. Once identified, the risk is document in the Project Risk Log.
Project Risk Identification Checklist
Project Management Risks
Scheduled activities and tasks are documented
but not set in realistic timeframes
The project scope, vision, objectives, and
deliverables are not clearly defined or understood.
SAP AG 2005
May 2005 Release
4 of 7
5/22/2014
229975771.xlsx.ms_office
Requirements Risks (Technical - Change Control Management)
Requirements have not been baselined and
continue to change without formal Change
management control.
Requirements take longer to satisfy than expected.
Requirements for interfacing with others are not
under the teams control and result in
unforeseen implementation considerations.
Unfamiliar and unproven procedures cause
unforeseen problems.
External Environment Risks
Regulations change unexpectedly. Technical standards change unexpectedly.
Vendor Risks
End-user ultimately finds product to be
unsatisfactory, requiring redesign and rework.
End-user input is not solicited, so product
ultimately fails to meet user expectations and must
be reworked.
Customer Risks
Customer does not participate in reviews
resulting in unstable requirements and time-
consuming changes.
Customer response time to answer clarification
questions is slower than expected.
Customer will not accept the project
deliverables even though they meet acceptance
criteria
Customer has expectations project team cannot
meet.
Quality Risks (Technical)
Overly simplified approach fails to address
major project issues.
Inaccurate quality tracking results in not knowing
about problems until late in the project.
Quality-assurance and quality management
activities are shortchanged.
Project Management tools are not in place.
End Risks (Technical)
Personnel need extra time to learn unfamiliar
processes and procedures.
Team members do not buy into the project and
consequently do not provide the level of
performance estimated.
Hiring takes longer than expected.
SAP AG 2005
May 2005 Release
5 of 7
5/22/2014
229975771.xlsx.ms_office
Contractors do not deliver components when
promised.
SAP AG 2005
May 2005 Release
6 of 7
5/22/2014
229975771.xlsx.ms_office
1
2
3
4
5
1
2
3
4
5
1 2 3 4 5
Risk Analysis Matrix
5
4
Probability Levels
I
m
p
a
c
t
(
I
f

R
i
s
k

O
c
c
u
r
s
)
2
Minimal
Small
1
3
Improbable (1 - 20%)
Possible (21-40%)
Probable (41-60%)
Highly Probably (61-80%)
Almost Certain (81-100%)
Impact Levels
Average
Large
Very Large
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 Zone."

The Contingency Plan will be executed when the
risk event occurs and is intended to reduce the
impact of the risk event on the project.
Probability
(That the Risk will occur)
SAP AG 2005
May 2005 Release
7 of 7
5/22/2014