Risk Analysis Workbook

1. 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).
List the name of the person that has ownership of this risk, and the ownership to make
Risk Owner
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
Enter Yes if a contingency plan was developed. Enter No if one was not developed.
Developed?
© SAP AG 2005
1 of 7
May 2005 Release 31-May-05

2. 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

3. 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 Requirements development lacks user
were not available. Cannot build a product involvement.
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
absent.
scope or available resources.
No appropriate contingency plans have been
Requirements are not under control.
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/14/2009
3 of 7
May 2005 Release riskanalysis-091214104146-phpapp01.xls

4. The personnel most qualified to work on
Team member assignments do not match
the project are not available for the
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)
Inaccurate quality tracking results in not
Overly simplified approach fails to address
knowing about problems until late in the
major project issues.
project.
Quality-assurance and quality
Project Management tools are not in place.
management activities are shortchanged.
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 and
rework. must be reworked.
Requirements Risks (Technical - Change Control Management)
Requirements have not been baselined
Requirements take longer to satisfy than
and continue to change without formal
expected.
Change management control.
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/14/2009
4 of 7
May 2005 Release riskanalysis-091214104146-phpapp01.xls

5. Vendor Risks
Contractors do not deliver components
when promised.
© SAP AG 2005 12/14/2009
5 of 7
May 2005 Release riskanalysis-091214104146-phpapp01.xls

6. 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
Purpose
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 Number roject Type
P
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
0
© SAP AG 2005 12/14/2009
6 of 7
May 2005 Release riskanalysis-091214104146-phpapp01.xls

7. 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
2
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/14/2009
7 of 7
May 2005 Release