I NDI AN A DE PAR T MEN T OF TRA N SPO R TA TION

P RO JE CT MANA GE MEN T T R AI NING PR OGRA M

Advanced
Project
Management
TRAINING MANUAL
INDIA N A DE P A R T ME NT O F T R A NS P O R T A T IO N
P R O J E C T MA N A G E ME NT T R A INING P R O G R A M

Advanced Project Management

TRAINING MANUAL

Acknowledgements:
Walter Land, Project Management, INDOT

Course Development and Seminar Leaders:

Contents
Contents ……………………………………….I Module 4
Acknowledgements…………………………..II W OR K T HE P L AN
Proj ec t Management Process………..……III
A. Schedule Terminology
.i i i
I N T R ODUC T ION and Definitions…………………4-2
A. INDOT’s Vision …..…..….……………….1 B. Schedule Tracking……………..4-10
B. INDDOT’s Mission…….………………….1 C. Schedule Recovery/
C. INDOT ’s Values….……..………………..1 Schedule Compression………..4-16
D. Course Goal and Outcomes…………….3
E. Ground Rules for Seminar………………4
F. Administrivia………………………………5 Module 5
R E S OUR C E P L ANNING
G. Course Agenda…………………………...6
H. Resources………………………………...7 A. Resource Estimating….……….….5-3
B. 4
Resource Histogram…….……… 5-4
Module 1 C. INDOT ’s Values….……..…………..1
INDOT P rojec t Management Overview D. Course Goal and Outcomes………3
E. Ground Rules for Seminar…………4
Project Management Process Chart……...1-2
A. I n i t i a t e & A l i g n the Team…..…1-3
B. Plan the Work…………………………...1-5
C. Endorse the Plan……………………….1-7 Module 6
D. Work the Plan…………………………..1-8 INDOT P rojec t Management Overview
E. Transition and Close………………….1-10
F. Project Management Plan……………1-11 AP P E NDIX A - p . 1 2 5
I - 7 4 a n d US 4 2 1 P rojec t
Management P lan
Module 2
G eneral P rojec t Management T heory
A. Project Management Body of AP P E NDIX B - p . 1 3 4
Knowledge……………………………..2-2 I N DOT P rojec t Development P lan
B. Organizational Planning……………...2-4 (P DP )
C. Organizational Breakdown
Structure…………………………….…2-6 AP P E NDIX C -2-p 1. 1 3 9
D. Responsibility Assignment Matrix C hange Management P lan
(RAM)…………………………………..2-7 C ommunic ation P lan, QA/
QC P lan T rans ition and
E. Organizational Influences C los ure P lan
and Structure…………………………..2-8 2- 1
F. Power………………………………....2-16
G. Conflict Management………………..2-21 AP P E NDIX D - p. 1 5 2
C ons truc tability
R eview F orms
Module 3
R is k P lanning and R is k Management
AP P E NDIX E - p. 1 8 1
A. Why Evaluate Risk?…………………..3-2 C ons ultant R ating F orm
B. Benefits of Risk Assessment.………...3-3
C. Risk Definitions.…………………...…3-4 2- 1(RAM)…………………………………..2-7
D. Risk Tolerance…………………………3-4 AP P E NDIX F - p . 1 8 3
E. INDOT Risk Policy…….……………….3-6 I - 7 4 a n d US 4 2 1 E ngineer's
S ummary
F. Risk Planning Process…….……….....3-7
G. Risk Response Definition….………...3-23
H. Risk Monitoring & Control…………...3-33
Introduction

T
his course identifies the principles and methodologies adopted by the
Indiana Department of Transportation (INDOT) to support successful project
management and delivery. Project management requires the application of
knowledge, skills, tools, and techniques to deliver the project on time, within
budget, and according to specifications. INDOT’s project management process is
based on proven industry standards for project management, such as the Project
Management Body of Knowledge (PMBOK) prepared by the Project
Management Institute (PMI) and INDOT’s accumulated experience with the
management and delivery of transportation construction projects.

A. INDOT’s Vision
Driving Indiana’s Economic Growth

B. INDOT’s Mission
Build, maintain, and operate a superior transportation system enhancing
safety, mobility, and economic growth.

C. INDOT’s Values
Customer Focus
We will understand and meet the needs of our customers in our policy, program
development, and decision-making process.

Integrity
We will maintain the highest ethical standards in our dealings with each other, our
customers, our business partners, and the environment.

People
We commit to developing and supporting a flexible, technically skilled work force
with individual teams that work toward our shared mission and goals.

Agility
We will have the knowledge and ability to rapidly adapt to the opportunities and
challenges offered by changing technology and business processes.

Continuous Improvement
We will continually improve our business processes through better products,
practices, procedures, and information-based decision making.

Safety
We will create, maintain, and promote a safe work environment for our employees
and continually strive to reduce incidents and the severity of traffic-related
accidents and injuries.
Page 1
INDOT’s Vision: Driving Indiana’s
economic growth

INDOT’s Mission: Build, maintain,

and operate a superior trans-
portation system enhancing safety,
mobility, and economic growth.

Source:http://www.ai.org/dot (7/14/06)

INDOT’s Values:
Customer Focus
Integrity
People
Agility
Continuos improvement
Safety

Source:http://www.ai.org/dot (7/14/06)

Page 2
D. Course Goal and Outcomes
1. Course Goal
The goal of this course is to provide participants with advanced management
tools and techniques in a form that allows application to their projects.
2. Learning Outcomes
Upon completion of this course you will be able to:
• Identify project team roles and methods of project conflict resolution
• Plan and estimate percent complete for schedule and budget
management
• Identify methods for schedule compression or recovery of time
• Develop risk management plans
• Identify methods for budget and scheduling estimates
• Develop a resource histogram and balance resources
• Perform earned value analysis on an actively tracked project plan

Page 3
E. Ground Rules for Seminar

• Participate
• Be on time
• Stay on task
• Share responsibility for training
• Listen when others talk
• Respect the opinions and attitudes of others
• Turn off cell phones, pagers, PDAs, and Blackberries

Page 4
 Ground Rules For Seminar
• Participate
• Be on time
• Stay on task
• Share responsibility for training
• Listen when others talk
• Respect the opinions and attitudes of
others
• Turn off cell phones, pagers, PDAs, and
Blackberries
F. Administriva

• Facilities – Restrooms, water, vending machines, phone, lunch

• Breaks and Lunch (Lecture will resume promptly at the conclusion of
each break and lunch)
• Course Evaluation (Please use a blue or black pen or soft pencil)
• Please sign the roster

Page 5
Administrivia

• Facilities
• Breaks and lunch
• Course evaluation
• Please sign the roster

Page 6
G. Course Agenda

TIME MODULE TITLE LENGTH (min.)

Day 1

8:00 - 8:15 Course Introduction 15

8:15 - 9:00 Module 1 45

9:00 -9:30 Module 2 30

9:30 -9:45 Break 15

9:45 -11:00 Module 2 (continued) 75

11:00 -11:15 Break 15

11:30 -12:00 Module 3 30

12:00 -1:00 Lunch 60

1:00 - 2:30 Module 3 (continued) 90

2:30 - 2:45 Break 15

2:45 - 3:45 Module 3 (continued) 60

3:45 - 4:00 Break 15

4:00 - 4:30 Module 3 (continued) 30

Day 2

8:00 - 10:00 Module 4 90

10:00 - 10:15 Break 15

10:15 -11:15 Module 4 (continued) 60

11:15 - 11:30 Break 15

11:30 -12:30 Module 5 60

12:30 -1:30 Lunch 60

1:30 - 2:30 Module 5 (continued) 60

2:30 - 2:45 Break 15

2:45 - 3:45 Module 6 60

3:45 - 4:00 Break 15

4:00 - 4:30 Module 6 (continued) 30

Page 7
INDO
H. Resources
• Project Management Process Training Manual
• Schedule Training Manual
• A Guide to the Project Management Body of Knowledge, 3rd Edition
(PMBOK Guide). Project Management Institute, Inc. 2004.
• Harold Kerzner, Ph.D. Project Management, A Systems Approach to
Planning, Scheduling, and Controlling, 8th Edition. John Wiley & Sons, Inc.
2000
• International Institute for Learning (IIL). “Advance Project Risk
Management” training manual, version 4.0. International Institute of
Learning, Inc. 2004

Resources
• Project Management Process Training Manual
• Schedule Training Manual
• A Guide to the Project Management Body of
Knowledge, 3rd Edition (PMBOK Guide). Project
Management Institute, Inc. 2004.
• Harold Kerzner, Ph.D. Project Management, A
Systems Approach to Planning, Scheduling, and
Controlling, 8th Edition. John Wiley & Sons, Inc. 2000
• International Institute for Learning (IIL). “Advance
Project Risk Management” training manual, version
4.0. International Institute of Learning, Inc. 2004

Page 8
 1
Module

INDOT Project Management Overview

Lear ning Outcomes
• Explain what a project management plan is.
• Describe what a Project Performance Baseline is.

Learning Outcomes
• Explain what a project management plan is.
• Describe what a Project Performance baseline is.

Page1-1
Page1-2
 1
Module

INDOT Project Management Overview

Project Management Process
INDOT’s project management process is a 5-step process very similar to other
project management approaches being used around the world by Project
Managers in both the private and public sectors.

A. Initiate & Align the Project Team

This is the first step in the project management process. Initiation is the formal
recognition that a project exists. Organizational senior management will initiate
the project and assign the project to a Project Manager. The Project Manager
will identify the project team and align the team with a common goal and
purpose. The elements of the Initiate & Align process are:

• Project Description: A description of the project’s product, purpose, or

intended outcome.

• Team Mission/Assignment: A high-level description of the approach the

project team will use to achieve the Project Description.

• Major Milestone: A listing of expected milestones for the project.

• Boundaries: Identification of physical boundaries, operational limitations,

and other objective constraints for the project.

• Team Identification: The Project Manager will identify the functional teams
required to deliver the project.

