IT Project Management Methodology. Project Risk Management Guide. Version 0.3

Transcription

1 NATIONAL INFORMATION TECHNOLOGY AUTHORITY - UGANDA IT Project Management Methodology Project Risk Management Guide Version 0.3 Project Risk Management Support Guide version 0.3 Page 1

2 Version Date Author Change Description rd Mar, 2013 Gerald Kisongoch, PMP Draft development th June, 2013 Gerald Kisongoch, PMP, PMI-RMP Overall revision of document th June, 2013 Abdul Nsubuga, PMP General review and restructuring of the document Project Risk Management Support Guide version 0.3 Page 2

3 Table of Contents 1 INTRODUCTION Project Risk Management Overview Intended Audience Risk Management Approach Avenues for Risks Identification Documentation of Identified Risks Risk Strategies for Negative Risks (Threats) ROLES AND RESPONSIBILITIES Project Risk Management Support Guide version 0.3 Page 3

4 1 Introduction 1.1. Project Risk Management Overview Risk management is an undertaking to lessen the of potentially undesirable events on a project and amplify the of a positive event. Risk should be thought of as the possibility of suffering a negative to the project; it can result into decreased quality, increased cost, delayed completion, or project failure. Managing projects risks enhances project success so it should be the project manager s responsibility that he/ she puts an effort in managing risks To be successful, an organization should have a risk management policy in place; and all stakeholders must be committed to addressing risk management throughout the project life cycle. This guide provides highlights on how to document policies and procedures for identifying and handling uncommon causes of project variation (i.e. risk) Intended Audience Generally, the risk management plan should apply to everyone on the project, including any consulting/contractor teams or resources Risk Management Approach The overall risk management approach should follow a standard risk management model. Below is a recommended model to be followed in our case in order to enhance standardization of IT projects risk management. Project Risk Management Support Guide version 0.3 Page 4

5 Table 1: Risk Management Process Process Risk Identification Risk Analysis Risk Response Planning Risk Monitoring and Control Objective To identify risks that might affect the project and documenting their characteristics. Sources of risk, potential risk events, and symptoms of risk are identified. To perform risk analysis; the value of opportunities to pursue verses the threats to avoid; and the opportunities to ignore verses the threats to accept are assessed refer to Section 4 for further guidance To develop risk management and contingency plans refer to Section 5 for further guidance. To ensure that corrective action plans are developed, implemented, and monitored see section 6 for further guidance Risk Identification A project manager should lead a team to identify risks. Predefined risk categories can be developed in an organization to provide a structure that can help a project team to ensure that a systematic process is followed to identify risks. A Risk Breakdown Structure or categories in the following charts can be used as guides during risk identification exercise. Project Risk Management Support Guide version 0.3 Page 5

6 Chart 1: Sample Risk Categorization Chart 2: Sample Risk Breakdown Structure Project Risk Management Support Guide version 0.3 Page 6

7 Avenues for Risks Identification Risk identification is done throughout the project life cycle, although majority of the risks should be identified early on so that proper response planning and monitoring can occur. The following should be considered as potential sources for risk identification: 1. Project charter 2. Analysis of high-level deliverables 3. Analysis of the WBS and project implementation plan 4. Analysis of scope change requests 5. Analysis of project assumptions 6. Project team input (which can take the form of interviews, brainstorming sessions, and/or Delphi technique) 7. Stakeholder and sponsor input 8. Formal risk identification sessions 9. Previous lessons learned 10. Software Quality Assurance audits and reviews 11. Performance and status reports 12. Diagramming techniques such as cause and effect diagrams, process or system flows, and influence diagrams Documentation of Identified Risks All identified risks should be documented and entered into the risk register / matrix (a sample is provided below). Only Risk Identified and Risk Description columns are filled at this stage. A comprehensive job should be done during risks identification exercise. Project Risk Management Support Guide version 0.3 Page 7

8 Table2: Sample Risk Register / Matrix S. No. Risk Identified Risk Description Likelihood (Scale of 0.1-1) Impact (Scale of 0.1-1) Factor (likelihood x Impact) Category (L,M,H) Risk Owner Mitigation (Response Plan) Comments Status 1 Project Risk Management Support Guide version 0.3 Page 8

