PMI Risk Register Guidelines

0% found this document useful (0 votes)
176 views7 pages
The document provides instructions for completing a project risk register. It describes the fields to include such as risk number, description, category, potential impact, probability, respo…

Uploaded by

BTconcord
  • Project Risk Register Instructions
  • Leading Questions for Risk Identification
  • Project Risk Identification Checklist
  • Risk Register
  • Risk Analysis Matrix

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 [Link].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 [Link].ms_office

Contractors do not deliver components when promised.

SAP AG 2005 May 2005 Release

5 of 7

1/15/2013 [Link].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 [Link].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

Common questions

Powered by AI

Not having a clearly defined project scope, vision, and objectives can lead to scope creep, misaligned expectations, and resource misallocation. These issues make it difficult to effectively identify and manage risks because the lack of clarity can obscure potential risk factors and their impacts on project success . This ambiguity can result in an increased likelihood of project changes and missed deliverables, as well as confusion among stakeholders . To address this, it is crucial to establish a clear, documented scope as part of the project planning process and ensure ongoing communication among all stakeholders to align expectations .

Project risks are identified and documented during the following key phases: Initiating, Planning, Executing/Monitoring/Controlling, and Closing. Each phase contributes to effective risk management by focusing on specific aspects of the project. In the Initiating Phase, the clarity of deliverables and commitment from the business sponsor are assessed . The Planning Phase emphasizes the realism of the schedule and budget, roles documentation, and contingency plans . During the Executing/Monitoring/Controlling phase, risks are managed through tracking schedule and budget adherence, and assessing team changes . Finally, the Closing Phase ensures all deliverables are met and customer satisfaction is achieved . These structured approaches across phases ensure comprehensive risk identification and management .

An unrealistic budget based on ad hoc estimates can lead to insufficient funding for necessary activities, causing delays and forcing scope reductions to stay within budget constraints . This often results in incomplete or low-quality deliverables and may require additional resources or restructuring, ultimately impacting overall project success . To improve budget forecasting, organizations can utilize historical data analysis, involve experienced personnel in the estimation process, and incorporate contingency reserves to address potential risks . Regularly reviewing and adjusting the budget as the project progresses ensures alignment with actual project needs and reduces financial risks .

Inadequate progress tracking can significantly impact project success by causing delays, increased costs, and resource misallocation. It may lead to a lack of awareness about whether the project is on schedule or budget, resulting in uninformed decision-making and reactive management . Risk management strategies to alleviate these issues include implementing accurate progress monitoring tools, regular reporting cycles, and contingency planning to address deviations promptly . Additionally, fostering a culture of proactive risk management where team members are encouraged to report potential concerns early can mitigate the likelihood and impact of such risks .

External environment risks, such as regulatory changes, can significantly impact project objectives by altering business processes, causing delays, and increasing costs due to rework or compliance requirements . Proactive measures to mitigate these risks include staying updated with industry regulations, actively engaging in industry forums, and building flexibility into project plans to accommodate changes. Additionally, setting up a dedicated team to monitor regulatory developments and instituting regular risk assessments can help identify potential impacts early and adjust project plans accordingly .

A contingency plan is significant in a risk management process because it provides predefined actions to be taken when a risk event occurs, aiming to minimize its impact on the project. Such plans are essential for maintaining project continuity and protecting objectives when unexpected events arise . The development of a contingency plan is usually determined by the risk level; risks in the "Red Zone" require mandatory contingency plans, while those in the "Orange Zone" are considered for contingency planning . This ensures resources are allocated effectively to manage potential disruptions according to their severity and likelihood .

Ineffective change control management can lead to project failure by allowing uncontrolled changes to disrupt project scope, timelines, and resource allocation, resulting in delays, budget overruns, and unmet objectives . Best practices to prevent uncontrolled changes include establishing a formal change control process that requires documentation and approval for all changes, involving key stakeholders in decision-making, and maintaining updated project documentation to reflect approved changes . Regular training and communication ensure that all project members are aware of and adhere to the change control process, reducing the risk of unauthorized changes .

Key challenges associated with managing resource risks include personnel unavailability, misalignment of skills with project needs, and high turnover rates. These issues can delay project timelines and impact quality . Effective management of these risks involves strategic workforce planning, ensuring the availability of qualified personnel, and aligning team member assignments with their strengths . Additionally, incorporating cross-training and succession planning can help mitigate the impact of turnover. Continuous engagement and communication with team members ensure alignment with project goals and enhance commitment .

A Risk Owner is responsible for the management and implementation of response plans for specific project risks. This role influences the response strategy selection by ensuring accountability and active management of the risk throughout the project lifecycle. The Risk Owner's understanding of the risk and its context allows them to choose the most effective strategy among options like Acceptance, Avoidance, Mitigation, and Transference . By owning the risk response, they ensure the plan aligns with project goals and integrates with existing processes, thereby potentially reducing the probability and impact of risks .

The Risk Level in project risk management is calculated by multiplying the probability of occurrence by the impact of the risk, each rated on a scale from 1 to 5. This numeric calculation helps quantify the potential severity of each risk. A significant aspect of this calculation is that if the resulting Risk Level is 15 or above, a Detailed Risk Response Form must be completed, indicating that additional response actions are needed to mitigate or manage this risk . This approach ensures that high-risk factors are prioritized for action to protect project objectives .

Field
Instructions
Risk Number
List the Risk Number in sequential order.   
Date Identified
Enter the date the risk was first
Leading Questions for Risk Identification 
Purpose
 Use the following as examples of project risks to assist in identificatio
Purpose
The Project Risk Identification Checklist provides checklist items in categories that serve as memory 
joggers during
Personnel need extra time to learn 
unfamiliar processes and procedures.
Team members do not buy into the project 
and conseq
Contractors do not deliver components 
when promised.
 SAP AG 2005
May 2005 Release
5 of 7
1/15/2013
124308370.xls.ms_office
CPI/Project Number
Customer Number
Project Sponsor
SAP Service Partner(s)
Probability 
of
Impact
Risk
Occurrence
of Risk
Leve
1
2
3
4
5
1
2
3
4
5
1
2
3
4
5
Average
Large
Very Large
Contingency Planning
A Contingency Plan should be developed for risks

You might also like