Page1-3
• Roles & Responsibilities: “Who will do what?” The project team roles (the
“who”) and the project responsibilities (the "what”) will be identified by the
project team.

• Measures of Success: Identifying critical success factors and methods to

measure performance relative to these factors.

• Operating Guidelines: The project team will identify how decisions will be
made and plan methods for managing project conflicts.

INDOT Project Management Overview

Initiate& Align

• Project Description
• Team Mission / Assignment
• Major Milestones
• Boundaries
• Team Identification
• Roles and Responsibilities
• Measures of Success
• Operating Guidelines

Page1-4
B. Plan the Work
This is the second step in the project management process. This step produces
the Project Management Plan that will be used by the project team to deliver the
project. The elements of the Plan the Work phase are:

• Work Breakdown Structure (WBS): Using, for example, the Project

Delivery Process Master Schedule, the project team will decompose the
list and develop a project specific WBS.

• Task Planning & Scheduling: The project team will use the WBS to
develop tasks to deliver the project deliverables. These activities are
entered into the project’s scheduling program. This will define the project
schedule.

• Budget: The project team may resource-load the project schedule to

develop a “bottom-up” or engineering estimate for the project. This will
define the project’s cost requirements (the project budget). This is
compared against programmed budgets. The project team will look at
ways to optimize the scope, schedule, and budget to match the earlier
identified project boundaries.

• Risk Planning: The project team will develop a Risk Management Plan
and Risk Register to identify, analyze, plan response action strategy, and
monitor risk events.

INDOT Project Management Overview

Plan the Work Project Performance

Baseline

Work Breakdown
Risk Planning
Structure (WBS)

Budget
Task Planning &
Development
Scheduling
(Resources)

“Progressive Elaboration”

Page1-5
 • Communication Plan: The project team will develop a Communication
Plan to identify and describe the methods, media, frequency, required
details, and information needed. Both external and internal
communications are planned.

• Change Management Plan: The project team will develop a Change

Management Plan that will provide a framework and process for the team
to use when change occurs.

• Quality Plan: The project team will identify the quality methods to be
planned and implemented to prevent errors from reaching the customer
(Quality Control-QC) and to ensure that the team is “doing the right things”
(Quality Assurance-QA).

• Transition & Closure Plan: “Beginning with the end in mind.” The project
team will develop the Transition & Closure Plan for the transition of the
project to the next phase or the closure of the project.

INDOT Project Management Overview

Plan the Work

• Communication Plan
• Change Management Plan
• Quality Plan
• Transition & Closure Plan

The first four elements (WBS, schedule, budget, risk) define the Project Performance
Baseline. The last four elements (Communication Plan, Change Management Plan,
Quality Plan, and Transition & Closure Plan) are developed to help facilitate project
management.

Page1-6
C. Endorse the Plan
Endorsement is the third step in the project management process. Endorsement
also completes the “Plan the Work” phase of project management. Once the
Project Management Plan is endorsed, the project team will move to the “Work
the Plan” phase of project management. The elements of endorsement are:

• Project Team Commitment: Getting an agreement or pledge from the

project team that they will perform and deliver the project deliverables as
documented in the Project Management Plan.

• Management Endorsement: Getting approval and a commitment from

senior management that the resources required and documented in the
Project Management Plan will be available.

Once the Project Management Plan is endorsed, it becomes the baseline for the
project, a metric for project performance, and the guide for project management.

Endorsement is not a “one-time” event, but is done throughout the life of the
project. As changes occur, the project team will need to review and re-commit
and re-endorse the updated plan.

INDOT Project Management Overview

Endorse the Plan

• Project Team Commitment

• Management Endorsement

Page1-7
D. Work the Plan
"Work the Plan" is the fourth step of the project management process.
Although the steps have been listed in a linear order, working the plan
requires the Project Manager to continually update the plan, requiring some
additional planning and possible re-endorsement in the case of change. This
updating process is referred to as "progressive elaboration." It is an iterative
process. As the project team knows more about the project, further
refinement of the plan is required. The elements of "Work the Plan" are as
follows:

• Managing scope, schedule, and the budget: These are the components
of the Project Performance Baseline. The Project Manager will
continually update the Project Performance Baseline by tracking what
work was actually completed, when that work was actually completed, and
how much was actually expended to complete the work planned.
Comparing these actuals against the Project Performance Baseline will
give the project team a sense of how the project is performing with respect
to schedule and budget.

• Managing Risks: The project team created a risk management plan

and a risk register during the "Plan the Work" step. During the "Work the
Plan" step, the Project Manager and the project team will monitor the
identified risk, continue to update the plan with new identified risks,
evaluate the impact and probability of the new identified risks, and monitor
the effectiveness of the risk response strategy.

• Managing Change: Change is inevitable on a project. A Project Manager

will manage change by implementing the Change Management Plan for
the project.

Page1-8
 • Communication: The most important skill set for a Project Manager is the
ability to communicate clearly and appropriately. The Communication Plan
developed during the "Plan the Work" step is implemented and updated as
needed. The items required for reporting are progress reporting (schedule
and budget performance); issues (risks and changes); and lessons
learned. These items should be a standing agenda item for all team
meetings.

Throughout the project life, the Project Manager will need to manage a dynamic
project team. These teams must be built and sustained to attain high
performance, produce effective results, and successfully deliver the project.

INDOT Project Management Overview

Work the Plan

• Managing Scope, Schedule, and Budget

• Managing Risks
• Managing Change
• Communication

Page1-9
E. Transition and Closure
The final step in the project management process is "Transition & Closure."
This is the step of transitioning the project to the next phase or completing
the project as described in the project description and delivering the product
to the customer. The elements for this project management step are as
follows:

• Implement the Transition Plan: During the "Plan the Work" step, the
project team developed a plan for transitioning and closing the project.
Implementation of this plan gives a foundation to accomplish this.
• Review Lessons Learned: Lessons learned were identified early on
and maintained throughout the project life. The team will review lessons
learned from the project and share it with the team and agency.
• Reward & Recognize: Look to recognize and reward the outstanding
achievements of the project team. Since teams are dynamic, this is an
element that is managed throughout the project's life.
• Archive: Archiving the project information as directed by agency
policies and in accordance with the Transition and Closure Plan. Being
able to plan early to identify what information will be archived and in
what format or media, will allow the team to archive as it develops and
completes the project.

INDOT Project Management Overview

Transition and Closure

• Implement Transition Plan

• Review Lessons Learned
• Reward & Recognize
• Archive

Page1-10
F. Project Management Plan
During the "Plan the Work" phase of the project, which encompasses the
first three project management process steps, the project team creates and
endorses a Project Management Plan. This plan will typically consist of the
following:

• Completed Initiate and Align Phase

• Project Work Breakdown Structure (WBS)

• Project Schedule

• Project Budget with appropriate forecasted expenditures

• Risk Management Plan with Risk Register

• Communication Plan

• Change Management Plan

• Quality Plan

• Transition and Closure Plan

• Commitment and Endorsement

Page1-11
 1. Project Performance Baseline Management

LE PROJECT
U

BU
D RISK
E

DG
H
C Q

ET
S

SCOPE

Project Managers often talk of a "triple constraint" or "trade-off triangle" — project

requirements (scope), project time (schedule), and project costs (budget).
Replacing these project objectives with the tools to manage those objectives gives
the "trade-off" triangle of scope, schedule, and budget. The relationship between
these parameters is such that if any one of the three parameters is changed, at
least one of the other project parameters is likely to be affected. Project quality is
affected by balancing these project objectives. High quality projects deliver the
required product, service, or result within scope, on time, and within budget.

Project Managers also manage projects in response to uncertainty. Project risk is

an uncertain event or condition that, if the risk event occurs, has a positive or
negative effect on at least one project parameter.

2. Project Requirements (Scope and Quality)

The project WBS is developed to define the project requirements and project
scope. The Project Manager will manage the project scope and the associated
quality defined for the project deliverables. If an additional project deliverable is
required, the Project Manager will implement the appropriate change management
actions to update the project scope. Work completed that is not part of the
endorsed project WBS is called "scope creep." Technically oriented team members
are motivated not only by meeting specifications, but also by exceeding them.
Unfortunately, exceeding specifications can become quite costly. The Project
Manager needs to be able to discern between legitimate scope change and scope
creep.

Page1-12
 3. Project Time (Schedule)
The Project Schedule is developed to define when the work will be completed on a
project. During the "Work the Plan" process step, a Project Manager will track the
actual dates for the work completed, and analyze the effects of these dates on the
remainder of the project network. Schedule performance will be evaluated by
comparing the actual dates to the planned dates (project performance baseline). A
Project Manager will use schedule compression techniques (discussed later) to
recover a project schedule.

4. Project Costs (Budget and Budget Aging)

The Project Budget is developed to define when financial resources will be required.
Based on the project WBS (work to be done) and the project schedule (when work
will need to be completed), the budget is developed and an appropriate forecasting
report, the "Aging Report" is developed. During the "Work the Plan" process step, the
Project Manager will track the actual expenditures for the work completed and
evaluate or analyze the effects of these actual costs on the remainder of the project
aging. Budget performance will be evaluated by comparing the actual expenditures
to the planned expenditures (Project Performance Baseline).

Page1-13
 Module 1 Exercise

1. The five steps of the project management process are:

2. Complete the below "trade-off triangle" with the appropriate project objectives
and tools to manage the objectives:

3. The Endorsed Project Performance Baseline consists of:

Page1-14
4. The Project Management Plan consists of:

5. The most important skill set for a Project Manager is:

a. Scheduling expertise
b. Communication
c. Technical
d. Budgeting

Page1-15
 1
Module

INDOT Project Management Overview

Lear ning Outcomes
• Explain what a project management plan is and how it is developed.
• Describe what a Project Performance Baseline is and how that baseline is
managed.

Learning Outcomes
• Explain what a project management plan is.
• Describe what a Project Performance baseline is.

Page1-16
 Module

2
General Project Management Theory
Learning Outcomes
• Describe an Organizational Breakdown Structure (OBS) and a
Responsibility Assignment Matrix (RAM) and their uses
• Compare and contrast functional organizations and project
organizations
• Describe the difference between “Organizational Power” and “Earned
Power,” and give examples of each
• List methods for resolving conflicts
• List and describe constructive and destructive team roles

Learning Outcomes

• Describe an Organizational Breakdown Structure (OBS)

and a Responsibility Assignment Matrix (RAM) and their
uses
• Compare and contrast functional organizations and
project organizations
• Describe the difference between “Organizational Power”
and “Earned Power,” and give examples of each
• List methods for resolving conflicts
• List and describe constructive and destructive team roles

Page2-1
 Module

2
General Project Management Theory
A. Project Management Body of Knowledge
While terminology may vary, the principles of project management are
consistent. Project Managers with the knowledge and skill to lead a team
toward a common goal will optimize team member talents to the best benefit
of the team and the organization.

The Project Management Body of Knowledge (PMBOK) Guide describes the

work planning process as defining and refining objectives and selecting the
best from alternative courses of action. There are many tools and techniques
unique to project management, such as work breakdown structures, critical
path, or earned value. These tools and techniques alone are not sufficient to
ensure a successful project outcome, but require a project team possessing
adequate project management knowledge and skills. The project team must
possess and use knowledge and skills from at least five areas:

1. The Project Management Body of Knowledge

Knowledge both unique to the project management field and overlapping
other management disciplines.

2. Application area knowledge, standards, and regulations

Project categories with common elements but not necessary in all projects
• Functional and supporting disciplines — legal, inventory management,
personnel, traffic, right-of-way, environmental, etc.

• Technical elements — software development, for example

• Management specializations — government contracting or new

product development

• Industry groups — automotive, chemical, agriculture

Page2-2
Each of these areas typically have there own sets of accepted standards and
practices.

3. Understanding the project environment

The team needs to understand the positive or negative cultural, political, social,
and environmental impacts the project may have and how people (customers,
stakeholders, etc.) may affect the project.

4. General management knowledge and skills

Planning, organizing, staffing, controlling ongoing operations through strategic
planning, accounting, procurement, human resources, information technology,
etc.

5. Interpersonal skills
Effective communication, getting things done, leadership, motivation, conflict
management, and problem solving.

Project Management
Body of Knowledge

Application Area
Interpersonal Knowledge,
Skills Standards, &
Regulations

General Understanding
Management the Project
Knowledge & Environment
Skills

Each of these areas may appear to be discrete elements, but they generally
overlap. It is not required that every team member be an expert in all five areas,
the combined knowledge of the team leads to an effectively managed project.

Page2-3
B. Organizational Planning
Organizational planning is a process that is primarily concerned with
identifying and assigning roles and responsibilities for the project. Everyone
on a project has a function or role and a responsibility assigned to that role or
function. It is important for the Project Manager to identify these roles and
oversee team members in the performance of their responsibilities in order to
keep the project running smoothly and ensuring project success.
Identifying and defining these roles is a vital part of the “Initiate and Align”
step of the project management process.

1. Project Manager
The Project Manager is ultimately responsible for the project. This person
uses organizational resources to accomplish the project objectives. The
Project Manager is “large and in charge” of the project. The Project Manager
leads each step in the project management process.

2. Project Sponsor
The sponsor and the Project Manager are the “owners” of the project.
Usually, the project sponsor will come from senior management, but can be
the customer in some cases. The project sponsor is the person or group
responsible for providing the resources (funding, labor, space, etc.) for the
project.

3. Senior Management (Executive Management)

Senior managers are the people above the Project Manager within an
organization. Senior management will prioritize projects in the organization.
Senior management will Initiate the project, which is the formal recognition
that a project exists. Senior managers delegate project responsibilities and
authority to the Project Manager.

It is also senior management’s role to create a productive environment for the

project, and to review and endorse the project management plan.

4. Functional Manager
The functional manager manages the specialty or specific resources required
to create the deliverables required for the project. Project Managers will
coordinate and negotiate with the functional managers for the resources
needed for the project. Functional managers are often involved in project
planning and setting priorities for the project.

Page2-4
5. Project Team Member
The individuals performing the work required for successful delivery of the
project.

6. Stakeholder
A project stakeholder is anyone with a particularly significant interest in the
project’s outcome including those providing funding or right of way for the project
and property owners who are affected by the project. Stakeholders are unique
for each project and include anyone actively involved in the project and whose
interests may be positively or negatively affected by the execution or completion
of the project. A stakeholder may also exert influence over the project and its
deliverables.

A Project Manager must manage stakeholder expectations, which can be difficult

because stakeholders often have different or even conflicting objectives for the
project. A Project Manager will need to work with the project team to identify key
stakeholders. Key stakeholders are those stakeholders who have a direct impact
on project success. Maintaining effective communication with key stakeholders
is vital to project success.

7. Customer
The person or organization that will acquire or use the project’s product, service,
or result.

The Project Team

Stakeholders

Sponsor
Sr. Mgmt

Project
Manager

Functional Manager

Project Team Members

Page2-5
C. Organizational Breakdown Structure
An Organizational Breakdown Structure (OBS) is a hierarchical organized
depiction of the project organization arranged so as to relate the work
packages to the performing organizational units (functional managers). This
is an effective tool for defining roles and responsibilities and facilitates the
development of the Project Communication Plan.

Organizational Breakdown Structure (OBS)

Sponsor
Sr. Mgmt.

E
L
U
BU

D
E PROJECT
Project Functional
DG

H RISK
C Q
E

S
T

SCOPE
Manager Manager

Functional
Team Team
Member Member

Page2-6
D. Responsibility Assignment Matrix (RAM)
A Responsibility Assignment Matrix (RAM) is a tool that relates the project OBS
to the project Work Breakdown Structure (WBS). It is used to help ensure that
each component of the project’s scope is assigned to a responsible team or
person.

Functional Manager M
Functional Manager G
Functional Manager C
Functional Manager D

Functional Manager H

Functional Manager N
Functional Manager A
Functional Manager B

Functional Manager E

Functional Manager K

Functional Manager P
Functional Manager F

Functional Manager L
Functional Manager J
Role

Project Manager
WBS Item

WBS Deliverable 1 R S A
WBS Deliverable 2 P S R A
WBS Deliverable 3 R I I A S
WBS Deliverable 4 S I

WBS Deliverable 5 R A I S
WBS Deliverable 6 R I A S

WBS Deliverable 7 R S S A
P - Participant; A – Accountable; R – Review; I – Input Required; S – Signature Required

Page2-7
E. Organizational Influences and Structure
Projects are typically part of an organization that is larger than the project.
Examples of organizations include corporations, governmental agencies,
healthcare institutions, international bodies, professional associations, and
others.
Project-based organizations are those whose operations consist primarily of
projects. These organizations fall into two categories:

• Organizations that derive their revenue primarily from performing

projects for others under contract (i.e. architectural firms, engineering
firms, consultants, construction contractors, and government
contractors).

• Organizations that have adopted management by projects. These

organizations usually have a management system in place to facilitate
project management.

Organizational Influences and Structure

Project-Based Organizations
• Organizations that derive their
revenue primarily from performing
projects for others under contract
• Organizations that have adopted
management by projects

Page2-8
The structure of an organization often constrains the availability of resources.

Org Structure Matrix

Functional Projectized
Characteristics Weak Balanced Strong

Project Mgr’s Little or Low to Moderate to High to

Limited
Authority None Moderate High Almost Total

Resource Little or Low to Moderate to High to

Limited
Availability None Moderate High Almost Total

Who controls Functional Functional Project Project

Mixed
project budget Manager Manager Manager Manager

Project Mgr’s
Part-time Part-time Full-time Full-time Full-time
Role

Project Mgr
Part-time Part-time Part-time Full-time Full-time
Admin Staff

1. Functional Organization
The typical functional organization is a hierarchy where each employee has
one clear supervisor. Staff members are grouped by their specialty. The
scope of work is typically bound by the group’s specialty or specific function.
Projects developed in a functional organization will have a project coordinator
in lieu of a Project Manager.

Functional Organization

Org Structure
Functional
Characteristics

Project Mgr’s Authority Little or None

Resource Availability Little or None

Who Controls Project

Functional Manager
Budget

Project Mgr’s Role Part-Time

Project Mgr. Admin Staff Part-Time

Page2-9
2. Projectized Organization
At the other end of the spectrum from the functional organization is the
projectized organization. Often, team members are co-located. Most of
the organization’s resources are involved with project work. Project
Managers have a great amount of independence and project authority.

Projectized Organization

Org Structure
Projectized
Characteristics

Project Mgr’s Authority High to Almost Total

Resource Availability High to Almost Total

Who Controls Project

Project Manager
Budget

Project Mgr’s Role Full-Time

Project Mgr. Admin Staff Full-Time

Page2-10
3. Matrix Organization
Matrix organizations are a blend of functional and projectized characteristics.
a. Strong Matrix
In a strong matrix organization, the Project Manager has considerable
authority and usually will have full-time staff assigned. The Project
Manager will usually report to a manager of Project Managers, or a Project
Management Office.

Strong Matrix Organization

Org Structure
Strong Matrix
Characteristics

Project Mgr’s Authority Moderate to High

Resource Availability Moderate to High

Who Controls Project

Project Manager
Budget

Project Mgr’s Role Full-Time

Project Mgr. Admin Staff Full-Time

Page2-11
b. Weak Matrix
Weak matrices maintain many of the characteristics of a functional
organization, with the Project Manager actually providing a
coordination role, with limited or no project authority.

Weak Matrix Organization

Org Structure
Weak Matrix
Characteristics

Project Mgr’s Authority Limited

Resource Availability Limited

Who Controls Project

Functional Manager
Budget

Project Mgr’s Role Part-Time

Project Mgr. Admin Staff Part-Time

Page2-12
c. Balanced Matrix
A balanced matrix recognizes the need for a Project Manager; this
structure does not provide the Project Manager with full authority over the
project and project funding.

Balanced Matrix Organization

Org Structure
Balanced Matrix
Characteristics

Project Mgr’s Authority Low to Moderate

Resource Availability Low to Moderate

Who Controls Project

Mixed
Budget

Project Mgr’s Role Full-Time

Project Mgr. Admin Staff Part-Time

Page2-13
d. Project Coordinator
In some organizations, Project Managers do not exist. Instead, these
organizations use the role of a project coordinator. The project
coordinator has less authority than a Project Manager. This person
may not be allowed to make budget decisions or overall project
decisions, but they have some authority to assign resources. Project
coordinators are typically found in weak matrix and functional
organizations.

Organizational Influences and Structure

Project Coordinator
• Less authority than a Project Manager
• Does not make project or budget
decisions
• May assign resources
• Functional and Weak Matrix

Page2-14
e. Project Expeditor
This role has the least amount of authority. The Project Expeditor is a
staff member who makes sure things arrive on time and that the tasks and
activities are completed on time. An Expeditor is usually found in a
functional organization.

Organizational Influences and Structure

Project Expeditor
• Least authority
• Staff member that ensures things arrive on
time
• Staff member that manages schedules
• Functional Organization

Page2-15
F. Power
Power is the ability to influence behavior in others. Power that is based on
the organization and the position or title of the Project Manager is
“Organizational” or “Legitimate” power. Power that is based on the
characteristics of the person is “Individual” or “Earned” power.

Power
“The ability to influence behavior in
others”
• Organizational / Legitimate
• Individual / Earned

Page2-16
1. Legitimate/Formal Power
Legitimate power, also known as formal power, is the power that the Project
Manager has due to the position or title. This power comes from being
formally in charge of a project and the backing and support from the agency
or organization.
Strong, broad-based, formal authority for a Project Manager is rare. This
would be characteristic of a projectized organizational structure.

Legitimate / Formal Power

(Organizational / Formal power)
• Power the Project Manager has due
to position
• Formally in charge of project with
support from agency/organization
• Projectized Organization

Page2-17
2. Reward Power
Reward power is the ability to give rewards and recognize achievements.
Some examples of these rewards and recognition are pay raises,
bonuses, time off, or any other type of reward that motivate.

Reward Power
(Organizational / Formal power)
• Ability to give rewards and recognize
achievements
• Examples: pay raises, bonuses, etc.

Page2-18
3. Punishment Power
Similar to reward power, this type of influence is the ability to punish an
employee if a goal is not met. “Nobody is taking vacation next month if we
miss this milestone date,” or “If you overspend the project budget, you’ll be
demoted,” are examples of a manager using punishment power. This type
of power is also known as coercive power.

Punishment Power
(Organizational / Formal power)
• Ability to punish employees if goals
are not met
• Also known as “coercive” power
• Examples: demotions, pay
reduction, etc.

Page2-19
4. Expert Power
Expert power exists when the individual or Project Manager is an expert
on the subject. People will listen and respond to an individual that has
expert power because that person has credibility. A Subject Matter Expert
(SME) has significant power to influence and control behavior.

Expert Power
(Individual / Earned power)
• Exists when individual is an expert
• People will respond and listen
because of credibility
• Subject Matter Experts (SMEs)

Page2-20
5. Referent Power
Referent power is a form of power based on the respect or charismatic traits
of the individual. This power is based in the persuasive ability of the person.

Another form of referent power is when a less persuasive (powerful) person

will use the influence of, or allies with, another person with more persuasive
traits, and leverages the power of the ally.

Referent Power
(Individual / Earned power)
• Respect / charismatic traits of the
individual
or

• Allies with more powerful individual

and leverages the power of the ally

Most project management references consider Reward and Expert

power as the most effective and Punishment or Coercive power as
the least effective.

Page2-21
G. Conflict Management
Project Managers need to realize that conflicts during the life of a project
are inevitable. Recognizing this fact, developing good procedures or
techniques, and planning for conflict resolution can help resolve conflicts
as they arise. A project management plan can identify potential conflicts,
develop resolution methods, and document the methods for the project
team to use throughout the project.

1. Sources of Conflict
Research has shown that the greatest source of conflict is between
Project Managers and functional managers. Most of these are the result
of disagreements over schedules, priorities, and resources. This runs
contrary to commonly held beliefs that most project conflicts are a result of
personality differences.

Conflict Management

Sources of Conflict
50%+ of project
conflicts

Technical Human
Personality Cost Procedure Priorities Schedules
Opinions Resources

Less More
common common
sources of sources of
conflict conflict

Page2-22
 Conflict Management

Conflict Resolution Methods

• Confronting / Problem Solving
• Compromising
• Forcing
• Smoothing / Accommodating
• Withdrawing / Avoiding

2. Confronting/Problem Solving
Sometimes referred to as “confronting” or “collaborating.” Although the term
confronting may have a negative connotation to it, this method is generally
viewed as the best method for conflict resolution. It “confronts” the source
of conflict and looks to solve the conflict so it will not be an issue for the
project.

Conflict Management

Confronting / Problem Solving

• Sometimes referred to as
“collaborating”
• Generally viewed as the best method
for conflict resolution
• Looks to solve the conflict at the
source so it will not be an issue for
the project

Page2-23
 Conflict Management

Confronting / Problem-Solving

• When conflicting parties can get at least

what they want and maybe more
• To reduce cost
• To create a common power base
• To attack a common foe
• When skills are complimentary

Conflict Management

Confronting / Problem-Solving

• When there is enough time

• When there is trust
• When you have confidence in the other’s
ability
• When the ultimate objective is to learn

Page2-24
3. Compromising
To compromise is to negotiate or bargain for a solution that gives both
parties some degree of satisfaction. Some would call this a “give and take”
or “win-win” situation. Others might call it a “lose-lose” position, since
neither party will get everything they want or need.

Conflict Management

Compromising
• To negotiate or bargain for a solution
to give both parties some degree of
satisfaction
• “Give and take” or “win-win”
• Neither party gets everything they
want or need (“lose-lose”)

Page2-25
 Conflict Management

Compromising
• When both parties need to be “winners”
• When you can’t win
• When others are as strong as you are
• When you haven’t time to win
• To maintain the relationship

Conflict Management

Compromising
• When you are not sure you are right
• When you get nothing if you don’t
• When stakes are moderate
• To avoid giving the impression of
“fighting”

Page2-26
4. Forcing
Forcing is exactly as the name implies. It is when one party tries to impose
the solution on the other party. The result is usually viewed as a “win-lose”
situation, where one party wins at the expense of the other. Typically, this
method does not address the underlying source of conflict and can reduce
team morale. It is not viewed as a good method for long term solutions and
relationship building.

Conflict Management

Forcing
• When one party imposes the solution
on the other party
• “win-lose” situation, wins at the
expense of the loser
• Does not always address the
underlying source of conflict and
often reduces team morale

Page2-27
 Conflict Management

Forcing . . .
• To gain status or power
• In short term (one-time) deals
• When the relationship is unimportant
• When a quick decision must be made

Conflict Management

Forcing . . .
• When you are right
• When a do -or-die situation exists
• When stakes are high
• When important principles are at stake
• When you are stronger

Page2-28
5. Smoothing /Accommodating
When using the smoothing or accommodating technique, the Project
Manager will emphasize the areas of agreement or turn attention to what is
going well and deemphasizing the areas of disagreement or conflict.
Smoothing tends to downplay the conflict instead of resolving it.

Conflict Management

Smoothing / Accommodating
• Emphasizes areas of agreement
• Tends to downplay conflict instead
of solving conflict
• May make sacrifices to satisfy the
needs of the other party

Page2-29
 Conflict Management

Smoothing / Accommodating…
• To maintain harmony
• When any solution will be adequate
• To create goodwill
• When you will lose anyway
• To gain time

Conflict Management

Smoothing / Accommodating…
• To reach an overarching or higher goal
• To create obligation for a trade-off at a
later date
• When the stakes are low
• When liability is limited

Page2-30
6. Withdrawal/Avoiding
Withdrawal is often regarded as a temporary solution at best. Some argue
that this is not conflict resolution at all. A Project Manager that uses this
method is merely hoping that the problem will go away by itself over time.
Because of the avoidance or temporary nature of this method, the conflict can
come up again and again throughout the project life.

Conflict Management

Withdrawing / Avoiding
• Temporary solution at best
• Conflict and source of conflict will
continue through project life
• Some view as cowardice and
unwillingness to address the conflict
situation

Page2-31
 Conflict Management

Withdrawing / Avoiding . . .
• When you can’t win
• When stakes are low
• When stakes are high, but you are not
ready
• To gain time

Conflict Management

Withdrawing / Avoiding . . .
• To unnerve your opponent
• To preserve neutrality or reputation
• When you think the problem will “go
away”
• When you win by delay

Page2-32
 Conflict Management

Conflict – Door stuck shut

• Throw shoulder into door and break it open
(Forcing)
• Ignore it; hope another will fix the door
(Withdrawing/Avoiding)
• Determine what is causing the door to be
stuck and correct the problem
(Confronting / Problem solving)

Conflict Management

Preferred
• Confronting / Problem-solving
• Compromising
Last Resort
• Forcing
Avoid
• Withdrawing / Avoiding

Page2-33
7. Team Roles
A Project Manager’s ability to effectively address and manage conflicts on
a project will be affected by his or her ability to recognize and deal with
constructive and destructive roles on the project team. An effective
Project Manager will be able to identify destructive roles within the
team and look to diminish or eliminate them and enhance and
maximize the positive effects from constructive team roles.

Team Roles
• Constructive Team Roles
• Destructive Team Roles
“An effective Project Manager will
look to diminish or eliminate the
effects of destructive team roles and
enhance and maximize the effects of
constructive team roles”

Page2-34
a. Constructive Team Roles
(1) Initiators
An initiator is a project team member that brings ideas and activities to
a project. This role is proactive and is considered highly productive
and positive.

Constructive Team Roles

Initiators
• Brings ideas and activities to the
project
• Proactive
• Highly productive

“Let’s try this!”

Page2-35
(2) Information Seekers
An information seeker is a project team member that actively seeks
to gain as much project information and project understanding as
possible. This role is considered positive because this develops an
environment of increased project knowledge and open
communications for the project team.

Constructive Team Roles

Information Seekers
• Looks to gain as much project
information and understanding as
possible
• Opens communication

“Can we get this information? ”

Page2-36
(3) Information Givers
An information giver is a project team member that openly shares
project information. Similar to the information seeker, this role is
considered positive because it develops an environment of increased
project knowledge and open communications for the project team. Be
mindful that not all information can be readily shared (i.e. confidential,
classified, secret information).

Constructive Team Roles

Information Givers
• Openly shares project information
• Increases project knowledge
• Opens communication

“Studies have shown that…”

Page2-37
(4) Encouragers
Encouragers are project team members that maintain a positive
and realistic attitude within the project team. These individuals
keep the team focused on what can be accomplished. This role is
considered positive because it contributes, improves, and maintains
team morale.

Constructive Team Roles

Encouragers
• Maintains positive and realistic
attitude within the project team
• Keeps focus on what can be
accomplished
• Improves team morale
“Your idea has a lot of merit.”

Page2-38
(5) Clarifiers
A clarifier is a project team member that works to ensure that
everyone has the same project understanding and project
knowledge. This role is considered positive because it is proactive
and keeps the team focused on the project objectives. This role also
improves communication.

Constructive Team Roles

Clarifiers
• Ensures everyone has the same project
knowledge and understanding
• Improves communication

“Let me restate what I’m hearing from the

team ...”

Page2-39
(6) Harmonizers
A harmonizer is a project team member that actively looks to
enhance project information in a way that increases project
understanding. This is considered a positive role because it
increases project understanding and can contribute to better
communication.

Constructive Team Roles

Harmonizers
• Enhances project information to increase
project knowledge and understanding
• Improves communication

“Your ideas are similar, let’s build from

there...”

Page2-40
(7) Summarizers
A summarizer can take the minute details of the project and restate or
relate them in a summarized form back to the project objectives. This
is considered a positive role because the fine details of a project can
become overwhelming to project team members. A summarizer will,
similar to the harmonizer, help to increase project understanding and
can contribute to better communication.

Constructive Team Roles

Summarizers
• Restate and relate project
information back to the project
objectives
• Improves project understanding
• “The details shared by the designers
will improve the product and present
a cost savings of...”

Page2-41
(8) Gate Keepers
The role of gate keeper has a couple of possible meanings in
project management, depending on the reference used. One
definition is a project team member that works to draw other team
members into the project discussions. This role is considered
positive because it encourages participation on the project.

Another definition is the project team member that judges whether

the project will continue when a “kill point” or “stage gate” has been
reached. This project team member makes decisions whether the
project still meets business needs and is justified in transitioning to
the next phase.

Constructive Team Roles

Gate Keepers
• Works to draw all project team
members into the discussion
• Also: Determines whether a project
will continue to the next phase
• “We haven’t heard from Jim, what are
your thoughts?”

Page2-42
b. Destructive Team Roles
(1) Aggressors
An aggressor is a project team member that is openly opposed and
hostile to the project and project objectives. This is a negative role
because it serves no productive purpose for the project.

Destructive Team Roles

Aggressors
• Criticizes everybody and everything
on project management
• Acts aggressively
• Deflates team morale

Page2-43
(2) Blockers
A blocker is a project team member that blocks access to
information and looks to disrupt the flow of communication.
Since good project communication is essential for project
success, this role is very destructive.

Destructive Team Roles

Blockers
• Rejects others viewpoints
• Likes to criticize
• Cites unrelated examples

Page2-44
(3) Withdrawers
A withdrawer is a project team member who does not participate in
discussions, brainstorming sessions, team meetings, etc. This
person will likely remain quiet or refuse to participate at all. This is
a negative role because it usually produces a project team member
that will not commit to the project plan and can have a negative
effect on team morale.

Destructive Team Roles

Withdrawers
• Is afraid to be criticized
• May withhold information
• May be “pouting”
• May be shy

Page2-45
(4) Recognition Seekers
A recognition seeker will look at a project to see how it can
personally benefit him or her. Because this person is more
interested in personal benefit than project success, he or she can
ultimately jeopardize the project.

Destructive Team Roles

Recognition Seekers
• Only volunteers if status is
recognized
• Like to hear themselves talk
• Boasts, rather than provides
meaningful information
• Does not give merit to other’s ideas

Page2-46
(5) Topic Jumpers
A topic jumper is a project team member that constantly changes
the subject and brings up irrelevant facts. This is a destructive role
because it disrupts effective communication and could prevent
important topics from being fully discussed and brought to closure.

Destructive Team Roles

Topic Jumpers
• Brings up irrelevant points
• Constantly changes topics
• Tries to keep project management
implementation as an action item
forever

Page2-47
(6) Dominator
A dominator is a project team member that disrupts team participation
and communication by presenting their own opinions forcefully and
without any recognition or consideration of other’s contributions or
points of view. This person will dominate the communication and bully
their way through the project. This is a negative role because is
prevents effective communication, quashes other’s valid opinions, and
may be contrary to the project’s objectives.

Destructive Team Roles

Dominator
• Disrupts team participation by
forcefully presenting ideas without
considering others
• Always tries to take over
• Challenges those in leadership roles
• Professes to “know everything”

Page2-48
(7) Devil’s Advocate
“advocatus diaboli” Although the origins of this role are rooted as a
positive role for the critical examination of canonization or beatification
in the Roman Catholic Church, for project management this is
considered a negative role. The definition of this role is a project team
member that takes up the contrary view just for the sake of argument
and not on the argument’s merits (if any). This role is negative
because it often frustrates and disrupts effective communication and
discourages people from participating.

Destructive Team Roles

Devil’s Advocate
• Finds faults in all areas of project
management
• Argues not on merits, but for sake of
arguing
• More of a “devil” than an “advocate”

Page2-49
Module 2 References
Harold Kerzner, Ph.D. Project Management, A Systems Approach to
Planning, Scheduling, and Controlling, 8th Edition. John Wiley & Sons, Inc.
2000.
Project Management Institute. A Guide to the Project Management Body of
Knowledge, 3rd Edition (PMBOK Guide). Project Management Institute, Inc.
2004.
Velociteach. The PMP Exam, 2005 Edition. Andy Crowe, PMP. 2004.

Page2-50
Module 2 Exercise
1) The project team member who is responsible for providing the financial
resources (funding) for the project is the:
a) Project Manager
b) Functional Manager
c) Project Sponsor
d) Senior Manager

