Project Ethics and Risk Management - Project Management

MGMT 8050 Project Ethics and Risk Management - 12 hours (1.2 CEU5)

COURSE After completing this course, students will know: OBJECTIVES

. What a risk is

. What the risk management processes are

. How to identify and analyze risks

. How to apply ethical decisions to your projects

PREREQUISITE None

TEXTS A Guide to the Project Management Body of Knowledge (PMBOK Guide), 6th Edition, Project Management Institute, 2017

Tom Kendrick, Identifying and Managing Project Risk, Third Edition, AMACOM, 2015

John C. Maxwell, Ethics 101: What Every Leader Needs to Know, Center Street, 2005

INSTRUCTOR

Module 2

Module Objectives

The objectives of this module are:

• Understand how to manage project risk by assessing and responding to project risks.

• Determine budget and schedule contingencies for our projects that result in a high probability of success

Reading Assignments

Kendrick, Chapters 7-14, Appendix

Perform Qualitative Risk Assessment

After the project risks are identified, we can assess their potential impact on the project’s

objectives in a qualitative risk assessment and/or a quantitative risk assessment.

In a qualitative risk assessment, we prioritize the risks based on the probability and impact

on the project objectives. Definitions associated with qualitative risk assessment are:

. Risk probability — the likelihood that a risk will occur.

. Probability scale — a qualitative value that reflects the likelihood that a risk will occur

. Risk impact — the effect on the project objectives (project cost, schedule, or performance) if the risk occurs.

. Impact scale — a qualitative value that reflects the severity of the effect on the project objectives (project cost, schedule, or performance) if the risk occurs. An example of an impact scale is shown in Table 1 1-1 of the PMBOK® Guide.

. Risk score — the probability scale times the impact scale.

A Probability and Impact Matrix can be created by showing the risk probability vs. the impact

scale, as shown in Figure 1 1 -5 of the PMBOK® Guide. The values shown inside of the table

cells are the probability times the impact scale, or the risk scores.

Another method of qualitatively assessing risks is to use an impact and probability scale.

Examples of the impact scale could be:

• High (5) — would cause project failure due to unacceptable performance, missed key milestones, or significant user dissatisfaction.

• Moderate (3) — would cause significant impact to project cost, schedule, or performance

• Low (1) — could affect project cost, schedule, or performance

2

Examples of the probability scale or likelihood could be:

• High (5) - risk will probably occur

• Moderate (3) - risk may occur

• Low (1) - risk will probably not occur

We can then create a Risk Assessment Table, like that shown on p.173 of Kendrick. We can

also multiply the impact scale times the probability scale to calculate a risk score, and then

use the risk score to prioritize our project risks. For example, if we take the project risks

listed on p.173 of Kendrick, we would have the following table:

Project Risk Probability Impact Risk Priority Scale Scale Score

Software guru is not available 3 5 15 1

Consultant is incompetent 3 3 9 2

Purchased component comes 1 5 5 3 late

Software development is too 1 3 3 4 slow

Needed test gear is not available I I 1 5

Prioritizing Project Risks

We can use this methodology to determine the highest priority project risks, and then

address the highest priority risks in our risk response planning.

3

The outputs from performing qualitative risk analysis can include:

I . Relative ranking or priority list of project risks

2. Risks grouped by categories

3. Causes of risk or project areas requiring particular attention

4. List of risks requiring response in the near-term

5. Lists of risks for additional analysis and response

6 . Watch I ists of low-priority risks

7. Trends in qualitative risk analysis results

Perform Quantitative Risk Assessment

We may want to quantify the risks that were identified as the highest priority risks in the

qualitative risk assessment in terms of potential schedule impacts in terms of days, or

potential cost impacts in terms of dollars.

Some commonly techniques used in quantitative risk analysis are listed in the PMBOK®

Guide:

1 . Sensitivity analysis

2. Expected monetary value analysis, including decision tree analysis

3. Modeling and simulation

An example of the modeling and simulation technique is the use of the Monte Carlo analysis

technique, where many computations are made using a distribution of estimates. One of the

methodologies used to generate these estimates is the Program Evaluation and Review

