Project Risk Management Slides

(1)

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

(2)

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)

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

(3)

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

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

(4)

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

Risk and

and project

project planning

planning helps

helps

distinguish

distinguish and

and deal

deal with

with all

all three

three

of

(5)

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

(6)

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

(7)

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

(8)

Chapter

(9)

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

(10)

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

(11)

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?)

(12)

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

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

(13)

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

(14)

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

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

(15)

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.

(16)

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?

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.

Why Set Limits

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

Work Breakdown Structure (WBS)

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

(17)

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

(18)

Chapter

Chapter 4

4 (Tom Kendrick)

(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

(19)

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

(20)

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 2--Activity Definition

Activity Definition

Insufficient decomposition Confusing terminology

3 3--Estimating Activity Duration

Estimating Activity Duration

Estimation Pitfalls Avoidance Optimism

(21)

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

(22)

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