project management mba winter 2009 professor nicholas g. hall department of management sciences...

Project Management

MBA Winter 2009

Professor Nicholas G. Hall

Department of Management SciencesFisher College of BusinessThe Ohio State [email protected]

2

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.

3

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)

4

Course Overview (1 of 3)

History of the course

History of the subject

Textbook

Readings

5


Software

Case studies

Case analysis presentations

Guest speakers

6


Multitasking simulation game

Class participation

Final exam

Questions

7

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

8

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.

9

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.

Chapter

Introduction to Project Management

11

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

12

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.

13

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 contributions made by their project managers.

14

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.

15

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.

16

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.

17

Characteristics of Flowshop, Job Shop and Project

Flowshop Job Shop Project

Product Mass Custom Unique

Labor Low skill High skill High skill

Capital High Medium Low

Performance (time, cost, quality)

Good Variable Highly variable

18

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

19

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

20

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 projectR.J. Might and W.A. Fischer (1985)

Question: Was the movie Titanic successful?

See coursepack article: The Chaos Report

21

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

22

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.

23

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 (1987-2007) 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 to stock their shelves manually.

24

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

25

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

26

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.

27

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

Engineering projects are measured by tasks completed

IT projects are measured by resources used

J. Vowler (2001)

Example: software development

Example: building construction

28

IT Project Outcomes

26%: On time29%: Cancellation

6%: Less than 20% late

16%: 101-200% late 9%: 51-100%

late

8%: 21-50% late

6%: more than 200% late

Standish Group Survey, 1999. (from a survey of 8000 business systems projects)

29

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 itConstrux Software Builders, Inc., 2005.

Why are IT projects more difficult?

30

Wheelwright and Clark’s Classification of Projects

31

Project Life Cycle

32

Design (Scope), Cost, Time Tradeoffs

Target

COST

DE

SIG

N

TIME (S

CHEDULE)

Due Date

Budget Constraint

Optimal Time-Cost Tradeoff

Required Performance

“You can have your job done cheap, quick, or right; pick two.” [Sign in local copy center.]

33

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

34

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.

35


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.

36


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.

Chapter

Project Initiation, Selection, and Planning

38

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

Importance of Project Initiation & Selection

Good project selection makes the later job of running projects much easier. Also, some poorly selected projects are doomed from the start.

39

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

40


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

41

Analyzing Project Portfolios: Bubble Diagram

Expected NPV

Prob of Commercial Success

HighZero

Low

High

Bubble diagrams are useful for representing a set of projects and visualizing a project portfolio.

Shapes

Shading

Color

Size

42

Analyzing Project Portfolios: Product vs Process

Ext

ent

o f P

r od u

ct C

hang

e

Extent of Process Change

Source: S.C. Wheelwright and K.B. Clark, 1992, Creating Project Plans to Focus, Harvard Business Review

Shape represents the production resource used

Size represents the resource requirement

43


3. Project risk factors

Probability of research being successfulProbability of development being successfulProbability of project success w.r.t. scopeProbability of commercial successOverall risk of projectCompetitors in market and their reactions

44


4. Quantitative factors

Payback period

Net present value / internal rate of return

Expected commercial value

Real options

Multifactor scoring

45

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

46

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.

47

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 andr = discount rate of return (hurdle rate)

T

tt

t

rF

0 )1( NPV

48

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

0)1(1 2

210

r

F

r

FF

Note that, in a typical project, early cash flows are negative.

49

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.

50

NPV Example

The results of Phase II (available at the end of year 4) identify the product's market potential as indicated below:

51

NPV Example

Year Expected Cash Flow ($m)

1 -18

2 -18

3 -10

4 -10

5-24 10

If the discount rate is 5 percent, the discounted expected cash flow at the end of the 4th year is $114.62m.

52

NPV Example

The internal rate of return is 49.12%.

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

53

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

54

Expected Commercial Value (ECV)

Develop New

Product

Technical Failure

Technical Success

Probability = pt

Probability = 1 - pt

Launch New

Product Commercial Failure (with net

benefit = 0)

Commercial Success (with net benefit = NPV)

Probability = pc

Probability = 1 - pc

Risk class 1 Risk class 2

ECV is the expected NPV of the project, calculated by using the probabilities of the various alternatives.

55

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

56

ECV Example

Discount rate r1=10%

Discount rate r2=10%

Research & Product

Development

Development Succeeds

Probability = 0.8

Development Fails

Probability = 0.2

Launch New

Product

One-time cost of $5.5M

3 Years

5 Years

Drop ProductAnnual

Cost: $6M

Commercial Success Revenue $15M/yr

Probability = 0.6

Commercial Failure

Revenue $2M/yr

Probability = 0.4

No Cost

57

ECV Example

Year What’s Happening

Commercial Success

Commercial Failure

Expected Annual Cash Flow

Discounted Cash Flow

1 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

$M

Example calculation: .8[(.6)(15)+(.4)(2)-5.50]+.2(0)=3.44

10%

Total = 4.40

58

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.

59

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.

60

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

61

Multifactor Project Scoring Example

Attribute Scale Weight

Will the project increase market share?

unlikely 1 2 3 4 5 likely 30%

Is new facility needed? yes no (2) (4)

15%

Are there safety concerns?

likely unsure no (1) (3) (5)

10%

Likelihood of successful technical development?


Likelihood of successful commercial development?


62

Multifactor Project Scoring Example

To convert various measurement scales to a [0,1] range.

LINEAR SCALE: EXPONENTIAL

SCALE:

LU

Lxxv i

ii

)(

)(

)(

1

1)(

UL

xL

ii e

exv

i

0.00

0.10

0.20

0.30

0.40

0.50

0.60

0.70

0.80

0.90

1.00

1 2 3 4 5 6 7

Response

Att

rib

ute

Va

lue

Linear ScaleExponential Scale

ix

)( ii xv

Note that the exponential scale places a premium on being “acceptable”, but not on “excellence”.

63

Multifactor Project Scoring ExampleWeight 0.30 0.15 0.10 0.20 0.25 Project

score (Vj)

Attribute #1 #2 #3 #4 #5

Project A 5 Yes (2) Likely (1) 4 2

Project B 2 No (4) Unsure (3) 3 4

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.

64

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

65

Project Selection Example

Revenue by Year 1 2 3 4

Project A ($40) $10 $20 $20

Project B ($65) ($25) $50 $50

Budget Limit $90 $20 $40 $55

Overall score of Project A: .581Overall score of Project B: .845

We want to maximize the total overall score, or value delivered, of the portfolio

66

0-1 Program for Project Selection

See coursepack article: Hall et al. (1992)

Maximize 0.581a + 0.845bSubject 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 1where a = 1 if project A is selected 0 if not and b similarly.

67

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

68

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

69

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)