2) An effective tool for identifying roles and responsibilities and facilitating the
development of the project communication plan is the:
a) Organizational Breakdown Structure (OBS)
b) Responsibility Assignment Matrix (RAM)
c) Work Breakdown Structure (WBS)
d) Key Stakeholder Analysis

3) Who manages the project budget in a functional matrix organization?

a) Project Manager
b) Functional Manager
c) Customer
d) Key Stakeholder

4) In what type of matrix organization does the Project Manager have high to
total authority of the project?
a) Balanced Matrix
b) Functional Matrix
c) Projectized Matrix
d) Weak Matrix

5) Which one of the following is an example of “Earned” or “Individual”

power?
a) Referent power
b) Reward power
c) Punishment power
d) Legitimate power

Page2-51
6) A project team member is an expert in hydraulic analysis. The other
project team members, including the Project Manager, look to this
team member for guidance through the hydraulic design and permitting
process. What type of power is this?
a) Punishment power
b) Referent power
c) Reward power
d) Expert power

7) Which of the following is a productive team role?

a) Recognition seeker
b) Withdrawer
c) Clarifier
d) Topic Jumper

8) If the Project Manager is heard saying, “We agree that this deliverable
is important and we have agreed on all of the other deliverables, let’s
not fight over a few thousand dollars.” What conflict resolution method
is this Project Manager using?
a) Smoothing
b) Confronting
c) Compromising
d) Forcing

