Project

Management
Class 3 – Project Initiation

1
Project Initiation
• Agenda
• Planning Fallacy
• Project Charter
• Work Breakdown Structure
• Task Dependence
• Estimating Task Times
• Resource Dependencies
The Planning Fallacy
• “The conviction that a current project will go as
well as planned even though most projects
from a relevant comparison set have failed to
fulfill their planned outcomes.”
Buehler, R., D. Griffin, J. Peetz. 2010. The planning fallacy: Cognitive,
motivational, and social origins. Advances in Experimental Social
Psychology, 43: 1-62.
The Berlin Airport

4
The Big Dig
• Who: United States Department of Transportation, Federal Highway
Administration & The Massachusetts Turnpike Authority.

• What: The largest civil works project in U.S. history.

• Where: Boston: 8 miles of Interstate highway construction,

approximately 4 miles of I-93 between Roxbury and Somerville, and
approximately 4 miles of I-90 between Chinatown and East Boston.

• When: Federal legislation passed 1987, ground broken in Boston 1991,

completion 2005.

• Why: To reconnect the city and to alleviate traffic bottlenecks.

Costs of the Big Dig
• The largest and most technologically complex
public works project in U.S. history
• Initial cost estimate in 1982
• $2.5 billion

• Final cost estimate in 2012

• About $24.3 billion
Public Works Project Cost
Overruns
Project Initial Estimate Final Cost

The Chunnel $11.5 billion $21 billion

Alaska Oil Pipeline $8 billion $14.2 billion

Denver Airport $1.5 billion $6 billion

LA Light Rail $200 million $900 million

Large Hadron Collider $3.5 billion $9 billion

Discussion
• Why do we see these cost over-runs in
projects?

8
• “In preparing for battle I have always found that
plans are useless, but planning is indispensable.”

(Dwight D. Eisenhower)
The Dual Purpose of Plans

Rational Purpose Political Purpose

• Analyze facts and data • Provide rational mantle
• Structure decision • Get people on board
making • Communication device
• Avoid biases • Manages impressions
• Think before doing • Postpones decisions
• Avoid pitfalls
Garbage in … Garbage out

Source: Dilbert Comic Strips Archive

http://www.dilbert.com/strips/
Defining a Project

12
The Project Charter

• “A document that clearly defines the key attributes of a

project such as the purpose, scope, deliverables and
timetable.”
• Early, not detailed (5 pages), team effort
• The key idea is to get all stakeholders onto the same
page as to
• the purpose of the project (scope),
• the resources that are available,
• and the time constraints (i.e. deadlines) that are necessary.
The Project Charter
Scope Risks

Objectives Deliverables

Background

Governance Assumptions

Schedule Budget

Team
Members
Stakeholders
• “Person or organization (…) that is actively
involved in the project, or whose interests may
be positively or negatively affected by
execution or completion of the project.”
Stakeholders
• Who will be impacted by the project?
• Who will be responsible or accountable for the project?
• Who will have decision authority on the project?
• Who can support the project?
• Who can obstruct the project?
• Who had been involved in this type of project in the
past?
Stakeholders

(www.gamestorming.com)
Stakeholders
• Management
• Project Team Members
• Customers
• Customer’s Customers
• Other Employees in Organization
• Government
• Public
Projects & Change
• Project Management is Change Management

• People react best to change if they are

• Informed early
• Given a chance to participate

19
RACI Matrix

• An assignment of who owns which parts of the project,

i.e. who is responsible for planning and executing the
different elements that form the project.
• The key idea is to get all stakeholders onto the same
page as to
• who is Responsible for what,
• who is Accountable for significant decisions,
• who needs to be Consulted during a task,
• and who needs to be Informed about a task.
RACI Matrix

Stakeholder 5
Stakeholder 1
Stakeholder 2
Stakeholder 3
Stakeholder 4

Stakeholder 6
Stakeholder 7
Stakeholder 8
Task A A R C R C C I R – Responsible
A – Accountable
Task B C R C A I I C – Consulted
I – Informed
Task C C I I C C R A C
Task D A I C I R C I
RACI Matrix
• Why can it be difficult to fully develop such an
RACI matrix upfront?

• What can be the consequences of not making

these responsibilities explicit?
Horizontal Analysis
R – Responsible