70

Two-Level WBS

1. Charity Auction

1.1 Event

Planning

1.2 Item

Procurement

1.3 Marketing

1.4 Corporate Sponsorships

WBS level 1

WBS level 2

71

Three-Level WBS

WBS level 2

WBS level 3

1.2 Item Procurement

1.3 Marketing

1. Charity Auction

1.4 Corporate Sponsorships

1.1.1 Hire Auctioneer

1.1.2. Rent space

1.1.3 Arrange for decorations

1.2.1 Silent auction items

1.2.2 Live auction items

1.2.3 Raffle items

1.3.1 Individual ticket sales

1.3.2 Advertising

1.1.4 Print catalog

WBS level 1

1.1 Event Planning

72

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.

73

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

74


Overlapped Product Design Approach

Allows downstream design stages to start before preceding upstream stages have finalized their specifications….

Stage 0

Stage 1

Stage N

75


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

What are the tradeoffs when moving from a traditional sequential product design approach to an overlapped product design approach?

Chapter

Project Teams and Organizational Relationships

77

Role of Project Manager and Team

Project Manager

Client

Subcontractors

Regulating Organizations

Project Team

Functional Managers

Top Management

This structure is what makes being a project manager both very interesting and very challenging!

78

Responsibilities of a Project Manager

To the organization and top management Meet budget and resource constraints Coordinate with functional managers

To the project team Provide timely and accurate feedback Keep focus on project goals Manage personnel changes

To the client 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.

79

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)

80

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

81

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

Artistic Viewpoint

82

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

83

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.

84

Group Harmony: High vs Low Performing Groups

4.00

4.20

4.40

4.60

4.80

5.00

5.20

5.40

5.60

5.80

6.00

1 2 3 4 5 6 7

Week

Gro

up

Ha

rmo

ny

High Performance (low cost) Teams Low Performance (high cost) Teams

High performing groups began with lots of conflict!

High performing (low cost) groups Low performing (high cost) groups

85

Extent of Individual Contribution: High vs Low Performing Groups

4.00

4.20

4.40

4.60

4.80

5.00

5.20

5.40

5.60

5.80

6.00

1 2 3 4 5 6 7

Week

Exte

nt

of

Ind

ivid

ua

l C

on

trib

uti

on

s


High performing groups began with individual contributions low!


86

Decision Making Effectiveness: High vs Low Performing Groups

3.00

3.50

4.00

4.50

5.00

5.50

6.00

1 2 3 4 5 6 7

Week

De

cis

ion

Ma

kin

g E

ffe

cti

ve

ne

ss


High performing groups began with slow decision making!


87

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?

88

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?

89

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?

90

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 globally

91

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.

92

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)

93

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

Marketing Department Chair

Finance Department Chair

Gloria

Diane

Bob

ZeldaLarry

Curly

Moe

Barby

Leslie

Comments: bureaucratic, confusing, stressful

94

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

95

Study Data Classification of 547 respondents (64% response rate)

30% project managers or directors of PM programs 16% top management (president, vice president, etc.) 26% managers in functional areas (e.g., marketing) 18% specialists working on projects

Industries included in studies 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

96

ANOVA Results by Organizational Structure

The results are statistically significant at the p<0.01 level

Controlling Cost

Meeting Schedule

Technical Performance

Overall Results

Organizational Structure N Mean (SD) Mean (SD) Mean (SD) Mean (SD)

AFunctional

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)

F-statistic 10.38* 6.94* 7.42* 11.45*

Scheffe ResultsA,B < C,D,E

E < D A,B < C < D,E A,B < C,D,E A,B < C,D,E

Higher values represent greater success

An exception occurs here

97

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

98

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

99

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

100

Decision Model

Step 1. Evaluate the way in which the organization reacts to a new project.

Organizational Factors Availability of resources Inflexibility of the organizational

management system Unsupportiveness of culture

_______

_______

_______

Low<-->High

Level or Intensity

Find the mean ______

101

Decision Model

Step 2. Evaluate the project itself.

Project factors Strategic importance Size Novelty & need for innovation Need for interdependence/integration Environmental complexity Need to meet tight constraints Stability in resource loading