9) Which conflict resolution method produces the most lasting results and
in considered the most effective method?
a) Smoothing
b) Confronting
c) Compromising
d) Forcing

10) According to research, what is the most common source of conflict on

a project?
a) Personality conflicts
b) Procedures
c) Resource priority (availability) / Schedules
d) Technical Opinions

Page2-52
 Module

2
General Project Management Theory
Learning Outcomes
• Describe an Organizational Breakdown Structure (OBS) and a
Responsibility Assignment Matrix (RAM) and their uses
• Compare and contrast functional organizations and project
organizations
• Describe the difference between “Organizational Power” and “Earned
Power,” and give examples of each
• List methods for resolving conflicts
• List and describe constructive and destructive team roles

Learning Outcomes

• Describe an Organizational Breakdown Structure (OBS) and

a Responsibility Assignment Matrix (RAM) and their uses
• Compare and contrast functional organizations and project
organizations
• Describe the difference between “Organizational Power”
and “Earned Power,” and give examples of each
• List methods for resolving conflicts
• List and describe constructive and destructive team roles

Page2-53
 3
Module

Risk Planning & Risk Management

Learning Outcomes
• Define project risk

• Describe how risk planning reduces project risk

• Describe how to develop a Risk Management Plan (RPM)

• Define risk management

Learning Outcomes

• Define project risk

• Describe how risk planning reduces risk

• Describe how to develop a Risk Management Plan (RMP)

• Define risk management

__________________________________________________________________________________
Page 3-1
 3
Module

Risk Planning & Risk Management

A. Why Evaluate Risk?
It is impossible to predict the future and there is unavoidable uncertainty
associated with long-lasting construction projects. If we ignore uncertainty, the
project plan will be flawed.

Decisions are of necessity made within the technical and cost context of their
time. The technical and cost context is dynamic, so the structures we build
often survive into very different times.

Why Evaluate Risk?

• It is impossible to predict the future

• Uncertainty is unavoidable

• If ignored, project planning will be flawed

__________________________________________________________________________________
Page 3-2
B. Benefits of Risk Assessment
The benefits of risk assessment include:

• Increased communication within the team and among cross-functional

groups, stakeholders, management, politicians, and the public.

• The risk ranking provided by workshop output helps the Project Manager
know where to focus the team’s efforts.

• The ability to act proactively on risk items and track the risk for which no
preemptive action can be taken.

• It provides a running start into development of the risk management plan

component of the project management plan.

• Project teams receive ideas on potential response strategies for major

risks.

• Project Managers are better prepared for the unexpected.

Benefits of Risk Assessment

• Improved communication.

• Focuses efforts.

• Able to be proactive to mitigate risk.

• Provided running start on PMP

• Potential response strategies are identified earlier.

• The Project is better prepared for unexpected.

__________________________________________________________________________________
Page 3-3
C. Risk Definitions:
1. Risk Management
Risk management is the act or practice of dealing with project risk. It includes
planning for risk, assessing risk (identification and analyzing), developing risk
response strategies, and monitoring risks during the project life.

2. Risk
Project risk is an uncertain event or condition that, if it occurs, has a positive or
negative effect on at least one of the project objectives (scope, schedule,
budget)

3. Threat
A project risk that has a negative effect is referred to as a threat. A project
manager will proactively manage threats to the project and look for ways to
reduce the probability or impact of the threat or eliminate the threat all together.

4. Opportunity
A project risk that has a positive effect is referred to as an opportunity. A
project manager will proactively manage opportunities to the project and look
for ways to exploit, enhance, or share the opportunity.

5. Risk Trigger
A risk may have one or more causes. Identifying the causes of risk events
defines the risk trigger. A risk trigger indicates that a risk event is imminent.

D. Risk Tolerance:
There are many resources available to give guidance for risk management.
Unfortunately, there is no single textbook answer for how to manage project
risk. Project Managers need to rely on the organization’s policies, project team
involvement in risk planning, and the input from subject matter experts.
Ultimately, the decisions made on how to deal with project risk will be based on
the risk profile, or risk tolerance, of the Project Manager, project team, and
organization.
Three common classifications used for describing risk tolerance are the risk
averter (or avoider), risk neutral, or risk seeker (or taker). The method to
classify these is based on the “utility,” or the satisfaction received from the risk
payoff.

