Managing Project Risk

Project Risk “…an uncertain event or condition that, if it occurs, has a positive or a negative effect on a project objective.”

Project Risk Some probability that something negative will happen to a project ultimately affecting The project’s budget, schedule, and/or deliverables Risk planning Where to look for risk Assessing the risk Deciding how to handle it Developing a plan to handle risk Risk is defined in terms of it’s bottom line: the probability that something will happen with a negative impact on a project’s budget, schedule, deliverables or any combination of them. To grab a hold of this risk and manage it, project leaders need a risk management plan and a general way of approaching risk. That plan and that approach involves Knowing where to look for risk (sources of risk) Assessing the risk once it is found (risk assessment) Deciding on how to handle the risk (risk responses) and Developing a plan for responding to risk as it arises Once the planning is done, attention turns to handling risk “on the run” Checking for risk as it arises in project execution and handling it as it does. These are the topics covered in this presentation Leading Project Teams: The Basics of Project Management and Team Leadership, 2e by Anthony T. Cobb ©2011 SAGE Publications, Inc.

Sources of Risk Risk from project management Risks from the host organization Deliverable risks External risks This is an “agenda” slide to introduce the topics of risk sources to come Risk from project management Problems coming from the planning and execution of the project Risks from the host organization Problems that come from within the organization that is hosting the project Deliverable risks Problems that may occur to the deliverables of the project in terms of client or end user satisfaction External risks Problems that can come from the larger physical, economic, and market environment of the project Leading Project Teams: The Basics of Project Management and Team Leadership, 2e by Anthony T. Cobb ©2011 SAGE Publications, Inc.

Risks from Project Management Project Execution Command and control Project and team processes Project Execution Command and control The leadership structure—who has authority and responsibility for doing various parts of the project Becomes more of a risk the larger and more complex a project becomes because more people and critical jobs become involved Risks: Leadership roles, time demands, and capabilities not well understood Need for monitoring: Milestone reviews at critical points, tools like earned value analysis used Project and team processes Communications: Information will flow to the right persons when needed Decision making: Everyone with important information, knowledge, and project responsibilities are involved Coordination: People know about project events that will affect them. People who need to work together are doing so. Leading Project Teams: The Basics of Project Management and Team Leadership, 2e by Anthony T. Cobb ©2011 SAGE Publications, Inc.

Risks from the Host Organization Organizational support Funding and other resource support Organizational politics Recall that the “Host organization” is either Hosting a project for an outside client Hosting a project for its own use Many sources of risk are the same for both kinds of host organizations but may surface in different ways Organizational support Support from higher management for the project Projects need to be championed by higher management, particularly if problems arise Funding and other resource support Getting funding on time as the project moves forward Needs attention to funding sources and prediction of resource flow “Volunteered” support may not come through as assumed There is often resistance to promised or ordered help from other parts of the organization Organizational politics Projects compete for resources Projects within host organizations can develop opponents to the means or goals of the project Successful projects advance the careers of their leaders, sometimes at the detriment of others Leading Project Teams: The Basics of Project Management and Team Leadership, 2e by Anthony T. Cobb ©2011 SAGE Publications, Inc.

Deliverable Risks Technical problems Other Problems Issues to consider Organizational changes required Issues to consider How easy will it be to deliver the products –services How demanding are the clients The risk that deliverables will not meet quality or performance requirements Or not satisfy the client or end user Technical problems Risk goes up the more deliverables push the boundaries of known science Or simply the knowledge, skills and abilities of those working on the project Other Problems The project requires that organizational changes be made in the use of tools, materials, or operations Making changes that actually work is often very difficult Changes push at the limits of our knowledge Changes invite resistance Issues to consider How easy will it be to deliver the products –services As difficulty increases, so does risk How demanding are the clients Some clients are more demanding than others Clients often have different areas of concern. For example, cost vs. performance issues Leading Project Teams: The Basics of Project Management and Team Leadership, 2e by Anthony T. Cobb ©2011 SAGE Publications, Inc.

