This document provides a summary of project risk management. It begins with introducing the importance of managing risk for project success. It then outlines various project risks from human factors, project design issues, and external dependencies. The document describes a six step overall risk management process including preliminary assessment, planning, identification, analysis, response planning, and monitoring. Each step is explained in one to two sentences. Examples of risk matrices and registers are also provided.

1. © 2011 IBM Corporation
Project Risk Management
Sasha Lazarevic, PMP, PMI-RMP
September 2, 2011

2. © 2011 IBM Corporation2
Introduction
 Success in business is determined by just two things: winning new business
and managing risk
 But statistics are almost tragic:
– 60% ERP projects were late and 70% over budget (US market report 2010)
– 34% of IT projects will finish on time and budget (Standish CHAOS Report 2010)
– 50% of IT projects will cost 189% more than original estimates
– 20% of IT projects will bring full statisfaction
 “Lightning never strikes twice in the same place”
– But lightning strikes the same spot hundreds of times, always the highest place with the best
electrical connection to the ground. The same with projects: Problems tend to recur in project
after project, unless the root cause is understood and something differently is done to avoid
the problem.
 « There is not enough time for risk planning »
- But is there enough time for rework, firefighting, and recovering troubled projects ?

3. © 2011 IBM Corporation3
Beware of: Humans
 Salesmen
- Strategy “price to win the business”. In this case, it might be even impossible to deliver the
project.
 Project sponsors
– They are ambitious and much more risk tolerant than most project leaders and teams.
 Line managers
– Escalations to them usually don’t work.
 Engineers
- Most engineers are analytical, and like to be precise, accurate, and thorough. If there is time
available to try to make something perfect, most engineers will try.
 Ourselves (as Project Leaders)
- People tend to estimate desirable outcomes as more probable than it is realistic (“This lottery
ticket is sure to win”). The result are over-optimistic estimates.

4. © 2011 IBM Corporation4
Beware of: Project Design
 Project Size
- Very large projects are rarely successful. As project is bigger, as more risks it carries
- Project that is only 20% larger than previous one has significant risk
 Lack of details
- When describing details of the work to be done or the technical solution to the lowest level is
difficult, it is sign of risk. What is not clear in the beginning tends to keep unclear until the end. And
then it causes delays.
 Non-assigned activities
- Any activity where owner is not named during planning phase is a risk. What is not assigned in
the beginning, tends to remain unassigned until the end. And then it causes delays.
 Invisible correlation among project risks
- Most risks become much more likely after other risks have occurred. Project activities are linked
through common resources and methodologies. Whenever there is a problem, all of the project
leader’s attention (and much of the project team’s) will be on recovery. Much less focus will remain
on other project activities, and the troubles start to appear everywhere.

5. © 2011 IBM Corporation5
And what about this ?
 Mandatory use of new technology
 Unfamiliar tools, methods or solutions
 Incomplete or poorly defined acceptance tests or criteria
 Technical complexity
 Conflicting or inconsistent specifications
 Dependency on external companies for a key subcomponent
– 75% of all deliverables from external suppliers are late or unsatisfactory
 Influences from other orgnizational units to favor friends, to align with
“strategic” partners, or to use a global (or a local) supplier
– If the suppliers are not selected by the project team, this represents significant, and
sometimes disastrous, project risk

6. © 2011 IBM Corporation6
How to manage all these risks ?
 Schedule risky activities earlier, so the problems can be uncovered as soon as
possible
 Be ready to abandon the project
 Make two schedules: target schedule and committed schedule
– target schedule for a risky project might be twelve months, but the committed schedule,
reflecting potential problems, may be set at fourteen months. Completion within (or before) this
range defines a successful project.
 Identify if risks are controllable or out of control
– For those controllable, establish early warning system
– For those out of control, experiment with shifting the time, changing responsible owner,
infrastructure, or other parameters
 Avoid unproven technologies whenever possible
– If avoiding is not possible, develop plan B based on already proven methods
 Test with users, early and often
 Publish « top ten » risks to the project team and internal project sponsors
 Watch for risks
 Use project portfolio risk management to eliminate particularly risky projects