Technique (PERT), discussed in Kendrick p. 96-99 and p. 182-1 85. To use the PERT

technique, three estimates are made for the schedule duration or the cost of a project task

or project phase, as follows:

4

. Optimistic duration or cost — best case

. Most likely duration or cost

. Pessimistic duration or cost — worst case

After a Monte Carlo analysis is performed on the range of cost estimates, the project cost

vs. cumulative probability can be plotted. An example is shown in Figure 1 1-1 7 of the

PMBOK® Guide. It can be seen that a target budget of $2.2M has only a cumulative

probability of 23%. If a higher cumulative probability is desired, the budgeted value has to be

higher.

One suggestion by Goldratt (Goldratt, Critical Chain, 1997) is to take half of the difference

between the total of the pessimistic values and the total of the most likely values as a

budget contingency. This budget contingency is then added to the total of the most likely

values to produce the budgeted value.

For example, the following range of cost estimates are listed for three project phases:

WBS Element Optimistic Most Pessimistic Likely

Design 4 6 10

Build 16 20 35

Test 11 15 23

Total Project 31 41 68

Range of Project Cost Estimates ($K)

Taking half of the difference between the total of the pessimistic estimates and the total of

the most likely estimates for the example in the PMBOK® Guide gives us a budget

contingency of $13.5K:

5

Budget contingency = 0.50 x (Pessimistic total — Most likely total)

= 0.50x($68K—$41K) = $13.5K

Adding this budget contingency to the most likely total of $41 K gives us a budget of $54.5K:

Project budget = Most likely total + Budget contingency

= $41K + $13.5K = $54.5K

Typically, this method results in a project budget that has a cumulative probability between

80% and 90%.

A similar analysis can be performed with schedule estimates. For example, if we have the

following range of duration estimates for the three project phases:

WBS Element Optimistic Most Pessimistic Likely

Design 10 15 20

Build 20 25 50

Test 15 20 30

Total Project 45 60 100

Range of Project Duration Estimates (days)

As we did in the case of the cost estimates, we take half of the difference between the total

of the pessimistic values and the total of the most likely values as a contingency. This

schedule contingency, sometimes called a project buffer, is then added to the total of the

most likely values to produce the project schedule duration.

6

Taking half of the difference between the total of the pessimistic estimates and the total of

the most likely estimates for the above example gives us a schedule contingency of 20

days:

Schedule contingency = 0.50 x (Pessimistic total — Most likely total)

= O.50x(100 days—60 days) = 20 days

Adding this schedule contingency to the most likely total of 60 days results in a project

schedule duration of 80 days:

Project schedule duration = Most likely total + Schedule contingency

= 60 days + 20 days = 80 days

Again, this method usually produces a project schedule duration that has a cumulative

probability between 80% and 90%.

7

Plan Risk Responses

There are several strategies for responding to project risks, as described in the PMBOK®

Guide. These strategies are summarized in the following table:

Risk Response Strategy Definition Example Action

Avoid Eliminate the risk, usually Avoid an unproven software by eliminating the cause application

Transfer Shift the consequences of Take out insurance the risk to a third party

Mitigate Reduce the probability or Design redundancy into a impact of the risk system

Exploit Achieve a positive result Assign more talented resources to ensure success

Share Allocate proportions of the Partner with vendors risk to different parties

Enhance Increase the size of the Target a larger market opportunity

Accept Accept the consequences Establish a budget or of a risk schedule contingency

Escalate Threat is outside of the Escalate risk to higher project scope management

The risk response strategies of Avoid, Transfer, and Mitigate are applicable to negative risks

or threats; while Exploit, Share, and Enhance are applicable to positive risks or

opportunities; and Accept and Escalate are applicable to either.

8

Some ways to avoid risks are discussed on p. 200-202 of Kendrick. Mitigation of risks is

discussed on p. 202-21 3, transferring risk is discussed on p. 213-214, contingency planning

is discussed in p. 219-222, and risk acceptance is discussed on p. 222-223.

Since it is usually cost-prohibitive to address all of the project risks we have identified, we

should rank the risks we have identified with the qualitative risk assessment and select a