__________________________________________________________________________________
Page 3-4
1. Risk Adverse / Averter
U

With a risk adverse or averter, the utility rises at a decreasing rate. This means
when more money is at stake, the tolerance for risk diminishes. Another way to
describe this is that the limit of risk tolerance is achieved at a lower dollar
amount.
A risk adverse person will prefer a more certain outcome and demand a
premium to accept risk.

2. Risk Neutral
U

With a risk neutral profile, the utility, or satisfaction from a risk payoff rises at a
constant rate.

3. Risk Taker / Seeker

U

With a risk taker or risk seeker, the utility rises at an increasing rate. This
means when more money is at stake, the tolerance increases. Another way to
describe this is that the limit of risk tolerance is not achieved unless the dollar
amount is greater.
A risk taker will prefer a more uncertain outcome and is willing to pay a penalty
to take a risk.

__________________________________________________________________________________
Page 3-5
E. INDOT Risk Policy:
During the “Plan the Work” step, the elements of risk are identified and the Risk
Management Plan and Risk Register are developed. The Office of Project
Management also has tools available for risk planning, such as the Risk
Management Plan Template and sample risk plans.
Projects can greatly benefit from formal risk assessments. Typically, the larger
the project, the greater the benefit. Also, projects with one or more of the
following features can benefit from risk analysis:

• Projects that are unique or unusual

• Projects with a high degree of political interest

• Projects that have been through an abbreviated scoping process

• Projects with alternative solutions with varying scope and cost

• New alignments or bypass sections

• Capacity improvements that widen an existing highway

• Major structures

• Interchanges on multi-lane facilities

• Projects with extensive or expensive environmental or geotechnical

requirements

• Projects with materials that are difficult to acquire or require special

efforts

• Projects involving major reconstruction or difficult construction

• Projects with multiple stages

• Projects with major right-of-way or utility issues

These factors are important because the levels of risk, variability, and
opportunity associated with each are generally higher than with routine or
typical projects.

__________________________________________________________________________________
Page 3-6
F. Risk Planning Process:
1. Review Organization Risk Policy
The first step in risk planning is to review the organization’s risk policy.
Depending on the cost or complexity of the project, special risk planning skills
may be required from the Office of Project Management. Reviewing the INDOT
Project Management Policy for Risk Assessment will help the project team
determine the appropriate level of risk planning.

2. Risk Identification
Risk identification determines which risks might affect the project and
documents the characteristics of the risk event. Risk identification is an
iterative process because additional risks may become apparent as the project
progresses through its life cycle.
Some tools a project team can use to identify and gather information about
project risks are:
a. Brainstorming: The goal of brainstorming is to obtain a comprehensible
list of project risks. The project team will identify the risk events and the
trigger for the risk event. Risks can also be categorized by which project
parameters are affected by the risk event. This is a common technique for
risk information gathering.
b. Delphi Technique: The Delphi technique is a way to reach a consensus
of experts. Risk experts participate anonymously as a facilitator uses a
questionnaire to solicit project risks. The responses are summarized and
then recirculated to the experts for further comment. Consensus is reached
after a few rounds of this process. This technique helps reduce bias in the
data and keeps any one person from having excessive influence on the
outcome.
c. Interviewing: Interviewing experienced project team members,
stakeholders, and subject matter experts (SMEs) can identify risks.
Interviews are another common source of risk identification data gathering.
d. Root Cause Identification: This is a method used to further define the
risk event. Think of the little 2-year old, asking “why” after each response.
Eventually, the root cause, the trigger, for the risk event is identified.
Developing the plan to address the risk trigger is the most effective way to
respond to risk events.

__________________________________________________________________________________
Page 3-7
 e. SWOT Analysis: Strengths, weaknesses, opportunities, and threats
(SWOT) technique ensures examination of the project from each of the
SWOT perspectives. This increases the breadth of considered risks.
f. Assumption Analysis: Every project is developed based on a set of
hypotheses, scenarios, or assumptions. Analyzing and exploring the
validity of the assumptions can help identify risks due to inaccuracy,
inconsistency, or incompleteness.
g. Diagramming Techniques: Risk diagramming methods such as the
cause-and-effect diagram (also known as an “Ishikawa” or “fishbone”
diagram) and flow charts can be used to help in risk identification and
risk trigger identification.

3. Risk Register
The outputs from risk identification typically become initial entries in a
document called a risk register. A sample of a risk register template is shown
in Appendix A with descriptions of column headers and an example. The risk
identification section of the template identifies:

• Status: Whether a risk is an active risk, a dormant risk, or a retired risk.

• ID Number: the identification for the risk

• Date Identified and Project Phase: When a risk was identified and
what project phase (preconstruction or construction) the risk was
identified in.

• Functional Assignment: The capital delivery functions (planning,

design, ROW, environmental, construction, etc.) that are impacted by the
risk.

• Risk Event: What the risk event is to the project with a detailed
description using the SMART technique (Specific, Measurable,
Achievable, Realistic, and Time sensitive)

• Risk Trigger: Warning signs that indicate the risk is likely to occur or
imminent. Used to determine when response strategies will be
implemented.
Appendix B is the user’s guide for the Risk Management Plan (RMP) and
provides a complete list of the template column headers.
Once the risk has been identified, the project team can conduct further analysis
(qualitative and quantitative) on the risk event.

__________________________________________________________________________________
Page 3-8
Exercise – Risk Identification

As a team, choose one of the following projects:

1. Building a house
2. Planning a Caribbean trip
For the project, use risk-gathering techniques such as interviewing and
brainstorming to identify risk events. Also identify the risk triggers for each
event. Enter the information onto the risk register. Prepare a listing to
present to the group.

(Time: 15 minutes)

4. Risk Considerations

a. Document the Risks

Sources of scope risk include:

● Requirements that seem likely to change
● Mandatory use of new technology
● Requirements to invent or discover new capabilities
● Unfamiliar or untried development tools or methods
● Extreme reliability or quality requirements
● External sourcing for a key subcomponent or tool
● Incomplete or poorly defined acceptance tests or criteria
● Technical complexity
● Conflicting or inconsistent specifications
● Incomplete product definition
● Very large WBS

b. Key Ideas for Identifying 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.

__________________________________________________________________________________
Page 3-9
 ● Assign ownership for all project work and probe for reasons behind
any reluctance.
● Note risk arising from expected project duration or complexity.

c. Document the Risks

Schedule risks become visible throughout the planning and scheduling

processes. Here are some examples:

● Long duration activities

● Significant worst-case estimates
● High-uncertainty estimates
● Overly optimistic estimates
● All critical path (and near-critical path) activities
● Multiple critical paths
● Convergence points in the logical network
● External dependencies and interfaces
● Deadlines further out than the planning horizon
● Cross-functional and subcontracted work

d. 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.
● 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.

e. Document the Risks

Resource risks become visible throughout the planning and scheduling

processes. Examples include:

● Activities with unknown staffing

● Understaffed activities
● Work that is outsourced
● Contract risks
● Activities requiring a unique resource
__________________________________________________________________________________
Page 3-10
 ● Part-time team members
● Remote team members
● The impact of the work environment
● Budget requirements exceed the project objectives

f. Key Ideas for Identifying Resource Risks

● Identify all required skills you need for which you lack named,
committed staffing
● Determine all situations in the project plan where people or other
resources are overcommitted.
● Find all activities with insufficient resources.
● Identify uncertain activity effort estimates.
● Note outsourcing risks.
● Gain funding approval early for needed training, equipment purchases,
and travel.
● Ascertain all expected project costs.

g. Key Ideas for Constraint Management and Risk Discovery

● Minimize differences between project plans and objectives.

● Understand and clearly document project priorities.
● Use priorities to identify project alternatives.
● Explore project opportunities.
● Identify and explicitly remove unnecessary project scope.
● Determine risks and costs of proposed project changes.
● Minimize unknown risk through brainstorming, analysis, and
research.

h. Strategies for Avoiding Risks

Many of your schedule risks are consequences of decisions you made in

preparing your preliminary schedule. You may be able to remove
sources of schedule risk as follows:

● Reduce the number of critical paths.

● Modify the work to have fewer activity dependencies.
● Schedule the highest uncertainty activities as early as possible.
● Avoid having the same staff members work on two successive or
concurrent critical (or near-critical) activities.
__________________________________________________________________________________
Page 3-11
 ● Decompose lengthy activities further.
● Reschedule work to provide greater flexibility.

i. Resource risks may also be a consequence of choices you made in

resource planning. Explore opportunities to avoid these risks using the
following:

● Obtain names for all required project roles.

● Get explicit availability commitments from all project staff (and from
their managers).
● Work to limit commitments by project staff to other projects,
maintenance and support work, and other time conflicts. Explicitly
document all that remain.
● Modify plans to reduce the load on fully-loaded or overcommitted
resources.
● Use the best people available for the most critical activities.
● Educate team members to use more efficient or faster methods, and
do it early in the project.
● Use mentoring to build teamwork and establish redundancy for critical
skills.
● Upgrade or replace older equipment to make work more efficient, and
do it in the beginning of the project.
● Automate manual work when possible.
● Locate and gain access to experts to cover all skill areas not available
on the project team.
● Minimize dependence on a single individual or other resource for
project work.
● When you use outside services, use the same suppliers that you (or
others that you trust) have used successfully in the past.
● Establish contract terms with all suppliers that are consistent with
project objectives.

__________________________________________________________________________________
Page 3-12
 j. Mitigation Strategies for Scope and Technical Risks

Mitigation of scope risks involves shifts in approach and potential

changes to the project objective. Ideas for mitigating scope risks include:

● Explicitly specify project scope and all intermediate deliverables in

measurable, unambiguous terms, including what is not in the
deliverable. Eliminate “wants” early – make them part of scope or drop
them.
● Gain acceptance for and use a clear and consistent specification
change management process.
● Build models, prototypes, and simulations.
● Test with users, early and often.
● Deal with scope risks promptly.
● Obtain funding for any required outside services.
● Minimize external dependency risks.
● Consider the impact of external and environmental problems.
● Keep all plans and documents current.

k. Mitigation Strategies for Schedule Risks

Tactics for mitigating schedule risks include making additional

investments in planning and revising your project approach. Some ideas
to consider include:

● Use “expected” estimates when worst cases are significant.

● Schedule highest-priority work early.
● Schedule proactive notifications.
● If you must use new technology, explore how you could use older
methods.
● Use parallel, redundant development.
● Send shipments early.
● Be conservative in estimates for training and new hardware.
● Break projects with large staffs into parallel efforts.
● Partition long projects into a sequence of shorter ones.
● Schedule project reviews.
● Reschedule work coincident with known holidays and other time
conflicts.
● Track progress with rigor and discipline.
__________________________________________________________________________________
Page 3-13
 l. Mitigation Strategies for Resource Risks

As with schedule risks, there are many tactics for resource risk
mitigation. Some ideas for minimizing resource risk include:

● Avoid planned overtime.

● Build teamwork and trust on the project team.
● Use “expected” cost estimates where worst-case activity costs are
high.
● Obtain firm commitment for funding and staff.
● Keep customers involved.
● Anticipate staffing gaps.
● Minimize safety and health issues.
● Encourage team members to plan for their own risks.
● Staff risky work with successful problem solvers.
● Rigorously manage outsourcing.
● Detect and address flaws in the project objective promptly.
● Rigorously track project resource use.

__________________________________________________________________________________
Page 3-14
5. Qualitative Risk Analysis
Qualitative Risk Analysis includes methods for prioritizing the identified risks for
further action, such as Quantitative Risk Analysis and Risk Response Planning.
Project teams can improve performance by focusing on high-level or high-priority
risks.
Qualitative Risk Analysis assesses the risk events with respect to the impact to
the project objectives and the probability of occurrence. Definitions of the levels
of impact and probability, as well as interviewing techniques, can help correct
biases that are present in the data, as well as address the different risk profiles
(tolerances) within the project team.

a. Impact/Probability Matrix
A very useful tool for Qualitative Risk Analysis is the Impact/Probability
matrix. This matrix combines impact and probability values for the risk
event that lead to categorizing the risk as low, medium, or high priority risks.
These matrices can vary in size depending on the organization’s risk
policies and the nature of the project. The diagram that follows is called a
2x2 Impact/Probability matrix. The values in this matrix are “low” and “high.”
2 X 2 Impact/Probability Matrix
High
PROBABILITY
Low

Low High
IMPACT

Each risk event is evaluated with respect to the impact to the project objectives.
Once the impact for the risks has been assessed, the project team will evaluate
the probability of the high impact risks. Risks are categorized as low risk,
medium risk, or high risk. (In a black and white matrix, these conditions are
noted as shades of gray with the darker gray representing high risk and white
representing low risk.)
Typically, in a 2x2 matrix, the high risks will be further analyzed and a specific
response strategy will be developed. The medium risks will be actively accepted
or further analyzed, depending on the risk tolerance of the project team. The low
risks will be passively accepted. Acceptance is further discussed in Risk
Response Strategy.
__________________________________________________________________________________
Page 3-15
 Risk Management Planning