_________________________________________________

Low<-->High

Level or Intensity


102

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.

103

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

104

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

________________________

________

________

________

________

________________________

Level or Intensity

Low<-->High


105

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.

106

Scoring Model Application: Control System Project

1. A major utility is functionally structured with culture unsupportive of project needs

2. Management systems cannot serve project needs for planning, control, general administration

3. Severe shortage of specialized human resources, as they are badly needed for ongoing operations

4. High strategic importance: technical failure could result in a major public catastrophe

5. Medium to large project: cost is around $200 million, and project duration is 6 years

107

Decision Model: Control System Project (cont.)

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

7. Strong need for integration: contributions from many tech departments are needed and are highly interdependent

8. 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,…

108

Decision Model: Control System Project (cont.)

9. Project is very politically sensitive, because of the visibility the press has given to the shortcomings of the present system.

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

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

12. Budget allocation and expenditures are tightly controlled by the overall organization.

13. The accuracy of the financial reporting system is low: poor control system, significant potential for human error.

109

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?

110

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?

111

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

Chapter

Precedence Networks and The Critical Path Method (CPM)

113

Precedence Relationships

Finish-to-start (FS = ): Task B cannot start until days after task A is finished

Start-to-start (SS = ): Task B cannot start until days after task A has started

Finish-to-finish (FF = ): Task B cannot finish until days after task A is finished

Start-to-finish (SF = ): Task B cannot finish until days after task A has started

The most common precedence network has FS = 0.

Several types of precedence requirements occur in practice.

114

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.

115

Precedence Networks: Activity-on-Node (AON)

A

B

C

D

Start End

116

Precedence Networks: Activity-on-Arc (AOA)

2

1

Start

End

Task A

Task B

Task C

Task D

Dummy task

Task A: (start, 2)

Task B: (start, 1)

Task C: (2, end)

Task D: (1, end)

Dummy task: (1, 2)

117

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

118

Critical Path Method: AON with Two Paths

Task A7 months

Task B3 months

End

Task C 11 months

Start

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.

119

Start

Task A7 months

Task B3 months

Task C11 months

End

ESStart = 0LFStart = 0

ESA = 0LFA = 8

ESB = 7LFB = 11

ESC = 0LFC = 11

ESEnd = 11LFEnd = 11

ESj = Earliest starting time for task (milestone) j

LFj = Latest finish time for task (milestone) j

CPM Example 1: AON Calculations

Step 1. Work ES calculations forward.

Step 2. Set LFEND=ESEND.

Step 3. Work LF calculations backward.

120

Example 1: Network Paths and Lengths

Path Tasks Duration (months)

1 START-A-B-END 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

121

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

122

CPM Example 2: AON Network

Task A 14 wks

Task D 12 wks

Task E 6

wks

Task B 9 wks

Task C 20 wks

Task F 9

wks

START END

123

Example 2: Network Paths and Lengths

Path TasksExpected

Duration (wks)1 START-A-D-F-END 352 START-A-D-E-END 323 START-B-D-F-END 304 START-B-D-E-END 275 START-C-E-END 26

Thus, START-A-D-F-END is a critical path.

124

Example 2: CPM Calculations

ESD=max{ESA+tA, ESB+tB}=max{0+14, 0+9}=14.

LFD=min{LFE-tE, LFF-tF}=min{35-6, 35-9}=26.

(EFi) (LSi)

125

CPM Example 2: AON Network

Task A 14 wks

Task D 12 wks

Task E 6

wks

Task B 9 wks

Task C 20 wks

Task F 9

wks

START END

ESSTART=0

LFSTART=0

ESA=0

LFA=26-12=14

ESD= max{14,9} =14

LFD= min{35-9,35-6}=26

ESF=14+12=26

LFF=35-0=35

ESE=max{0+20,14+12}=26

LFE=35-0=35

ESEND=35

LFEND=35ESB=0

LFB=26-12=14

ESC=0

LFC=35-6=29

126

Types of SlackTotal 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)

127

Example 2: Calculating Total Slack (TSi)

Task or Milestone

Duration ( )

Earliest Start Time

(ESi)

Lastest Finish Time

(LFi)Total Slack

(TSi)Critical Task?

START 0 0 0 0 Yes

A 14 0 14 0 Yes

B 9 0 14 5 No

C 20 0 29 9 No

D 12 14 26 0 Yes

E 6 26 35 3 No

F 9 26 35 0 Yes

END 0 35 35 0 Yes

ti

Total Slack for task i = TSi = LFi - ESi - ti

128

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)

129

Slack Calculations: Example

Task A 14 wks

Task D 12 wks

Task E 6

wks

Task B 9 wks

Task C 20 wks

Task F 9

wks

START END

ESC=0

LFC=29

TSC=LFC-ESC-tC

=29-0-20=9FSC=ESC,min-ESC-tC

=ESE-ESC-tC

=26-0-20=6

ESE=26

LFE=35

SSC=LFC-LFC,max-tC

=LFC-LFSTART-tC

=29-0-20=9ISC=max(0,ESC,min-LFC,max-tC) =max(0,ESE-LFSTART-tC) =max(0,26-0-20)=6

ESSTART=0

LFSTART=0

130

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

131

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

132

LP Model for Example 2

Minimize ENDSubject 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

133

Simplified LP Model for Example 2

Minimize ENDSubject to:

14 AD STARTSTART9 BD STARTSTART20 CE STARTSTART

12 DE STARTSTART

9 FSTARTEND6 ESTARTEND