strategy and action for these high priority risks, as shown in the following table:

Priority Project Risk Risk Response Risk Response Strategy Action

I Software guru is not available

2 Consultant is incompetent

3 Purchased component comes late

4 Software development is too slow

5 Needed test gear is not available

6

7

Selecting Strategies and Actions for Project Risks

If we decide to accept a project risk, we should set aside a budget contingency to cover the

expected effect of the project risk on the project budget. Definitions we will use in this

calculation are:

• Risk probability — the quantified likelihood that a risk will occur.

• Risk impact — the quantified effect on the project objectives (project cost, schedule, or performance) if the risk occurs.

• Expected value = sum (probability x impact)

9

• Budget contingency = amount of money that should be set aside to cover the effect of the project risks on the project budget

One project risk may be the failure to pass system testing. The probability of failure may be

0.3 (30%), and the impact of failure may be $50K. Therefore the expected value = 0.3 X

$50K = $15K. Adding all of the expected values for all of the risks will result in a required

budget contingency for risk acceptance.

Assuming we decide to accept all of the risks listed, we could quantify the project risks in the

previous example as follows:

Project Risk Risk Risk Expected Probability Impact Value

Software guru is not available 0.4 $30K $12.0K

Consultant is incompetent 0.3 $6K $1.8K

Purchased component comes 0.1 $25K $2.5K late

Software development is too 0.1 $5K $0.5K slow

Needed test gear is not available 0.15 $2K $0.3K

Total $17.IK

Establishing a Budget Contingency for Risk Acceptance

We would then set aside an additional $17.IK to cover the expected effect of accepting the

project risks on the project budget.

10

Module 2 Summary

In Module 2, we learned how to:

. Manage project risk by assessing and responding to project risks.

. Calculate budget and schedule contingencies for our projects that result in a high probability of success

Risk Assignment I — Identify and Analyze Risks

The first risk assignment is to identify and analyze risks in a project that you have worked on

or are familiar with. Brainstorm at least three risks for each of the six risk categories for a

total of at least 1 8 risks.

Qualitatively assess these risks by using an impact scale and probability scale. Examples of

the impact scale could be:

. High (5) — would cause project failure due to unacceptable performance, missed key milestones, or significant user dissatisfaction.

• Moderate (3) — would cause significant impact to project cost, schedule, or performance

• Low (1) — could affect project cost, schedule, or performance

Examples of the probability scale or likelihood could be:

• High (5) - risk will probably occur

• Moderate (3) - risk may occur

• Low (1) - risk will probably not occur

Multiply the impact scale times the probability scale to calculate a risk score, and then use

the risk score to prioritize your project risks, as shown in the following table:

11

IMPACT PROB RISK RISK CATEGORIES RISKS SCALE SCALE SCORE PRIORITY

Poor lighting 4 2 8 4

Technical AV system not compatible with electronics 5 1 5 10

PMScolorerror 3 1 3

Lowqualityelectronics 2 2 4 Quality Alcohol expired 4 1 4

Error in logo on glasses 4 1 4

Poorcontractorperformance 4 2 8 4

Performance Backorderofsupplies 3 2 6 8

Outdated P05 system 2 1 2

. Miscalculated task timeline 3 3 9 2

Project Unforeseen costs 3 3 9 2Management Fail inspection 4 2 8 4

Not paying staff enough money 3 2 6 8

Organizational Team ownership failure to approve 4 2 8 4

League does not approve licensing 4 1 4

Failure to obtain liquor license 5 1 5 10

External Arena not built in time 5 2 10 1

Failure to obtain food safety certification 4 1 4

Prioritize and Analyze Project Risks

Submit this assignment by the date shown in the Syllabus.

Discussion Postings

Post your discussion posting by the date shown in the Syllabus. Discussion postings must

be a minimum of 1 00 words. In order to obtain full credit, review and comment on a

minimum of two other students’ discussion postings within two days after the scheduled

posting date. Please respond to comments on your discussion postings.

The discussion posting for Module 2 is:

1. What is your experience in assessing and responding to your project risks? How successful have you been?

2. What methods have you used to establish budget and/or schedule contingencies? How successful have these methods been?

12