Stakeholder 5
Stakeholder 1
Stakeholder 2
Stakeholder 3
Stakeholder 4

Stakeholder 6
Stakeholder 7
Stakeholder 8
A – Accountable
C – Consulted
I – Informed

2 people responsible
Task A A R C R C C I and 3 people need to
be consulted?
Task B C R C A I I
Task C C I I C C R A C
Task D A I C I R C I
Vertical Analysis
R – Responsible

Stakeholder 5
Stakeholder 1
Stakeholder 2
Stakeholder 3
Stakeholder 4

Stakeholder 6
Stakeholder 7
Stakeholder 8
A – Accountable
C – Consulted
I – Informed

Task A A R C R C C I
Task B C R C A I I
Responsible/accountable for
Task C C I I C C R A C 2 tasks, consulted on
another 2?
Task D A I C I R C I
Project Initiation
What Data do we need for Planning?

Scope/Tasks  Work Breakdown Structure

Task Dependence  Design Structure Matrix

Task  Task Time Estimation/CPM Analysis
Time/Schedule

Resources  Resource Dep. Matrix/Crit. Chain

Work Breakdown
Structure
Work Breakdown Structure
• Beginning from the ‘overall’ project, break
down complex tasks into smaller, better
defined elements

• The objective is to break larger, aggregate

tasks into more measurable and manageable
elements

• The ‘Bill of Materials’ for project managers

Work Breakdown Structure
Considering the Product
Level 1 Level 2 Level 3
(Deliverables) (Major Subsystems) (Minor Subsystems)

1.1 Write 1.1.1 Write Text

1. Publish Book
Chapter 1 Chapter 1

1.1.2 Design
Figures Chapter 1

1.2 Write 1.2.1 Write Text

Chapter 2 Chapter 1
Work Breakdown Structure
Considering the Product & Process
A Work Breakdown
Level 1 Level 2 Level 3 Structure usually considers
(Major
(Deliverables)
(Minor both product elements, as
Subsystems) Subsystems)
well as process (or product
lifecycle) elements.
1.1 Write Chapter 1.1.1 Write Text
1. Publish Book
1 Chapter 1

1.1.2 Design
Figures Chapter 1
1.2 Write Chapter 1.2.1 Write Text
2 Chapter 1
1.3 Copy Editing
Not all Subsystems need to
be broken down to the same
level, i.e. copy editing does
not need to be broken into
further subsystems just for
the sake of it.
 Work Breakdown Structure
Considering the Product & Process

Level 2 The last elements in each

Level 1 Level 3 branch of the work
(Major (Minor
(Deliverables) Subsystems) Subsystems) breakdown structure are
called activities, elemental
1. Publish Book
1.1 Write Chapter 1.1.1 Write Text work packages, or tasks.
1 Chapter 1

1.1.2 Design
Figures Chapter 1

1.2 Write Chapter 1.2.1 Write Text

2 Chapter 1

1.3 Copy Editing

 Work Breakdown Structure
How many Levels?
Three levels can define many
projects. Projects with complex
Level 1 Level 2 Level 3 Level 4 end products may require 4-5
levels.
1.1.1 Write Text Subsection 1
An activity “should be selected so
Chapter 1
that it is small enough to be
1. Publish Book 1.1 Write Chapter
1 Subsection 2 visualized as a complete entity for
estimating purposes. On the
1.1.2 Design
Figures Chapter 1
Design Figure 1 other hand, the size of the task
must be large enough to
Design Figure 2 represent a measurable part of
1.2 Write Chapter
2
1.2.1 Write Text
Chapter 2
the whole project.”
Loch, C. H.,, M. T. Pich, M. Urbschat and C. Terwiesch.
Selecting R&D Projects at BMW. IEEE Transactions on
1.3 Copy Editing Engineering Management, 48(1), 70-80.
 Work Breakdown Structure
How many Levels?
DoD/Nasa Guide:
Work packages should not exceed 3
Level 1 Level 2 Level 3 Level 4 months in duration.

1.1.1 Write Text

Other Rules of Thumb:
•No more than 80 employee hours of
Subsection 1
Chapter 1

1. Publish Book 1.1 Write Chapter work.

