Project Risk Register Instructions

Field Risk Number Date Identified List the Risk Number in sequential order. 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 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 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 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 certain the response plan is implemented. Instructions

Risk Description

Category

Potential Impact

Risk Owner

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

Response

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. Choose from the list the status of the risk: New, Under Review, In Progress, Complete.

Status

Date of Invoked Response Contingency Plan Developed?

Enter the date the response strategy was invoked/implemented.

Enter Yes if a contingency plan was developed. Enter No if one was not developed.

SAP AG 2005 May 2005 Release

1 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

31-May-05 2 of 7

Project Risk Identification Checklist

Purpose

The Project Risk Identification Checklist provides checklist items in categories that serve as memory joggers during risk identification. Once identified, the risk is documented in the Project Risk Log. Project Management Risks Scheduled activities and tasks are documented but not set in realistic timeframes 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 Product is larger than estimated. The project scope, vision, objectives, and deliverables are not clearly defined or understood.

Requirements development lacks user involvement.

Project does not have senior management support. Similar projects have been delayed or canceled Project benefits are not defined.

Effort is greater than estimated. Estimates ignore project history. 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. The project has a high chance of success but at the expense of burning out the team members which could cause excessive staff turnover.

Financial budget is not realistic and based on ad hoc estimates.

Inaccurate progress tracking results in not knowing if the project is on, ahead of, or behind schedule. Resource Risks

Customer is not committed to the project

Friction exists between project team members and clients. The personnel most qualified to work on the project are not available for the project. SAP AG 2005 May 2005 Release

New personnel are added late in the project, and additional training is required. Team member assignments do not match their strengths.

3 of 7

1/15/2013 124308370.xls.ms_office

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.

Customer Risks Customer does not participate in reviews resulting in unstable requirements and time-consuming changes. Customer will not accept the project deliverables even though they meet acceptance criteria Customer response time to answer clarification questions is slower than expected. 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) 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.

Requirements Risks (Technical - Change Control Management) Requirements have not been baselined and continue to change without formal Change management control. Requirements for interfacing with others are not under the teams control and result in unforeseen implementation considerations. Requirements take longer to satisfy than expected.

Unfamiliar and unproven procedures cause unforeseen problems.

External Environment Risks Regulations change unexpectedly. Technical standards change unexpectedly.

Vendor Risks

SAP AG 2005 May 2005 Release

4 of 7

1/15/2013 124308370.xls.ms_office

Contractors do not deliver components when promised.

SAP AG 2005 May 2005 Release

5 of 7

1/15/2013 124308370.xls.ms_office

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 projects objectives. )

Project Identification Project Name Customer Name Project Sponsor Project Manager (SAP) Program Manager SAP Service Partner(s) Project Type CPI/Project Number Customer Number Project Start/Finish Date Project Manager (Customer) Project Manager (Service Partner) Probability of Occurrence (1 - 5) 2 3 5

Risk #

Date Identified

Impact of Risk (1 - 5) 5 3 3

Risk Level (1 - 25) 10 9 15 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0

Risk Description

Category

Potential Impact

Risk Owner

Response Strategy

Risk Response

Status

Date of Invoked Response

Contingency Plan Developed?

SAP AG 2005 May 2005 Release

6 of 7

1/15/2013 124308370.xls.ms_office

Risk Analysis Matrix

Probability Levels 1 Improbable (1 - 20%) 2 Possible (21-40%) 3 Probable (41-60%) 4 Highly Probably (61-80%) 5 Almost Certain (81-100%) Impact Levels 1 Minimal 2 Small 3 Average 4 Large 5 Very Large

4
(If Risk Occurs)

Impact

1 1 2 3 Probability
(That the Risk will occur)

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.

SAP AG 2005 May 2005 Release

1/15/2013 7 of 7