Impact/Probability Matrix
• Incorrect : Confusing or combining
Impact & Probability
“It is very unlikely, therefore the impact is low”

• Correct: Keep Impact & Probability

independent
“Probability is low, but if it happens, the project
will fail. Therefore, the impact is high.”

__________________________________________________________________________________
Page 3-16
 Risk Management Planning

Using a 2x2 Impact/Probability Matrix

Gray: Low Risk

High
Probability (Passive Acceptance
– workarounds)
White: Moderate
Risk (Active Acceptance
Low

contingency)

Low High
Black Area: High Risk
Impact (Risk Response Planning)

Risk Management Planning

2x2 Impact/Probability Matrix Example

Risk: Key project team

High
Probability

member with specialized

skill leaves project team
before work is done.
Low

X Impact: High
Probability: Low
Low High
Impact White Area: Moderate Risk

__________________________________________________________________________________
Page 3-17
 Risk Management Planning

2x2 Impact/Probability Matrix Example

Risk: Change to regulatory

High
Probability

X
ordinance requires additional
wetland mitigation, requiring
additional ROW purchase.
Low

Impact: High
Probability: High
Low High
Impact
Black Area: High Risk

b. Risk Impact

● High = Project objective is at risk (mandatory change to one or more

of scope, schedule, and resources).
● Medium = Project objectives are okay, but significant re-planning is
required.
● Low = No major plan changes; the risk is an inconvenience or it will be
handled through minor overtime work.
● Very low = Less than 1 percent impact on scope, schedule, cost, or
Quality
● Low = Less than 5 percent impact on scope, schedule, cost, or quality
● Moderate = Less than 10 percent impact on scope, schedule, cost, or
quality
● High = Less than 20 percent impact on scope, schedule, cost, or
quality
● Very high = 20 percent or more impact on scope, schedule, cost, or
quality

__________________________________________________________________________________
Page 3-18
 b. Comparative Risk Rating (CRR)
Once risk events have been qualitatively assessed, the project team can
prioritize the risks within each category. An easy and common method of
prioritizing these risks is using a comparative risk rating method (sometimes
referred to as “poor man’s” rating).
Each risk event within the category is compared one-on-one with the other
risk events. The project team will identify the higher priority risk event and
record that comparison result. A simple matrix such as the following can be
set up to compare these risk events.

Comparative Risk Rating for 4 risk events

A X

B A X

C C C X

D A B C X

A B C D

Simply counting the number of occurrences for each risk comparison will
prioritize the risks in the category. For the example, in the figure above,
risk event C has 3 scored comparisons, risk event A has scored 2
comparisons, risk event B has 1 scored comparison and risk event D
has none. The order of priority for these four risk events would be C-A-
B-D.

Comparative risk ratings are done to the risk events that fall into the
high-risk zone and medium-risk zone.

__________________________________________________________________________________
Page 3-19
Exercise – Risk Analysis using 2x2 matrix (continuation of
earlier exercise results)

Using a 2x2 impact and probability matrix, assess the risks identified in the
last exercise.
• First, evaluate the impact of the risk event on the project objectives.
• Then, with the risks identified as “high” impact, assess the probability of
the risk event
• Perform a comparative risk rating on the “high-high” risk events to
prioritize these risk events.
(Time: 15 minutes)

2 X 2 Impact/Probability Matrix
High
PROBABILITY
Low

Low High
IMPACT

__________________________________________________________________________________
Page 3-20
6. Quantitative Risk Analysis
Quantitative Risk Analysis is a way of numerically estimating the probability that
a project will meet its time and cost objectives. Quantitative analysis is based
on simultaneous evaluation of the impacts of all identified and quantified risks.

The Office of Project Management will help with the risk analysis for projects
and can assist in the quantitative risk analysis using modeling techniques.
Project Managers should contact the Office of Project Management during the
“Initiate and align” step of the Project Management Process to plan for these
risk analysis products.

Risk Management Planning

Quantitative Risk Analysis

● The process of numerically analyzing the

effect of identified risks on the project’s
objectives. (In particular, the project
schedule and the project costs.)

Quantitative Risk Analysis is performed on risks that have been prioritized by

the Qualitative Risk Analysis process as potentially and substantially impacting
the project objectives. The Quantitative Risk Analysis process analyzes those
risk events and assigns a numerical value to these risk events. This process
uses modeling techniques such as Monte Carlo simulations and decision-tree
analysis to:
• Quantify the possible outcomes for the project and their probabilities
• Assess the probability of achieving specific project objectives
• Identify risks requiring the most attention by quantifying their relative
contribution to overall project risk
• Identify realistic and achievable cost, schedule, or scope targets, given
the project risks
• Determine the best management decision when some conditions or
outcomes are uncertain.

__________________________________________________________________________________
Page 3-21
Interviewing techniques are used to quantify the probability and impact of risks
on project objectives. These values (typically optimistic, most likely, and
pessimistic) are used to develop a probability distribution for the project
components. Decision-tree analysis or modeling and simulation techniques are
then used to develop the probabilities for scenarios and the rewards for logical
paths.
Products of the Quantitative Risk Analysis process are:
• An updated risk register, the information for the individual risk events is
updated based on this analysis
• Probabilistic analysis of success for project objectives (time and cost)
• Updated prioritization of quantified risks, the risks that pose the greatest
threat or present the greatest opportunity to the project
• Trends in quantitative risk analysis. If this process and analysis is
repeated during the project’s life cycle, trends can become apparent
leading to conclusions regarding the risk response.

Risk Management Planning

Quantitative Risk Analysis

• Quantify possible outcomes for the project.
• Assess probability of achieving specific
project objectives.
• Identify risks requiring most attention
• Identify realistic and achievable costs,
schedule, or scope targets, given project
risks.
• Determine best management decisions
when conditions or outcomes are uncertain

__________________________________________________________________________________
Page 3-22
 Risk Management Planning

Quantitative Risk Analysis tools

• Interviewing (SMEs)

• Decision Tree Analysis

• Monte Carlo Simulation

Risk Management Planning

Quantitative Risk Analysis Products

• Updated Risk Register

• Probabilistic analysis for project

success (time and cost)

• Updated priority of risk events

• Trends in risk analysis

__________________________________________________________________________________
Page 3-23
7. Monte Carlo Simulation
A Monte Carlo Simulation is a project simulation using a model that translates
the uncertainties specified at the detailed level of the project into their potential
impact on project objectives (time and cost). In a Monte Carlo simulation, the
project model is computed many times (iterated) with the input values randomly
selected based on the probability distribution for the project element or
schedule activity. A probability distribution is calculated.

For a cost risk analysis, a simulation can use the project WBS or a cost
breakdown as its model. For schedule risk analysis, the precedence
diagramming method (PDM) is used. (PDM is further discussed in Module 4 –
Schedule Management)

TOTAL PROJECT COSTS

Cumulative Chart
100%
90%
PROBABILITY

75%

50%

25%
15%

0%

$30m $33m $36m $39m

$37.5m
COST

In the figure above, assume that the project has a programmed budget of $33
million dollars. Risk events are identified, qualitatively analyzed, quantitatively
analyzed and tied to the project WBS. Using the Monte Carlo simulation
technique, a Total Project Cost graph is generated reflecting the probability of
achieving certain cost values. In the graph above, the project has a 15%
probability of achieving a $33 million cost or less. Depending on the risk
tolerance of the organization, this chart can be used to look for contingency
values needed to meet the probability for success. In this example, assume the
organization is very conservative (risk averse) and wants a 90% confidence, or
probability, for project success. Based on the evaluated risk events for the
project, this project needs a contingency of $4.5 million (a contingency of nearly
14%) to achieve this level of risk tolerance.
__________________________________________________________________________________
Page 3-24
This page Printed from PDF

__________________________________________________________________________________
Page 3-25
7. Risk Response Strategy
Risk response strategy is the process of planning and developing options and
actions to enhance opportunities and reduce or eliminate threats to the project
objectives. This process follows the qualitative and quantitative analyses.
Planned risk responses must be:

• Proactive, not reactive

• Appropriate to the significance of the risk
• Cost effective
• Timely
• Realistic within the project context
• Agreed upon by the project team and parties involved
• Owned by a responsible person

Selection of the best response from several options is often required. Several
risk response strategies are available. The strategy (or mix of strategies) most
likely to be effective should be selected for each risk event.

Risk Management Planning

Risk Response Strategy

• The process of developing options and

actions to enhance opportunities and to
reduce threats to the project objectives.

__________________________________________________________________________________
Page 3-26
 Risk Management Planning

Risk Response Strategy

• Proactive, not reactive

• Appropriate to significance of risk

• Cost effective

• Timely

Risk Management Planning

Risk Response Strategy

• Realistic within the project context

• Agreed upon by project team and all

parties involved

• Owned by a responsible person

__________________________________________________________________________________
Page 3-27
G. Risk Response Definitions:
1. Avoidance
Risk avoidance involves changing a project objective to eliminate the threat
posed by the risk event.

Risk Management Planning

• Avoidance – Changing a project objective to

eliminate a threat posed by an adverse risk
event.

2. Transference
Risk transference requires shifting the negative impact of a threat along with
the ownership of the response to a third party. Transferring the risk does not
eliminate the risk. Transferring liability for a risk is most effective in dealing with
financial risk exposure. Risk transference nearly always involves payment of a
risk premium to the party taking on the risk. Some examples of risk
transference are insurance, performance bonds, warranties, guarantees, etc.

Risk Management Planning

• Transference – Shifting the negative impact of a

threat, along with the ownership of the
response, to a third party.

__________________________________________________________________________________
Page 3-28
3. Mitigation
Risk mitigation implies a reduction in the probability or impact of a threat posed
by the risk event to an acceptable threshold. Taking early action to reduce the
probability or impact of a risk event occurring on a project is often more
effective than trying to repair the damage after the risk has occurred.

Risk Management Planning

• Mitigation – Reducing the probability or impact of

an adverse risk event (threat) to an acceptable
level.

4. Acceptance
This strategy is adopted because it is seldom possible to eliminate all risk from
a project. This strategy is used when the project team has decided not to
change the Project Management Plan to address or deal with the identified risk
event, or the project team is unable to identify any other suitable response
strategy. Acceptance is a risk response strategy used for both threats and
opportunities. This strategy can be either passive or active. Passive
acceptance requires no action, leaving the project team to deal with the risk
event as it occurs (workaround). Active acceptance strategies will establish a
contingency reserve, including time, money, or resources, to handle known
(and sometimes unknown) risks.

Risk Management Planning

• Acceptance – The project team decides not to

change project objectives to deal with risks.

o Passive acceptance – no action, deal with

threats as they occur (workarounds).

o Active acceptance – establish a contingency reserve

to handle risks.

__________________________________________________________________________________
Page 3-29
 Risk Management Planning

Risk Response Strategy (threats)

High
T

(workaround)
Acceptance
Probability

Passive
M

Active
Low Acceptance
(or A-T-M)

Low High
Impact

5. Exploit
This strategy may be selected for risks with positive impacts where the
organization wishes to ensure that the opportunity is realized. This strategy
seeks to eliminate the uncertainty associated with an opportunity by making
sure it happens.

Risk Management Planning

• Exploit – This strategy seeks to eliminate the

uncertainty with an opportunity by changing
a project objective to ensure it happens.

__________________________________________________________________________________
Page 3-30
6. Share
Sharing a positive risk involves allocating ownership to a third party who is best
able to capture the opportunity for the project. One example of a risk sharing
strategy is forming of partnerships or joint ventures.

Risk Management Planning

• Share – Allocating ownership of the positive

risk event to a third party who is best able to
capture the opportunity for the project.

7. Enhance
This strategy, similar to mitigation, increases the probability or positive impacts
of an opportunity. This is done by identifying and maximizing key drivers of
these positive risk events.

Risk Management Planning

• Enhance – Increasing the probability or positive

impact of an opportunity.

8. Contingency Reserve
Contingency reserve is not a risk response strategy; it is an output of risk
planning. When a project team chooses to actively accept a project risk event,
a contingency reserve is established. This is the amount of funds, budget, or
time needed above the estimate to reduce the risk of overruns of project
objectives to a level acceptable to the organization.

Risk Management Planning

• Contingency – Not a risk response, but an

output from risk planning. Developed for
actively accepted project risks. This is
typically defined as time or funds.

__________________________________________________________________________________
Page 3-31
Module 3 Exercise – Risk Response development

Using the result from the qualitative risk analysis from the last exercise:
• Identify risk response strategies for the “high-high” risk events.
• Decide who will be the responsible person to monitor the risk event the
effectiveness of the risk response.
• Decide if active acceptance of further risk response planning will be
required for the “high-low” (yellow zone) risk events.

(Time: 15 minutes)