0,, CBA STARTSTARTSTART

12 DF STARTSTART

134

Extension of LP Model: Enforce Early Start Times

How to ensure that all tasks are started at their earliest possible times.

135

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

136

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)

137

AOA: Precedence Networks

Task A: (start, 2)

Task B: (start, 1)

Task C: (2, end)

Task D: (1, end)

Dummy task: (1, 2)

2

1

Start

End

Task A 4 Weeks

Dummy task

Task B 2 Weeks

Task C 7 Weeks

Task D 10 Weeks

138

AOA: Computing Earliest and Latest Occurrence Times

1

2

Start

End

Task A 4 Weeks

Dummy task

Task B 2 Weeks

Task C 7 Weeks

Task D 10 Weeks

TESTART=0

TLSTART=0

TE1=2

TL1=2

TE2=4

TL2=5

TEEND=12

TLEND=12

Step 3. Work TL calculations backward

Step 1. Work TE calculations forward

Step 2. Set TLEND=TE

END

139

Slack Calculations for AOA

TSij = Total slack for Task (i,j)

ijE

iLj tTT

FSij = Free slack for Task (i,j)

ijE

iEj tTT

SSij = Safety slack for Task (i,j)

ijL

iLj tTT

ISij = Independent slack for Task (i,j)

) ,0max( ijL

iEj tTT

Interpretations are the same as in AON.

140

Slack Values for AOA: Example

Task Duration (tij)

Earliest Start Time (TE

j)

LatestFinish Time (TL

j)

Total Slack (TSij)

Free Slack (FSij)

Safety Slack (SSij)

Indep. Slack (ISij)

A: (START, 2) 4 0 5 1 0 1 0B: (START, 1) 2 0 2 0 0 0 0Dummy (1,2) 0 2 5 3 2 3 2C: (2, END) 7 4 12 1 1 0 0D: (1, END) 10 2 12 0 0 0 0

141

AOA: Calculating Slack

1

2

Start

End

Task A 4 Weeks

Dummy task

Task B 2 Weeks

Task C 7 Weeks

Task D 10 Weeks

TESTART=0

TLSTART=0

TE1=2

TL1=2

TE2=4

TL2=5

TEEND=12

TLEND=12

Step 3. Work TL calculations backward

Step 1. Work TE calculations forward

Step 2. Set TLEND=TE

END

TSSTART2=1, FSSTART2=0SSSTART2=1, ISSTART2=0

TSSTART1=0, FSSTART1=0SSSTART1=0, ISSTART1=0

TS12=3, FS12=2SS12=3, IS12=2

TS2END=1, FS2END=1SS2END=0, IS2END=0

TS1END=0, FS1END=0SS1END=0, IS1END=0

142

LP Model for AOA Network

Decision variables: the occurrence time of each node

Chapter

Planning to Minimize Cost

144

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

145

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

146

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.

147

Project Budget Example

Task A 14 wks

Task D 12 wks

Task E 6

wks

Task B 9 wks

Task C 20 wks

Task F 9

wks

START END

ES F = 26LFF = 35

ES D = 14LFD = 26

ES START = 0LFSTART = 0

ES A = 0LFA = 14

ES B = 0LF B = 14

ES END = 35LFEND = 35

ES C = 0LFC = 29

ES E = 26LFE = 35

148


Cost for Resource A worker = $400/week

Cost for Resource B worker = $600/week

149


Early Start TimesTask 1 2 3 4 5 6 7 8 9 10 11 12

A 1140 800 800 800 800 800 800 800 800 800 800 800

B 8925 8800 8800 8800 8800 8800 8800 8800 8800

C 9600 9600 9600 9600 9600 9600 9600 9600 9600 9600 9600 9600

DEF

Weekly Subtotals 19665 19200 19200 19200 19200 19200 19200 19200 19200 10400 10400 10400

Cumulative 19665 38865 58065 77265 96465 115665 134865 154065 173265 183665 194065 204465

Late Start Times

Task 1 2 3 4 5 6 7 8 9 10 11 12

A 1140 800 800 800 800 800 800 800 800 800 800 800

B 8925 8800 8800 8800 8800 8800 8800 8800

C 9600 9600 9600 9600

DEF

Weekly Subtotals 1140 800 800 800 9725 9600 9600 9600 19200 19200 19200 19200Cumulative 1140 1940 2740 3540 13265 22865 32465 42065 61265 80465 99665 118865

The total duration is 35 weeks

150

Weekly Costs (Cash Flows)

0

5000

10000

15000

20000

25000

1 3 5 7 9

11

13

15

17

19

21

23

25

27

29

31

33

Week

We

ek

ly C

osts

Early Start Schedule Late Start Schedule

Example 2 from Chapter 4

151

Cumulative Costs

0

50000

100000

150000

200000

250000

300000

350000

400000

450000

1 3 5 7 9

11

13

15

17

19

21

23

25

27

29

31

33

Week

Cu

mu

lati

ve

Co

st

Early Start Schedule Late Start Schedule

1 3 5 7 9 11 13 15 17 19 21 23 25 27 29 31 33

152

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 time reliability (prefer ES schedule)

153

Cash Flow Example

M1

END

START

Task B 8 mos

Receive payment of $3000

Receive payment of $3000

Make payment of $5000

Task C 4 mos

Task A 2 mos

M2

Task D 8 mos

Task E 3 mos

154

Cash Flow Example: Solver Model

10111213141516171819

See cashflow analysis.xls on the CD

Objective: Maximize NPV

C D E FF19=F13+F15+F18

155

Material Management Example

Task A 4 wks

Task B 8 wks

Task C 5 wks

Task D 6 wks

Task E 2 wks

Task F 3 wks

EndStart 2 units

30 units

LSA = 0 LSB = 4 LSC = 12

LSD = 6 LSE = 12 LSF = 14

LSEND=17

A total of 32 units of resource must be acquired.What is the best ordering policy?

156


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

157


• To minimize holding costs, only place orders at Latest Start times

• Can never reduce total costs by delaying the project

Time

1 2 3 4 5 6 7 8 9 10 11 12

Demand: 2 30

Order option #1: 32

Order option #2: 2 30

Choose the option that minimizes inventory cost =

order cost + holding cost of raw materials

158


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

159

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.

160

Time / Cost Tradeoff Example

TaskNormal

Duration Normal Cost

Marginal Cost to Crash One

Week

A 7 $60 $8B 6 $85 $5C 15 $55 $10D 10 $120 $4

A

B

C

D

Start End

7 wks

6 wks 10 wks

15 wks

Critical path with makespan 22

Assume constant marginal crash cost, i.e. linear cost of crashing

Assume task C cannot be crashed below 13 weeks

161

Time / Cost Tradeoff Example

Project

Duration

(weeks) Critical Path(s) Task(s) Reduced

Total Direct

Cost

22 Start-A-C-End - $320

21 Start-A-C-End A $328

Start-B-C-End

20 Start-A-C-End C $338

Start-B-C-End

19 Start-A-C-End C $348

Start-B-C-End

18 Start-A-C-End A, B $361

Start-B-C-End

As we reduce the project duration, we need to keep track of the lengths of all paths

This “crashing” procedure is a heuristic ---- it does not always find the cheapest sequence of reductions

162

Linear Time / Cost Tradeoff

Time

Cost

Crash point

Normal point

Slope (bj) = increase in cost from reducing task duration by one time unit

Normal time =Crash time =

Normal cost =

Crash cost =

tjNtj

c

Cjc

CjN

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.

163

Time / Cost Tradeoff Using LPAssume marginal cost of crashing task j is bj = (Cj

C-CjN)/(tj

N-tjC) > 0

Decision Variables: Sj = starting time of task j

END = end time of project tj = duration of task j

Minimize total direct cost = j

jj tb

s.t. Sj ≥ Si + ti, for all tasks i that immediately precede job j

tjC ≤ tj ≤ tj

N, for all tasks in the project

END ≥ Sj + tj, for all tasks in the project

tj , Sj ≥ 0, for all tasks in the project

END ≤ Tmax

The following model allows us to minimize the total direct cost required to complete the project by time Tmax

164

Minimizing Total Cost

Project duration

Cost

Overhead costs

Direct costs

Total cost

Crash time Normal timeMinimum cost solution

Here we assume that overhead costs are proportional to project duration.

165

Minimizing Total Cost

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.

The following model allows us to minimize the total of direct and indirect costs

j

jj ENDItb )( costs totalMinimize

Chapter

Planning with Uncertainty

167

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.

168

Uncertain Task Durations

Pessimistic time, tjpMost likely time, tj

mOptimistic time, tjo

Completion time of task j

Time

Probability density function

Expected time,

It is widely assumed that, in many projects, task durations follow the beta distribution shown below

169

Standard Approximations for Task Durations

For each task, we need three estimates: most optimistic time, most pessimistic time, most likely time,

otpt

mt

6

4duration Expected

mpo ttt

6deviation Standard

op tt

In practice, how easy is it

to estimate these?

These formulas are designed to approximate (simply, but not very accurately) the beta distribution.

170

More Accurate Approximations

85.2

95.595mttt

25.3

595 tt

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.

Note that these approximations require the estimation of slightly different data, which could be easier (or harder) to estimate.

171

Three Mechanisms by which Uncertainty Creates Problems

1. Parkinson’s Law

2. Procratinasting Workers

3. Schonberger’s Hypothesis

172

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

173

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 of T 1 Prob Values of T 2 Prob

Project Makespan Prob

7 0.3 14 0.5 24 0.157 0.3 18 0.5 25 0.158 0.4 14 0.5 24 0.28 0.4 18 0.5 26 0.29 0.3 14 0.5 24 0.159 0.3 18 0.5 27 0.15

E[T(D)] = 25 days

*

*

*

*makespan expanded to fit deadline

Values of T1 Values of T2

174

Mechanism 2: Procrastinating Workers

Set a deadline D = 24 days

E’[T(D)] = E(T1) + E(T2) + E{max[0, D - T1 - E(T2)]}

Values of T 1 Prob

E[Delay] = max[0, D - T1 - E(T2)] E[Makespan]

7 0.3 1 248 0.4 0 249 0.3 0 25

8 0.3 24.30

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,…)

