Upcoming SlideShare
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Standard text messaging rates apply

# Risk Analysis Workbook

2,289

Published on

Risk Analysis Workbook

Risk Analysis Workbook

0 Likes
Statistics
Notes
• Full Name
Comment goes here.

Are you sure you want to Yes No
• Be the first to comment

• Be the first to like this

Views
Total Views
2,289
On Slideshare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
186
0
Likes
0
Embeds 0
No embeds

No notes for slide

### Transcript

• 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