1 Subsection 2
1.1.2 Design
Figures Chapter 1
1.2 Write Chapter 1.2.1 Write Text
2 Chapter 2
1.3 Copy Editing
•No more than 2% of total project
Design Figure 1
length.
•If it requires more than one
Design Figure 2
specialized resource, break it up.
•If it falls into the reporting domain
of different managers, break it up.
Work Breakdown Structure
• Capture all necessary tasks to complete the
project
Exhaustive
• Involve people with experience (i.e. those who will
be doing the work) in the development of the
WBS
• Do a bottom-up analysis (i.e. do the subtasks add
up to the higher level tasks)?
• Work packages should allow for
• Clearly defined deliverables
Detailed
• Clear ownership
• Effective reporting
 Work Breakdown Structure
Echelon Release Project
Launch the
Release

Train the
Promote Release Build the Code Customer
Organization

Prepare
Finalize Feature Integrate Code Train PSO and
Marketing Code Feature 1 Code Feature 2 Test and Fix
Specification Features Pre-Sales
Message

Prepare
Engine Engine Educate Sales
Marketing
Development Development Force
Material

Component Component
Announce Launch
Development Development

Web/Interface Web/Interface
Development Development
Team Exercise
• Pick a Lego Racer
• Develop a Work Breakdown Structure
• Pin your WBS on the Wall

35
Task Dependence
Relationships Between Elements
Step 1: Gather Information
Task Description Predecessor

Prepare Marketing Message Finalize Feature Specification

Prepare Marketing Material Prepare Marketing Message

Announce Launch Test & Fix, Train PSO and Pre-Sales, Educate Sales Force, Prepare
Marketing Material
Finalize Feature Specification

Feature 1 Engine Development Finalize Feature Specification

Feature 1 Component Development Feature 1 Engine Development

Feature 1 Web Development Feature 1 Component Development

Feature 2 Engine Development Finalize Feature Specification

Feature 2 Component Development Feature 2 Engine Development

Feature 2 Web Development Feature 2 Component Development

Integrate Code Features Feature 1 Web Development, Feature 2 Web Development

Test & Fix Integrate Code Features

Train PSO and Pre-Sales Integrate Code Features, Prepare Marketing Message

Educate Sales Force Prepare Marketing Message

Why Precedence?
• Information Requirement: A task requires
information generated in a previous task, i.e. in
order to develop a prototype, you need a
design.

• Physical Requirement: A task requires a

physical output generated in a previous task,
i.e. in order to build the roof of a house, you
need the walls.
Question Precedence
Precedence relationships usually result from one task using the
output of another task as input. Precedence constraints are a
major reason why tasks need to be performed in sequence and
cannot be performed in parallel. Sequential processing
increases the duration of the project.

The parallel processing of tasks formerly thought of as

sequential, also called concurrence, has become an essential
strategy to speed up projects.
Parallel Processing Examples
• Building a House in 1 Day
• https://vimeo.com/1346363

40
Parallel Processing

41
Keys to Parallel Processing
Step 1: Identify the reason for precedence relationship
(information flows, physical requirements, resource
constraints))
Step 2A: See if you can split up the task to remove this
dependence for certain subtasks (atomization)

Step 2B: Attempt to de-couple tasks by standardizing interfaces

(modularization)

Step 3: Reduce resource constraints

 Step 2: Order Tasks by Precedence
Task Description Predecessor

A Finalize Feature Specification

B Feature 1 Engine Development Finalize Feature Specification

C Feature 1 Component Development Feature 1 Engine Development

D Feature 1 Web Development Feature 1 Component Development

E Feature 2 Engine Development Finalize Feature Specification

F Feature 2 Component Development Feature 2 Engine Development

G Feature 2 Web Development Feature 2 Component Development

H Integrate Code Features Feature 1 Web Development, Feature 2 Web Development

I Test & Fix Integrate Code Features

J Prepare Marketing Message Finalize Feature Specification

K Train PSO and Pre-Sales Integrate Code Features, Prepare Marketing Message

L Educate Sales Force Prepare Marketing Message

M Prepare Marketing Material Prepare Marketing Message

N Announce Launch Test & Fix, Train PSO and Pre-Sales, Educate Sales Force, Prepare
Marketing Material
Step 2: Order Tasks by Precedence
Task Description Predecessor

A Finalize Feature Specification

B Feature 1 Engine Development A