A procrastinating worker waits until the last possible time to start (given the expected duration of their task).

*

* Delayed by procrastinating worker, who starts tasks 1 day later.

175

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.

176

Example of Schonberger’s Hypothesis

The longest expected path length = 14

177

Example of Schonberger’s Hypothesis

RealizationTask A

DurationTask B

Duration Probability Max (A, B)

1 12 10 0.05 122 14 10 0.4 143 16 10 0.05 164 12 15 0.05 155 14 15 0.4 156 16 15 0.05 16

Duration of Task A Probability

Duration of Task B Probability

12 0.3 10 0.514 0.4 15 0.516 0.3

14.0 12.5

Increasing the variance of Task A:

Now, the expected duration = 14.65 days

Expected duration equals 14.55 days

This is an enumeration of all possible events.

178

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 j, 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]

Program Evaluation and Review Technique

}{max][path on task

Sjj

SkESEk Expected early start time of task ,

where S is a path from the start of the project to task k.

179

PERT Model

Thus, we have several results:

path criticalon task

][j

jENDESE

path criticalon task

2][j

jENDESVar

][

][Pr)Pr( max

max

END

ENDEND

ESVar

ESETzTES

Expected project duration:

Variance of project duration:

Using Central Limit Theorem and standard normal distribution:

Look up theresult in thez table

Also: given on time completion probability, we can find Tmax.

180

PERT Example 1

(2+14+4×6)/6(14-2)^2 / 36

181

PERT Example 1

Pr(z≤Zi)

E(A)+E(C)=6.67+

7.83

Var(A)+Var(C)=4.00+3.36

(15-14.5)/Sqrt(7.36)

PERT expected duration = PERT variance = See PERT example 1.xls

182

PERT Example 1

PERT assumes that the path with the longest expected duration will still be the critical path when all the activity durations are known.

Path Expected Duration

Variance

START-A-B-E-F-END

23.33 6.67

START-A-C-E-F-END

23.83 8.25

START-A-D-END

21.00 5.00

183

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

184

PERT Example 2

Task B

B = 12

B2 = 4

Task D

D = 3

D2 = 1

Task A

A = 4

A2 = 2

Task C

C = 10

C2 = 5

ENDSTART

Expected makespan=12 + 3 = 15

Variance of makespan = 4 + 1 = 5

185

PERT Example 2

START->B->D->END

E[ESEND]=15 and Var[ESEND]=5

Pr([ESEND]≤17)=Pr(z ≤(17-15)/√5)=0.81

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

Classic PERT estimate

Thus, classic PERT overestimates the probability of completion on time (i.e., is too optimistic)

186

Example 3: Discrete Probabilities

Task A Task B Task C Task DValue 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

START END

Task A(8.0)

Task B(10.0)

Task C(19.0)

Task D(9.3)

Expected project duration from PERT = 19.3 weeks.

μj 8 10 19 9.3

187

Example 3

This is an enumeration of all possible 36 combinations of events. Probabilities of paths

being critical

188

Example 3

Task A Task B Task C Task D

6.8% 32.0% 61.1% 38.8%

Criticality Indices (probability of each task being critical):

Expected Project Duration = 23.22 >> 19.3

Since the analysis enumerates all events, these probabilities are exact.

Length of CP's Prob. Cumulative Prob.10 0.004 0.00411 0.004 0.00812 0.004 0.01215 0.108 0.12019 0.019 0.13920 0.019 0.15821 0.019 0.17724 0.224 0.40125 0.599 1.000

189

Calculating Confidence Intervals

nSS

X

Using a normal approximation, a (1- ) two-sided confidence interval is given by:

XszX 2/

To calculate a confidence interval, we can use the sample mean and the estimated standard error of the mean.

Example: =27.65, s=4.25, and n=200 trials, where s is the sample standard deviation and n is the number of trials.

X

Project Makespan Lower Limit Upper Limit

95% confidence interval 27.07 28.24

99% confidence interval 26.88 28.43

27.65±(1.96)(4.25)/√200=27.65±0.59

27.65±(2.56)(4.25)/√200=27.65±0.77

190

Monte Carlo Simulation (PERT Example 1)

Project Makespan Lower Limit Upper Limit

95% Confidence interval 26.56 27.7299% Confidence interval 26.37 27.90

Recall that PERT expected duration = 23.83 (i.e., much too optimistic)

Beta Distribution

See PERT example 1.xls

Task Duration

95%: 27.14±(1.96)(4.095)/√200=27.14±0.58

99%: 27.14±(2.56)(4.095)/√200=27.14±0.76

Criticality index for task B

191

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.

192

Critical Chain Project Management

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

Background

193


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.

Critique of Traditional Project Management

194


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.

Eight Principles

195


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

Eight Principles (cont.)

196

Critical Chain Buffers

Projectbuffer

End

1 1 1

2 2 2

2 days 1 day

Task C25 days

197

Calculating Project Buffer Size

chain critical on task

2)(bufferk

kpkt

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 time, and is the most pessimistic estimate of task k’s duration:

pkt

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

Like PERT, uses only longest path

198


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.

Critique of CCPM

199


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)