External Risk Client and end users Vendors and other suppliers Regulatory risks Market dynamics The physical environment External risks come from problems that may emerge from the project’s larger environment Client and end users Clients are those who are paying for the project. How demanding they are and their tendency to push the scope of the project to include more deliverables can be risk factors Because they are your customers, a great deal of attention needs to be given to them End users are those who will actually use the deliverables Deliverables must address their needs and suitability for use. Consider planning and budgeting for field testing Vendors and other suppliers Internal suppliers in the host organization may resist providing resources External vendors: Risks associated with quality and timeliness of deliverables More risky the more resources are critical and irreplaceable from other sources Regulatory risks Regulators and regulations can shut down a project or render its deliverables useless for the client Careful attention needs to be paid to the demands of regulations and regulators and when regulatory clearance is required Market dynamics Risk for deliverables In some markets (e.g., electronics) products to be delivered compete with the products of the competition Risk for resources If demand is high for project resources, it can produce cost and scheduling problems The physical environment Weather is always a problem for outdoor work Weather can also affect the availability or delivery of resources Interior noise, lighting, air pollution, and the like should be considered if appropriate to the conduct of the project or suitability of its deliverables. Leading Project Teams: The Basics of Project Management and Team Leadership, 2e by Anthony T. Cobb ©2011 SAGE Publications, Inc.

Information Systems Associated Risks Technology and project management related Positive Availability of new project management tools Negative Rate of change in technologies Upgrades and new releases Assumptions computer-generated output is always correct Formation of teams

Risk & Project Life Cycle Initiation stage Identification and selection of specific projects Inside or outside of organization’s core competencies Planning stage Procurement Unreliability of new technology delivery timeframe Development of accurate project schedule

Risk & Project Life Cycle (cont.) Execution stage Missed scheduled delivery date Technology upgrades Control stage Implementation of risk plan Modification of project schedule Closing stage Acceptance of project as finished

Project Risk Examples New or different project management methodologies Different: Cultures Organization structures Human resources

General Categories of Project Risk Ongoing changes to technology/materials Finding, assigning, and retaining skilled personnel Gaining user acceptance Choosing the correct development methodology Choosing correct manufacturing tools/materials

Outsourcing / Offshoring Positives: Expanded skill set availability Cheaper labor Reduced requirements for non-core competencies Negatives: Internal resistance Possible solutions to reduce risk: Ensure strong upper management support Select the right personnel Involve managers early in the outsourcing process Educate and reassure internal employees

Outsourcing / Offshoring (cont.) Negatives (cont.): Increased security and privacy concerns Possible solutions to reduce risk: Increase physical security measures Use software event logging and monitoring tools Intrusion detection systems and firewalls Encryption hardware/software

Top Five Project Risks Lack of top management commitment to the project Failure to gain user commitment/acceptance Misunderstanding the requirements Lack of adequate user/consumer involvement Failure to manage end user expectations

Risk Management Planning A systematic approach to planning the risk management activities of a given project

Risk Management Planning – Inputs Enterprise environmental factors Attitudes toward risk and risk tolerance Organizational process assets Processes in place to handle risk Project scope statement Defining the project Project management plan Project summary document

Risk Management Planning – Tools & Techniques Risk planning meetings Senior managers, project team leaders, stakeholders, project members with decision-making responsibilities Development of specific risk management plans Inclusion of risk-related items in budget and schedule Creation of risk management templates

Risk Management Planning – Outputs Methodology or approach to risk management Roles and responsibilities of project members Risk management budget Integration of risk management activities into project life cycle Scoring and interpretation of risk analysis Risk thresholds Reporting formats Tracking

Risk Identification The process of identifying potential risks to a project and documenting them

Risk Identification – Inputs Enterprise environmental factors Organizational process assets Project scope statement Project management plan Risk management plan

Risk Categories Defined in a Risk Register A formal recording of all project risks, explaining the nature of the risk and management of the risk

Risks

Risk Identification – Tools & Techniques Documentation reviews The review of organizational information to aid during risk identification May include: Project profiles (previous project information and related lessons learned) Published information Articles/studies/benchmarking information

Risk Identification – Tools & Techniques (cont.) Information gathering techniques Brainstorming Delphi technique Interviewing Strengths, weaknesses, opportunities, and threats (SWOT) Checklists