C Feature 1 Component Development B

D Feature 1 Web Development C

E Feature 2 Engine Development A

F Feature 2 Component Development E

G Feature 2 Web Development F

H Integrate Code Features D,G

I Test & Fix H

J Prepare Marketing Message A

K Train PSO and Pre-Sales H,J

L Educate Sales Force J

M Prepare Marketing Material J

N Announce Launch I,K,L,M

Network Representation

B C D I
H
E F G K

A J L N

M
Some Advice
• “(…) we go to the grass roots and ask
individual development teams what they
need from other teams to do their jobs. It’s
important to focus on input rather than
output because we have found that
managers, engineers, and other product-
development professionals are more accurate
in identifying what they need to know than in
describing what others need to know.”

Steven Eppinger, Innovation at the

Speed of Information, Harvard
Business Review
Task Durations
Getting to know your schedule …
Estimating Task Durations
• Upfront, we will not know precisely how long a
task will take

• Task times are stochastic (i.e. random,

probabilistic)

• The best thing we can hope to know is the

probability distribution of how long a task will
take
Estimation Alternatives

Uncertainty
Deterministic Stochastic
Subjective

Point 3-Point
Judgments Judgments
Source

Point Distribution
Objective

Estimates Estimates
Deterministic vs. Stochastic
Task Durations have a Distribution
0.06

0.05

0.04
Probability

0.03

0.02

0.01

0
5 6 7 8 9 10

Duration

Deterministic

Stochastic
 Objective vs. Subjective
Objective Subjective

•From database of past projects •People with relevant experience

•Personal notes from past projects
Sources

•Public sources
•Parametric rules of thumb (e.g. x lines of
code take y hours)

•Tasks may be more different than •Biased judgments on center

expected •Unintentional (Optimism)
•Intentional (Incentives)
•Limited sample size does not allow good
Risks

parameter estimation •Biased judgments on variation

•Overconfidence (asking for 95%
confidence interval usually results in
a 65% confidence interval)
•Anchoring (estimates of the center
have a strong influence on
estimates of the range)
Objective Estimation Example
Design Engineering in Civil Construction

Task Duration (hrs) = 0.0161×useable building area (sq. ft.)

+ 3.530 × # of deep foundations
+ 0.492 × structural concrete (cb. yrds.)
+ 6.382 × tons of steel (structural, pipe rack, misc.)

(Australian Contract Construction Institute, N=76, R2 = 84%)

Objective Estimation Example
Design Engineering in Civil Construction

Task Duration (hrs) = 0.0161×useable building area (sq. ft.)

+ 3.53 × # of deep foundations
+ 0.492 × structural concrete (cb. yrds.)
+ 6.382 × tons of steel (structural, pipe rack, misc.)

(Australian Contract Construction Institute, N=76, R2 = 84%)

Use regression error

Use regression
distribution to create
estimates to create
distribution estimate
point estimate
Subjective Estimation
Who Should Provide Estimates?

The Person Someone Else A Committee

Responsible in or Group in
for a Task Organization Organization
Task Duration Estimation
Individual Biases
Local Buffers in Point Estimates
True Task Duration
0.06

0.05

0.04
Probability

0.03

0.02

0.01

0
5 6 7 8 9 10

Duration

True Mean ‘Padded Mean’

Individual Biases
Overconfidence in Distribution Estimates
True Task Duration
0.06

0.05

0.04
Probability

0.03

0.02

0.01

0
5 6 7 8 9 10

Duration

Reported Range

True Range
Accountability
• “It’s important psychologically that the developer who is writing
the feature estimates the feature … That’s the only way you can
get the buy-in necessary if you want to ship on time. Because if
you hand estimates to a person, that really isn’t their ship date.
It’s your ship date. (…) You never have to fear estimates will be
too pessimistic, because developers always generate a too-
optimistic schedule. So you give the illusion of freedom, while still
having a very ambitious ship date (…).” Chris Peters, VP of Microsoft Office
Product Unit, quoted in Cusumano, M.
A., and Selby, R. W. Microsoft Secrets,
p. 204-206.
 Conflict
Whom do you ask for a task duration estimate?

The person responsible for the task

Pros:
- Most knowledgeable
- Buy-in and accountability

