17-Mar-16
Project Risk
Text and References
Identifying and Managing Project Risks
by Tom Kendrick
Project Risk Management: Guidance for
WSDOT Projects
Risk Management: Tricks of the Trade
for Project Managers by Rita Mulcahy
A risk is any uncertain event or condition
that might affect the project.
The purpose of project risk management is
to obtain better project outcomes, in terms
of schedule, cost and operations
performance.
Project Risk (Ctd.)
Not all risks are negative. Some events (like
finding an easier way to do an activity) or
conditions (like lower prices for certain
materials) can help the project! When this
happens, it is called an opportunity but
its still handled just like a risk.
Project Risk (Ctd.)
All risks have two related, but distinctly
different, components. Risk is the product
of the probability that the event might occur
and expected consequences of the event.
Risk may be characterized in the aggregate
for a large population of events (macrorisk), or it may be considered on an eventby-event basis (micro-risk).
17-Mar-16
Project Risk (Ctd.)
All risks have two related, but distinctly
different, components. Risk is the product
of the probability that the event might occur
and expected consequences of the event.
Risk may be characterized in the aggregate
for a large population of events (macrorisk), or it may be considered on an eventby-event basis (micro-risk).
Some Basics
Coins
Coloured Balls
Car Park
The Archer
Anti aircraft gun with 5% hit. 10 hits is
equal to one kill.
Normal Distribution Curve (68.2, 95.4,
99.7)
Type
Duration
(months)
Risk
Complexity
Technology
Type A
>18
High
High
Breakthrough
Type B
9 to 18
Medium
Medium
Current
Type C
3 to 9
Low
Low
Best of breed
Type D
<3
Very low
Very low
Practical
17-Mar-16
Test Yourself
Explain why each of the following inputs to
risk management are needed before you can
adequately complete the risk management
process
Format
INPUT
List of Inputs
Project
management process
Project background information
Project charter
Why is it needed
List of Inputs (Contd.)
Internal
stakeholders
External stakeholders
Scope statement
Constraints
Assumptions
WBS
Network diagram
List of Inputs (Contd.)
Time
& cost estimates
Human Resource Plan
Communication Management Plan
Procurement Management Plan
17-Mar-16
List of Inputs (Contd.)
Risk
management system
Historical records
Lessons learnt
Risk tolerance
Risk thresholds
Planning for
Risk Management
Main Reasons of Project Failure
because they actually are impossible
possible deliverable, but the rest of the
objective is unrealistic
Deliverable and the rest of the objective
is possible but too little thought is put
into the work
Risk and project planning helps
distinguish and deal with all three
of these situations
situations..
17-Mar-16
Outcomes of
Effective Project Selection Process
Appropriate Project Selection
Number of projects can be minimized
Project priorities can be aligned with
business and technical strategies
Overestimation of resources and resource
capabilities can be avoided
Risk tolerance should be kept in mind
Group Discussion
the project is authorized, OR
the project may require changes to scope,
schedule, or resources, OR
The project is postponed for later
reconsideration, OR
The project ideas are turned down
Overall Project Planning Processes
Working in a group of 3 to 4, do the following:
Identify and introduce of an innovative
project idea
May be considered as unnecessary
overhead and luxury
Prepare a list of risks involved in acceptance
of the idea
Is project routine or high-tech
History of success & failure
Brief plan to minimize idea acceptance risks
(30 min preparation + 5 min presentation)
17-Mar-16
Results of Appropriate Planning
Better communication
Less rework
Lowered costs, reduced time
Earlier identification of gaps and
inadequate specifications
Fewer surprises
Less chaos and fire-fighting
Known and Unknown Risks
Overcoming Project Risk: Lessons from the
PERIL Database
known risks occur frequently enough
to be analyzed in advance.
Tom Kendrick
unknown risks result from the
uniqueness of the work and are difficult
or impossible to anticipate.
Program Manager, Hewlett-Packard
Company
17-Mar-16
The PERIL Database
The PERIL Database (Contd.)
Project Experience Risk Information
Library
Project Experience Risk Information
Library
Input from a large number of projects
and project managers
Input from a large number of projects
and project managers
Contains samples
May shift unknown to known
The PERIL Database (Contd.)
PERIL is not comprehensive
PERIL is not unbiased. It is random and
self-reported.
PERIL represents only significant risks.
IT Projects PERIL Database
17-Mar-16
Chapter 3 (Tom Kendrick)
17-Mar-16
Well begun is half done.
(ARISTOTLE)
Unclear scope almost always
have a negative cost and
schedule impact (Rita)
Why Requirements may be Unclear
Changing environments
Difference in language or culture
Determination time is not enough
Inexperienced project manager
Tendency to avoid arguments
Poor realization of concequences
To keep options open etc.
Scope Risk Ideas
I.
Sources of scope risk
II.
Defining deliverables
III.
High-level risk assessment
IV.
Setting limits
V.
Work breakdown structure
VI.
Market and confidentiality risk
17-Mar-16
I. Sources of Scope Risk
Change Risks
Defect Risks
Change Risks
Scope creep: requirements that evolve
and mutate as a project runs
Gaps: specifications or activities added to
the project late
Scope dependencies: inputs or other
needs of the project not anticipated at the
start of a project
Defect Risks
Relate to non conformity to specification
Generally visible
More in innovative and technological
projects
10
17-Mar-16
II. Defining Deliverables
Scope Risk Management
Techniques
Start by identifying the people
who should participate
Deliverable Definition Process
Documented definition process
Straw-man definition document
Rigorous evolutionary methodology
Deliverable Definition Process
1. Alignment with business strategy (How does this
project contribute to stated high-level business
objectives?)
2. User and customer needs (Has the project team
captured the ultimate end user requirements that
must be met by the deliverable?)
4. Competition (Has the team identified both
current and projected alternatives to the proposed
deliverable, including not undertaking the project?)
5. Positioning (Is there a clear and compelling
benefit-oriented project objective that supports the
business case for the project?)
6. Decision criteria (Does this project team have an
agreed upon hierarchy of measurable priorities for
cost, time, and scope?)
3. Compliance (Has the team identified all relevant
regulatory, environmental, and manufacturing
requirements, as well as any relevant industry
standards?)
11
17-Mar-16
Deliverable Definition Process
7. Delivery (Are logistical requirements understood
and manageable? These include, but are not
limited to, sales, distribution, installation, sign-off,
and support.)
8. Sponsorship (Does the management hierarchy
collectively support the project, and will it provide
timely decisions and ongoing resources?)
Deliverable Definition Process
9. Resources (Does the project have, and will it
continue to have, the staffing and funding needed
to meet the project goals within the allotted time?)
10. Technical risk (Has the team assessed the
overall level of risk it is taking? Are technical and
other exposures well documented?)
STRAW- MAN DEFINITION
DOCUMENT
Used when there is a lack of data/info
Project team defines specific requirements
based on earlier projects, assumptions,
guesses and their understanding of the
problem etc.
Definition constructed this way is certain to
be inaccurate and incomplete
STRAW- MAN DEFINITION
DOCUMENT (contd)
First possibility: invented requirements will
be accepted and approved giving a solid
basis for planning. (may be misused)
Second possibility: outcome is a flood of
criticism,
corrections,
edits,
and
improvements. (everyone seems to enjoy
being a critic.)
12
17-Mar-16
Evolutionary Methodologies
Evolutionary Methodologies
(contd)
Rather than defining a system as a whole,
set out a more general objective and then
cyclically describe incremental stages, each
producing a functional deliverable.
The algorithm is called genetic because it
mimics evolution, randomly mutating the
design in small increments and accepting
those mutations that improve the design.
Scope Documentation
Project description
Project Justification
Completion criteria
Customer(s) and/or users
What the project will and will not include
Internal and external dependencies
It starts the project with no certain end
slower and more expensive
Minimize scope risk but increase schedule
and resource risk
More common in high end IT projects
Scope Documentation (contd)
HR requirements (in terms of skills and
experience)
High-level risks
Cost (rough order-of-magnitude, at least)
Technology required
Infrastructure required
Other significant data and issues
13
17-Mar-16
Risk Framework
III. High- Level Risk Assessment Tools
Risk framework
Consider the following project factors &
their sub factors
Technology (the work)
Risk complexity index
Marketing (the user)
Risk assessment grid
Manufacturing (the production and delivery)
For each of these factors, assess the
amount of change required (insignificant or
significant only)
Part Index Estimation
Risk Complexity Index
Looks more deeply at the technology being
employed
Separates it into three parts and assigns index (0
to 5 each)
also looks at another source of project risk: the
scale.
Correlate changes with risk
0Only existing technology required
1Minor extensions to existing technology needed
in a few areas
2Significant extensions to existing technology
needed in a few areas
3Almost certainly possible, but innovation needed
in some areas
4Probably feasible, but innovation required in
many Areas
5Completely new, technological feasibility in doubt
Index = (Technology+Architecture+System) x Scale
(Uniqueness, Infrastructure & Resources, System) x scale
14
17-Mar-16
Project Risk Assessment
Scale Values
up to twelve people 0.8
thirteen to forty people 2.4
forty-one to one hundred people 4.3
more than one hundred people 6.6
Risk Assessment Grid
Index below 20 are generally low-risk
projects with durations of well under a year
Projects assessed between 20 and 40 are
medium risk. These projects are more likely
to get into trouble and often take a year or
longer.
Most projects with an index above 40 are
high risk, finish long past their stated
deadline, if they complete at all.
Setting Limits
Decisions to continue or to quit in
situations that involve spending more time,
more money, or both.
15
17-Mar-16
Why Set Limits
Hold or hang up in a telephone queue for
help desks?
Continue to wait for a bus or get a taxi?
Repair an old car or invest in a new one?
Hold or sell a falling stock investment?
Work Breakdown Structure (WBS)
of the project work (Project Management
Detecting project overrun early enough
to abort or modify impossible or
unjustified projects will minimize the risk
of unproductive investments.
By organizational function (marketing, R&D,
manufacturing)
By product physical decomposition (engine,
wings, tail)
By product functional decomposition (fuel
system, atmosphere control system, flight
control system)
scope of the project. Each descending level
represents an increasingly detailed definition
Defining project scope with sufficient
detail and limits is an essential
foundation for risk management and
project planning.
WBS Decomposition Approaches
A deliverable oriented grouping of project
elements that organizes and defines the total
Institute)
16
17-Mar-16
By skill set
assembly)
By
geography
Johannesburg)
WBS Completion Test
By discipline (hardware, software, quality,
support)
(programming,
(Karachi,
accounting,
Birmingham,
By life-cycle phase (investigation, design,
development, test)
Status/completion are measurable
Clearly defined start/end events
Activity has a deliverable
Time/cost easily estimated
Duration within acceptable limits
Work assignments are independent
Key Ideas to Identify Scope Risks
Risk Identification in WBS
If any part of the project resists work
breakdown using common decomposition
approaches or/and completion tests, that
portion of the project is not well understood,
and it is inherently risky.
Clearly define all project deliverables, and note
challenges.
Set limits on the project based on the value of
the deliverables.
Decompose all project work into small pieces,
and identify work not well understood.
Assign ownership for all project work and probe
for reasons behind any reluctance.
Note risk arising from expected project duration
or complexity.
17
17-Mar-16
Chapter 4 (Tom Kendrick)
IDENTIFYING PROJECT
SCHEDULE RISK
Schedule Risk Ideas
Parkinsons Law
Work expands so as to fill the
time available for its completion.
(C. NORTHCOTE PARKINSON)
1.
Sources of Schedule Risk
2.
Activity Definition
3.
Estimating Activity Duration
4.
Activity Sequencing
18
17-Mar-16
Delay Risks
1-Sources of Schedule Risk
Delay risks
Dependency risks
Estimating risks
Late delivery
Slow documentation
Defective supply
Slow decisions
Poor access
Lack of interest
Extended debates
Delay Risks (contd.)
Dependancy Risks
Lack of information
Dependency on other projects
Geographic time lag
Delay
Miscommunication
Non-conformity
Rework etc.
Interfacing
19
17-Mar-16
Dependancy Risks (contd.)
Estimation Risks
Dependency on support
Misleading historical data
Difference in approach
Level of skill
Delay
Non-conformity
Documentation
Improportional scale
Judgment error
Over-optimism
Quick planning
Learning curve issues
2-Activity Definition
Insufficient decomposition
Confusing terminology
3-Estimating Activity Duration
Estimation Pitfalls
Avoidance
Optimism
Lack of information
Granularity
20
17-Mar-16
Project-specific Factors
Overall Estimation Process
Clarity of the project specifications
Likelihood of significant specification change
New resource requirements
Longer expected project duration
New required technology
Unusual technical complexity
Resource Factors
Project-specific Factors (Contd.)
Extreme requirements for reliability
Geographic separation and cultural diversity
on the project team
Infrastructure and environment differences
Training requirements
The amount of time each day each team
member has for project work
The number of people contributing to each
activity
The skills, experience, and productivity of
each team member
Training and mentoring requirements
Non-project responsibilities for each person
21
17-Mar-16
Resource Factors (Contd)
Nonproject Factors
Issues of distributed teams
Holidays
Expected turnover during the project
Weekends
The number and duration for meetings
Vacations and other paid time off
The amount of project communication and
reporting
Other projects
Lengthy non-project meetings
Travel requirements
Equipment downtime
The number of required people not yet
assigned
Interruptions and shut-downs
Medical leave
Methods for Estimating
Activity Durations
Similarity to Other Activities
Historical Data
Rules and Formulas
Expert Advice
Delphi Technique
Three Point Technique
Wide-band Delphi Technique
22