9 Furthermore, during risk identification, the following information should be documented: 1. Risk category 2. Risk trigger 3. Potential outcome 4. Raised By 5. Date Raised 6. Source Risk Riggers The risk trigger is the event that would need to happen in order for the potential outcome to occur. A project manager should always encourage the risk owners to pay attention to risk triggers of assigned risks throughout the project life. Risk triggers are usually expressed with some sort of dependency, or qualifier. For example, a risk trigger for a possible flood threat could be rain. Any form of rain therefore alerts the risk owner to ensure the contingency plan for a flood is ready to execute if the rain causes a flood Risk Analysis After identifying all possible risks, proceed to analyze the risks to ascertain their probability or likelihood of occurrence and their on the specific tasks and overall project should they occur. Impacts can be assessed against project cost, schedule, scope, and/or quality. If the risk event affects more than one dimension and the scores are different, the higher definition should be utilized Table 3 and table 4 provide probability and definitions respectively, which should be applied on all IT projects for purposes of standardization and comparability of IT projects in government. Project Risk Management Support Guide version 0.3 Page 9

10 Table 3: Risk Probability Definition Probability Category Probability Description Very High 0.9 Risk event expected to occur High 0.7 Risk event more likely than not to occur Probable 0.5 Risk event may or may not occur Low 0.3 Risk event less likely than not to occur Very Low 0.1 Risk event not expected to occur During risk analysis the potential of each risk should be analyzed, and an appropriate level (0.05, , 0.40, or 0.80) be selected based on the guidelines defined in table 4 below. Table 4: Risk Impact Definition Project Very Low Low Moderate High Very High Objective Cost Insignificant < 5 % cost 5-10% cost 10-25% cost > 25% cost cost Schedule Insignificant < 5% 5-10% 10-20% > 20% schedule schedule schedule schedule schedule Scope Barely Minor areas Major areas Changes Product noticeable ed ed unacceptable becomes to sponsor effectively useless Quality Barely Only very Sponsor Quality Product noticeable demanding must reduction becomes applications approve unacceptable effectively ed quality to sponsor useless reduction Project Risk Management Support Guide version 0.3 Page 10

11 Once the appropriate risk and probability are selected, the risk factor or priority (product of probability and ) can be determined. The matrix in table 5 below shows the combination of and probability that in turn yield a risk priority (shown by the red, yellow, and green colored shadings). Risk priority is utilized during response planning and risk monitoring/control. It is critical to understand the priority for each risk as it allows the project team to properly understand the relative importance of each risk. Table 5: Risk Factor or Priority Analysis Probability Risk Factor Impact Risks that fall into the red-shaded cells of the matrix are the highest priority, and should receive the majority of risk management resources during response planning and risk monitoring/control. Risks that fall into the yellow-shaded cells of the matrix are the next highest priority, followed by risks that fall into the green-shaded cells Develop a similar matrix for opportunities. It is a good risk management practice to start with identification and management of Project Risk Management Support Guide version 0.3 Page 11

12 positive risks as this gives the team the much needed motivation and optimism with regards to the project After the above analysis, you should be able record: Likelihood; Impact; Factor (likelihood x Impact); Category (Low, Medium, High) and Risk Owner in the risk register defined in table2 above Response Planning After completing risks identification and analysis, you should proceed to formulate a response plan of action to lessen the risks. During response planning, strategies and plans are developed to minimize the effects of the risk to a point where the risk can be controlled and managed Higher priority risks should receive more attention during response planning than lower priority risks. Every risk threat should be assigned an risk owner during response planning Risk Strategies for Positive Risks (Opportunities) The following response plan to opportunities could be considered: Enhance Risk enhancement increases the probability an opportunity will occur by focusing on the trigger conditions of the opportunity and optimizing the chances. Exploit Risk exploitation should be used on opportunities when the organization wishes to assure the opportunity is realized. For example hiring the best experts or assuring Project Risk Management Support Guide version 0.3 Page 12

