1. Managing Project Risk

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

24. Risks

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

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

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

28. Risk Identification – Output

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

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

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

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

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

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

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

36. Qualitative Risk Analysis – Outputs
Updated risk register

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

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

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

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

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

42. Tornado Analysis

43. Expected Monetary Value + Decision Tree Analysis

44. Quantitative Risk Analysis – Outputs
Updated risk register

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

46. Risk Response Planning – Inputs
Risk management plan
Risk register

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

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

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

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

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

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

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

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

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

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

57. Questions?