Risk Identification – Tools & Techniques (cont.) Diagramming techniques Cause and effect (Fishbone) System or process flowcharts Influence diagrams

Risk Identification – Output

Risk Assessment Two basic approaches Three kinds of impact to consider Qualitative judgments Quantitative calculations Three kinds of impact to consider Budget impact Time impact Quality impact on deliverables This is an agenda slide for the two basic approaches to risk assessment that are coming. This slides includes, as well, the “ultimate” impact problems may have on a project. When problems arise in a project they can: Adversely affect the costs and therefore the budget of a project Stretch out the time it takes to get the project done (its schedule) Make the deliverables fall below client expectations or make them completely unusable Leading Project Teams: The Basics of Project Management and Team Leadership, 2e by Anthony T. Cobb ©2011 SAGE Publications, Inc.

Qualitative Risk Analysis Establishment of probabilities regarding both the impact and likelihood of specific risk occurrences

Qualitative Risk Assessment Broader judgments of risk Likelihood problem will occur (low to high) Impact if problem occurs (minor to major) Likely the most commonly used method of risk assessment Can be formalized to produce useful risk assessments Care must be taken to assess risk seriously Broader judgments of risk This is likely the most common approach to assessing project risk Assessing the likelihood a problem will occur These assessments are often judged to be low, medium, or high This may well be the most often used risk assessment in practice because when a risk is identified a quick assessment is made about its likelihood. If it’s judged to be low or unlikely, the risk assessor moves on to another risk Many unlikely risks are, not doubt, handled this way The risk, of course, is in dismissing the likelihood of a risk too easily, without sufficient consideration Assessing the impact if problem occurs (minor to major) These judgments are also often assessed as minor, medium, or major in their likely impact If a risk is judged to be somewhat more likely (above), attention turns to how much of a problem it can produce As potential harm assessment goes up, more attention is given to how the risk might be addressed Qualitative assessments can be formalized into quite useful procedures with clear identification of low to high evaluations of risk occurrence and potential harm Leading Project Teams: The Basics of Project Management and Team Leadership, 2e by Anthony T. Cobb ©2011 SAGE Publications, Inc.

Qualitative Risk Analysis – Inputs Organizational process assets Project scope statement Risk management plan Risk register

Qualitative Risk Analysis – Tools & Techniques Risk probability and impact assessment Probability/impact risk rating matrix Risk data quality assessment Risk categorization Risk urgency assessment

Probability/Impact Risk Rating Matrix A technique used to analyze project risk in terms of its probability of occurrence and its impact on project outcomes

Risk Data Quality Assessment Assessment of the quality of the data used to assess risk May include: Extent to which a risk is understood Available risk data Data quality Data integrity and reliability

Qualitative Risk Analysis – Outputs Updated risk register

Quantitative Risk Analysis Analysis of the probability of occurrence and impact of risk on project objectives using numerical techniques

Quantitative Risk Assessment Probability the problem will occur (0 to 100%) Estimated cost if problem does occur Expected value of the risk = (Probability of occurrence X estimated cost) Actual numbers with probability and cost allow other kinds of calculations Quantitative assessments puts numbers behind the estimates Probability that the problem will occur Probabilities are given in estimates of 0% to 100% likelihood the problem will come up Estimated cost if problem does occur Estimates are then given in terms of the likely cost to the project if the problem does emerge Most common is dollar costs but other costs can be assessed such as amount of time lost This will impact dollar cost but attention may want to be given to time Expected value of the risk = (Probability of occurrence X estimated cost) Although “Expected value” is technically correct, “Expected cost” may make more sense to the audience Actual numbers with probability and cost allow other kinds of calculations PERT analysis, for example, provides a kind of probability distribution to time risks: Best, most likely, pessimistic estimates of the time it will take to complete a task. The advantage of using quantifiable risk estimates is that they can be used in calculations of risk. The expected values of risk in any one component of the project, for example, might be integrated into its budget and added to the price of the project. The costs of contingency plans or other ways of dealing with risk can be compared to the estimated value of the risk. One potential downside to quantitative assessments may be a false sense of security. These are estimates, after all, with their own, often unknown, probability of accuracy. Leading Project Teams: The Basics of Project Management and Team Leadership, 2e by Anthony T. Cobb ©2011 SAGE Publications, Inc.

