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