Critique of CCPM (cont.)

Chapter

Risk Management

201

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

202

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

203

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

204

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

205

Tornado Diagram

Rank by largest cost range on top

Project Cost ($000’s)

206

Sensitivity Chart

Rank by correlation with total project cost, largest

absolute value on top

Wage Rate

Direct Labor Hours

Material Units Needed

Early Completion Bonus

Material Unit Costs

Interest Rates

Energy Costs

Overhead

207

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 weeksProbability: 20 percentRisk Exposure = (.20) (3 weeks)

= .6 week

What are the limitations of this analysis?

208

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

209

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

210

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)

211

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 B = 1

Fixed Price Contract

Risk Continuum

Client’s Risk Subcontractor’s Risk

212

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

213213

Risk Management Strategies: Overview

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

4 Types of Strategies

H. Taylor, Project Management Journal, 2006

214214

Risk Management Strategies: Control

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

Best Control Strategies

215215

Risk Management Strategies: Negotiation

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

Best Negotiation Strategies

216216

Risk Management Strategies: Research

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)

Best Research Strategies

217217

Risk Management Strategies: Monitoring

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

Best Monitoring Strategies

218

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

219

Van Allen Company: Tasks

220

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

221

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?

222

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

223

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

224

Van Allen Company: Minimum Cost Solution (No Strike Considered)

