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
 Project Risk
 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
it’s 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 (‘‘macro-
risk’’), or it may be considered on an event-
by-event basis (‘‘micro-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 (‘‘macro-
risk’’), or it may be considered on an event-
by-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)
 Duration
Type Risk Complexity Technology
(months)

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

 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 Why is it needed
 List of Inputs

Project management process

Project background information
Project charter
 List of Inputs (Contd.)
Internalstakeholders
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
 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.
 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
 Outcomes of
Effective Project Selection Process
 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
 Group Discussion
Working in a group of 3 to 4, do the following:

 Identify and introduce of an innovative

project idea
 Prepare a list of risks involved in acceptance
of the idea
 Brief plan to minimize idea acceptance risks
(30 min preparation + 5 min presentation)
Overall Project Planning Processes

 May be considered as unnecessary

overhead and luxury
 Is project routine or high-tech
 History of success & failure
 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
 ‘‘known’’ risks occur frequently enough
to be analyzed in advance.
 ‘‘unknown’’ risks result from the
uniqueness of the work and are difficult
or impossible to anticipate.
Overcoming Project Risk: Lessons from the
PERIL Database

Tom Kendrick

Program Manager, Hewlett-Packard

Company
 The PERIL Database

 Project Experience Risk Information

Library
 Input from a large number of projects
and project managers
 Contains samples
 The PERIL Database (Contd.)

 Project Experience Risk Information

Library
 Input from a large number of projects
and project managers
 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
Chapter 3 (Tom Kendrick)
 IDENTIFYING
PROJECT SCOPE RISK
‘‘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
 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
 II. Defining Deliverables

Start by identifying the people

who should participate
 Scope Risk Management
Techniques
 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?)
 3. Compliance (Has the team identified all relevant
regulatory, environmental, and manufacturing
requirements, as well as any relevant industry
standards?)
 Deliverable Definition Process
 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?)
 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.)
 Evolutionary Methodologies
 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.
 Evolutionary Methodologies
(contd)

 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
 Project description
 Project Justification
 Completion criteria
 Customer(s) and/or users
 What the project will and will not include
 Internal and external dependencies
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
III. High- Level Risk Assessment Tools

 Risk framework
 Risk complexity index
 Risk assessment grid
 Risk Framework
 Consider the following project factors &
their sub factors
 Technology (the work)

 Marketing (the user)

 Manufacturing (the production and delivery)

 For each of these factors, assess the

amount of change required (insignificant or
significant only)

 Correlate changes with risk

 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.
Index = (Technology+Architecture+System) x Scale

(Uniqueness, Infrastructure & Resources, System) x scale

 Part Index Estimation
 0—Only existing technology required
 1—Minor extensions to existing technology needed
in a few areas
 2—Significant extensions to existing technology
needed in a few areas
 3—Almost certainly possible, but innovation needed
in some areas
 4—Probably feasible, but innovation required in
many Areas
 5—Completely new, technological feasibility in doubt
 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
 Project Risk Assessment
 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.
Risk Assessment Grid
 Setting Limits

Decisions to continue or to quit in

situations that involve spending more time,
more money, or both.
 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?
 Why Set Limits
 Defining project scope with sufficient
detail and limits is an essential
foundation for risk management and
project planning.
 Detecting project overrun early enough
to abort or modify impossible or
unjustified projects will minimize the risk
of unproductive investments.
Work Breakdown Structure (WBS)

A deliverable oriented grouping of project

elements that organizes and defines the total
scope of the project. Each descending level
represents an increasingly detailed definition
of the project work (Project Management
Institute)
 WBS Decomposition Approaches

 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)
 By discipline (hardware, software, quality,
support)
 By skill set (programming, accounting,
assembly)
 By geography (Karachi, Birmingham,
Johannesburg)
 By life-cycle phase (investigation, design,
development, test)
 WBS Completion 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
 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.
 Key Ideas to Identify Scope Risks
 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.
Chapter 4 (Tom Kendrick)
IDENTIFYING PROJECT
SCHEDULE RISK
 Parkinson’s Law

‘‘Work expands so as to fill the

time available for its completion.’’
(C. NORTHCOTE PARKINSON)
 Schedule Risk Ideas

1. Sources of Schedule Risk

2. Activity Definition

3. Estimating Activity Duration

4. Activity Sequencing
 1-Sources of Schedule Risk

 Delay risks
 Dependency risks
 Estimating risks
 Delay Risks
 Late delivery

 Slow documentation

 Defective supply

 Slow decisions
– Poor access
– Lack of interest
– Extended debates
 Delay Risks (contd.)

 Lack of information

 Geographic time lag

 Miscommunication

 Rework etc.
 Dependancy Risks

Dependency on other projects

 Delay

 Non-conformity

 Interfacing
 Dependancy Risks (contd.)

Dependency on support

 Delay

 Non-conformity

 Documentation
 Estimation Risks
 Misleading historical data
– Difference in approach
– Level of skill

– 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
Overall Estimation Process
 Project-specific Factors
 Clarity of the project specifications

 Likelihood of significant specification change

 New resource requirements

 Longer expected project duration

 New required technology

 Unusual technical complexity

 Project-specific Factors (Contd.)
 Extreme requirements for reliability
 Geographic separation and cultural diversity
on the project team
 Infrastructure and environment differences
 Training requirements
 Resource Factors
 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
 Resource Factors (Contd)
 Issues of distributed teams
 Expected turnover during the project
 The number and duration for meetings
 The amount of project communication and
reporting
 Travel requirements
 The number of required people not yet
assigned
 Nonproject Factors
 Holidays
 Weekends
 Vacations and other paid time off
 Other projects
 Lengthy non-project meetings
 Equipment downtime
 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
 Project- level Estimates
 Thinking—all the initial work on a project,
such as planning, analysis, investigation, initial
design, proposal generation, specification, and
preparation for the business decision to
commit to the project.
 Doing—the work that generally defines the
project. This is where the team rolls up their
sleeves and digs into the creation of the
project deliverable.
 Checking—testing the results created by the
project, searching for defects in the
deliverable(s), correcting problems and
omissions, and achieving project closure.
Applying Estimating Techniques
Estimates Adjusted for Uncertainty

O+4M+P
E=
6

O Optimistic time
P Pessimistic time
M Most likely time
Beta Distribution
Sources of Sequencing Risks

 Three point technique

 Finish-to-Start relationship
 Open links
 Critical path
 Multiple critical paths
 Interfaces
 Key Ideas for Identifying
Schedule Risks
 Determine the root causes of all uncertain
estimates.
 Identify all estimates not based on historical
data.
 Note dependencies that pose delay risks,
including all interfaces.
 Find any differences between project effort
requirements and life-cycle norms.
 Key Ideas for Identifying
Schedule Risks (Contd.)
 Identify risky activities and schedule them
early in the project.
 Ascertain risks associated with multiple critical
(or near-critical) paths.
 Note risks associated with lengthy projects.