__________________________________________________________________________________
Page 3-32
H. Risk Monitoring and Control
Throughout the project’s life cycle, new risks may develop. Some risks will not
occur at all and the impacts of risk may change. If the Risk Management Plan
and the Risk Register are not maintained, monitored, and controlled, the effort
and work done during the planning step will go to waste.

Risk monitoring and control is the process of:

• Monitoring risk and opportunity elements

• Identifying new risk and opportunity elements

• Evaluating/upgrading probability of occurrence and potential impacts

• Devising and implementing response strategies

• Evaluating and documenting the effectiveness of response actions

• Reporting to Management and Stakeholders

Risk Management Planning

Risk Monitoring and Control

• Managing the Risk Register during the “Work

the Plan” phase of the project.

• Recognize the probability and impact of risk

events may change during the life of the project.

• Also recognize that additional risk events can

be identified during the “Work the Plan” phase.

__________________________________________________________________________________
Page 3-33
 Risk Management Planning

Risk Monitoring and Control

• Assigning a responsible party (ownership) to

the risk event.

• Track risk event status

o Active or Dormant: risk is currently being

monitored and analyzed.

o Retired: risk event (trigger) no longer poses

a threat to the project.

Risk Management Planning

Risk Monitoring and Control

• Risk Registers should be a standing agenda

item for project team meetings.

• Risk reporting should be a standing reporting

Item for all project progress reporting.

__________________________________________________________________________________
Page 3-34
Module 3 References
INDOT. “A Policy for Cost Risk Assessment”.
A Guide to the Project Management Body of Knowledge, 3rd Edition (PMBOK
Guide). Project Management Institute, Inc. 2004.
Harold Kerzner, Ph.D. Project Management, A Systems Approach to Planning,
Scheduling, and Controlling, 8th Edition. John Wiley & Sons, Inc. 2000.
Velociteach. The PMP Exam, 2005 Edition. Andy Crowe, PMP. 2004.
International Institute for Learning (IIL). Advance Project Risk Management”
training manual, version 4.0. International Institute of Learning, Inc. 2004

__________________________________________________________________________________
Page 3-35
 3
Module

Risk Planning & Risk Management

Learning Outcomes
• Define project risk

• Describe how risk planning reduces project risk

• Describe how to develop a Risk Management Plan (RPM)

• Define risk management

Learning Outcomes

• Define project risk

• Describe how risk planning reduces risk

• Describe how to develop a Risk Management Plan (RMP)

• Define risk management

__________________________________________________________________________________
Page 3-36
 Module

4
Schedule Management
Learning Outcomes
• Define what a work breakdown structure (WBS) is and how it is
developed
• Define the terms deliverable, activity, and milestone
• Define the terms logical relationship, critical path, and float
• Distinguish between CPM and Gantt chart schedules
• Describe how to update a schedule
• Describe how to track a schedule
• Understand “fast tracking”

Learning Outcomes
• Define what a work breakdown structure (WBS) is and how it is developed
• Define the terms deliverable, activity, and milestone
• Define the terms logical relationship, critical path, and float
• Distinguish between CPM and Gantt chart schedules
• Describe how to update a schedule
• Describe how to track a schedule
• Understand “fast tracking”

_____________________________________________________________________
Page 4-1
 Module

4
Schedule Management
A. Schedule Terminology & Definitions
1. Work Breakdown Structure (WBS)
A deliverable-oriented, hierarchical decomposition of the work to be executed
by the project team to accomplish the team mission and create the required
deliverables. The WBS defines the project scope.

Team
Mission

_____________________________________________________________________
Page 4-2
2. Deliverable
Any unique and verifiable product or result that must be produced to complete
a project. Usually the lowest level of the WBS.

Team Mission

D D

D D D D

3. Scheduled Activity (task)

A component of work performed to create a deliverable.

Team Mission
(Scope)
WBS
Activity List

Task 1 Task 1 Task 1 Task 1 Task 1 Task 1

(Schedule)

Task 2 Task 2 Task 2 Task 2 Task 2 Task 2

(Etc.) (Etc.) (Etc.) (Etc.) (Etc.) (Etc.)

_____________________________________________________________________
Page 4-3
4. Scheduled Milestone

A significant event in the project schedule, such as an event restraining future

work or marking the completion of a major deliverable. A “measuring point.”
Milestones have zero duration and no resource assignments.

5. Logical Relationship
Logical relationship is a dependency between two project schedule activities,
or between a project schedule activity and a schedule milestone. Logical
relationships are generally defined as mandatory dependencies (or “hard
logic”) and discretionary dependencies (or “soft logic”).

Schedule Terminology & Definitions

Logical Relationships
•A dependency between scheduled activities, or between a
scheduled activity and a schedule milestone.
•

• “Hard Logic” – Mandatory dependencies

•
“Soft Logic” – Discretionary dependencies
•

_____________________________________________________________________
Page 4-4
The four possible types of logical relationships are:

• Finish-to-Start (most common): The end of one schedule activity will

constrain the start of another activity.

Finish-to-Start

• Finish-to-Finish: The end of one schedule activity will constrain the

finish of another activity.

Finish-to-Finish

• Start-to-Start: The start of one schedule activity will constrain the start
of another activity.

Start-to-Start

• Start-to-Finish (very rare, not available in some software applications):

The start of one schedule activity will constrain the finish of another
schedule activity.

Start-to-Finish

All four of these logical relationships can be modified by applying a “lead,”

advancing the start of the successor activity, or a “lag,” postponing the start of
the successor activity.

_____________________________________________________________________
Page 4-5
6. Precedence Diagram
A schedule network diagramming technique in which schedule activities are
represented by nodes. Schedule activities are graphically linked by one or
more logical relationships to show the sequence in which the activities are to
be performed. Also referred to as “Activity-on-Node (AON).”

A D

F
B
E
C G
Precedence Diagram

7. Critical Path
The critical path is the sequence of schedule activities that determines the
duration of the project. Some characteristics of the critical path are:

• Longest duration path through the project network

• Activities on the Critical Path are called “Critical Activities”
• Critical activities may have no float or slack
• A project can have more than one critical path
• Activities not on the Critical Path are called “Non-Critical Activities”
• To shorten the project duration or delay the project completion, the
critical path must be shortened or lengthened.

_____________________________________________________________________
Page 4-6
8. Float (Slack)
Float, or slack, is the amount of time a scheduled activity can be delayed or
extended without affecting the project (total float) end date or the next
scheduled activity (free float). Float can be further defined as:

• Total Float – The total amount of time that a scheduled activity (or
milestone) may be delayed or extended without delaying the project
end date or violating a schedule constraint.

Activity Total
Duration Float

• Free Float – The amount of time that a scheduled activity (or

milestone) can be delayed without delaying the start of the next
activity in the network.

Activity Free
Duration Float

• Negative Float – The amount of time by which a critical activity (or

milestone) misses a required date.

Negative Activity
Float Duration

_____________________________________________________________________
Page 4-7
9. Critical Path Method (CPM) Scheduling
A schedule network analysis technique used to determine the amount of float
on paths in the project schedule network and to determine the project
duration (critical path). This is done by performing a forward pass through the
project schedule network to determine the early start and early finish dates.
Then performing a backward pass through the project schedule network to
determine the late start and late finish dates.

Forward Pass
Backw ard Pass

•Early Start A D •Late Start

•Early Finish •Late Finish
F
B
E
C G

_____________________________________________________________________
Page 4-8
10. Gantt Chart
Also called a “bar chart.” A graphic display of schedule-related information.
Schedule activities or WBS components are listed at the left of the chart and
dates are shown across the top of the chart. Schedule activities are shown
as a date-paced horizontal bar. This is the most common form of
communication for a schedule. This is a report from the project management
or project scheduling programs.

_____________________________________________________________________
Page 4-9
B. Schedule Tracking
Once the project team has committed to and endorsed a project schedule, a
Project Manager needs to baseline the project schedule. This project
performance baseline represents a “snapshot” of the approved project scope
(WBS) and project schedule. Evaluating actual schedule dates to the project
performance baseline will help the project team evaluate schedule and cost
performance.

A Project Manager needs to track the schedule activities and record when
these schedule activities actually started and completed. This will help
identify where the project is currently at and what potential changes or delays
are approaching.

1. Tracking Schedule “Actuals”

a. Actual Start
This is the date that the work on the deliverable or schedule activity
actually started. In the project schedule software applications, this field
is called “Actual Start.”

Schedule Tracking

Actual Start – This is the date that work on

the scheduled activity actually started. In
project management software applications,
this field is called “Actual Start.”

_____________________________________________________________________
Page 4-10
 b. Actual Finish
This is the date that the work on the deliverable or schedule activity
actually finished. In project schedule software applications, this field is
called “Actual Finish.”

Schedule Tracking

Actual Finish – This is the date that the work

on the scheduled activity actually finished. In
project management software applications,
this field is called “Actual Finish.”

c. Percent Complete
Percent Complete is a function of time. The formula for this value is
defined as “Elapsed Duration/Activity Duration x 100%.”

Schedule Tracking

Percent Complete – This is a function of time.

The formula for this value is

Elapsed Duration / Total Duration x 100%

_____________________________________________________________________
Page 4-11
 d. Base Cost Percent Complete
The key to accurately calculating project progress is having an
accurate estimate of how much of the deliverable (or work) is
complete, expressed in a percentage (%). There are several methods
to choose from, depending upon the type of work performed.

Schedule Tracking

Base Cost % Complete – This is the percent

of the deliverable that has been completed.
There are several ways to estimate this based
on the deliverable.

A project performance baseline must be

defined in the project management program
before this value can be entered.

e. Units Produced Method

This is the ratio of the units produced to the total specified at
completion. Units must be nearly identical. Some examples would be:
• Drilling 10 holes, completed 4 holes, % complete would be 40%
• Paving 5 lane miles, completed 4 lane miles, % complete would
be 80%

Schedule Tracking

Base Cost % Complete

Units Produced Method – This is the ratio of

units produced to the total specified at
completion. Units must be nearly identical.

Example:
Drilling 10 holes, 4 complete – 40% complete

_____________________________________________________________________
Page 4-12
 f. Interim Milestone Method (Agreement Method)
Establish the percent of the total that is represented by each milestone,
based on experience or an agreement with the project team members
on percent complete of various stages of the process/deliverable.
Some examples would be:

• Geometric design complete = 30%

• Detailed Plans = 60%
• Contract Documents = 90%
or
• Data Collection = 10%
• Draft Report = 70%
• Revised Draft = 90%
• Published final = 100%

Schedule Tracking

Interim Milestone (Agreement) Method – Establish the

percent of the total that is to be represented by each
milestone.

Example:
Deliverable: Traffic Signal Design
•Data Collected – 10% complete
•Preliminary Design – 60% complete
•Final Design – 90% complete
•PS&E – 100% complete

_____________________________________________________________________
Page 4-13
 g. 50/50 Method
The 50/50 method is best used when an accurate estimate is nearly
impossible and when durations are relatively short (less than the
reporting frequency). This method is a good method for higher-level
Earned Value Methods (EVM) and when there are several processes
(or deliverables) to be evaluated. The more tasks or deliverables
evaluated, the more accurate the EVM. 50% complete is assumed
when the task or deliverable has started. 100% complete is assumed
when the task/deliverable is finished.

h. 0/100 Method
The 0/100 method is best used when a task or deliverable has no
value unless it is completed and when durations are relatively short
(less than the reporting frequency). This method is also a good
method for higher-level EVM and when there are several processes (or
deliverables) to be evaluated. 0% complete is assumed until a task or
deliverable is complete. 100% complete is assumed when the
task/deliverable is finished.

Schedule Tracking

50/50 Method – 50% complete assumed when

scheduled activity actual starts. 100% complete
when scheduled activity is actually completed.

0/100 Method – 0% complete assumed when

scheduled activity actual starts. 100% complete
when scheduled activity is actually completed.

_____________________________________________________________________
Page 4-14
 i. Proportional Relationship Method
This method is used when the completion of a measurable amount of
one work package indicates the completion of another task that cannot
be easily measured. This method works well for the “on-going” or
hammock tasks within the project schedule. An example of this
method would be:

• 40% of the project is complete, so 40% of the project management

task is complete.

Schedule Tracking

Proportional Relationship Method – This is used

when the completion of a measurable amount of one
work package indicates the completion of another
scheduled activity that cannot be easily measured.
Use for “hammock” tasks.

Example:
Project is 45% complete, Project Management
hammock task is 45% complete

_____________________________________________________________________
Page 4-15
C. Schedule Recovery / Schedule Compression
Schedule compression is a technique used to shorten the project duration
without reducing the project scope. There are two methods used to
compress, or recover a schedule.

Schedule Recovery / Schedule Compression

Schedule Compression
A technique used to shorten a project duration
without reducing the project scope.
There are two methods of schedule compression:
•Schedule Crashing
•Schedule Fast Tracking

_____________________________________________________________________
Page 4-16
1. Schedule Crashing
Schedule crashing is a compression technique in which schedule activity
durations are modified, working-day definitions are modified, or resource
requirements are modified. These modifications are analyzed to determine
how to obtain the greatest amount of compression for the least incremental
cost (Triple Constraints Theory). Typically, crashing a project schedule will
increase project costs, and sometimes crashing a project schedule does not
produce a viable alternative. Some examples of crashing are:

