Document 7108691
Download
Report
Transcript Document 7108691
Project Management
MBA
Winter 2009
Professor Nicholas G. Hall
Department of Management Sciences
Fisher College of Business
The Ohio State University
[email protected]
Reasons for Studying Project Management
Product and service life cycles are shorter than
ever before, hence there is more rapid “change”
in industry, and managing this change requires
professional project management.
Emerging applications, especially IT
implementations, are often managed as projects.
More managers are using a project format to
motivate many different activities.
Project management skills are useful in both
manufacturing and service sectors.
2
Objectives of the Course
Understand the critical tradeoffs and decisions
in project management
Learn how to select and organize projects
Learn the uses and limitations of project
management software
Learn how to monitor and control single
projects
Learn how to manage uncertainty and risk in
projects
Learn how to prioritize and manage multiple
projects
Learn how to manage projects better than
typical business practice (70 – 30 mix)
3
Course Overview (1 of 3)
History of the course
History of the subject
Textbook
Readings
4
Course Overview (2 of 3)
Software
Case studies
Case analysis presentations
Guest speakers
5
Course Overview (3 of 3)
Multitasking simulation game
Class participation
Final exam
Questions
6
Carmen Website Contents
Introduction: syllabus, frequently asked
questions
Lecture notes in Powerpoint
Background readings
Case report example
Software tutorials (5)
Multitasking simulation game: templates,
student note
Forms: guest speaker evaluation, course
midterm feedback, peer group evaluation
To be added: case analysis assignments, guest
speaker presentations, student requests, ... 7
Project Management Institute (PMI®)
“We’ve long been acknowledged as a pioneer
in the field and now our membership
represents a truly global community with over
100,000 professionals, representing 125
countries. PMI professionals come from
virtually every major industry…”
PMI offers a valuable certification program,
Project Management Professional (PMP). It
also publishes Project Management Journal, a
valuable source of practical research that is
available through OSU Library e-journals.
8
Useful Readings
Textbook
Klastorin, T. Project Management: Tools and
Tradeoffs, Wiley, Hoboken, NJ, 2004.
Other Useful Sources
Brooks, F. The Mythical Man-Month. Addison-Wesley,
Reading, MA, 1995.
Goldratt, E.M. Critical Chain. The North River Press,
Great Barrington, MA, 1997.
A Guide to the Project Management Body of
Knowledge (PMBOK Guide), PMI, Newton Square, PA,
2000.
Kerzner, H. Strategic Planning for Project Management
Using a Project Management Maturity Model, Wiley,
New York, NY, 2001.
Stevenson, N. Microsoft Project 2003 for Dummies,
Wiley, Indianapolis, IN, 2004.
9
Chapter
Introduction to Project
Management
History of Project Management
One of the first examples of project management was
the construction of the pyramids in Egypt
Henry L. Gantt (1861-1919) added an important
visualization tool around 1917 with the Gantt Chart
In the late 1950s, DuPont Company developed the
Critical Path Method (CPM)
Also in the late 1950s, Booz Allen Hamilton developed
the Program Evaluation and Review Technique (PERT),
which models uncertainty in project management
11
Importance of Project Management
Project management effectively controls
organizational change, allowing organizations
to introduce new products, new processes,
and new programs effectively.
Projects are becoming more complex,
making them more difficult to control without
a formal management structure.
Projects with substantially different
characteristics, especially in IT, are
emerging.
Project management helps cross-functional
teams to become more effective.
12
Comment on the Importance of
Project Management
“At last we are beginning to see
research which proves how important
project management is ... without
well-trained and capable project
managers the percentage of GDP
spent through projects is inflated due
to many exceeding their budget
through poor management.”
Richard Pharro, author and consultant (2003)
Still, many organizations underappreciate the
13
contributions made by their project managers.
What is a Project?
A project is a “temporary endeavor
undertaken to create a unique product or
service”. (PMBOK, 2000)
A project is a well-defined set of tasks or
activities that must all be completed in
order to meet the project’s goals. Two
prevalent characteristics:
Each task may be started or stopped
independently of other tasks;
Tasks are ordered such that they must be
performed in a technological sequence.
14
Examples of Projects
Construction of the pyramids
Apollo moon landing mission
Development of MS Windows
Making The Lord of the Rings
Organizing the Olympics Games
Development and marketing of a new drug
Implementing a new company wide IT system
Design of this course
Project management spans both the
manufacturing and service sectors.
15
Manufacturing Perspective
Flowshop: The same sequence of
operations is used to create each product
or service.
Job Shop: A product or service only flows
through centers which are required to
create it.
16
Characteristics of Flowshop, Job Shop
and Project
Flowshop Job Shop Project
Product
Mass
Custom
Labor
Low skill
High skill High skill
Capital
High
Medium
Low
Variable
Highly
variable
Performance Good
(time, cost,
quality)
Unique
17
Project Management versus Process
Management
“Ultimately, the parallels between process
and project management give way to a
fundamental difference: process
management seeks to eliminate variability
whereas project management must accept
variability because each project is unique.”
J. Elton, J. Roe. 1998. Bringing Discipline to
Project Management. Harvard Business Review.
See coursepack article: Oltra, Maroto and Segura
18
“Lean” Principles in Project Management
Focusing on customer needs
Balancing work to ensure an even
flow
Using “customer pull” rather than
“supplier push” to initiate work
Using principles of continuous
improvement
See coursepack article: Brown et al.
19
Measures of Project Success
Overall perception
Cost
Completion time
Technical goals, compared to initial
specifications
Technical goals, compared to other
projects in the organization
Technical goals, taking into account the
problems that arose in the project
R.J. Might and W.A. Fischer (1985)
Question: Was the movie Titanic successful?
See coursepack article: The Chaos Report
20
Nine Factors Critical to
the Success of Many Projects
Clearly defined goals
Competent project manager
Top management support
Competent project team members
Sufficient resource allocation
Adequate communication channels
Effective control mechanisms
Use of feedback for improvement
Responsiveness to clients
J. Pinto and D. Slevin (1987)
See coursepack article: Czuchry and Yasin
21
Famous Project Failures
In 1988, Westpac Banking Corporation initiated a 5-year,
$85m project to improve its information system. Three
years later, after spending $150m with nothing to show for
it, they cancelled the project and eliminated 500
development jobs.
The computerized baggage handling system at the Denver
International Airport delayed the opening of the airport
from March 1994 to February 1995 and added $85 million
to the original budget. The baggage system continued to
unload bags even though they were jammed on the
conveyor belt. The system also loaded bags into telecarts
that were already full. Hence, some bags fell onto the
tracks, causing the telecarts to jam. The timing between
the conveyor belts and the moving telecarts was not
properly synchronized, causing bags to fall between the
conveyor belt and the telecarts. Then the bags became
wedged under the telecarts, which were bumping into each
other near the load point.
22
Famous Project Failures (cont.)
Disney's shipbuilder was six months late in delivering its
new cruise ships in 1998. Thousands of Disney customers
who had purchased tickets had to be compensated for
making different plans.
In 1997-99, Universal Studios in Orlando, Florida, built a
new restaurant and entertainment complex, a two year
project. The opening was delayed by three months.
The “Big Dig” road construction project in Boston (19872007) was budgeted at $5.8b but cost over $15b. The
project resulted in criminal arrests, thousands of water
leaks, death of a motorist from a tunnel collapse, and
hundreds of millions of dollars in lawsuits.
In 2005, UK grocery chain J. Sainsbury wrote off its
$526m investment in an automated supply chain
management system. They hired 3000 additional workers
23
to stock their shelves manually.
Reasons why Projects Fail
Improper focus of the project management
system, e.g. on low level details
Fixation on first budget estimates
Too much reliance on inaccurate project
management software
Too many people on the project team
Poor communication within the project team
Incentives that reward the wrong actions
See coursepack article: Mulder
24
Common Excuses for Project Failures
Unexpectedly poor weather delayed
construction
Unforeseeable poor performance by
contractors
Senior management imposed an
unrealistic schedule
Instructions by senior management
were unclear
Many wasteful “synchronization”
meetings interrupted actual work
See coursepack article: Pinto and Kharbanda
25
Management of IT Projects
More than $250 billion is spent in
the US each year on approximately
175,000 information technology
projects.
IT project management is an $850
million industry and is expected to
grow by as much as 20 percent per
year.
Gene Bounds, “The Last Word on Project
Management”, IIE Solutions, 1998.
26
IT Projects are Different
“[in IT projects], if you ask people what’s
done and what remains to be done there
is nothing to see. In an IT project, you go
from zero to 100 percent in the last
second--unlike building a brick wall where
you can see when you’re halfway done.”
J. Vowler (2001)
Engineering projects are measured by tasks completed
Example: building construction
IT projects are measured by resources used
Example: software development
27
IT Project Outcomes
29%:
Cancellation
26%: On time
6%: Less than
20% late
6%: more than
200% late
8%: 21-50% late
16%: 101-200%
late
9%: 51-100%
late
Standish Group Survey, 1999.
(from a survey of 8000 business
systems projects)
28
Why do IT Projects Fail?
Ill-defined or changing requirements
Poor project planning/management
Uncontrolled quality problems, e.g.
software fails to complete computing task
in time
Unrealistic expectations/inaccurate
estimates
Adoption of new technology without fully
understanding it
Construx Software Builders, Inc., 2005.
Why are IT projects more difficult?
29
Wheelwright and Clark’s Classification
of Projects
30
Project Life Cycle
31
DESIGN
Design (Scope), Cost, Time Tradeoffs
Required
Performance
Target
COST
Budget
Constraint
Due Date
Optimal Time-Cost
Tradeoff
“You can have your job done cheap, quick, or
right; pick two.” [Sign in local copy center.]
32
Project Management Maturity Model
(PMMM)
PMMM is a formal tool that can be used
to measure an organization's project
management maturity.
Once the initial level of maturity and
areas for improvement are identified, the
PMMM outlines the steps to take toward
project management excellence
PMMM is based on extensive empirical
research that defines a “best practice”
database, as well as a plan for improving
the project management process
33
Project Management Maturity Model
1. Ad-Hoc: The project management
process is disorganized or even chaotic.
Systems and processes are not defined.
Chronic cost and schedule problems exist.
2. Abbreviated: Some project
management processes exist, but
underlying principles are not consistently
followed. Project success is largely
unpredictable. Cost and schedule
problems are common.
34
Project Management Maturity Model
3. Organized: Project management
processes and systems are
documented and and integrated.
Project success rates, and cost and
schedule performance, are improved.
4. Managed: Projects are effectively
controlled by management. Project
success is usually routine. Cost and
schedule performance usually
conform to plan.
35
Project Management Maturity Model
5. Adaptive: Continuous
improvement of the project
management process occurs through
feedback and testing of innovative
ideas and technologies. Project
success rates, and cost and schedule
performance, are continuously
improving.
Source: The Project Management Institute PM Network
1997. Micro Frame Technologies, Inc. and Project
Management Technologies, Inc.
36
Chapter
Project Initiation,
Selection, and Planning
Importance of Project Initiation &
Selection
“There are two ways for a
business to succeed at new
products: doing projects right,
and doing the right projects.”
R.G. Cooper, S. Edgett, E. Kleinschmidt. 2000.
Research and Technology Management.
Good project selection makes the later job of
running projects much easier.
Also, some poorly selected projects are
doomed from the start.
38
Project Selection - Overview
1. Strategic factors
Competitive necessity: keep a foothold in the
market, not get left behind
Market expansion opportunities: not yet
profitable, but need to establish a
presence
Consistency: in line with overall
organization’s mission statement
Image: potential impact of project on
corporate image
39
Project Selection - Overview
2. Project portfolio factors
Diversification: reduce market and other
risks by maintaining a mix of projects
Cash flow constraints: balance available cash
over time and across projects
Resource constraints: plan available
resources (facility, personnel) over time
40
Analyzing Project Portfolios:
Bubble Diagram
Prob of Commercial Success
High
Shapes
Shading
Zero
High
Expected NPV
Color
Size
Low
Bubble diagrams are useful for representing a set of
projects and visualizing a project portfolio.
41
Analyzing Project Portfolios:
Product vs Process
Shape represents
the production
resource used
Size represents the
resource requirement
Extent of Process Change
Source: S.C. Wheelwright and K.B. Clark, 1992,
Creating Project Plans to Focus, Harvard Business Review
42
Project Selection - Overview
3. Project risk factors
Probability of research being successful
Probability of development being successful
Probability of project success w.r.t. scope
Probability of commercial success
Overall risk of project
Competitors in market and their reactions
43
Project Selection - Overview
4. Quantitative factors
Payback period
Net present value / internal rate of return
Expected commercial value
Real options
Multifactor scoring
44
Payback Period Analysis
Number of years needed for the
project to repay its initial fixed
investment.
Example:
A project costs $100,000 and is
expected to save the company
$20,000 per year
Payback Period =
$100,000 / $20,000 = 5 years
45
Comments on Payback Period
Easy to calculate and explain, and
sometimes can be used to achieve a
common purpose throughout an
organization.
Ignores the time value of money,
including interest rates and inflation.
Ignores money earned after the
payback period.
46
Net Present Value (NPV)
Let Ft = net cash flow in period t
(t = 0, 1,..., T), where F0 = initial
cash investment at time t = 0 and
r = discount rate of return (hurdle
rate)
T
Ft
NPV
t
t 0 (1 r )
47
Internal Rate of Return (IRR)
Find a value of r such that NPV is
equal to 0 (but this value may not
be unique)
Example (with T = 2):
Find r such that
F1
F2
F0
0
2
1 r (1 r )
Note that, in a typical project, early cash flows are
negative.
48
NPV Example
Phase I Research and Product
Development: $18 million annual
research cost for 2 years.
Phase II Market Development: $10
million annual expenditure for 2 years
to develop marketing and distribution
channels.
Phase III Sales: All cash flows are
after-tax and occur at year's end.
49
NPV Example
The results of Phase II (available at the end of
year 4) identify the product's market potential
as indicated below:
50
NPV Example
Year
1
2
3
4
5-24
Expected Cash Flow ($m)
-18
-18
-10
-10
10
If the discount rate is 5 percent, the
discounted expected cash flow at the end of
the 4th year is $114.62m.
51
NPV Example
Expected cash flows (with sale of product at end of year 4)
Cash Outflow Cash Inflow
NPV
Year 1
18.00
-18.00/(1+r)
Year 2
18.00
-18.00/(1+r)2
Year 3
10.00
-10.00/(1+r)3
Year 4
10.00
124.62
+114.62/(1+r)4
This is the discounted value of sales at the end of year 4
The internal rate of return is 49.12%.
52
Criticisms of NPV Analysis
Assumes that cash flow forecasts are
accurate; ignores the “human bias” effect
Does not take into account the possibility that
decisions (and therefore cash flows) may
adapt to changing circumstances over time
Ignores project portfolio issues
Use of a single discount rate for the entire
project is problematic, since risk is typically
reduced as the project evolves
See coursepack article: Hodder and Riggs
53
Expected Commercial Value (ECV)
Probability = pc
Probability = pt
Develop
New
Product
Technical
Success
Probability = 1 - pt
Launch
New
Product
Commercial
Success (with net
benefit = NPV)
Commercial
Failure (with net
benefit = 0)
Probability = 1 - pc
Technical
Failure
Risk class 1
Risk class 2
ECV is the expected NPV of the project, calculated by using
the probabilities of the various alternatives.
54
ECV Example
The design of a new product is expected to
take 3 years, at a cost of $6m/year
There is a .8 probability that the product
will be technically feasible
If feasible, the product can be launched in
year 4 with an estimated cost of $5.5M
If launched, the product will be a
commercial success with probability 0.6,
earning gross revenues of $15M per year
for 5 years
If it is a commercial failure, then the
revenue is only $2M per year for 5 years
The discount rate is 10 percent
55
ECV Example
5 Years
Probability = 0.6
3 Years
Research &
Product
Development
Annual
Cost: $6M
Probability = 0.8
Development
Succeeds
One-time
cost of $5.5M
Launch
New
Product
Probability = 0.2
Development
Fails
Drop
Product
Commercial Success
Revenue $15M/yr
Commercial
Failure
Revenue $2M/yr
Probability = 0.4
No Cost
Discount rate
r1=10%
Discount rate
r2=10%
56
ECV Example
$M
Year
What’s
Happening
1
Commercial
Success
Commercial
Failure
10%
Expected
Annual
Cash
Flow
Discounted
Cash Flow
Technical
development
(6.00)
(5.45)
2
Technical dev.
(6.00)
(4.96)
3
Technical dev.
(6.00)
(4.51)
4
Product sales
$15
$2
3.44
2.35
5
Product sales
$15
$2
7.84
4.87
6
Product sales
$15
$2
7.84
4.43
7
Product sales
$15
$2
7.84
4.02
8
Product sales
$15
$2
7.84
3.66
Total = 4.40
Example calculation: .8[(.6)(15)+(.4)(2)-5.50]+.2(0)=3.44
57
Criticisms of ECV Analysis
The possibility of changing decisions
in the future changes the risk
characteristics of the project.
Consequently, the use of the same
discount rate may be inappropriate.
However, it’s not clear what other
discount rate should be used.
That’s where the idea of real options
analysis can (possibly) help.
58
Real Options Analysis
Based on the view that the evaluation of
financial options can be applied to other
investments.
Implicitly finds the correct discount rate by
expressing the cash flows in the project as
a combination of flows whose cost of capital
is supposedly known.
In principle, this should give more accurate
evaluation of projects than ECV.
However, the usefulness of real options
analysis for evaluating projects is unclear.
59
Real Options Analysis
A leader in the application of real options analysis is
Hewlett-Packard. But they mainly use it for
procurement and other low risk, contract-protected
decisions, not to evaluate projects.
Real options analysis is probably not useful in high risk
industries, such as pharmaceuticals.
Real options analysis may also not be useful if a
company lacks the discipline to end a project without
delay if the initial investment doesn’t work out.
Real options author N. Kulatilaka says, “Although you
can make any project look good if you build in enough
options, a real world approach must address two
questions: when exactly do you shut it down, and is
there a good mechanism in sight to do that?”
60
Multifactor Project Scoring Example
Attribute
Scale
Weight
Will the project
unlikely 1 2 3 4 5 likely
increase market share?
30%
Is new facility needed?
15%
Are there safety
concerns?
yes
(2)
likely
(1)
unsure
(3)
no
(4)
no
(5)
10%
Likelihood of
successful technical
development?
unlikely 1 2 3 4 5 likely
20%
Likelihood of
successful commercial
development?
unlikely 1 2 3 4 5 likely
25%
61
Multifactor Project Scoring Example
vi ( xi )
xi L
vi ( xi )
U L
To convert various
measurement
scales to a [0,1]
range.
LINEAR SCALE:
EXPONENTIAL
SCALE:
1 e( L xi )
vi ( xi )
1 e( L U )
1.00
0.90
0.80
Attribute Value
0.70
0.60
Linear Scale
Exponential Scale
0.50
0.40
0.30
0.20
Note that the
exponential scale
places a premium
on being
“acceptable”, but not
on “excellence”.
0.10
0.00
1
2
3
4
Response
5
6
7
xi
62
Multifactor Project Scoring Example
Weight
0.30
0.15
0.10
0.20
0.25
Attribute
#1
#2
#3
#4
#5
Project A
5
Yes (2)
Likely (1)
4
2
Project B
2
No (4)
Unsure (3)
3
4
Project
score (Vj)
Linear Scale
Project A
1.00
0.25
0
0.75
0.25
0.550
Project B
0.25
0.75
0.50
0.50
0.75
0.525
Exponential Scale
Project A
1.00
0.64
0.00
0.97
0.64
0.751
Project B
0.64
0.97
0.88
0.88
0.97
0.845
Note that the linear scale recommends Project A, whereas the
exponential scale recommends Project B.
63
Project Selection as a Portfolio
Problem
A project is a multi-period investment
problem
Top management typically allocates
resources to different product lines (e.g.,
compact cars, high-end sedans)
Product lines sell in separate (but not
necessarily independent) market segments
Product line allocations (which resources
should produce which products) may
change frequently
Conditions in each market segment are
uncertain from period to period due to
competition and changing customer
preferences
64
Project Selection Example
Project A
Revenue by Year
1
2
3
4
($40) $10
$20
$20
Project B
($65)
($25)
$50
$50
$90
$20
$40
$55
Budget Limit
Overall score of Project A: .581
Overall score of Project B: .845
We want to maximize the total overall
score, or value delivered, of the portfolio
65
0-1 Program for Project Selection
Maximize 0.581a + 0.845b
Subject to
40a + 65b ≤ 90 (Year 1)
-10a + 25b ≤ 20 (Year 2)
-20a – 50b ≤ 40 (Year 3)
-20a – 50b ≤ 55 (Year 4)
a, b = 0 or 1
where a = 1 if project A is selected
0 if not
and b similarly.
See coursepack article: Hall et al. (1992)
66
Project Planning Information
1. Project overview and organization
Summary statement, work breakdown
structure, organization plan, subcontracting
plan
2. Project scheduling
Time and schedule, budget, resource allocation
plan
3. Project monitoring and control
Cost control system, contingency plans
4. Project termination
Evaluation, benchmarking and archiving
67
Work Breakdown Structure (WBS)
Specifies the end-item “deliverables”
Divides the work, reducing the dollars and
complexity with each additional division
Stop dividing when the tasks are manageable “work
packages”, which will depend on:
Skill levels of group(s) involved
Managerial responsibility
Length of time
Value of task
Rules of thumb for tasks: small enough for
estimation, large enough for measurability
For example, the 1969 Apollo moon landing project
had about 500,000 tasks
68
Common Problem in WBS Design
“The usual mistake PMs make is to lay out too
many tasks; subdividing the major
achievements into smaller and smaller
subtasks until the work breakdown structure
(WBS) is a “to do” list of one-hour chores…
This springs from the screwy logic that a
project manager’s job is to walk around with
a checklist of 17,432 items and tick each item
off as people complete them….”
The Hampton Group (1996)
69
Two-Level WBS
WBS level 1
WBS level 2
1.1
Event
Planning
1. Charity Auction
1.2
Item
Procurement
1.3
Marketing
1.4 Corporate
Sponsorships
70
Three-Level WBS
1. Charity Auction
WBS level 1
WBS level 2
1.1 Event
Planning
1.2 Item
Procurement
1.1.1 Hire
Auctioneer
1.1.2. Rent space
WBS level 3
1.1.3 Arrange for
decorations
1.1.4 Print
catalog
1.3
Marketing
1.2.1 Silent
auction items
1.2.2 Live
auction items
1.2.3 Raffle
items
1.4 Corporate
Sponsorships
1.3.1 Individual
ticket sales
1.3.2
Advertising
71
Sandbagging
A common problem in estimation of task
durations is building in too much slack (also
known as “sandbagging”).
Sandbagging often results from poorly
aligned incentives. If project workers will
incur a penalty for missing a standard task
time, but no benefit from completing the
task earlier, then the natural tendency is to
inflate the standard task time.
A common problem in projects is that
sandbagging and other “slack” proliferate.
72
New Product Development
Projects
Sequential Approach
Design follows a sequential pattern where
information about the new product is slowly
accumulated in consecutive stages
Stage 0
Stage 1
Stage N
73
New Product Development
Projects
Overlapped Product Design Approach
Allows downstream design stages to start before
preceding upstream stages have finalized their
specifications….
Stage 0
Stage 1
Stage N
74
New Product Development
Projects
What are the tradeoffs when moving from a
traditional sequential product design
approach to an overlapped product design
approach?
Time to market is smaller in the
overlapped design
But the schedule is more vulnerable
(which requires additional monitoring)
Can add further resources to tasks to
reduce duration--but costs are increased
75
Chapter
Project Teams and
Organizational Relationships
Role of Project Manager and Team
Client
Top
Management
Project Manager
Subcontractors
Project Team
Regulating
Organizations
Functional
Managers
This structure is what makes being a project manager
both very interesting and very challenging!
77
Responsibilities of a Project
Manager
To the organization and top management
To the project team
Provide timely and accurate feedback
Keep focus on project goals
Manage personnel changes
To the client
Meet budget and resource constraints
Coordinate with functional managers
Communicate in a timely and accurate manner
Provide control over scope changes
Maintain quality standards
To the subcontractors
Provide information on overall project status
Comment: It’s a long list, and requires prioritization.
78
Project Team
What is a project team?
A group of people committed to achieving a
common set of goals for which they hold
themselves mutually accountable
Characteristics of a project team
Diverse backgrounds/skills
Need to work together effectively, often under
time and cost pressures
May not have worked together before
Have a sense of accountability as a unit (but
perhaps only temporarily)
79
Sources of Conflicts within
Projects
Scheduling and sequencing
Administrative procedures
Staffing issues
Budget and cost issues
Personality conflicts
Project priorities
Trade-off between technical performance
and business performance
Source: H.J. Thamhain and D.L. Wilemon, 1971
80
Artistic Viewpoint
“I design user interfaces to please an
audience of one. I write them for me. If
I’m happy, I know some cool people will like
it… As for schedules, I’m not interested in
schedules; did anyone care when War and
Peace came out?”
Developer, Microsoft Corporation
As reported by MacCormack and Herman,
HBR Case 9-600-097: Microsoft Office
2000
However, is this comment a reasonable one for most
project management environments?
81
Group Harmony and Project
Performance
What is the relationship between the design
of multidisciplinary project teams and
project success?
Two schools of thought:
“Humanistic” school -- groups that have
positive characteristics will perform well
“Task oriented” school -- positive group
harmony detracts from group performance
82
Group Harmony and Project
Performance
Experiment conducted with MBA students
at U. of Washington and Seattle U., using
computer based simulation of a nuclear
power plant.
14 project teams with a total of 44 team
members; compared high performance
(low cost) teams vs low performance
(high cost) teams
Measured:
Group harmony
Individual contributions to group
Speed of decision making
K. Brown, T.D. Klastorin, J. Valluzzi. 1990. “Project Management
Performance: A Comparison of Team Characteristics”, IEEE
Transactions on Engineering Management, 37, 2, 117-125.
83
Group Harmony:
High vs Low Performing Groups
High performing (low cost) groups
Low performing (high cost) groups
High performing groups began with lots of conflict!
84
Extent of Individual Contribution:
High vs Low Performing Groups
High performing (low cost) groups
Low performing (high cost) groups
High performing groups began with individual contributions low!
85
Decision Making Effectiveness:
High vs Low Performing Groups
High performing (low cost) groups
Low performing (high cost) groups
High performing groups began with slow decision making!
86
Organizational Issues
What administrative and control
relationships should be established
between the project and the existing
organization?
How much autonomy and authority
should be given to the project?
What management practices and
systems should be used to manage the
project, and how should they differ from
those used in the existing organization?
87
Fundamental Approaches
Project as a Distinct Entity: In order to
maximize the chances of success, it is better to
organize the project as an entity distinct from
the rest of the organization. This minimizes
interdependencies between the project and the
rest of the organization.
Project Integrated into Existing Structure:
When an organization undertakes a new
project, strong pressures favor the integration
of the project into the existing structure and
management systems and practices.
But, what is the overall company objective?
88
Autonomous Projects Tend to be
More Successful
Because their results are more visible and
attract more management attention
Motivation level tends to be higher
Because they suffer less from conflicts over
priorities than functionally managed projects,
which facilitates time and cost control
Because maintaining relationships between the
project and the organization creates complex
coordination problems
So, why aren’t all projects managed as autonomous
units?
89
Organizational Pressures for
Project Integration
Upper management may resist special status for
projects, because this creates additional risks and
setup costs as well as jealousy
Functional managers like to believe that the
project falls within their department’s jurisdiction
Department managers may feel threatened by
losing some of their best resources to the project
Personnel may resist transfer to the project,
especially for risky projects and when
reintegration after the project could be difficult
Personnel and accounting functions strive for
standardized methods and procedures across the
organization
Managers of autonomous projects choose
methods and materials to optimize locally, not
90
globally
Project Organization Types
1. Functional: The project is divided, and assigned
to appropriate functional departments. The
coordination of the project is carried out by functional
and high-level managers.
2. Functional matrix: A manager is designated to
oversee the project across different functional areas.
3. Balanced matrix: A manager is assigned to
oversee the project, and interacts on an equal basis
with functional managers.
4. Project matrix: A manager is assigned to
oversee the project as an independent entity, and is
responsible for the completion of the project. There
may be a project team, but part time.
5. Project team: A manager is put in charge of a
team drawn from several functional areas who are
assigned to the project full time.
91
Matrix Organization
Motivated by conflicting incentives in the
organization: functional managers typically
want to optimize scope and product
performance and design, project managers
focus more on the cost and schedule of the
project
Matrix organization became widely used in
the 1970’s and early 1980’s
More recently, has evolved into many
different forms (based on reporting
structure, level of standardization, sharing of
responsibility and authority)
92
A Business School as a
Matrix Organization
Dean
Associate Dean for
Undergraduate
Programs
Associate Dean for
MBA Programs
Director of
Doctoral Program
Management Science
Department Chair
Larry
Zelda
Diane
Marketing
Department Chair
Curly
Bob
Barby
Finance Department
Chair
Moe
Gloria
Leslie
Comments: bureaucratic, confusing, stressful
93
Organizational Structure & Project
Success
Studies by Larson and Gobeli (1988,
1989)
Sent questionnaires to 855 randomly
selected PMI members
Asked about organizational structure used
Perceptual measures of project success:
successful, marginal, unsuccessful with
respect to:
Meeting schedule
Controlling cost
Technical performance
Overall performance
94
Study Data
Classification of 547 respondents (64% response rate)
project managers or directors of PM programs
top management (president, vice president, etc.)
managers in functional areas (e.g., marketing)
specialists working on projects
Industries included in studies
30%
16%
26%
18%
14% pharmaceutical products
10% aerospace
10% computer and data processing products
others: telecommunications, medical instruments, glass products,
software development, petrochemical products, houseware goods
Organizational structures:
13% (71): Functional organizations
26% (142): Functional matrix
16.5% (90): Balanced matrix
28.5% (156): Project matrix
16% (87): Project team
95
ANOVA Results by
Organizational Structure
N
Controlling
Cost
Mean (SD)
A
Functional
Organization
71
1.76 (.83)
1.77 (.83)
2.30 (.77)
1.96 (.84)
B
Functional Matrix
142
1.91 (.77)
2.00 (.85)
2.37 (.73)
2.21 (.75)
C
Balanced Matrix
90
2.39 (.73)
2.15 (.82)
2.64 (.61)
2.52 (.61)
D
Project Matrix
156
2.64 (.76)
2.30 (.79)
2.67 (.57)
2.54 (.66)
E
Project Team
87
2.22 (.82)
2.32 (.80)
2.64 (.61)
2.52 (.70)
Total Sample
546
2.12 (.79)
2.14 (.83)
2.53 (.66)
2.38 (.70)
10.38*
6.94*
7.42*
11.45*
Organizational Structure
F-statistic
Scheffe Results
Meeting
Schedule
Mean (SD)
An exception
occurs here
Technical
Overall
Performance
Results
Mean (SD)
Mean (SD)
A,B < C,D,E
E<D
A,B < C < D,E A,B < C,D,E A,B < C,D,E
The results are statistically significant at the p<0.01 level
Higher values represent greater success
96
Principles for Determining Autonomy Level
in New Projects (Organizational Factors)
Ready availability of resources facilitates
the establishment of autonomous projects
The less the organization’s information
system and administrative policies and
procedures are able to serve a project, the
more the project needs specific and
dedicated systems
The more the firm’s culture differs from the
desired project management culture, the
more autonomous a project should be
97
Principles for Determining Autonomy Level
in New Projects (Project Factors)
The greater the strategic importance for an
organization and the larger the size of the project,
the more autonomous the project should be
The more a project is interdependent (“integrated”)
(e.g., there is a need for frequent project meetings),
the more autonomous it should be
The higher the complexity, and the more the
project’s success depends on its environment, the
more autonomous it should be
The greater the need to meet severe budget/time
constraints (especially time, from Larson and
Gobeli), the more autonomous the project should be
The more stable the resource loading, the more
economical it is to dedicate resources to the project
and run it as an autonomous unit
98
Decision Model for Determining the
Level of Autonomy in a New Project
A five step decision model (or, “scoring
model”) is now proposed for determining
the level of autonomy to be allowed in a
new project.
This model provides useful structure and
guidance to the process of determining an
appropriate level of autonomy.
But this model is definitely NOT AN
ALGORITHM! Thus, the same inputs can
lead to different outcomes, based on
judgment and interpretation.
This model is adapted from “Organizational Choices for
Project Management ”, B. Hobbs and P. Menard
99
Decision Model
Step 1. Evaluate the way in
which the organization reacts
to a new project.
Level or
Intensity
Low<-->High
Organizational Factors
_______
Availability of resources
Inflexibility of the organizational
_______
management system
_______
Unsupportiveness of culture
Find the mean
______
100
Decision Model
Step 2. Evaluate the project
itself.
Project factors
Level or
Intensity
Low<-->High
Strategic importance
Size
Novelty & need for innovation
Need for interdependence/integration
Environmental complexity
Need to meet tight constraints
Stability in resource loading
Find the mean
_______
_______
_______
_______
_______
_______
_______
______
101
Decision Model
Step 3. Using the information
from Steps 1 and 2, make a
subjective judgment about
the desired level of autonomy
in the new project. For
example, average the Step 1
and Step 2 numbers.
102
Decision Model
Step 4. Identify to what
extent the desired level of
autonomy from Step 3 is
compatible with the current
management culture (which is
identified on the following
page).
103
Current Management Culture
Ability to manage in an autonomous mode
Percentage of time assigned to projects
Quality of reporting process
Percentage of resources fully dedicated to
projects
Level of control over budget and
management of resources
Level of control over budget allocation and
expenditures
Ability to make independent decisions about
technical choices and tradeoffs
Project-specific systems and procedures
already in place
Project resources located together
Physical separation from parent organization
Find the mean
Level or
Intensity
Low<-->High
________
________
________
________
________
________
________
________
________
________
104
______
Decision Model
Step 5. Based on the information
from Steps 3 and 4, and the relative
importance of the project to the
organization, make a decision about
the appropriate level of autonomy
for the project. The numbers from
Steps 3 and 4 inform that decision,
but should not dominate it.
105
Scoring Model Application:
Control System Project
1.
2.
3.
4.
5.
A major utility is functionally structured
with culture unsupportive of project needs
Management systems cannot serve project
needs for planning, control, general
administration
Severe shortage of specialized human
resources, as they are badly needed for
ongoing operations
High strategic importance: technical failure
could result in a major public catastrophe
Medium to large project: cost is around
$200 million, and project duration is 6 years
106
Decision Model: Control System
Project (cont.)
6.
7.
8.
Strong need for innovation: control system of a large and
complex distribution network needs to be replaced.
Members of the project team participated in the design of
existing control system in the 1970’s, but the new system
is very complex and state of the art.
Strong need for integration: contributions from many
tech departments are needed and are highly
interdependent
Medium-high environmental complexity: many external
interfaces and high dependency on suppliers, because of
highly specialized consulting services and
software/hardware and because the number of potential
suppliers is extremely small. The project impacts many
users who have to be involved in design and
implementation. Industry in turmoil; inability to
terminate contracts, bankruptcies,…
107
Decision Model: Control System
Project (cont.)
9.
10.
11.
12.
13.
Project is very politically sensitive, because of the
visibility the press has given to the shortcomings of
the present system.
Medium budget/time constraints: There is no hard
deadline for the new system, but the risk of severe
problems in the existing system is too high after the
target date. Cost issues are not critical, but they
receive close attention from top management.
Medium stability of resource loading: the level of
internal resources assigned to the project varies
from phase to phase, but the most critical resources
will be with the project throughout.
Budget allocation and expenditures are tightly
controlled by the overall organization.
The accuracy of the financial reporting system is
low: poor control system, significant potential for
human error.
108
Summary of Project
Organization Structure
Project structure is significantly related to project
success
Projects that use a traditional functional organization
have the worst cost, time and scope performance
Projects using either a project matrix or a project team
were more successful in meeting their schedules than
those using the balanced matrix
Projects using the project matrix were better able to
control costs than those using the project team
Overall, the most successful projects used a balanced
matrix, project team, or--especially--project matrix. But,
were these the most successful organizations?
109
Subcontracting Issues
What parts of a project will be subcontracted?
What type of bidding process will be used?
What type of contract?
Should you use a separate request for bids for
each task or use one for all tasks?
What is the impact of subcontracting on the
expected duration of the project?
Should you offer incentives, such as a bonus for
finishing early? Or require penalties for
finishing late?
How does subcontracting impact risk?
110
Advice for Choosing a
Subcontractor
Talk to at least three potential subcontractors
Use referrals where possible
Face-to-face meetings are essential
Tradeoff between quality and price needs to be
considered
Present candidates with test scenarios
Communicate your needs and expectations in
detail
Establish benchmarks for performance
Establish guidelines for contract termination
111
Chapter
Precedence Networks and The
Critical Path Method (CPM)
Precedence Relationships
Several types of precedence requirements occur in practice.
Finish-to-start (FS = a): Task B cannot start until a
days after task A is finished
Start-to-start (SS = a): Task B cannot start until a
days after task A has started
Finish-to-finish (FF = a): Task B cannot finish until
a days after task A is finished
Start-to-finish (SF = a): Task B cannot finish until
a days after task A has started
The most common precedence network has FS = 0.
113
Precedence Networks
Networks represent immediate precedence
relationships among tasks and milestones
identified by the work breakdown structure
Milestones are tasks that take no time and have no
cost, but indicate significant events in the life of
the project (e.g., completion of a project phase)
Two types of networks: Activity-on-Node (AON)
Activity-on-Arc (AOA)
All networks must have only one starting and one
ending point. This can always be achieved
artificially, where necessary.
114
Precedence Networks:
Activity-on-Node (AON)
A
C
Start
End
B
D
115
Precedence Networks:
Activity-on-Arc (AOA)
2
Task C
Task A
Dummy
task
Star
t
Task B
1
End
Task D
Task A: (start, 2)
Task C: (2, end)
Task B: (start, 1)
Task D: (1, end)
Dummy task: (1, 2)
116
AON vs AOA
Arguments for AON
AON is easier to explain and understand
AON is used in most PM software (e.g., Microsoft
Project)
AON does not require the use of dummy tasks to
represent precedence relationships
Arguments for AOA
The PERT model (Chapter 6) is based on AOA
AOA can be drawn using arc lengths
corresponding to task durations, which adds
intuition to the network representation
117
Critical Path Method: AON with
Two Paths
The minimum time needed to complete a
project is equal to the length of the longest
path through the network; this path is known
as a Critical Path. Activities along the critical
path are called Critical Activities.
Task A
7 months
Task B
3 months
Start
End
Task C
11 months
118
CPM Example 1: AON
Calculations
ESB = 7
LFB = 11
ESA = 0
LFA = 8
ESStart = 0
LFStart = 0
Task A
7 months
Task B
3 months
Start
ESEnd = 11
LFEnd = 11
End
Task C
11 months ESC = 0
LFC = 11
Step 1.
Work ES
calculations
forward.
Step 2. Set
LFEND=ESEND.
Step 3.
Work LF
calculations
backward.
ESj = Earliest starting time for task (milestone) j
LFj = Latest finish time for task (milestone) j
119
Example 1: Network Paths and
Lengths
Path
1
Tasks
START-A-B-END
Duration (months)
10
2
START-C-END
11
• There may be more than one critical path,
but there must be at least one
• Critical paths can be found easily using CPM
(as in MS Project), linear programming or
other optimization methods
120
Critical Activities: Implications
Activity j is a critical activity if LFj – ESj = tj
Any activity on a critical path is a critical
activity
A delay to a critical activity causes a delay to
the completion of the entire project
Therefore, critical activities require particularly
efficient execution, so they often receive more
and better resources and closer monitoring
Critical chain project management (Goldratt,
1997) treats a critical path in a project similarly
to a “bottleneck” in a manufacturing process
121
CPM Example 2: AON Network
Task A
14 wks
Task F
9 wks
Task D
12 wks
START
END
Task B
9 wks
Task E
6 wks
Task C
20 wks
122
Example 2: Network Paths and
Lengths
Path
1
2
3
4
5
Tasks
START-A-D-F-END
START-A-D-E-END
START-B-D-F-END
START-B-D-E-END
START-C-E-END
Expected
Duration (wks)
35
32
30
27
26
Thus, START-A-D-F-END is a critical path.
123
Example 2: CPM Calculations
(EFi)
(LSi)
ESD=max{ESA+tA, ESB+tB}=max{0+14, 0+9}=14.
LFD=min{LFE-tE, LFF-tF}=min{35-6, 35-9}=26.
124
CPM Example 2: AON Network
ESA=0
LFA=26-12=14
Task A
14 wks
ESSTART=0
LFSTART=0
ESD= max{14,9} =14
LFD= min{35-9,35-6}=26
ESB=0
LFB=26-12=14
START
ESF=14+12=26
LFF=35-0=35
Task F
9 wks
Task D
12 wks
END
Task B
9 wks
ESC=0
LFC=35-6=29
Task C
20 wks
ESEND=35
LFEND=35
Task E
6 wks
ESE=max{0+20,14+12}=26
LFE=35-0=35
125
Types of Slack
Total Slack (TSi) assumes no delays at other tasks (i.e., all
the noncritical tasks before i use their ES times, and all the
noncritical tasks after i use their LS times)
Free Slack (FSi) assumes no delays at earlier tasks, but
allows delays at later tasks (i.e., all the noncritical tasks use
their ES times)
Safety Slack (SSi) assumes no delays at later tasks, but
allows delays at earlier tasks (i.e., all the noncritical tasks use
their LS times)
Independent Slack (ISi) allows delays at all other tasks (i.e.,
all the noncritical tasks before i use their LS times, and all the
noncritical tasks after i use their ES times)
126
Example 2:
Calculating Total Slack (TSi)
Task or
Milestone
START
A
B
C
D
E
F
END
Duration
( ti )
0
14
9
20
12
6
9
0
Earliest
Start Time
(ES i)
0
0
0
0
14
26
26
35
Lastest
Finish Time
(LFi)
0
14
14
29
26
35
35
35
Total Slack
(TSi)
Critical
Task?
0
0
5
9
0
3
0
0
Yes
Yes
No
No
Yes
No
Yes
Yes
Total Slack for task i = TSi = LFi - ESi - ti
127
Calculating All Slack Values
Total Slack (TSi)
= LFi - ESi - ti
Free Slack (FSi)
= ESi,min - ESi - ti
where ESi,min = minimum earliest start time of all tasks
that immediately follow task i
Safety Slack (SSi)
= LFi - LFi,max - ti
where LFi,max = maximum latest finish time of all tasks
that immediately precede task i
Independent Slack (ISi) = max (0, ESi,min - LFi,max - ti)
128
Slack Calculations: Example
Task A
14 wks
ESSTART=0
LFSTART=0
START
Task D
12 wks
Task B
9 wks
ESC=0
LFC=29
TSC=LFC-ESC-tC
=29-0-20=9
FSC=ESC,min-ESC-tC
=ESE-ESC-tC
=26-0-20=6
Task F
9 wks
Task C
20 wks
ESE=26
LFE=35
END
Task E
6 wks
SSC=LFC-LFC,max-tC
=LFC-LFSTART-tC
=29-0-20=9
ISC=max(0,ESC,min-LFC,max-tC)
=max(0,ESE-LFSTART-tC)
=max(0,26-0-20)=6
129
LP Model: Motivation
It is unnecessary to use an LP model just to
find the critical paths (because CPM is
simpler)
However, an LP model can easily be
extended to evaluate, for example, time /
cost tradeoffs, and task completion time
preferences for the noncritical activities
Also, LP output provides extensive
sensitivity and related information which
should be valuable to project managers
Whereas, most project management
software (such as MS Project) does not
130
LP Model for AON Network
Decision variables: STARTj = start time for task j
END = ending time of project (END milestone)
Minimize END
subject to
STARTj ≥ FINISHi for all tasks i that immediately precede task j
STARTj ≥ 0
for all tasks j in the project
where FINISHi = STARTi + ti
Note that the FINISHi variables will not explicitly appear in the
simplified version of the model
131
LP Model for Example 2
Minimize END
Subject to:
STARTD ≥ FINISHA = STARTA + 14
STARTD ≥ FINISHB = STARTB + 9
STARTE ≥ FINISHC = STARTC + 20
STARTE ≥ FINISHD = STARTD + 12
STARTF ≥ FINISHD = STARTD + 12
END ≥ FINISHE = STARTE + 6
END ≥ FINISHF = STARTF + 9
STARTA, STARTB, STARTC ≥ 0
132
Simplified LP Model for Example 2
Minimize END
Subject to:
STARTD STARTA 14
STARTD STARTB 9
STARTE STARTC 20
STARTE STARTD 12
STARTF STARTD 12
END STARTE 6
END STARTF 9
STARTA , STARTB , STARTC 0
133
Extension of LP Model:
Enforce Early Start Times
How to ensure that all tasks are started at
their earliest possible times.
134
Extension of LP Model:
Enforce Late Start Times
How to ensure that all tasks are started at
their latest possible times, subject to not
delaying the project.
Run any model (for example, CPM) that
minimizes the project duration.
Call the duration of the project
ENDTIME.
In the model on the previous page, add
constraints which ensure that all tasks
complete by ENDTIME
Change minimize to maximize
135
Microsoft® Project
MS Project is an excellent visual aid for
monitoring and controlling projects
For projects without time/cost tradeoffs,
uncertainty in task times, and resource
constraints, it delivers optimal solutions
Outside these simpler environments, the
performance of MS Project is less reliable
See Klastorin, p. 195, for a discussion of
the relative performance of several software
packages, including MS Project
See coursepack article: Fox and Spence (1998)
136
AOA: Precedence Networks
Task A
4 Weeks
2
Task C
7 Weeks
Dummy
task
Star
t
Task B
2 Weeks
End
Task D
10 Weeks
1
Task A: (start, 2)
Task C: (2, end)
Task B: (start, 1)
Task D: (1, end)
Dummy task: (1, 2)
137
AOA: Computing Earliest and
Latest Occurrence Times
TE2=4
TL2=5
Task A
4 Weeks
TESTART=0
TLSTART=0
2
Task C
7 Weeks
Dummy
task
Star
t
Task B
2 Weeks
Step 1. Work TE calculations forward
Step 2. Set TLEND=TEEND
1
TE1=2
TL1=2
TEEND=12
TLEND=12
End
Task D
10 Weeks
Step 3. Work TL
calculations backward
138
Slack Calculations for AOA
TSij = Total slack for Task (i,j)
T jL Ti E tij
FSij = Free slack for Task (i,j)
T jE Ti E tij
SSij = Safety slack for Task (i,j)
T jL Ti L tij
ISij = Independent slack for Task (i,j)
max( 0, T jE Ti L tij )
Interpretations are the same as in AON.
139
Slack Values for AOA: Example
Task
Duration
(tij)
Earliest
Start
Time
(TEj)
Latest
Finish
Time
(TLj)
Total Free Safety Indep.
Slack Slack Slack Slack
(TSij) (FSij) (SSij) (ISij)
A:
(START, 2)
4
2
0
7
10
0
0
2
4
2
5
2
5
12
12
1
0
3
1
0
B:
(START, 1)
Dummy
(1,2)
C:
(2, END)
D:
(1, END)
0
0
2
1
0
1
0
3
0
0
0
0
2
0
0
140
AOA: Calculating Slack
TSSTART2=1, FSSTART2=0
SSSTART2=1, ISSTART2=0
TE2=4
TL2=5
2
Task A
4 Weeks
TESTART=0
TLSTART=0
Star
t
TS12=3, FS12=2
SS12=3, IS12=2
TSSTART1=0, FSSTART1=0 Task B
SSSTART1=0, ISSTART1=0 2 Weeks
Step 1. Work TE calculations forward
Step 2. Set TLEND=TEEND
TS2END=1, FS2END=1
SS2END=0, IS2END=0
Task C
7 Weeks
TEEND=12
TLEND=12
Dummy
task
End
Task D
10 Weeks
1
TE1=2
TL1=2
TS1END=0, FS1END=0
SS1END=0, IS1END=0
Step 3. Work TL
calculations backward
141
LP Model for AOA Network
Decision variables: the occurrence time of each node
142
Chapter
Planning to Minimize Cost
Project Budget
The budget is an important communication
link between the functional units and the
project
Should be presented in terms of measurable
outputs, which correspond to work packages
in the WBS
Should clearly indicate project milestones
Establishes goals, schedules and
benchmarks, and assigns resources to tasks
Serves as a baseline for progress monitoring
and control
144
Types of Budgeting
Top-down Budgeting: Aggregate
measures (cost, time) provided by top
management, based on strategic goals
and constraints
Bottom-up Budgeting: Specific
measures aggregated up from WBS
tasks/costs and subcontractors
Hybrid: Top management typically
indicates a budget constraint, while
project managers use a bottom-up
approach to estimate individual costs
145
Types of Costs in Projects
Direct costs: resource costs, including expediting
costs. These vary with task duration.
Material costs: reflect the cost of acquiring
materials needed to complete work. These vary
with project scope.
Overhead costs: administrative costs allocated to
support the project, and usually not attributable
to any specific task. These vary with project
duration.
Performance costs / bonuses: vary with project
duration, or sometimes with performance relative
to milestones, depending on the contract.
146
Project Budget Example
ES A = 0
LF A = 14
Task A
14 wks
ES START = 0
LF START = 0
ES B = 0
LF B = 14
START
Task B
9 wks
ES C = 0
LF C = 29
ES F = 26
LF F = 35
ES D = 14
LF D = 26
Task F
9 wks
Task D
12 wks
ES END = 35
LF END = 35
END
ES E = 26
LF E = 35
Task E
6 wks
Task C
20 wks
147
Project Budget Example
Cost for Resource A worker = $400/week
Cost for Resource B worker = $600/week
148
Project Budget Example
Early Start Times
Tas k
1
A
1140
B
8925
C
9600
D
E
F
2
3
4
800
8800
9600
800
8800
9600
800
8800
9600
800
8800
9600
800
8800
9600
800
8800
9600
800
8800
9600
800
8800
9600
19665
19665
19200
38865
19200
58065
19200
77265
19200
96465
19200
115665
19200
134865
19200
154065
19200
173265
Wee kly Su btotals
Cumul ative
5
6
7
8
9
10
11
12
800
800
800
9600
9600
9600
10400
183665
10400
194065
10400
204465
Late Start Times
Tas k
A
B
C
D
E
F
Wee kly Su btotals
Cumul ative
1
2
3
4
5
6
7
8
1140
800
800
800
800
8925
800
8800
800
8800
800
8800
1140
1140
800
1940
800
2740
800
3540
9725
13265
9600
22865
9600
32465
9600
42065
9
10
11
12
800
8800
9600
800
8800
9600
800
8800
9600
800
8800
9600
19200
61265
19200
80465
19200
99665
19200
118865
The total duration is 35 weeks
149
Weekly Costs (Cash Flows)
Example 2 from Chapter 4
150
Cumulative Costs
1
3
5
7
9
11 13 15 17 19 21 23 25 27 29 31 33
151
Cash Flow Management
Need to manage both payments and receipts
It is usually better to pay as late and receive
as early as possible
Must consider budget constraints and
organizational requirements on projects
(e.g., payback period)
Noncritical activities may have flexibility in
their start times that affects cash flow and
NPV
Frequently, there is a tradeoff between cash
flow (prefer LS schedule) and completion
152
time reliability (prefer ES schedule)
Cash Flow Example
Make payment of
$5000
M1
Task A
2 mos
Task D
8 mos
Receive payment
of $3000
Task C
4 mos
START
END
Task B
8 mos
Task E
3 mos
M2
Receive payment
of $3000
153
Cash Flow Example: Solver Model
Objective: Maximize NPV
C
D
E
F
10
11
12
13
14
15
16
17
18
19
F19=F13+F15+F18
See cashflow analysis.xls on the CD
154
Material Management Example
LS A = 0
Task A
4 wks
LS B = 4
Task B
8 wks
LS C = 12
Task C
5 wks
2 units
Start
LS D = 6
LS E = 12
LS F = 14
Task D
6 wks
Task E
2 wks
Task F
3 wks
LSEND=17
End
30 units
A total of 32 units of resource must be acquired.
What is the best ordering policy?
155
Material Management Example
Main Issue: How much to order, and
when?
In the example:
Single material is needed for Task B (2 units) and
Task E (30 units)
Fixed cost (including delivery) to place order =
$300
Cost of holding raw materials is $2 times the
number of unit-weeks in stock
Cost of holding finished product is greater than
the cost of holding raw material, because of value
added
Project can be delayed (beyond 17 weeks) at cost
of $P per week, where $P > 30 x $2
156
Material Management Example
• To minimize holding costs, only place orders at Latest Start times
• Can never reduce total costs by delaying the project
Time
1
2
3
Demand:
4
5
6
7
8
9
10
11
2
12
30
Order option #1: 32
Order option #2:
2
30
Choose the option that minimizes inventory cost =
order cost + holding cost of raw materials
157
Material Management Example
Fixed cost to place order:
$300/order
Cost of holding raw material:
$2/unit/week
Cost of option #1:
$300*1+$2*30*8=$780
Cost of option #2: $300*2=$600
158
Time / Cost Tradeoffs
Crashing: investing in additional resources
(and usually incurring additional cost) in
order to reduce individual task durations and
therefore also overall project duration.
What are some methods for crashing?
Some practical models:
minimize total of overhead, indirect, direct
and penalty costs
minimize project duration subject to a budget
for direct cost.
159
Time / Cost Tradeoff Example
7 wks
15 wks
A
Critical path with
makespan 22
C
Start
End
B
D
6 wks
Task
Normal
Duration
A
B
C
D
7
6
15
10
10 wks
Marginal Cost
to Crash One
Normal Cost
Week
$60
$85
$55
$120
$8
$5
$10
$4
Assume constant
marginal crash cost,
i.e. linear cost of
crashing
Assume task C cannot be crashed below 13 weeks
160
Time / Cost Tradeoff Example
Project
Duration
(weeks)
As we
reduce
the
project
duration,
we need
to keep
track of
the
lengths of
all paths
Total Direct
Critical Path(s)
22
Start-A-C-End
21
Start-A-C-End
Task(s) Reduced
Cost
A
$320
C
$338
C
$348
A, B
$361
$328
Start-B-C-End
20
Start-A-C-End
Start-B-C-End
19
Start-A-C-End
Start-B-C-End
18
Start-A-C-End
Start-B-C-End
This “crashing” procedure is a heuristic ---- it does not
always find the cheapest sequence of reductions
161
Linear Time / Cost Tradeoff
Even where the duration of a task can be reduced by assigning
additional resources to it, in practice there is always a lower
limit on task duration.
Cost
Crash
point
Crash
cost = Ccj
Slope (bj) = increase in cost
from reducing task duration by
one time unit
Normal
point
Normal
cost = CN
j
c
Crash time = tj
Normal time
N
= tj
Time
162
Time / Cost Tradeoff Using LP
Assume marginal cost of crashing task j is bj = (CjC-CjN)/(tjN-tjC) > 0
Decision Variables:
Sj = starting time of task j
END = end time of project
tj = duration of task j
The following model allows us to minimize the total direct cost
required to complete the project by time Tmax
Minimize total direct cost =
b
j
tj
j
s.t. Sj ≥ Si + ti, for all tasks i that immediately precede job j
tjC ≤ tj ≤ tjN, for all tasks in the project
END ≥ Sj + tj, for all tasks in the project
END ≤ Tmax
tj , Sj ≥ 0, for all tasks in the project
163
Minimizing Total Cost
Cost
Total cost
Here we assume
that overhead
costs are
proportional to
project duration.
Overhead
costs
Direct
costs
Crash time
Minimum cost
solution
Normal time
Project
duration
164
Minimizing Total Cost
The following model allows us to minimize
the total of direct and indirect costs
Minimize total costs b j t j I ( END)
j
where
I = indirect (overhead) cost/time period
The constraints are the same as in the
previous model, except the upper limit
on END is deleted.
165
Chapter
Planning with Uncertainty
The Effects of Uncertainty
The most obvious effect is that uncertainty in a task
duration causes late completion of that task.
Depending on the criticality of that task, this may delay
overall project completion.
Effective planning can reduce uncertainty or mitigate its
effects.
The more uncertain a task when it is initiated, the more
monitoring and control are needed to ensure effective
performance.
There are three additional mechanisms by which
uncertainty interacts with project management practice
to create problems.
167
Uncertain Task Durations
It is widely assumed that, in many projects, task
durations follow the beta distribution shown below
Probability density
function
Completion time of task j
Time
Optimistic time, tjo
Most likely time, tjm
Expected time, m
Pessimistic time, tjp
168
Standard Approximations for
Task Durations
For each task, we need three estimates:
o
most optimistic time, t
most pessimistic time,
m
most likely time, t
tp
In practice,
how easy is it
to estimate
these?
t o t p 4t m
Expected duration m
6
p
o
t t
Standard deviation
6
These formulas are designed to approximate (simply, but
169
not very accurately) the beta distribution.
More Accurate Approximations
The approximations on the previous page are
most commonly used in practice, because
they are oldest and simplest. However, the
approximations of Perry and Grieg (1975)
shown below are more accurate.
t95 t5 .95t m
m
2.85
t95 t5
3.25
Note that these approximations require the
estimation of slightly different data, which
could be easier (or harder) to estimate.
170
Three Mechanisms by which
Uncertainty Creates Problems
1. Parkinson’s Law
2. Procratinasting Workers
3. Schonberger’s Hypothesis
171
Mechanism 1: Parkinson’s Law
Consider a project with two tasks in series, where the
duration of each task is described by a random variable
with value Ti, i = 1, 2
E(T1)
E(T2)
So the expected makespan is 24
16.0
172
Example of Parkinson’s Law
“Work expands so as to fill the time
available for its completion”
C.N. Parkinson (1957)
Set a deadline D = 24 days
So T(D) = project makespan (function of D) where
E[T(D)] = E(T1) + E(T2) + E[max(0, D - T1 - T2)]
Values
Values of
of T
T11
7
7
8
8
9
9
Prob
0.3
0.3
0.4
0.4
0.3
0.3
Values
Values of
ofTT22
14
18
14
18
14
18
E[T(D)] = 25 days
Prob
0.5
0.5
0.5
0.5
0.5
0.5
Project
Makespan
24 *
25
24 *
26
24 *
27
Prob
0.15
0.15
0.2
0.2
0.15
0.15
*makespan expanded
to fit deadline
173
Mechanism 2: Procrastinating
Workers
A procrastinating worker waits until the last possible time to
start (given the expected duration of their task).
Set a deadline D = 24 days
E’[T(D)] = E(T1) + E(T2) + E{max[0, D - T1 - E(T2)]}
Values of T 1
7
8
9
Prob
0.3
0.4
0.3
8
E[Delay] =
max[0, D - T 1 - E(T2)]
E[Makespan]
1
0
0
0.3
24 *
24
25
24.30
* Delayed by
procrastinating
worker, who
starts tasks 1
day later.
We can show that E[T(D)] ≥ E’[T(D)] ≥ D.
What are some possible solutions?
Provide incentives for early completion, set tight deadlines
However, unreasonably tight deadlines may have other
negative effects (stress, loss of quality, turnover,…)
174
Mechanism 3: Schonberger’s Hypothesis
An increase in the variability of
task durations will increase the
expected project duration….
This is true even if the
expected task durations do
not change.
175
Example of Schonberger’s
Hypothesis
The longest expected path length = 14
176
Example of Schonberger’s
Hypothesis
Realization
1
2
3
4
5
6
Task A
Duration
12
14
16
12
14
16
Task B
Duration
10
10
10
15
15
15
Probability
0.05
0.4
0.05
0.05
0.4
0.05
Max (A, B)
12
14
16
15
15
16
Expected duration equals 14.55 days
This is an
enumeration
of all
possible
events.
Increasing the variance of Task A:
Duration of
Task A
12
14
16
14.0
Probability
0.3
0.4
0.3
Duration of
Task B
Probability
10
15
0.5
0.5
12.5
Now, the expected duration = 14.65 days
177
Program Evaluation and Review Technique
Traditional Model of Uncertainty PERT
Task times are assumed to be random variables
Assume all task times are statistically independent
(when is this realistic?)
Use values of mj, the expected time of task j, to identify
the expected critical path
The time of any event (e.g., ESk) is now the sum of
independent random variables. So the Central Limit
Theorem says that ESk is approximately normally
distributed with mean E[ESk] and variance Var[ESk]
Expected early start time of task
k E[ ESk ] max {
S
m
j
task j on path S
},
where S is a path from the start of the project to task k.
178
PERT Model
Thus, we have several results:
Expected project duration:
Variance of project duration:
E[ ES END ]
m
j
task j on critical path
Var[ ES END ]
2
j
task j on critical path
Using Central Limit Theorem and standard normal distribution:
Pr( ES END
T
E
[
ES
]
max
END
Tmax ) Pr z
Var
[
ES
]
END
Look up the
result in the
z table
Also: given on time completion probability, we can find Tmax.
179
PERT Example 1
(2+14+4×6)/6
(14-2)^2 / 36
180
PERT Example 1
Var(A)+Var(C)
=4.00+3.36
(15-14.5)/Sqrt(7.36)
E(A)+E(C)=
6.67+7.83
Pr(z≤Zi)
PERT expected duration =
PERT variance =
See PERT example 1.xls
181
PERT Example 1
Path
Expected
Duration
START-A-B-E- 23.33
F-END
START-A-C-E- 23.83
F-END
START-A-D21.00
END
Variance
6.67
8.25
5.00
PERT assumes that the path with the longest
expected duration will still be the critical path when
all the activity durations are known.
182
Problems with the PERT Model
Difficult to estimate the most optimistic,
most pessimistic and most likely times
The assumption that task times are
probabilistically independent
Poor approximations when using the Central
Limit Theorem for small projects
The assumption that the path with the
longest expected length is still critical at
realization
As a result of the last problem above, PERT
estimates are systematically too optimistic
183
PERT Example 2
Task A
mA= 4
2A= 2
Task C
mC= 10
2
C= 5
END
START
Task B
Task D
mB= 12
2
B= 4
mD= 3
2
D= 1
Expected makespan=12 + 3 = 15
Variance of makespan = 4 + 1 = 5
184
PERT Example 2
START->B->D->END
E[ESEND]=15 and
Var[ESEND]=5
Pr([ESEND]≤17)=Pr(z
Classic
PERT
≤(17-15)/√5)=0.81 estimate
START->A->C->END
E[ESEND]=14 and Var[ESEND]=7
Pr([ESEND]≤17)=Pr(z ≤(17-14)/√7)=0.872
There are only two paths with no tasks in common,
therefore the probability that the task is completed in
17 days (assuming independence) is in fact:
0.81*0.872=0.706
Thus, classic PERT overestimates the
probability of completion on time (i.e.,
is too optimistic)
185
Example 3: Discrete Probabilities
Task A
(8.0)
Task D
(9.3)
Task B
(10.0)
START
END
Task C
(19.0)
Task A
μj
Task B
Task C
Task D
Value
Prob
Value
Prob
Value
Prob
Value
Prob
7
0.333
2
0.2
5
0.2
3
0.3
8
0.333
12
0.8
15
0.2
12
0.7
9
0.333
25
0.6
8
10
19
9.3
Expected project duration from PERT = 19.3 weeks.
186
Example 3
This is an enumeration of all possible 36
combinations of events.
Probabilities of paths
being critical
187
Example 3
Length of CP's
10
11
12
15
19
20
21
24
25
Prob.
0.004
0.004
0.004
0.108
0.019
0.019
0.019
0.224
0.599
Cumulative Prob.
0.004
0.008
0.012
0.120
0.139
0.158
0.177
0.401
1.000
Since the
analysis
enumerates all
events, these
probabilities are
exact.
Criticality Indices (probability of each task being critical):
Task A
Task B
Task C
Task D
6.8%
32.0%
61.1%
38.8%
Expected Project Duration = 23.22 >> 19.3
188
Calculating Confidence Intervals
To calculate a confidence interval, we can use the sample
mean and the estimated standard error of the mean.
Using a normal approximation, a (1- a) twosided confidence interval is given by:
X za / 2 s X
SX S
n
Example: X =27.65, s=4.25, and n=200 trials,
where s is the sample standard deviation and n is
the number of trials.
Project Makespan
Lower Limit
Upper Limit
95% confidence interval
27.07
28.24
27.65±(1.96)(4.25)/√200=27.65±0.59
99% confidence interval
26.88
28.43
27.65±(2.56)(4.25)/√200=27.65±0.77
189
Monte Carlo Simulation
(PERT Example 1) Beta Distribution
Task Duration
Criticality
index for
task B
Recall that PERT expected
duration = 23.83 (i.e.,
much too optimistic)
See PERT example 1.xls
Project Makespan
95% Confidence interval
99% Confidence interval
Lower Limit
26.56
26.37
Upper Limit
27.72
27.90
95%: 27.14±(1.96)(4.095)/√200=27.14±0.58
99%: 27.14±(2.56)(4.095)/√200=27.14±0.76
190
Fixing PERT’s Problems
PERT is still quite widely used in practice
It is easier to use, and possibly more
intuitive, than simulation
PERT estimates can be adjusted to make
them less optimistic and more realistic. The
problem with doing this is knowing by how
much to adjust them.
Alternatively, PERT can be run using more
than one critical path. The problems with
doing this are (a) project networks have
many paths, and (b) their lengths are not
independent if they have tasks in common
which is frequently the case.
191
Critical Chain Project Management
Background
A modern approach to dealing with
uncertainty in project management (an
alternative to PERT)
Developed by Goldratt (1997) to apply
concepts from the “Theory of Constraints”
to project management
The fundamental principle is to identify and
protect the only thing that is critical – the
overall project completion time
192
Critical Chain Project Management
Critique of Traditional Project Management
When individual tasks have slack built into them to deal
with uncertainty, this slack proliferates and Parkinson’s
Law applies.
The proliferation of slack is due to:
- poorly aligned incentives, sandbagging
- need to allow for urgent external distractions
- conservative use of statistics
- assumption that all tasks may take longer than
expected
As a result, projects routinely (a) take longer than
necessary to complete and (b) fail to meet due dates.
193
Critical Chain Project Management
Eight Principles
1. Build the project schedule without safety time, i.e. use
50th percentile estimates of task durations.
2. Drop the notion of due dates and accept the possibility of
delays.
3. Identify and protect critical resources (and don’t worry so
much about noncritical resources).
4. Aggregate all the required safety time in a project buffer
at the end of the critical path.
194
Critical Chain Project Management
Eight Principles (cont.)
5. For the critical resources, identify their lead (i.e., startup)
times. This information defines resource buffers.
6. Fast and slow completion of tasks will tend to cancel out,
at least in part, enabling a reduction (possibly better than
50%) in the project buffer size.
7. For noncritical activities, the only priority occurs where
they feed into the critical chain. Protect these points with
feeding buffers.
8. The project is controlled by buffer management, instead
of due dates. Monitor the amount of time remaining in
buffers, and if necessary trigger contingency plans.
See coursepack article: Patrick (1998).
195
Critical Chain Buffers
1
1
1
End
2 days
Task C2 2
5 days
1 day
2
Project
buffer
2
196
Calculating Project Buffer Size
For those “who want a scientific approach to sizing
buffers....”
For task k on the critical chain, we can calculate the
required project buffer using the following formula,
assuming that the project will be completed within
worst-case duration estimates around 90% of the
p
time, and t k is the most pessimistic estimate of task Like
PERT,
k’s duration:
p
2
(
t
m
)
k k
buffer
task k on critical chain
uses only
longest
path
For example 1, the buffer is:
Sqrt[(14-6.67)2+(13-7.85)2+(7-5.00)2+(7-4.33)2]=9.51
197
Critical Chain Project Management
Critique of CCPM
1. Overestimation of task durations, and application of
Parkinson’s Law, are not widespread problems. Some
empirical studies support this view.
2. Shortening deadlines reduces task managers’
motivation.
3. There is no scientific basis for setting buffer sizes.
4. It is not clear how much of a feeding buffer to allocate to
different successor tasks when there is more than one.
198
Critical Chain Project Management
Critique of CCPM (cont.)
5. Buffer calculations based on resource leveling output may
be inaccurate, since this is a hard problem to solve.
6. What if the critical chain changes during the execution
phase?
7. Buffers tend to clutter up Gantt charts and create
confusion.
8. Resource buffer information obtained from outside
contractors may not be reliable (especially if they are
unusually busy).
See coursepack article: Raz et al. (2003)
199
Chapter
Risk Management
Introduction to Risk Management
Risk management is the practice of dealing
with risk, which includes:
Planning for risk
Assessing risk issues
Developing risk handling strategies
Monitoring risk
Risk management should be consistent
with: overall project management, systems
engineering, cost, scope, quality and
schedule
Risk management is often more effective
and cheaper when proactive rather than
reactive
201
Factors in Managing Risk
Amount and quality of information
about the actual hazards that cause
the risk
Amount and quality of information on
the magnitude of the damage
Length of exposure to the risk
Avoidability of the risk
The existence of cost-effective
alternatives to accepting risk
202
Information Sources for Risk
Analysis
Studies of similar projects and their
risks
Results from tests and prototype
development
Data from engineering or other
models
Specialist and expert judgments
Sensitivity analysis of alternatives
203
Tools for Assessing Risk
Tornado Diagram represents a sensitivity
analysis of the input variables
Tornado Diagrams are calculated by
varying one factor at a time while holding
all other input variables constant
Sensitivity Chart considers changes in all
input variables simultaneously
We can use a random number generator to
set the value of each input variable in a
sensitivity chart
204
Tornado Diagram
Project Cost ($000’s)
Rank by largest cost
range on top
205
Sensitivity Chart
Wage Rate
Direct Labor Hours
Material Units Needed
Early Completion Bonus
Material Unit Costs
Interest Rates
Energy Costs
Overhead
Rank by correlation with total project cost, largest
absolute value on top
206
Simple Risk Analysis
Risk Exposure (RE) or Risk Impact =
(probability of unexpected loss)
x (size of loss)
Example: Additional features specified by
new client request
Loss: 3 weeks
Probability: 20 percent
Risk Exposure = (.20) (3 weeks)
= .6 week
What are the limitations of this analysis?
207
Risk Management Actions
Preventive Actions: what to do in
anticipation of an adverse event, to
reduce the probability of the
undesirable event occurring or to
mitigate its effect
May require action before the project
actually begins
Costs of preventive actions may
be small, relative to project value
208
Risk Management Actions (cont.)
Contingency Planning: what to do if
an undesirable event occurs
“Trigger point” based on performance
invokes the contingency plan
Frequently involves substantial
additional costs
209
Managing Risk in Contracts
Fixed price contract - commonly used
when it is easy to estimate material
and labor cost accurately
Cost plus contract – typically used
when accurate estimation of costs is
difficult, may include a cost ceiling
Units contract – client agrees to a fixed
price per unit (within a specified range
for the number of units)
210
Managing Risk in Contracts
General Form:
Payment to Subcontractor = Fixed Fee + (1 - B) (Project Cost),
where B = cost sharing rate
Cost Plus Contract
B=0
Client’s Risk
Fixed Price Contract
Risk Continuum
B=1
Subcontractor’s
Risk
211
Insuring against Risk
Direct property damage: includes insurance
for assets, project materials, equipment,
and properties
Indirect consequential loss: includes
protection for contractors for indirect losses
due to third party actions
Legal liability: protection from legal liability
resulting from poor product design, product
liability, and project performance failure
Personnel: protection resulting from
employee bodily injury, loss of key
employees, replacement cost of key
employees
212
Risk Management Strategies: Overview
4 Types of Strategies
Control (within manager’s control)
Ex: schedule, budget, documentation
Negotiation (partly within manager’s control)
Ex: soft issues, interactions, relationships
Research (further information required)
Ex: undetermined technology and scope risks
Monitoring (wait and see what happens)
Ex: risks to business or market environment
H. Taylor, Project Management Journal, 2006
213
Risk Management Strategies: Control
Best Control Strategies
Perform detailed analysis of work
breakdown structures
Closely monitor each task’s progress
Design contracts to control scope
change
Respond to schedule problems initially
by increasing overtime
Reschedule the remaining tasks
following a delay
214
Risk Management Strategies:
Negotiation
Best Negotiation Strategies
Control scope changes through a detailed
assessment of client needs
Perform trust- and relationship-building
activities
Manage client’s expectations
Balance cost, schedule and scope
Perform team-building activities within the
project team
As a last resort, escalate problems to the
client’s executive
215
Risk Management Strategies:
Research
Best Research Strategies
New technology risk is not viewed as
threatening, because project staff find it
interesting to work on
Avoid customization if possible
Avoid negotiation with internal
developers
Take no explicit actions (and just
monitor the project)
216
Risk Management Strategies:
Monitoring
Best Monitoring Strategies
Maintain situation awareness using constant
surveillance
Apply triggers to initiate more intense
monitoring when needed (such as when
dealing with external contractors)
Delay any decisions about how to respond to
a problem until the problem materializes
217
Risk Management Example: Van
Allen Company
The Van Allen Construction Company
is hoping to sign a contract in the
next few months for demolition work
for a new soccer stadium
Indirect and overhead charges will
cost approximately $1,200 per week
The demolition project consists of
nine tasks, with crash times, crash
costs, normal times and normal costs
218
Van Allen Company: Tasks
219
Van Allen Company: Strike
•
•
•
•
•
The project manager has become aware that
workers may strike during the demolition project
The probability of a strike is 60-80%
It is equally likely that the strike will start at any
time
At most one strike will occur
If a strike occurs, its duration has the following
probability distribution
220
Van Allen Company: Question
How should the company manage
the risk of a strike?
Should the company take any
preventive actions or plan any
contingency actions? If so, what?
221
Van Allen Company: Preventive
Actions
Negotiate directly with the workers involved
to reduce the likelihood of a strike
Write the project contract so that the client
assumes any losses resulting from a strike
Purchase an insurance policy to cover any
financial losses incurred by a strike
Compress the project beyond the time that
minimizes total project costs, to increase
the probability of completing the project
before a strike hits
222
Van Allen Company: Contingency
Actions
Hire non-union labor
Assign Van Allen managers to work
on the project to replace any
striking workers
Suspend the project until the strike
is over
223
Van Allen Company: Minimum Cost
Solution (No Strike Considered)
Task
Duration
Immediate
Predecessors
Starting
Times
START
0
-
0
0
A
5
START
0
5
3
60
5
40
10
0
B
1
START
0
1
1
50
5
30
5
20
C
6
B
1
7
5
70
10
40
6
24
D
2
A
5
7
2
60
7
40
4
20
E
6
A
6
12
2
50
6
30
5
0
F
10
C, D
7
17
5
90
11
60
5
5
G
6
C, D
7
13
4
60
6
30
15
0
H
4
G
13
17
1
40
5
20
5
5
I
4
E, G
13
17
1
50
4
20
10
0
END
0
F, I, H
17
17
Totals
Indirect cost=$12*17 days=204
Total cost=$310+$70+$204=$588
Finish
Times
Crash
Time
Crash
Cost
(100$)
530
Normal
Time
Normal
Cost
(100$)
Slope
(100$)
Marginal
Cost Incr
(100$)
310
74
Slope=(crash cost – normal cost)/(normal time – crash time)
224
Van Allen Company: Minimum
Cost Solution (Strike Considered)
Task
Duration
START
0
-
0
0
A
5
START
0
5
3
60
5
40
10
0
B
1
START
0
1
1
50
5
30
5
20
C
6
B
1
7
5
70
10
40
6
24
D
2
A
5
7
2
60
7
40
4
20
E
6
A
6
12
2
50
6
30
5
0
F
10
C, D
7
17
5
90
11
60
5
5
G
6
C, D
7
13
4
60
6
30
15
0
H
4
G
13
17
1
40
5
20
5
5
I
4
E, G
13
17
1
50
4
20
10
0
END
0
F, I, H
17
17
Totals
Immediate
Predecessors
Starting
Times
Finish
Times
Crash
Time
Crash
Cost
(100$)
Normal
Time
530
The same table as the previous page.
Total expected cost: $588 + $12*3.8*0.7=$619.92
Normal
Cost
(100$)
Slope
(100$)
Marginal
Cost Incr
(100$)
310
74
225
Van Allen Company: Insights
The possibility of a strike has only added a
constant to the total cost
Therefore, the tradeoff involved in the
crashing decisions is unchanged by the
possibility of a strike
Since the marginal cost for additional
crashing is $16 and the marginal indirect
cost is $12, it is not worthwhile to crash the
project further, even if the probability of a
strike is 1
However, if there were a penalty for late
completion of the project, then this
conclusion might change
226
Chapter
Resource
Management
Introduction to Resource Management
Resources should be chosen for maximum flexibility,
e.g. flexibility of amount, flexibility of available date
Up to a certain point, the more of a particular resource
is used, the less expensive it is per period or per unit,
due to economies of scale
In many situations, the marginal contribution of a
resource decreases with usage
Resources are organizational assets, so using them
may have implications elsewhere (“opportunity cost”)
The organization has better control over its own
resources than those which are borrowed or leased
228
Resource Leveling and Allocation
Resource Leveling: Reschedule the noncritical
tasks to smooth resource requirements over
time (without increasing project duration)
Resource Allocation: Minimize project time or
cost objective subject to meeting resource
availability constraints
Both the above problems (especially resource
allocation) are difficult to solve, so for large
projects we are not able to find optimal
solutions (using either MS Project or Excel)
But some good heuristic priority approaches
help make better decisions
229
Resource Leveling and Allocation
Three types of resources:
Renewable resources: “renew”
themselves at the beginning of each
time period (e.g., workers)
Non-Renewable resources: can be
used at any rate but constrained on
total amount used over time (e.g., a
budget limit)
Doubly constrained resources:
both renewable and non-renewable
(e.g., money under both total budget
and unit cost constraints)
230
Resource Leveling Example
Duration tj
231
Resource Leveling Example:
Early Start Schedule
F
F
B
A
B
A
E
E
E
D
D
D
D
D
G
G
C
C
G
G
A
C
C
C
C
C
The maximum number of workers needed is 21.
C
C
G
232
Resource Leveling Example:
Late Start Schedule
E
D
A
A
A
D
D
E
D
E
B
C
C
G
D
C
B
G
C
G
G
G
F
F
C
C
C
C
C
Now the maximum number of workers needed is only 16.
233
Resource Leveling
Discussion
Can the maximum number of workers needed be
reduced below 16 without increasing the project
duration above 13 weeks?
The schedule of tasks A, D, and G cannot be changed,
because they are critical
If task E starts in week 5 or earlier, then tasks C, D and
E are all performed during week 5; alternatively, if task
E starts in week 6 at its LS time, then tasks C, D and E
are all performed during weeks 6, 7 and 8
Therefore, if the project is not to be delayed, at least
2+10+4=16 workers are needed
It follows that Late Start is optimal for this example.
But this is not true for all examples.
For practical size problems, heuristics such as Late
Start are often used (because optimal solutions are
hard to find).
234
Renewable Resource Allocation
Example 1 (Single Resource Type)
3 workers
6 workers
Task A
4 wks
Task C
1 wk
Task E
4 wks
START
Task B
3 wks
Task D
5 wks
5 workers
8 workers
END
7 workers
Makespan: 12 weeks
Maximum number of workers available = R = 9
Resource allocation question: Is this schedule feasible?
235
Resource Allocation
Questions for Example 1
Can the project be completed within
12 weeks using no more than 9
workers?
If not, how many more workers will
be needed to meet the 12 week
deadline?
If the manager cannot hire more
than 9 workers, what is the
minimum delay beyond 12 weeks?
236
Resource Allocation Example 1:
Early Start Schedule
Maximum number of workers available = R = 9 workers
Worker-weeks needed = 12+15+6+40+28 = 101
Minimum “wasted” worker-weeks at start of project = 3
237
Wasted Worker-Weeks
from Early Start Schedule
Let rE(t) denote the number of
workers needed in time period t by
the early start schedule
Let TE=smallest value of t such that
rE(t)>R. In the example, TE=4
For each value of t=1,…, TE-1, the
number of wasted worker-weeks is
equal to R-rE(t)
Sum the wasted worker-weeks,
which are 3 in this example
238
Resource Allocation Example 1:
Late Start Schedule
Maximum number of workers available = R = 9 workers
Minimum “wasted” worker-weeks at end of project = 8
239
Wasted Worker-Weeks
from Late Start Schedule
Let rL(t) denote the number of
workers needed in time period t by
the late start schedule
Let TL=largest value of t such that
rL(t)>R. In the example, TL=8
For each value of t=D,D-1,…,TL+1,
find R-rL(t), where D is the
minimum makespan without
resource constraints
Sum the wasted worker-weeks,
which are 8 in this example
240
Solution to Example 1
Altogether, 9*12=108 worker-weeks are
available
At least 3+8=11 worker-weeks are wasted at
the start and end of any schedule
The number of useable worker-weeks = 10811 = 97, which is less than the 101 required
worker-weeks, so 9 workers cannot finish
within 12 weeks
At least 101+11 = 112 worker-weeks are
required to finish the project, so at least
112/9 = 12.44 -> 13 weeks are needed to
complete the project using 9 workers
At least 112/12 = 9.33 -> 10 workers are
needed to complete the project in 12 weeks
241
Resource Leveling / Allocation
Heuristics
Heuristics are simple rules of thumb for prioritizing
tasks in resource leveling and resource allocation
problems, and can be implemented in MS Project.
Here are some heuristics for assigning priorities to
available task j, where R kj denotes the number of
units of resource k used by task j.
FCFS: First available task
GRD: Largest resource utilization
k
max
R
j t j
× task duration = k
GTS: Largest total number of successors
242
Resource Leveling / Allocation
Heuristics (cont.)
• SPT: Shortest processing time = min {tj}
• MINSLK: Minimum total slack
• LFS: Minimum total slack per successor
• ACTIMj: Longest path from task j to end of project
243
Resource Allocation Example 2
244
How to Schedule Tasks to
Minimize Project Duration
Heuristic priority rule: schedule tasks using
minimum total slack (i.e., tasks with smaller total
slack have higher priority)
Task A1
GC
PC
1
2
3
4
Task C1
Task B1
5
6
7
8
9 10 11 12 13 14 15 16 17 18 19 20
Task A2
1
2
3
4
5
6
7
8
Task B2
Task C2
9 10 11 12 13 14 15 16 17 18 19 20
Makespan=20
245
Minimizing Project Duration
But, can we do better? Is there a
better priority rule?
Shortest Processing Time (SPT):
C1
GC
PC
1
B1
2
3
4
A1
5
6
7
8
9
C2
1
2
3
4
5
10
11
12
13
B2
6
7
8
9
10
14
15
16
17
18
19
20
16
17
18
19
20
A2
11
12
13
14
15
Now the makespan is reduced to 16.
Which heuristic works better depends on the
project data.
246
Microsoft Project Solution
(Resource Leveling Option)
A1
A2
B1
B2
C1
C2
Makespan=17 days (excluding weekends), but we
know from the previous page that 16 days is possible!
Solution by: Microsoft Project
247
Non-Renewable Resources
Nonrenewable
resources are
delivered to
the project
over time. At
any time, we
cannot have
used more
than the total
resources
delivered so
far.
Task
A
B
C
D
Duration
6
5
3
2
No. of Nonrenewable
Resources Units
Needed
6
12
10
8
Early Start
0
6
6
11
Late Start
0
6
8
11
248
Non-Renewable Resources:
Comparing Solutions
Cumulative
resources supplied
(given)
Cumulative
resources required
(using LS times)
Cumulative
resources required
(using ES times)
Using LS times always works
best, since they allow the
most time for resources to be
delivered.
Weeks
249
Teaming Problem
Question: When is it better to “team”
two or more workers versus letting
them work separately?
Example
We have 2 workers, Bob and Barb, and 4
tasks: A,B,C,D
Bob and Barb can work as a team, or they
can work separately
If they work as a team, tasks take only half
as long
How should Bob and Barb be assigned to
the tasks?
250
Teaming Example
A
C
Start
End
B
D
Configuration 1: Bob and Barb work jointly on
all four tasks; they complete each task in onehalf the time needed if either did the tasks
individually.
Configuration 2: Bob and Barb work
independently. Bob is assigned to tasks A
and C; Barb is assigned to tasks B and D.
251
Teaming Example
TASK A
Duration
6
5
4
Expected
duration
Prob
0.33
0.33
0.33
5.0
TASK B
Duration
9
6
Prob
0.667
0.333
TASK C
Duration
12
7
8.0
Prob
0.6
0.4
10.0
TASK D
Duration
10
6
Prob
0.25
0.75
7.0
Configuration 1
Bob and Barb work jointly on all four tasks.
What is the expected project makespan?
Jointly completing A, then B, then
C, then D requires time 5+8+10+7
= 30 -> 30/2 = 15, because they
work twice as fast as a pair
252
Teaming Example
Bob and Barb work independently. Bob is assigned
to tasks A and C; Barb is assigned to tasks B and D
This is an enumeration of all possible events
253
Teaming Example
Bob and Barb work independently. Bob is assigned
to tasks A and C; Barb is assigned to tasks B and D
max (A+C,
B+D)
12
13
15
16
17
18
19
Prob
0.07
0.03
0.20
0.20
0.17
0.17
0.17
Cumulative
Prob
0.07
0.10
0.30
0.50
0.67
0.83
1.00
Expected Project Makespan: 16.42
This is larger than the expected “team makespan” of 15
Because of the randomness in the task completion times, it
hurts to “parallelize” the project and “teaming” works better
254
Chapter
Monitoring and Control
Control Systems
Formal systems: accounting, periodic
status reports, scheduled milestone
meetings, internal audits, client
reviews, and external benchmarks
Informal systems: meetings, e-mail,
and just walking around and asking
project team members questions
256
Control System Issues
How frequently should performance
data be collected, and from what
sources?
Which performance metrics should be
used?
How should data be analyzed to
detect current and future deviations?
How frequently, and to whom, should
the results of the analysis be reported?
See coursepack article: Royer
257
Controlling Projects
Key decisions in controlling performance
in project management:
What is the optimal review frequency?
What are appropriate acceptance levels at
each review stage?
“Both over-managed and under-managed
development processes result in lengthy design
lead time and high development costs.”
R.H. Ahmadi, R. Wang. 1999. Managing
Development Risk in Product Design Processes.
Operations Research 47, 235-246
See coursepack article: Staw and Ross
258
Types of System Variation
Common cause variation: “incontrol” or normal variation
Special cause variation: variation
caused by forces that are outside
the system
Treating common cause variation as if it
were special cause variation is called
“tampering”
Tampering always degrades the
performance of a system – W.E. Deming
259
Control System Example 1
Week 2: Task expenses = 460 worker-hours
Planned Cost
Week
(BCWS)
1
400
2
400
470
Actual Cost
420
460
Actual
460
Cost (in worker-hours)
Cumulative
Actual Cost
(ACWP)
420
880
450
440
430
420
Planned
410
400
390
Is the task
“out of
control”?
380
370
1
2
3
4
Week
260
Control System Example 1
Week 3: Task expenses = 500 worker-hrs
Week
Planned cost
(worker-hours )
Actual cost
(worker-hours )
Cumulative cos t
(worker-hours )
1
2
3
400
400
400
420
460
500
420
880
1380
600
Actual
Worker-hours
500
400
Planned
300
200
100
0
1
2
3
4
Again, is
the task
“out of
control”?
Week
261
Earned Value Analysis
Integrates cost, schedule, and work
performed
Based on three metrics that are
used as building blocks:
ACWP: Actual cost of work performed
BCWS: Budgeted cost of work
scheduled (Planned Value)
BCWP: Budgeted cost of work
performed (Earned Value)
262
Estimation of BCWP
Estimating BCWP requires the manager to
estimate the proportion of work
completed during each period. This may
be difficult if value accrues mainly at the
end, e.g. software development project.
Fixed rules to estimate BCWP generally
take the form:
X% completed at the start of a task
(1-X)% completed at the end of a task
263
Performance Metrics for Example 1
Week BCWS ACWP Percent of work BCWP
completed
(PWC)
1
400
420
23%
368
2
800
880
50%
800
3
1,200 1,380
85% 1,360
4
1,600 1,500
100% 1,600
264
Schedule Variance (SV)
Schedule Variance (SV)
= difference between value of
work completed and value
of scheduled work
= Earned Value - Planned Value
= BCWP - BCWS
Week
BCWS
ACWP
PWC
BCWP
SV
1
400
420
23%
368
(32)
2
800
880
50%
800
0
3
1,200
1,380
85%
1,360
160
4
1,600
1,500 100%
1,600
0
265
Cost Variance (CV)
Week
Cost Variance (CV)
= difference between value of
work completed and actual
expenditures
= Earned Value - Actual Cost
= BCWP - ACWP
BCWS
ACWP
PWC
BCWP
CV
1
400
420
23%
368
(52)
2
800
880
50%
800
(80)
3
1,200
1,380
85%
1,360
(20)
4
1,600
1,500
100%
1,600
100
266
Total Variance (TV)
Total Variance
=Cost Variance–Schedule Variance
=(BCWP-ACWP)-(BCWP-BCWS)
=BCWS-ACWP
Week
BCWS
ACWP
PWC
BCWP
TV
1
400
420
23%
368
(20)
2
800
880
50%
800
(80)
3
1,200
1,380
85%
1,360
(180)
4
1,600
1,500
100%
1,600
100
267
Time Variance (tV)
Ο
Time Variance
= (BAC * PWC) – Current Time
BAC: Budget at Completion
After week 3
tV =4 * 85% - 3 PWC: Percent of Work Completed
=0.4 (weeks)
Week
BCWS
ACWP
PWC
BCWP
tV
1
400
420
23%
368
(0.08)
2
800
880
50%
800
0
3
1,200
1,380
85%
1,360
0.4
4
1,600
1,500
100%
1,600
0
268
Earned Value Metrics Illustrated
Worker-Hours
Present time
Planned Value
(BCWS)
BAC
Budget at
Completion
Actual Cost
(ACWP)
Cost Variance
(CV)
Earned Value
(BCWP)
Schedule Variance
(SV)
Week 1
Week 2
Week 3
Week 4
Week 5
Week 6
269
Relative Measure: Schedule Index
Schedule Index
(SI ) =
BCWP
BCWS
If SI = 1,
the task is on schedule
If SI > 1,
the task is ahead of schedule
If SI < 1,
the task is behind schedule
270
Relative Measure: Cost Index
Cost Index (CI) =
BCWP
ACWP
o
If CI = 1, then work completed equals
payments
o
If CI > 1, then work completed is ahead
of payments (cost saving)
o
If CI < 1, then work completed is behind
payments (cost overrun)
271
Control System Example 2
cumulative
272
Control System Example 2
Progress report at the end of week #5:
Cumulative Percent of Work
Completed:
Worker-Hours Charged to Project:
273
Control System Example 2
Progress report at the end of week #5:
SV=BCWP-BCWS
CV=BCWP-ACWP
274
Control System Example 2
WorkerHours
275
Using a Fixed 20/80 Rule
Cumulative Percent of Work Completed:
1
Week
Task A 20%
Task B
Task C
2
3
4
5
20%
20%
20%
20%
20%
20%
Assume that 20% of a
task’s work is
completed when it is
started, and 80% when
it is finished
Not started yet
W E E K
Cumulative
Scheduled
Worker-Hrs
(BCWS)
Actual WorkerHrs Used
(ACWP)
Earned Value
(BCWP)
Schedule
Variance (SV)
Cos t Variance
(CV)
1
2
3
4
5
6
7
8
9
10
6
12
18
38
60
82
92
104
116
128
5
11
19
44
64
7.2
7.2
7.2
14.4
14.4
1.2
-4.8
-10.8
-23.6
-45.6
SV=BCWP-BCWS
2.2
-3.8
-11.8
-29.6
-49.6
CV=BCWP-ACWP
276
Using a Fixed 20/80 Rule
WorkerHours
277
Updating Forecasts: Pessimistic
Viewpoint (Example 2)
Assumes that the rate of cost overrun will
continue for the life of the project.
278
Updating Forecasts: Optimistic
Viewpoint (Example 2)
Assumes that no further cost overruns will
occur.
Estimate at Completion (EAC)
= BAC – CV
= 128+11.8
= 139.8 worker hrs
279
Chapter
Managing Multiple Projects
Introduction
Most organizations maintain a portfolio of
projects in order to maximize and level
resource utilization, and to diversify and
minimize organizational risk
Resources are sometimes shared among
projects, so decision making in a multiple
project environment is more complex
than in the case of a single project
Most project management software
packages do not handle multiple projects
effectively
281
Types of Project Portfolios
Task-oriented project portfolios
Independent project portfolios
Interdependent project portfolios
Source: M. Dobson. 1999. The Juggler's Guide
to Managing Multiple Projects. PMI.
282
Task-Oriented Project Portfolios
Establish a project control system –
include priority, time, cost,
deliverables
Keep information on all projects in
one location
Prioritize and re-prioritize projects
Determine available time and
resources
Put projects on your calendar – and
complete them when scheduled
283
Independent Project Portfolios
Distinguish between projects with fixed and
flexible deadlines
Determine and schedule resource
requirements for fixed deadline projects
Make allowance for catch-up time and
special “senior management priority”
projects that arise
Identify resources for the remaining projects
Prioritize and schedule the remaining
projects based on least available resource
first
284
Interdependent Project Portfolios
Define portfolio goals
Use the tools commonly available to plan
projects (WBS, CPM, PERT, etc.)
Establish minimum/maximum performance
standards for each task
Develop methods to monitor progress
Identify tasks that can be done early and
start on them
Identify tasks that are particularly
critical/high risk and create a mechanism to
monitor their progress
Create a schedule of tasks
285
Managing Multiple Projects
A Creative Thinking and Simulation
Game
Comments from Previous
Participants
“It makes the point with a hands-on
experience. Great simulation.”
“It was a great illustration of the impact that
different approaches can have.”
“It really shows off the value of being able to
select the project to work on.”
“Brings decision making / strategic aspect of
project management into reality.”
“I have always multitasked. Now I see that I
may not have been working efficiently.”
“It was great! Wow! It was stimulating.”
287
Outline
Introduction
Priority approach
Multitasking approach
Team–designed approach
Comparison of results
Conclusions
288
Introduction
The management of multiple projects,
especially for different customers, requires
making difficult priority choices
One traditional approach is simply to
prioritize the projects and perform them one
at a time
Another traditional approach is multitasking,
or rotating activity between several projects
currently in progress
We will compare these two approaches and
search for creative alternatives that work
better
289
Performance Measures
We will focus on two practical performance measur
- Total completion time of all projects
- Makespan (i.e., completion time of the last
project)
Both performance measures directly evaluate the
level of service received by customers
290
Priority and Multitasking Approaches
How to prioritize among multiple projects?
Consider two projects (A and B) that need to
be performed by the same project team
Priority Approach: A has priority over B
Project A
A-1
B-1
A-2
Project B
B-2
A-3
B-3
A-4
B-4
Multitasking Approach: A and B have equal priority
291
Advantages of the Priority Approach
If payment is received only when a project is
completed, it offers good cash flow
It has fewer time-wasting project changeovers
Economies of scale (e.g., better resource usage)
arise when continuously handling one project
It passes projects through for subsequent
downstream processing more quickly
292
Advantages of the Multitasking
Approach
Many people feel very productive
when multitasking
Greater variety makes work more
interesting
You can report at least “some
progress” on all tasks
Treats projects, and therefore also
customers, more equitably than the
priority approach
293
Forming Teams
Teams consist of either 3 or 4
players
In a team with 3 players, they
progress the available Red, Blue and
Green tasks
A team with 4 players also has a
Controller, who keeps records and
checks that the rules are followed
Players cannot work on each others’
tasks
294
Randomly Generating Work
Roll
1
2
3
4
5
6
Value
1
3
5
6
7
8
Each box represents one day’s work
The amount of work performed in a
week is random (roll a die)
We skew a fair die to average 5 days’
work and approximately follow the
inverse beta distribution
We use a conversion table to do so; roll
the die, and convert the number into
the number of days of work performed
in the week
295
Single Project
For each project, each player (red, blue, or
green) rolls at most one fair die each week
In the box for each day’s work achieved that
week, write the week number
The blue and green tasks start the week
after the first red task is finished
The blue and green tasks can proceed
concurrently (requiring two random
numbers)
The second red task starts the week after
the blue and green tasks are both finished
Record the number of weeks needed to
complete the project
296
Roll Value
1
1
2 3
3
5
4
6
5
7
6
8
Single Project
Blue task A
Red task 1
Blue task B
Red task 2
Green task
Week Completed___
297
Priority Approach: Results
Single projects
Completion time:
Multiple (three identical) projects
Total completion time:
Makespan:
298
Multiple Projects:
Multitasking Approach
All unfinished tasks are progressed in turn
The red player works on Project R in week 1,
Project S in week 2, Project T in week 3,
Project R in week 4, and so on
There is carryover Ra->Rb, Sa->Sb and
Ta->Tb, but not between projects
When other colors become available, then
their players each multitask
At most 3 players work in the same week
Record the time to complete Projects R, S
and T and the overall makespan
299
Multiple Projects: Multitasking
Approach
Project R
Red task R1
Blue task Ra
Blue task Rb
Green task R
Project S
Red task S1
Project T
Red task T1
Roll Value
1
1
2 3
3
5
4
6
5
7
6
8
Red task R2
Week Completed___
Blue task Sa
Blue task Sb
Red task S2
Green task S
Week Completed___
Blue task Ta
Blue task Tb
Red task T2
Green task T
Week Completed___
300
Multitasking Approach: Results
Multiple projects
Total completion time:
Makespan:
301
Multiple Projects:
Team-Designed Approach
The rules are mostly the same as for
multitasking
However, it is not necessary to progress all
unfinished tasks in turn; instead, teams can
choose which tasks to progress in each week
Teams are encouraged to develop creative
approaches to solving the problem
One suggestion: identify the bottleneck tasks,
or “critical chain”, and do everything to
progress them
Reallocating resources is not allowed
Record the time to complete Projects R, S and
T and the overall makespan
302
Multiple Projects: Team-Designed
Approach
Roll Value
1 1
2
3
3
5
4
6
5
7
6
8
Project R
Week Completed___
Project S
Week Completed___
Project T
303
Week Completed___
Team–Designed Approach:
Results
Multiple projects
Total completion time:
Makespan:
304
Multiple Projects: Comparison of
Results
Priority Approach
Total completion time:
Makespan:
Multitasking Approach
Total completion time:
Makespan:
Team-Designed Approach
Total completion time:
Makespan:
305
Conclusions
A priority approach is often ineffective at
scheduling multiple projects, especially when
measured by makespan
A multitasking approach is also often
ineffective, especially when measured by total
completion time
A critical chain approach focuses on the
“bottleneck tasks” and often leads to
significant improvements in performance
The improvements identified here will be even
greater if resources are reallocated to the
bottleneck tasks (as happens in practice) 306
Dynamically Arriving Projects
Projects arrive dynamically (a common
situation in both manufacturing and
service organizations)
How to set due dates for new
projects?
How to schedule tasks in newly
arrived projects?
307
Dynamically Arriving Projects:
Research Study
Four due date assignment rules and five scheduling
heuristics are investigated
Simulated 250 projects that randomly arrive over
2000 days
Performance criteria:
average interarrival time = 8 days
6 - 49 tasks per project (average = 24); 1 - 3
resource types
average critical path = 31.4 days (ranging from 8 to
78 days)
mean completion time
mean project lateness
standard deviation of lateness
total tardiness of all projects
Partial and complete control of setting due dates
308
Dynamically Arriving Projects:
Research Study
Complete control environment: managers
can set the due date for all arriving
projects
Partial control environment: a proportion
of projects arrive with a preset due date
Heuristics to set due dates:
Mean flow due date rule
Number of activities rule
Critical path rule
Scheduled finish time due-date rule
309
Dynamically Arriving Projects:
Research Study
Heuristics to schedule tasks:
First in system, first served (FCFS)
Shortest task from shortest project
Minimum slack based on due date
Minimum late finish based on due
date
Minimum task duration from the
shortest remaining project
310
Dynamically Arriving Projects:
Research Study
No single scheduling heuristic performs best
across all due date setting combinations
Mean completion times for all scheduling and
due date rules are not significantly different
FCFS scheduling rule leads to increased total
tardiness
SPT-based rules do not work well in project
management
J. Dumond, V. Mabert. 1988. Evaluating Project
Scheduling and Due Date Assignment Procedures:
An Experimental Analysis. Management Science,
34, 1, 101-118.
311
Cited References 1
Brown, K.A., T.G. Schmitt, R.J. Schonberger, S.
Dennis. Quadrant Homes applies lean concepts in a
project environment. Interfaces 34 (2004), 442450.
Chaos Report, The. The Standish Group
International, Inc., 1994.
Czuchry, A.J., M.M. Yasin. Managing the project
management process. Industrial Management &
Data Systems 103 (2003), 39-46.
Fox, T.L., J.W. Spence. Tools of the Trade: A Survey
of project management tools. Project Management
Journal, September 1998.
312
Cited References 2
Hall N.G., J.C. Hershey, L.G. Kessler, R.C. Stotts. A
model for making project funding decisions at the
National Cancer Institute. Operations Research 40
(1992), 1040-1052.
Hodder, J.E., H.E. Riggs. Pitfalls in evaluating risky
projects. Harvard Business Review (1985), 128-136.
Mulder, L. The importance of a common project
management method in the corporate environment.
R&D Management 27 (1997), 189-196.
Oltra, M.J., C. Maroto, B. Segura. Operations strategy
configurations in project process firms. International
Journal of Operations and Production Management 25
(2005), 429-448.
313
Cited References 3
Patrick, F.S. Critical chain scheduling and buffer
management. 1998. www.focusedperformance.com
Pinto, J.K., O.P. Kharbanda. How to fail in project
management (without really trying). Business
Horizons, July-August 1996, 45-53.
Raz, T., R. Barnes, D. Dvir. A critical look at critical
chain project management. Project Management
Journal, December 2003.
Royer, I. Why bad projects are so hard to kill.
Harvard Business Review, March-April 1987, 49-74.
314
MBA 820
315