Task Duration ImmediatePredecessors

Starting Times

FinishTimes

Crash Time

Crash Cost (100$)

Normal Time

Normal Cost (100$)

Slope (100$)

Marginal Cost Incr (100$)

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 530 310 74

Indirect cost=$12*17 days=204

Total cost=$310+$70+$204=$588

Slope=(crash cost – normal cost)/(normal time – crash time)

225

Van Allen Company: Minimum Cost Solution (Strike Considered)

Task Duration ImmediatePredecessors

Starting Times

FinishTimes

Crash Time

Crash Cost (100$)

Normal Time

Normal Cost (100$)

Slope (100$)

Marginal Cost Incr (100$)

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 530 310 74

The same table as the previous page. Total expected cost: $588 + $12*3.8*0.7=$619.92

226

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

Chapter

Resource Management

228

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

229

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

230

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)

231

Resource Leveling Example

Duration tj

232

Resource Leveling Example: Early Start Schedule

The maximum number of workers needed is 21.

A A A

B B

C C C C C C C C C

D D D D DE

E EF

F

G G G G

G

233

Resource Leveling Example: Late Start Schedule

A A A

B B

C

C C C C C C C C

D D D D D

E E E

F FG G G

G G

Now the maximum number of workers needed is only 16.

234

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

235

Renewable Resource Allocation Example 1 (Single Resource Type)

Task B 3 wks

Task D 5 wks

Task A 4 wks

Task E 4

wksSTART

END

Task C 1 wk

3 workers

5 workers

6 workers

8 workers

7 workers

Maximum number of workers available = R = 9

Makespan: 12 weeks

Resource allocation question: Is this schedule feasible?

236

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?

237

Resource Allocation Example 1: Early Start Schedule

Maximum number of workers available = R = 9 workers

Minimum “wasted” worker-weeks at start of project = 3

Worker-weeks needed = 12+15+6+40+28 = 101

238

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

239

Resource Allocation Example 1: Late Start Schedule

Maximum number of workers available = R = 9 workers

Minimum “wasted” worker-weeks at end of project = 8

240

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

241

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 = 108-

11 = 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

242

Resource Leveling / Allocation Heuristics

Here are some heuristics for assigning priorities to available task j, where denotes the number of units of resource k used by task j.

kjR

GRD: Largest resource utilization × task duration = j

kj

ktR max

GTS: Largest total number of successors

FCFS: First available task

Heuristics are simple rules of thumb for prioritizing tasks in resource leveling and resource allocation problems, and can be implemented in MS Project.

243

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

244

Resource Allocation Example 2

245

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 Task B1 Task C1

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20

Task A2 Task B2 Task C2

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20

GC

PC

Makespan=20

246

Minimizing Project Duration

But, can we do better? Is there a better priority rule?

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20

GC

PC

C1 B1 A1

Shortest Processing Time (SPT):

C2 B2 A2

Now the makespan is reduced to 16.

Which heuristic works better depends on the project data.

247

Microsoft Project Solution (Resource Leveling Option)

Solution by: Microsoft ProjectMakespan=17 days (excluding weekends), but we know from the previous page that 16 days is possible!

B1

A1

B2C1

C2

A2

248

Non-Renewable Resources

Task Duration

No. of Nonrenewable Resources Units

Needed Early Start Late Start

A 6 6 0 0B 5 12 6 6C 3 10 6 8D 2 8 11 11

Non-renewable resources are delivered to the project over time. At any time, we cannot have used more than the total resources delivered so far.

249

Non-Renewable Resources: Comparing Solutions

Cumulative resources supplied (given)

Cumulative resources required (using ES times)

Weeks

Using LS times always works best, since they allow the most time for resources to be delivered.

Cumulative resources required (using LS times)

250

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?

251

Teaming Example

Configuration 1: Bob and Barb work jointly on all four tasks; they complete each task in one-half the time needed if either did the tasks individually.

A C

B D

Start End

Configuration 2: Bob and Barb work independently. Bob is assigned to tasks A and C; Barb is assigned to tasks B and D.

252

Teaming ExampleTASK A TASK B TASK C TASK D

Duration Prob Duration Prob Duration Prob Duration Prob

6 0.33 9 0.667 12 0.6 10 0.255 0.33 6 0.333 7 0.4 6 0.754 0.33

Expected duration 5.0 8.0 10.0 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

253

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

254

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

Cumulative Prob

12 0.07 0.0713 0.03 0.1015 0.20 0.3016 0.20 0.5017 0.17 0.6718 0.17 0.8319 0.17 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

Chapter

Monitoring and Control

256

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

257

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

258

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

259

Types of System Variation

Common cause variation: “in-control” 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

260

Control System Example 1Week 2: Task expenses = 460 worker-hours

370

380

390

400

410

420

430

440

450

460

470

1 2 3 4

Week

Cos

t (i

n w

ork

er-h

ours

)

WeekPlanned Cost

(BCWS) Actual Cost

Cumulative Actual Cost

(ACWP)

1 400 420 4202 400 460 880

Is the task “out of control”?

Actual

Planned

261