13 the most technologically advanced resources are available to the project team. Share Risk sharing involves sharing responsibility and accountability with another to enable the team the best chance of seizing the opportunity. Accept Risk acceptance is any decision not to change to deal with a risk. Risk acceptance is either passively accepted by doing nothing or actively by establishing a contingency reserve Risk Strategies for Negative Risks (Threats) The following response plan to negative risks could be considered: Avoid Risk avoidance involves changing aspects of the overall project management plan to eliminate the threat, isolating project objectives from the risk s, or relaxing the objectives that are in threatened (e.g. extending the schedule or reducing the scope). Risks that are identified early in the project can be avoided by clarifying requirements, obtaining more information, improving communications, or obtaining expertise. Transfer Risk transference involves shifting the negative of a threat (and ownership of the response) to a third party. Project Risk Management Support Guide version 0.3 Page 13

14 Risk transference does not eliminate a threat; it simply makes another party responsible for managing it. Mitigate Risk mitigation involves reducing the probability and/or the of risk threat to an acceptable level. Taking early and pro-active action against a risk is often more effective than attempting to repair the damage a realized risk has caused. Developing contingency plans are examples of risk mitigation. Accept Acceptance is often taken as a risk strategy since it is very difficult to plan responses for every identified risk. Risk acceptance should normally only be taken for low-priority risks. Risk acceptance can be passive, where no action is taken at all, or active. The most common active approach to risk acceptance is to develop a cost and/or schedule reserve to accommodate known (or unknown) threats Documentation The results of response planning should be documented in the risk register (table 2 above). The following information should be entered in the register: 1) Response strategy (avoid, transfer, mitigate, or accept) 2) Response notes (description of plan) if a mitigation approach is taken, specific trigger points that require aspects of the contingency plan to be executed should be documented 3) Risk owner Project Risk Management Support Guide version 0.3 Page 14

15 1.3.4 Risk Monitoring and Control After completing risks identification, analysis and developing strategies for response plan, you embark on controlling and managing risks. Planned risk responses should be executed as required over the project life cycle of the project, but the project should also be continuously monitored for new and changing risks. During risk monitoring and control the following tasks should be performed: 1) Identify, analyze, and plan for new risks 2) Risk owners should keep tracking identified risks and monitor trigger conditions 3) Review project performance information (such as progress/status reports, issues, and corrective actions) 4) Re-analyze existing risks to see if the probability,, or proper response plan has changed 5) Review the execution of risk responses and analyze their effectiveness 6) Ensure proper risk management policies and procedures are being utilized 7) Have specific risk review meetings Documentation The results of risk monitoring and control should be documented in the risk register (table 2 above). The following information should be captured: 1) Status valid statuses are: i. Identified Risk documented, but analysis not performed Project Risk Management Support Guide version 0.3 Page 15

16 ii. iii. iv. Analysis Complete Risk analysis done, but response planning not performed Planning Complete Response planning complete Triggered Risk trigger has occurred and threat has been realized v. Resolved Realized risk has been contained vi. vii. 2) Comments Retired Identified risk no longer requires active monitoring (e.g. risk trigger has passed) Trigger Date if the risk has been triggered 2 Roles and Responsibilities The following key stakeholders will be responsible for different aspects during project risk management effort. Below find guidelines for the same. Role Project Sponsor Responsibilities Should participate in risk identification and risk activities during project charter formulation. Should also receive escalated risks and assist with mitigation and contingency actions for escalated risks. Project Manager Responsible for approval of the risk management plan, Project Team Quality Leads and participates in the risk management process, and Takes ownership of risk mitigation/contingency planning and execution. The project manager is ultimately responsible for the final decision on risk actions, in coordination with the project sponsors. Project team members participate in the risk identification process and discuss risk monitoring and mitigation activities at team meetings. They can be risk owners if deemed capable by the project manager The software quality assurance (SQA) lead is responsible for Project Risk Management Support Guide version 0.3 Page 16

17 Assurance Lead Other Project Stakeholders ensuring identified risks are managed as per the risk management plan. The SQA lead also assist in identifying new risks and/or proposing mitigation strategies and contingency plans, along with proposing improvements to the risk management plan and processes. Stakeholders assist in identifying, analysis, response plans and monitoring risk action effectiveness and participate in risk escalation, as necessary. Project Risk Management Support Guide version 0.3 Page 17