Quantitative Risk Analysis – Inputs Organization process assets Project scope statement Risk management plan Risk register Project management plan

Quantitative Risk Analysis – Tools & Techniques Data gathering through interviewing Quantitative procedures Sensitivity analysis Technique used to examine the potential impact of specific risks to a project (Tornado analysis) Decision tree analysis Diagramming technique used to evaluate courses of action in terms of their potential cost and benefits relative to other courses of action

Quantitative Risk Analysis – Tools & Techniques (cont.) Expected monetary value analysis (EMV) Statistical technique which captures the average value of potential projects by analyzing the likelihood of possible project outcomes as well as each outcome’s financial consequences Simulation Statistical technique where what-if analyzes are run to determine the impact of a given situation on a project objective (Monte Carlo)

Tornado Analysis

Expected Monetary Value + Decision Tree Analysis

Quantitative Risk Analysis – Outputs Updated risk register

Risk Response Planning The process of developing methods for responding to project risks

Risk Response Planning – Inputs Risk management plan Risk register

Risk Responses Accept the risk Avoid the risk Low, unlikely, or “forced” acceptance Contingency plans and “triggers” Avoid the risk E.g., drop risky procedures or deliverables Risk responses are developed for potential problems that are “risky enough” to warrant further consideration. Accept the risk Risks with a low probability of happening and/or low negative impact are often accepted Other times, projects are simply forced to accept some risks It might be mentioned that risks not known or fully considered are also “accepted” although not consciously Contingency plans and “triggers” When projects accept risk that may have a high negative impact, it is worthwhile to think through a contingency plan to use in case the problem begins to emerge. Triggers are events that signal that a problem is beginning to emerge It is best to think through contingency plans and triggers in advance to catch the problem early and have thought out how best to approach it. Although these plans may altered in the light of new facts, they provide a better base of action than a reflexive response in the “heat of battle” Avoid the risk E.g., drop risky procedures or deliverables In the planning of a project, consideration should be given to project components that may be too risky to assume In the example in the book, Chief Sessions decided not to promise too much in selling his proposal at the outset If forced to assume the risk, ways of reducing the risk or transferring it should be considered along with all cost considerations of those approaches (see next slide) Leading Project Teams: The Basics of Project Management and Team Leadership, 2e by Anthony T. Cobb ©2011 SAGE Publications, Inc.

Risk Responses Reduce the risk Transfer the risk Reduce probability or potential harm of the problem Transfer the risk E.g., insurance or to the client Reduce the risk Reduce probability or potential harm of the problem Reducing the probability of the risk usually calls for looking at the potential source of the risk or problem Once identified, those sources are addressed in advance. Developing contingency plans is one approach to minimizing potential harm If the problem does emerge, for example, more resources may be mobilized to minimize its negative impact Transfer the risk E.g., insurance or to the client Insurance can be taken out to cover the financial aspects that a problem may cause. The costs of that insurance needs to be budgeted The client might accept risks in terms of allowing “cost +” contingencies written into the project contract or “time +” contingencies. Sometimes other organizations are better able to handle project components, reducing the risk to the project. When these project components are outsourced, “performance clauses” can be included in contracting to effectively transfer cost risk to outsourced organization. Something to keep in mind: Clients want things delivered on time and on budget with deliverables made to specification. They may have tolerance for variation in these—and may even have accepted risk associated with them But they are never happy and often angry when costs, time, and/or deliverables are not achieved as promised. Leading Project Teams: The Basics of Project Management and Team Leadership, 2e by Anthony T. Cobb ©2011 SAGE Publications, Inc.

Risk Response Planning – Summary Avoidance Identified risks are avoided through a different course of action Transference Transfer of risk to another party through the use of contracts Mitigation Steps are taken to reduce the occurrence or impact of stated risks Acceptance Risks are accepted and contingency strategies are planned

Risk Response Planning – Outputs Updates to: Risk register Project management plan Risk-related contractual agreements