Control System Example 1

Week 3: Task expenses = 500 worker-hrs

WeekPlanned cost

(worker-hours)Actual cost

(worker-hours)Cumulative cost (worker-hours)

1 400 420 4202 400 460 8803 400 500 1380

Again, is the task “out of control”?0

100

200

300

400

500

600

1 2 3 4

Week

Wor

ker-

hour

s

Actual

Planned

262

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)

263

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

264

Performance Metrics for Example 1

Week BCWS ACWP Percent of work completed (PWC)

BCWP

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

265

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

266

Cost Variance (CV) Cost Variance (CV)

= difference between value of work completed and actual expenditures

= Earned Value - Actual Cost = BCWP - ACWP

Week 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

267

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

268

Time Variance (tV)

Time Variance= (BAC * PWC) – Current Time

Ο After week 3tV =4 * 85% - 3

=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

BAC: Budget at Completion

PWC: Percent of Work Completed

269

Earned Value Metrics IllustratedW

orke

r-H

ours

Week 1 Week 2 Week 3 Week 4 Week 5 Week 6

Present timeBAC

Actual Cost (ACWP)

Earned Value (BCWP)

Planned Value (BCWS)

Schedule Variance (SV)

Cost Variance (CV)

Budget at Completion

270

Relative Measure: Schedule Index

Schedule Index (SI ) = BCWPBCWS

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

271

Relative Measure: Cost Index

Cost Index (CI) = BCWPACWP

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)

272


cumulative

273

Control System Example 2 Progress report at the end of week #5:

Cumulative Percent of Work Completed:

Worker-Hours Charged to Project:

274


Progress report at the end of week #5:

SV=BCWP-BCWS

CV=BCWP-ACWP

275


Worker-Hours

276

Using a Fixed 20/80 RuleCumulative Percent of Work Completed:

W E E K1 2 3 4 5 6 7 8 9 10

Cumulative Scheduled

Worker-Hrs (BCWS) 6 12 18 38 60 82 92 104 116 128

Actual Worker-Hrs Used (ACWP) 5 11 19 44 64

Earned Value (BCWP) 7.2 7.2 7.2 14.4 14.4Schedule

Variance (SV) 1.2 -4.8 -10.8 -23.6 -45.6Cost Variance

(CV) 2.2 -3.8 -11.8 -29.6 -49.6

Week 1 2 3 4 5Task A 20% 20% 20% 20% 20%Task B 20% 20%Task C Not started yet

SV=BCWP-BCWS

CV=BCWP-ACWP

Assume that 20% of a task’s work is completed when it is started, and 80% when it is finished

277

Using a Fixed 20/80 Rule

Worker-Hours

278

Updating Forecasts: Pessimistic Viewpoint (Example 2)

Assumes that the rate of cost overrun will continue for the life of the project.

279

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

Chapter

Managing Multiple Projects

281

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

282

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.

283

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

284

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

285

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

Managing Multiple Projects

A Creative Thinking and Simulation Game

287

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

288

Outline

Introduction

Priority approach Multitasking approach

Team–designed approach

Comparison of results

Conclusions

289

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

290

Performance Measures

We will focus on two practical performance measures:

- 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

291

Priority and Multitasking Approaches

Consider two projects (A and B) that need to be performed by the same project team

How to prioritize among multiple projects?

Project A Project B

A-1 B-1 A-2 B-2 A-3 B-3 A-4 B-4

Multitasking Approach: A and B have equal priority

Priority Approach: A has priority over B

292

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

293

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

294

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

295

Randomly Generating Work

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

Roll Value

1 1

2 3

3 5

4 6

5 7

6 8

296

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

297

Red task 1 Red task 2

Blue task A

Blue task B

Green task

Week Completed___

Roll Value 1 1 2 3 3 5 4 6 5 7 6 8

Single Project

298

Priority Approach: Results

Single projectsCompletion time:

Multiple (three identical) projectsTotal completion time:Makespan:

299

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

300

Project R

Red task R2

Blue task Ra

Blue task Rb

Green task R

Red task R1

Project S

Red task S2

Blue task Sa

Blue task Sb

Green task S

Red task S1

Project T

Red task T2

Blue task Ta

Blue task Tb

Green task T

Red task T1

Week Completed___

Week Completed___

Week Completed___

Roll Value 1 1 2 3 3 5 4 6 5 7 6 8

Multiple Projects: Multitasking Approach

301

Multitasking Approach: Results

Multiple projects

Total completion time:

Makespan:

302

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

303

Project R

Project S

Multiple Projects: Team-Designed Approach

Project T

Roll Value 1 1 2 3 3 5 4 6 5 7 6 8

Week Completed___

Week Completed___

Week Completed___

304

Team–Designed Approach: Results

Multiple projectsTotal completion time:

Makespan:

305

Multiple Projects: Comparison of Results

Priority ApproachTotal completion time:Makespan:

Multitasking ApproachTotal completion time:Makespan:

Team-Designed ApproachTotal completion time:Makespan:

306

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)

307

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?

308

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 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) Performance criteria:

mean completion time mean project lateness standard deviation of lateness total tardiness of all projects

Partial and complete control of setting due dates

309


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

310


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

Heuristics to schedule tasks:

311


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.

312

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), 442-450.

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.

313

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.

314

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.

315

MBA 820

project management mba winter 2009 professor nicholas g. hall department of management sciences...

Documents

project management slide

history of project management

project management product

project management journal

examples of project

project management skills

project format

microsoft project