and focus on best available project opportunities
 Do smaller projects, decompose large initiatives into smal pieces

7. © 2011 IBM Corporation7
Overall Risk Management Process
 1. Preliminary Risk Assessment
 2. Risk Management Planning
 3. Risk Identification
 4. Risk Analysis
 5. Risk Response Planning
 6. Risk Monitoring and Control

8. © 2011 IBM Corporation8
Process Flowchart

9. © 2011 IBM Corporation9
Step 1: Preliminary Risk Assessment
Objective: Identify major and visible risks
Risk Categories :
 Risks to win business
 Risks to win profit
 Risks for the customer satisfaction
Balanced approach to minimize overall risk
Determine potential financial loss that the project can incur
Setup the requirements and resources for the future risk management

10. © 2011 IBM Corporation10
Risk Template

11. © 2011 IBM Corporation11
Step 2: Risk Management Planning
Objective: Create Risk Management Plan
 Inputs : contract, statement of work
 Output: Risk Management Plan. Components :
- Methodology,
- Roles and Responsibilites,
- Budgeting,
- Definition of risk categories,
- Definition of probability and impacts,
- Stakeholder risk tolerance,
- Reporting and tracking requirements

12. © 2011 IBM Corporation12
Exhibit: Risk Impact Matrix
Other risks
Personal consequences Bad performance appraisal, loss of reputation, no prospect for promotion,
health problems
Team consequences Loss of productivity, team disputes
Organizational consequences Delayed concurrent projects, resignations, loss of trust
Risk level Impact description
Very High Project « showstopper » that can result in the project cancellation, or make overall long-
term business impact
High Risk that threatens one or more of the project objectives like company’s satisfaction
(read: profit), customer satisfaction (read: delays and quality)
Moderate Risk that results in significant project replanning and would lead to a noticeable effect for
the organization
Low Any impact that can be handled within the project team
Very Low Any impact that is not visible outside the project team

13. © 2011 IBM Corporation13
Step 3: Risk Identification
Objective: create Risk Register
Inputs: historical records, lessons learnt from previous projects, Risk Management
Plan, Project Scope Statement, WBS, Project Schedule, activity estimates,
stakeholder register
Techniques: Organize Risk Identification Workshop, Brainstorming, Root-cause
Analysis, Interviewing, Delphi technique, Documentation Review, use already
available checklists, develop process flowcharts, use iterative process
Outputs: List of identified risks, their potential impacts and potential responses

14. © 2011 IBM Corporation14
Exhibit: Risk Register

15. © 2011 IBM Corporation15
Step 4: Risk Analysis
Objective: separate big from small, urgent from less urgent risks
Inputs: Risk register, Risk Management Plan, Project Scope Statement
Techniques: Organize Risk Analysis Workshop, risk probability and impact
assessment, risk categorization, risk urgency assessment, risk sensitivity analysis,
decision tree analysis, use iterative process
Outputs: Update the Risk Register (priority list of risks, near-term response risks),
Watch-list, new risks can be added

16. © 2011 IBM Corporation16
Step 5: Risk Response Planning
Objective: determine the best possible responses to identified risks
Inputs: Risk register, Risk Management Plan
Techniques: Avoid, Transfer, Reduce, Acceptance (active and passive)
- Active acceptance means putting contingency reserves aside should the risks
occur (money or time buffers)
- Organize Risk Response Planning Workshop
Outputs:
- Update the Risk Register (risk owners, risk triggers, risk action plans, fallback
plans in case primary plans don’t work, list of residual risks after actions have been
performed, list of secondary risks caused by the actions),
- Update all project related plans (schedules, cost, procurement etc)

17. © 2011 IBM Corporation17
Step 6: Risk Monitoring and Control
Objective: track risks, activate risk response plans, identify new risks,
implement workarounds
Inputs: Risk register, Individual work reports,
Techniques: Risk reassessment, Audits, Quality assurance reviews, Status meetings,
Trend analysis, Reserve analysis (of the contingency reserves)
Outputs: Update the Risk Register (closed risks, new risks) , Change Requests,
updates to the relevant project plans, Lessons Learnt