Establishing a Risk Response Plan Always residual and secondary risk Risk left over or created by primary risk reduction Risk registers Anticipated problems Triggers to look out for Risk owners assigned Action plans to monitor risk in each area of the project There is no way to avoid or handle all risk There is always residual and secondary risk Risk left over or created by the reduction of a primary risk There are risks that were not foreseen Even when we handle risk, how we do so creates risks of its own (secondary risks) It’s good, then, to have a risk plan moving forward A risk register is an important part of that plan Risk registers Essentially a list of foreseen risks and what is being done about it Risk registers can be very formalized but they do not have to be. For smaller projects, a simple, reminder list may do They do need to address certain elements, however Anticipated problems Big problems should be anticipated as much as possible Sufficient time and due diligence need to be paid to risk Those potential problems need to be recorded along with the area within the project the problem may arise Triggers to look out for Recall that triggers are events that signal a problem may be emerging Risk owners assigned Risk owners are responsible for monitoring and responding to risk and problems as they arise Those in charge of project areas are usually responsible for the potential problems that their project component might “host” Action plans to monitor risk in each area of the project Risk owners should have action plans for monitoring for potential problems beyond looking out for previously identified triggers Leading Project Teams: The Basics of Project Management and Team Leadership, 2e by Anthony T. Cobb ©2011 SAGE Publications, Inc.

Dealing with Risk in Project Execution Monitor and respond to risk Risk monitoring a regular part of the job Risk owners take responsibility for their project areas Informing others, if possible handling the problem Careful how you treat those who bring problems Don’t punish the bearers of bad news Monitor and respond to risk Risk monitoring should be a regular part of the job Risk owners need to review potential problems as they might appear in their part of the project as the project moves forward This reviewing responsibility needs to go up the chain of command with each level the “risk owner” of levels below it Risk owners need to take responsibility for their project areas: Informing others when appropriate; handling the problem when they can Risk owners should be empowered to handle emerging problems on their own if possible They need to inform others, however, when a potential problem can affect other operations. Coordinated action will likely be needed to handle the fallout of the problem Risk owners should also seek out others if the problem is a challenge to them. Doing so early on is better than waiting too long Careful how you treat those who bring problems Don’t punish the bearers of bad news People are naturally reluctant to bring their boss bad news, particularly in their areas of operation If you punish them for doing so, the word will get out not to bring bad news to your attention When you get bad news, focus on how to deal with problem, not on blame Try to bring the risk owner in on the problem solving task—this is “on the job training” Wait until the immediate problem is handled before reviewing for deeper sources of the problem Leading Project Teams: The Basics of Project Management and Team Leadership, 2e by Anthony T. Cobb ©2011 SAGE Publications, Inc.

Risk Response Plan Contents (Project Management Institute) Any risks that have been identified along with a description and the areas and objectives the identified risk may affect The roles and responsibilities of any risk owners Qualitative and quantitative risk analysis results as well as any trends identified during either of these processes A description of the risk response strategies including avoidance, transference, mitigation, and acceptance, and the risk that the strategies will be applied to An acknowledgement of any residual risk projected to remain after any risk response strategies have been applied A list of actions to be used to implement the risk response strategies Budget and schedule information in terms of risk response Any contingency plans used as part of an active response to accept risks

Additional Risk Terms Residual risks Secondary risks Any risks remaining after risk response strategies have been applied Secondary risks Any risks resulting from the application of a risk response strategy Contractual agreements Any contracts for the purpose of risk transference during the project

Risk Monitoring & Control The process of monitoring identified risks for change and controlling those changes

Review Risk Performance Review successes and failures at handling risk After significant milestones After significant risk events After the project is completed Develop “lessons learned” To carry on to the next phase or project After action reviews of a project, when it is done and at significant points during the project: Help project leaders and others develop their knowledge and skills for future projects After action reviews should include attention to the risks that were dealt with successfully, those that were not, and to problems that were unanticipated Review successes and failures at handling risk After significant milestones After significant risk events After the project is completed Develop “lessons learned” To carry on to the next phase or project Leading Project Teams: The Basics of Project Management and Team Leadership, 2e by Anthony T. Cobb ©2011 SAGE Publications, Inc.

Questions?