Cons:
- Biased (optimism)
- Incentives (pessimism)
 Conflict
Whom do you ask for a task duration estimate?

Someone else in the organization

Pros:
- Less biased

Cons:
- Not accountable
- Less knowledgeable
Some Advice
• Provide more detailed Work Breakdown
Structure
• Optimism is reduced for less aggregate tasks
• Force people to think of past experience
• Lowers optimism by re-emphasizing history
• People are more biased (optimistic) when
estimating larger projects than smaller projects
• Underestimation of coordination work required
Some more Advice
• Explain the purpose of the estimates to minimize bias
• Planning vs. Performance Measurement

• Avoid anchoring by estimating the range before

estimating the center of a distribution

• Question people’s estimate of the range much more

than their estimate of the center
• Ask how estimates were developed
• Educate team members on the pitfalls of overconfidence
How About Groups?

The Person Someone Else A Committee

Responsible in or Group in
for a Task Organization Organization
 The Marbles Experiment
• How many marbles are in the
container?
• Take 5-10 minutes
• You can look at container, but
don’t pick it up
• Prepare a Judgment
• By Yourself
• In Teams
Random Error in Judgment

++ 0 - - +
Random Error in Judgment

++ 0 - - +

Ideally, the group identifies the member with the

best estimate, and adopts that estimate.
(rarely happens!)
Random Error in Judgment

++ 0 - - +

Worst case, the most optimistic (and overconfident)

group member dominates the discussion.
(often happens!)
Simple Averaging?

++ 0 - - +

“The fact that groups perform at the level of averaging

suggests the radical prescription that groups might wish to
forego discussion and simply average their private
quantitative judgments (…)” (Larrick and Soll 2006)
The Wisdom of Crowds
• Ask multiple judges
• from diverse backgrounds,
• to make an independent judgment,
• and simply average their opinions.
The Wisdom of Crowds

70
Planning Poker
1. Up to 4 Team Members
2. Each Team Member gets one set (color) of cards
3. Team Members review available information
4. Each Team Member Privately Chooses a Card
Representing his/her estimate
5. Team Members simultaneously reveal cards
6. If no consensus, high/low estimators explain their
reasoning, and repeat

71
Planning Poker Practice
Lego # 75871
Ford Mustang GT

How many minutes

would it take for a team
of 4 people to assemble
the product?

72
Resource
Requirements
Identifying Bottlenecks
Resource Requirements
Knowledge Requirements
specialists
generalists

independent integrated

Coordination Requirements

74
Resource Requirements
Knowledge Requirements
specialists

total labor hours

total labor hours
generalists

# of resources # of resources
independent integrated

Coordination Requirements

75
Resource Requirements
Knowledge Requirements
specialists
generalists

independent integrated

Coordination Requirements

76
Marketing
X

VP
Marketing
X

Specialist
Q&A
X

Engineer
Web
X

Developer 2
Web
X

Developer 1
Component
X
X

Developer 2
Component
X
X

Developer 1
Product
X

Architect X
Product
X

X
Manager

M
G
B

D
A

N
E

L
J
I
Resource
Require

Matrix
ments
 Manager
Product

Architect
Product

Developer 1
Component

Developer 2
Component

Developer 1
Web

Developer 2
Web

Engineer
Q&A

Specialist
Marketing

VP
Marketing
A X Identify all resource-
critical tasks, i.e. all tasks
B X that do not have a backup
C X X resource.

D X X
E X Identify possible backup
resources for these tasks?
F X X
G X X
H X
I X
J X
K X
L X
M X
N X
 Manager
Product

Architect
Product

Developer 1
Component

Developer 2
Component

Developer 1
Web

Developer 2
Web

Engineer
Q&A

Specialist
Marketing

VP
Marketing
A X Identify all resources that
have to work on different
B X resource-critical tasks
C X X throughout the project.
These are resources
D X X whose schedule will
require particular
E X
attention.
F X X
G X X
H X We will talk about this
form of resource criticality
I X
in more detail when we
J X discuss the critical chain!
K X
L X
M X
N X
Key Take-Aways
• Work Breakdown Structure
• The ‘Bill of Materials’ of your project

• Design Structure Matrix

• Key dependencies within your project

• Task Time Estimation

• Key input into project planning

• Resource Requirements Matrix

• Identify critical resources