• Shorten schedule activity durations

• Assigning additional resources
• Working overtime / working on non-working days
• Changing project or resource calendars

Schedule Recovery / Schedule Compression

Schedule Crashing
A compression technique in which scheduled activity
durations are modified, working-day definitions are
modified, or resource requirements are modified.
Typically will increase costs.
Activities must be “resource dependant”

_____________________________________________________________________
Page 4-17
2. Schedule Fast Tracking
Fast tracking is a compression technique in which activities that would
normally be completed in sequence are performed in parallel. Fast tracking
does not change the resource requirements, but modifies the logical
relationships between schedule activities. This approach can require work to
be performed without complete detailed information. Typically, fast tracking a
project schedule will increase project risk, which may have an impact on
project costs (Triple Constraints Theory).

Schedule Recovery / Schedule Compression

Schedule Fast Tracking

A compression technique in which activities that
would be normally done in sequence are performed in
parallel.
Fast tracking does not change resource
requirements, but modifies the logical relationships.
Typically, fast tracking will increase project risk.
Cannot fast track “hard logic”

_____________________________________________________________________
Page 4-18
3. “What-If” Scenario Analysis
This is the analysis of the question “What if the situation represented by
scenario ‘X’ happens?” Using the schedule model, the effects of different
compression techniques can be analyzed with regards to project costs and
the amount of schedule time recovered. The outcome from “what-if” analysis
can be used to assess the feasibility of the project schedule under certain
adverse conditions. This can be further used for risk planning, contingency
planning, and response planning. Monte Carlo Analysis is a common “what-
if” technique used.

Schedule Recovery / Schedule Compression

What-if Scenario Analysis

Asking “what-if” for each situation and how it affects
the project model.
Outcomes can evaluate the effects to project
objectives.
Also used for risk planning.

4. Project Development Plans

See Appendix C

_____________________________________________________________________
Page 4-19
Module 4 Exercise

Task D
10 days
Task A Task G
20 days 14 days
Task E
20 days
S Task B
Task H F
16 days
Task F 10 days
7 days
Task C
Task J
25 days
15 days

1. Identify the paths through schedule network and determine the critical
path and project duration.

2. The project customer is requesting this project be completed in 45 days.

Is schedule compression required? If so, what methods would be used to
compress the project schedule?

3. Using the revised project schedule from #2 as the baseline plan, the
duration of Task E is delayed to 24 days due to a key resource being
unavailable for the first 4 days. Does this impact the project schedule and
project end date? If so, what methods would be used to recover the
remaining project schedule (assume everything else to date is completed
or in progress)?

_____________________________________________________________________
Page 4-20
 Module

4
Schedule Management
Learning Outcomes
• Define what a work breakdown structure (WBS) is and how it is
developed
• Define the terms deliverable, activity, and milestone
• Define the terms logical relationship, critical path, and float
• Distinguish between CPM and Gantt chart schedules
• Describe how to update a schedule
• Describe how to track a schedule
• Understand “fast tracking”

Learning Outcomes
• Define what a work breakdown structure (WBS) is and how it is developed
• Define the terms deliverable, activity, and milestone
• Define the terms logical relationship, critical path, and float
• Distinguish between CPM and Gantt chart schedules
• Describe how to update a schedule
• Describe how to track a schedule
• Understand “fast tracking”

_____________________________________________________________________
Page 4-21
 Module

5
Resource Planning
Learning Outcomes

• Define resource planning

• Define Resource estimating

• Explain the use of a resource histogram and its use in resource

planning

• Define resource leveling

• Explain resource conflict and balancing

Learning Outcomes
• Define resource planning

• Define Resource estimating

• Explain the use of a resource histogram and its use in

resource planning

• Define resource leveling

• Explain resource conflict and balancing

Page 5-1
 Module

5
Resource Planning
Estimating schedule activity resources involves determining what resources
(persons, equipment, materials), what quantity of each resource will be used,
and when each resource will be available to perform project activities.

Resource Planning

Estimating Schedule Activity

Resource Requirements
• Determining what resources will be required
(labor, equipment, material)
• What quantity for each resource will be
required.
• When resources are available to perform project
activities.

Page 5-2
A. Resource Estimating
Estimating the level of effort or quantity of resource can be challenging,
especially when a Project Manager is estimating the level of effort for a labor
resource (person).

There are several tools and techniques available to the Project Manager and
to the project team for estimating resources for project activities.

1. Expert Judgment
Any group or person with specialized knowledge can provide estimates for
specific activities.

2. Bottom-up Estimating
Decomposing the activity into smaller, more detailed sub tasks and evaluating
the resource requirements for these activities. The resource needs of each
lower, more detailed piece of work are estimated, and these estimates are
then aggregated into a total quantity for the schedule activity.

3. Three-point Estimating
Similar to estimating schedule activity duration, optimistic, pessimistic, and
most likely estimate values are identified. This method will allow for risk
contingency to be planned for the resource assignment and the schedule
activity.

Resource Planning

Resource Estimating Techniques

• Expert Judgment – Any group or person
with specialized knowledge.
• Bottom-Up Estimating – Decompose
activities into smaller work components.
• Three-Point Estimating – Optimistic,
pessimistic and most likely values are
determined to calculate estimate.

Page 5-3
B. Resource Histogram
A resource histogram is a bar chart showing the amount of time that a
resource is scheduled to work over a series of time periods. Resource
availability may be depicted as a line for comparison purposes.

40 hrs

Week 1
Week 2
Week 3

Week 4
Week 5
Week 6

Week 7
Week 8
Resource Histogram

C. Resource Conflict and Balancing

As discussed earlier, one of the primary sources of conflict on a project is the
availability of resources, especially critical or specialized resources that must
be shared with different projects. A Project Manager must be able to identify
when a resource is needed. Using the resource histogram, and comparing
the assigned work to the resource’s availability (calendar), a Project Manager
can validate the schedule activity.

1. Resource and Project Calendars

Resource calendars and project calendars identify the periods of work or
when work is allowed. Project calendars affect all activities. Resource
calendars only affect a specific resource or a category of resources.

Resource Planning

Resource Conflict and Balancing

• Project calendar – defines the workable
time periods for the project.
• Resource calendar – defines the workable
time periods for the specific resource.
• Conflicts in resource availability and
schedule activity dates must be resolved
to ensure the project will be completed
according to accepted project objectives.

Page 5-4
2. Resource Leveling
Resource leveling is a schedule network analysis technique that is applied to
a schedule model that has been already analyzed by the critical path method.
Resource leveling is used to verify the project schedule is realistic.
Scheduled start dates and scheduled finish dates can be modified to reflect
resource availability. Resource leveling is also performed to ensure that
capable resources are available for critical activities and to address situations
when critical resources must be shared. Resource leveling can also help
identify resources that may be underutilized, allowing a Project Manager to
use this available pool of resources to deliver scheduled activities on the
scheduled dates if other critical resources are not available.

Resource Planning

Resource Leveling
• Schedule network analysis technique
applied to a schedule model that has a
critical path identified.
• Schedule start and finish dates can be
modified to reflect resource availability.
• Identifies under-allocated resources

Page 5-5
There are different methods for resource leveling. A Project Manager must
be able to identify how resolving a resource conflict can impact project
objectives. The following methods can be used and the effects to time and
cost analyzed.

Resource Planning

Resource Leveling
• Different methods for resource leveling
• Project Manager analyzes effects on
project objectives (time and cost) for
resolving resource conflict.

a. Do nothing. This method is recognizing that the resource

requirements are an estimate and that a tolerable limit can be set for
accepting an over allocation of the resource.

• Time (schedule) impact – None.

• Cost (budget) impact – None.

Resource Leveling Methods

Do Nothing if over-allocation is
within acceptable limits
• Schedule/Time Impact – None
• Resource/Cost Impact – None

Page 5-6
b. Delay non-critical path tasks within available float.
• Time (schedule) impact – None.
• Cost (budget) impact – None (except for inflation effects)

Resource Leveling Methods

Delay non-critical tasks within

available float
• Schedule/Time Impact – None
• Resource/Cost Impact – None (except for
inflation effects)

Page 5-7
c. Extend non-critical path task durations within available float
(keeping total effort constant and decreasing the rate at which the
resource is used).

• Time (schedule) impact – None.

• Cost (budget) impact – None (except for inflation effects).

Resource Leveling Methods

Extend non-critical task durations

within the available float
• Schedule/Time Impact – None
• Resource/Cost Impact – None (except for
inflation effects)

Page 5-8
d. Add or substitute resources of equal or greater capability for the
over-allocated resource.

• Time (schedule) impact – May need to consider learning curve

for new resources.

• Cost (budget) impact – Substitute resource may have higher

cost.

Resource Leveling Methods

Add or substitute resource of equal

or greater capability
• Schedule/Time Impact – May need to
consider learning curve for new resource.
• Resource/Cost Impact – Cost impact if
substitute resource has higher costs

e. Delay critical path tasks.

• Time (schedule) impact – Project schedule delay impact equal
to delay value.

• Cost (budget) impact – Costs associated with project extension

and possible inflation costs.

Resource Leveling Methods

Delay critical path tasks

• Schedule/Time Impact – Schedule impact
equal to the delay
• Resource/Cost Impact – Cost impact due
to project time extension and inflation
costs

Page 5-9
f. Extend the durations of critical path tasks (while keeping the total
effort constant and decreasing the rate at which the resource is
used).

• Time (schedule) impact – Project schedule delay impact

equal to extension value.

• Cost (budget) impact – Costs associated with project

extension and possible inflation costs.

Resource Leveling Methods

Extend critical path task durations

• Schedule/Time Impact – Schedule impact
equal to the delay
• Resource/Cost Impact – Cost impact due
to project time extension and inflation
costs

Page 5-10
g. Authorize the use of overtime for tasks that are on the critical
path.

• Time (schedule) impact – Could shorten the schedule

(schedule crashing).

• Cost (budget) impact – Cost impact due to higher resource

cost if resources incur overtime cost. Also, introduces
potential inefficiencies.

Resource Leveling Methods

Authorize Overtime
• Schedule/Time Impact – Could shorten
schedule (schedule crashing)
• Resource/Cost Impact – Cost impact due
to premium cost rates

Page 5-11
h. Split the task into two or more non-sequential pieces.
• Time (schedule) impact – Schedule impact if part of task
extends outside of float.
• Cost (budget) impact – Cost impact due to possible project
extension, inflation costs, and inefficiencies in splitting the
task.

Resource Leveling Methods

Split the task into non-sequential

pieces
• Schedule/Time Impact – Schedule impact if
part of task extends outside of float (soft
logic)
• Resource/Cost Impact – Cost impact due
to project time extension and inflation
costs and inefficiencies in splitting the
task

Page 5-12
i. Modify the Scope.
• Time (schedule) impact – Could possibly shorten the schedule
due to less work or quality of work being accomplished.
• Cost (budget) impact – Could go either way. In the short run,
the costs should be less due to less work being accomplished;
however the long run costs may be increased

Resource Leveling Methods

Modify the scope

• Schedule/Time Impact – Could shorten
schedule due to less work or quality of
work being accomplished
• Resource/Cost Impact – Could go either
way. In the short term, costs could be less
due to less work, but long term costs may
increase

Page 5-13
Module 5 References

Project Management Institute. A Guide to the Project Management Body of

Knowledge, 3rd Edition (PMBOK Guide). Project Management Institute, Inc.
2004.

Page 5-14
Module 5 Exercise

Using the Gantt chart above (Gantt chart report from scheduling exercise
earlier), develop a resource histogram for this project. (Use the blank
histogram below.)
Assume that a “Design Engineer” is the required resource for each activity.
Each activity will only require one “Design Engineer” to complete the task.
Resource Histogram

4.0

3.0

2.0

1.0

W1 W2 W3 W4 W5 W6 W7 W8 W9 W10

Page 5-15
This page printed from Powerpoint slide

Page 5-16
Printed from Powerpoint slide

Page 5-17
Using the three charts on the previous pages, answer the following questions:

1. How many Design Engineers needed at any one time?

2. Only three Design Engineers are available. How would you resolve
this resource conflict?

Page 5-18
 3. Was there an impact to the project end date?

Complete the resource histogram for question number 2 above.

Resource Histogram

4.0

3.0

2.0

1.0

W1 W2 W3 W4 W5 W6 W7 W8 W9 W10

Page 5-19
 Module

5
Resource Planning
Learning Outcomes

• Define resource planning

• Define Resource estimating

• Explain the use of a resource histogram and its use in resource

planning

• Define resource leveling

• Explain resource conflict and balancing

Learning Outcomes
• Define resource planning

• Define Resource estimating

• Explain the use of a resource histogram and its use in

resource planning

• Define resource leveling

• Explain resource conflict and balancing

Page 5-20