Project Management a System approach to Planning Scheduling & Controlling - Harold Kerzner.

Project Management a System approach to Planning Scheduling & Controlling
- Harold Kerzner

Introduction to Project Management
Chapter Introduction to Project Management

History of Project Management
One of the first examples of project management was the construction of the pyramids in Egypt Henry L. Gantt ( ) 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

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.

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.

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.

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.

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.

Characteristics of Flowshop, Job Shop and Project
Product Mass Custom Unique Labor Low skill High skill Capital High Medium Low Performance (time, cost, quality) Good Variable Highly variable

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 Bringing Discipline to Project Management. Harvard Business Review. See coursepack article: Oltra, Maroto and Segura

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

Measures of Project Success
Overall perception Cost Completion time Technical goals, compared to initial specifications Technical goals, compared to other projects in the organization Technical goals, taking into account the problems that arose in the project R.J. Might and W.A. Fischer (1985) Question: Was the movie Titanic successful? See coursepack article: The Chaos Report

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

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.

Famous Project Failures (cont.)
Disney's shipbuilder was six months late in delivering its new cruise ships in Thousands of Disney customers who had purchased tickets had to be compensated for making different plans. In , 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 ( ) 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.

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

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

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.

IT Projects are Different
“[in IT projects], if you ask people what’s done and what remains to be done there is nothing to see. In an IT project, you go from zero to 100 percent in the last second--unlike building a brick wall where you can see when you’re halfway done.” J. Vowler (2001) Engineering projects are measured by tasks completed Example: building construction IT projects are measured by resources used Example: software development

IT Project Outcomes Standish Group Survey, (from a survey of 8000 business systems projects)

Why do IT Projects Fail? Ill-defined or changing requirements
Poor project planning/management Uncontrolled quality problems, e.g. software fails to complete computing task in time Unrealistic expectations/inaccurate estimates Adoption of new technology without fully understanding it Construx Software Builders, Inc., 2005. Why are IT projects more difficult?

Wheelwright and Clark’s Classification of Projects

Project Life Cycle

Design (Scope), Cost, Time Tradeoffs
Target COST DESIGN TIME (SCHEDULE) Due Date Budget Constraint Optimal Time-Cost Tradeoff Required Performance QUALITY “You can have your job done cheap, quick, or right; pick two.” [Sign in local copy center.]

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

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.

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.

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 Micro Frame Technologies, Inc. and Project Management Technologies, Inc.

Project Initiation, Selection, and Planning
Chapter Project Initiation, Selection, and Planning

Importance of Project Initiation & Selection
“There are two ways for a business to succeed at new products: doing projects right, and doing the right projects.” R.G. Cooper, S. Edgett, E. Kleinschmidt Research and Technology Management. Good project selection makes the later job of running projects much easier. Also, some poorly selected projects are doomed from the start.

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

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

Analyzing Project Portfolios: Bubble Diagram
Expected NPV Prob of Commercial Success High Zero Low Shapes Shading Color Size Bubble diagrams are useful for representing a set of projects and visualizing a project portfolio.

Analyzing Project Portfolios: Product vs Process
Shape represents the production resource used Size represents the resource requirement Extent of Product Change Extent of Process Change Source: S.C. Wheelwright and K.B. Clark, 1992, Creating Project Plans to Focus, Harvard Business Review

3. Project risk factors Probability of research being successful Probability of development being successful Probability of project success w.r.t. scope Probability of commercial success Overall risk of project Competitors in market and their reactions

4. Quantitative factors Payback period Net present value / internal rate of return Expected commercial value Real options Multifactor scoring

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

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.

Net Present Value (NPV)
Let Ft = net cash flow in period t (t = 0, 1,..., T), where F0 = initial cash investment at time t = 0 and r = discount rate of return (hurdle rate)

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 Note that, in a typical project, early cash flows are negative.

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.

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

Expected Cash Flow ($m)
NPV Example Year Expected Cash Flow ($m) 1 -18 2 3 -10 4 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.

The internal rate of return is 49.12%.
NPV Example Expected cash flows (with sale of product at end of year 4) Cash Outflow Cash Inflow NPV Year 1 18.00 -18.00/(1+r) Year 2 -18.00/(1+r)2 Year 3 10.00 -10.00/(1+r)3 Year 4 124.62 /(1+r)4 This is the discounted value of sales at the end of year 4 The internal rate of return is 49.12%.

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

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 In fact, the previous example for DCF is also an ECV example. ECV is the expected NPV of the project, calculated by using the probabilities of the various alternatives.

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

Research & Product Development
ECV Example 5 Years Probability = 0.6 One-time cost of $5.5M Commercial Success Revenue $15M/yr 3 Years Probability = 0.8 Launch New Product Development Succeeds Commercial Failure Revenue $2M/yr Research & Product Development Probability = 0.2 Drop Product Probability = 0.4 Annual Cost: $6M Development Fails No Cost Discount rate r1=10% Discount rate r2=10%

ECV Example $M 10% 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. (4.96) 3 (4.51) 4 Product sales $15 $2 3.44 2.35 5 7.84 4.87 6 4.43 7 4.02 8 3.66 Total = 4.40 Example calculation: .8[(.6)(15)+(.4)(2)-5.50]+.2(0)=3.44

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.

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.

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

Multifactor Project Scoring Example
Attribute Scale Weight Will the project increase market share? unlikely 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? 20% Likelihood of successful commercial development? 25%

To convert various measurement scales to a [0,1] range. LINEAR SCALE: EXPONENTIAL SCALE: Note that the exponential scale places a premium on being “acceptable”, but not on “excellence”.

Weight 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 No (4) Unsure (3) 3 Linear Scale 1.00 0.75 0.550 0.50 0.525 Exponential Scale 0.64 0.00 0.97 0.751 0.88 0.845 Note that the linear scale recommends Project A, whereas the exponential scale recommends Project B.

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

Project Selection Example
Revenue by Year Project A ($40) $10 $20 Project B ($65) ($25) $50 Budget Limit $90 $40 $55 Overall score of Project A: .581 Overall score of Project B: .845 We want to maximize the total overall score, or value delivered, of the portfolio

0-1 Program for Project Selection
Maximize 0.581a b Subject to 40a + 65b ≤ 90 (Year 1) -10a + 25b ≤ 20 (Year 2) -20a – 50b ≤ 40 (Year 3) -20a – 50b ≤ 55 (Year 4) a, b = 0 or 1 where a = 1 if project A is selected 0 if not and b similarly. See coursepack article: Hall et al. (1992)

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 3. Project monitoring and control Cost control system, contingency plans 4. Project termination Evaluation, benchmarking and archiving

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

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)

1.4 Corporate Sponsorships
Two-Level WBS WBS level 1 1. Charity Auction 1.1 Event Planning 1.2 Item Procurement 1.3 Marketing 1.4 Corporate Sponsorships WBS level 2

Three-Level WBS 1.2 Item Procurement 1.3 Marketing 1. Charity Auction
1.4 Corporate Sponsorships Hire Auctioneer Rent space Arrange for decorations Silent auction items Live auction items Raffle items Individual ticket sales Advertising Print catalog WBS level 1 1.1 Event Planning WBS level 2 WBS level 3

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.

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

Overlapped Product Design Approach Allows downstream design stages to start before preceding upstream stages have finalized their specifications…. Stage 0 Stage 1 Stage N

What are the tradeoffs when moving from a traditional sequential product design approach to an overlapped product design approach? Time to market is smaller in the overlapped design But the schedule is more vulnerable (which requires additional monitoring) Can add further resources to tasks to reduce duration--but costs are increased

Project Teams and Organizational Relationships
Chapter Project Teams and Organizational Relationships

Role of Project Manager and Team
Client Top Management Project Manager Subcontractors Project Team Functional Managers Regulating Organizations This structure is what makes being a project manager both very interesting and very challenging!

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.

Project Team What is a project team? Characteristics of 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)

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

Artistic Viewpoint “I design user interfaces to please an audience of one. I write them for me. If I’m happy, I know some cool people will like it… As for schedules, I’m not interested in schedules; did anyone care when War and Peace came out?” Developer, Microsoft Corporation As reported by MacCormack and Herman, HBR Case : Microsoft Office 2000 However, is this comment a reasonable one for most project management environments?

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

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 “Project Management Performance: A Comparison of Team Characteristics”, IEEE Transactions on Engineering Management, 37, 2,

Group Harmony: High vs Low Performing Groups
High performing (low cost) groups Low performing (high cost) groups High performing groups began with lots of conflict!

Extent of Individual Contribution: High vs Low Performing Groups
High performing (low cost) groups Low performing (high cost) groups High performing groups began with individual contributions low!

Decision Making Effectiveness: High vs Low Performing Groups
High performing (low cost) groups Low performing (high cost) groups High performing groups began with slow decision making!

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?

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?

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?

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

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.

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)

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 Zelda Larry Curly Moe Barby Leslie Comments: bureaucratic, confusing, stressful

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

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

ANOVA Results by Organizational Structure
An exception occurs here Controlling Meeting Technical Overall Cost Schedule Performance Results Organizational Structure N Mean (SD) Mean (SD) Mean (SD) Mean (SD) Functional A 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* A,B < C,D,E Scheffe Results E < D A,B < C < D,E A,B < C,D,E A,B < C,D,E The results are statistically significant at the p<0.01 level Higher values represent greater success

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

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

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

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 _______ Level or Intensity Low<-->High Find the mean ______

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 _______ Level or Intensity Low<-->High Find the mean ______

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.

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

Current Management Culture
Level or Intensity Low<-->High Ability to manage in an autonomous mode Percentage of time assigned to projects Quality of reporting process Percentage of resources fully dedicated to projects Level of control over budget and management of resources Level of control over budget allocation and expenditures Ability to make independent decisions about technical choices and tradeoffs Project-specific systems and procedures already in place Project resources located together Physical separation from parent organization ________ Find the mean ______

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.

Scoring Model Application: Control System Project
A major utility is functionally structured with culture unsupportive of project needs Management systems cannot serve project needs for planning, control, general administration Severe shortage of specialized human resources, as they are badly needed for ongoing operations High strategic importance: technical failure could result in a major public catastrophe Medium to large project: cost is around $200 million, and project duration is 6 years

Decision Model: Control System Project (cont.)
Strong need for innovation: control system of a large and complex distribution network needs to be replaced. Members of the project team participated in the design of existing control system in the 1970’s, but the new system is very complex and state of the art. Strong need for integration: contributions from many tech departments are needed and are highly interdependent Medium-high environmental complexity: many external interfaces and high dependency on suppliers, because of highly specialized consulting services and software/hardware and because the number of potential suppliers is extremely small. The project impacts many users who have to be involved in design and implementation. Industry in turmoil; inability to terminate contracts, bankruptcies,…

Decision Model: Control System Project (cont.)
Project is very politically sensitive, because of the visibility the press has given to the shortcomings of the present system. Medium budget/time constraints: There is no hard deadline for the new system, but the risk of severe problems in the existing system is too high after the target date. Cost issues are not critical, but they receive close attention from top management. Medium stability of resource loading: the level of internal resources assigned to the project varies from phase to phase, but the most critical resources will be with the project throughout. Budget allocation and expenditures are tightly controlled by the overall organization. The accuracy of the financial reporting system is low: poor control system, significant potential for human error.

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?

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?

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

Precedence Networks and The Critical Path Method (CPM)
Chapter Precedence Networks and The Critical Path Method (CPM)

Precedence Relationships
Several types of precedence requirements occur in practice. Finish-to-start (FS = a): Task B cannot start until a days after task A is finished Start-to-start (SS = a): Task B cannot start until a days after task A has started Finish-to-finish (FF = a): Task B cannot finish until a days after task A is finished Start-to-finish (SF = a): Task B cannot finish until a days after task A has started The most common precedence network has FS = 0.

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.

Precedence Networks: Activity-on-Node (AON)
B C D Start End

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 C: (2, end) Task B: (start, 1) Task D: (1, end) Dummy task: (1, 2)

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

Critical Path Method: AON with Two Paths
The minimum time needed to complete a project is equal to the length of the longest path through the network; this path is known as a Critical Path. Activities along the critical path are called Critical Activities. Task A 7 months Task B 3 months End Task C 11 months Start

CPM Example 1: AON Calculations
ESB = 7 LFB = 11 ESA = 0 LFA = 8 Step 1. Work ES calculations forward. Step 2. Set LFEND=ESEND. Step 3. Work LF calculations backward. ESStart = 0 LFStart = 0 Task B 3 months Task A 7 months ESEnd = 11 LFEnd = 11 Start End Task C 11 months ESC = 0 LFC = 11 ESj = Earliest starting time for task (milestone) j LFj = Latest finish time for task (milestone) j

Example 1: Network Paths and Lengths
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

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

CPM Example 2: AON Network
Ta sk A 14 w k s D 12 E 6 B 9 C 20 F START END

Example 2: Network Paths and Lengths
Thus, START-A-D-F-END is a critical path.

Example 2: CPM Calculations
(EFi) (LSi) ESD=max{ESA+tA, ESB+tB}=max{0+14, 0+9}=14. LFD=min{LFE-tE, LFF-tF}=min{35-6, 35-9}=26.

CPM Example 2: AON Network
ESA=0 LFA=26-12=14 ESF=14+12=26 LFF=35-0=35 ESD= max{14,9} =14 LFD= min{35-9,35-6}=26 Ta sk A 14 w k s Ta sk F ESEND=35 LFEND=35 ESSTART=0 LFSTART=0 9 w k s ESB=0 LFB=26-12=14 Ta sk D 12 w k s START END Ta sk B 9 w k s Ta sk E ESC=0 LFC=35-6=29 6 w k s ESE=max{0+20,14+12}=26 LFE=35-0=35 Ta sk C 20 w k s

Types of Slack Total Slack (TSi) assumes no delays at other tasks (i.e., all the noncritical tasks before i use their ES times, and all the noncritical tasks after i use their LS times) Free Slack (FSi) assumes no delays at earlier tasks, but allows delays at later tasks (i.e., all the noncritical tasks use their ES times) Safety Slack (SSi) assumes no delays at later tasks, but allows delays at earlier tasks (i.e., all the noncritical tasks use their LS times) Independent Slack (ISi) allows delays at all other tasks (i.e., all the noncritical tasks before i use their LS times, and all the noncritical tasks after i use their ES times)

Example 2: Calculating Total Slack (TSi)
Total Slack for task i = TSi = LFi - ESi - ti

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)

Slack Calculations: Example
Ta sk A 14 w k s Ta sk F ESSTART=0 LFSTART=0 9 w k s Ta sk D 12 w k s START END ESE=26 LFE=35 Ta sk B 9 w k s ESC=0 LFC=29 Ta sk E 6 w k s TSC=LFC-ESC-tC = =9 SSC=LFC-LFC,max-tC =LFC-LFSTART-tC = =9 Ta sk C FSC=ESC,min-ESC-tC =ESE-ESC-tC = =6 20 w k s ISC=max(0,ESC,min-LFC,max-tC) =max(0,ESE-LFSTART-tC) =max(0, )=6

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

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 ≥ 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

LP Model for Example 2 Minimize END Subject to:
STARTD ≥ FINISHA = STARTA + 14 STARTD ≥ FINISHB = STARTB + 9 STARTE ≥ FINISHC = STARTC + 20 STARTE ≥ FINISHD = STARTD + 12 STARTF ≥ FINISHD = STARTD + 12 END ≥ FINISHE = STARTE + 6 END ≥ FINISHF = STARTF + 9 STARTA, STARTB, STARTC ≥ 0

Simplified LP Model for Example 2
Minimize END Subject to:

Extension of LP Model: Enforce Early Start Times
How to ensure that all tasks are started at their earliest possible times.

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

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)

AOA: Precedence Networks
2 1 Start End Task A 4 Weeks Dummy task Task B 2 Weeks Task C 7 Weeks Task D 10 Weeks Task A: (start, 2) Task C: (2, end) Task B: (start, 1) Task D: (1, end) Dummy task: (1, 2)

AOA: Computing Earliest and Latest Occurrence Times
TL2=5 1 2 Start End Task A 4 Weeks Dummy task Task B 2 Weeks Task C 7 Weeks Task D 10 Weeks TEEND=12 TLEND=12 TESTART=0 TLSTART=0 Step 1. Work TE calculations forward Step 3. Work TL calculations backward TE1=2 TL1=2 Step 2. Set TLEND=TEEND

Slack Calculations for AOA
TSij = Total slack for Task (i,j) FSij = Free slack for Task (i,j) SSij = Safety slack for Task (i,j) ISij = Independent slack for Task (i,j) Interpretations are the same as in AON.

Slack Values for AOA: Example
Task Duration (tij) Earliest Start Time (TEj) LatestFinish Time (TLj) Total Slack (TSij) Free Slack (FSij) Safety Slack (SSij) Indep. Slack (ISij) A: (START, 2) 4 5 1 B: (START, 1) 2 Dummy (1,2) 3 C: (2, END) 7 12 D: (1, END) 10

AOA: Calculating Slack
TE2=4 TL2=5 TSSTART2=1, FSSTART2=0 SSSTART2=1, ISSTART2=0 TS2END=1, FS2END=1 SS2END=0, IS2END=0 2 Task A 4 Weeks Task C 7 Weeks TEEND=12 TLEND=12 Start End Dummy task TS12=3, FS12=2 SS12=3, IS12=2 TESTART=0 TLSTART=0 Task D 10 Weeks TSSTART1=0, FSSTART1=0 SSSTART1=0, ISSTART1=0 Task B 2 Weeks 1 TS1END=0, FS1END=0 SS1END=0, IS1END=0 Step 1. Work TE calculations forward Step 3. Work TL calculations backward TE1=2 TL1=2 Step 2. Set TLEND=TEEND

LP Model for AOA Network
Decision variables: the occurrence time of each node

Planning to Minimize Cost
Chapter Planning to Minimize Cost

Project Budget The budget is an important communication link between the functional units and the project Should be presented in terms of measurable outputs, which correspond to work packages in the WBS Should clearly indicate project milestones Establishes goals, schedules and benchmarks, and assigns resources to tasks Serves as a baseline for progress monitoring and control

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

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.

Project Budget Example
Ta sk A 14 w k s D 12 E 6 B 9 C 20 F START END ES = 26 LF = 35 = 14 = 0 = 29

Cost for Resource A worker = $400/week Cost for Resource B worker = $600/week

The total duration is 35 weeks

Weekly Costs (Cash Flows)
Example 2 from Chapter 4

Cumulative Costs

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)

Cash Flow Example Make payment of $5000 Receive payment of $3000 M1 M2
END START Task B 8 mos Receive payment of $3000 Make payment of $5000 Task C 4 mos Task A 2 mos M2 Task D Task E 3 mos

Cash Flow Example: Solver Model
Objective: Maximize NPV 10 11 12 13 14 15 16 17 18 19 C D E F F19=F13+F15+F18 See cashflow analysis.xls on the CD

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 End Start 2 units 30 units LSEND=17 A total of 32 units of resource must be acquired. What is the best ordering policy?

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

• To minimize holding costs, only place orders at Latest Start times • Can never reduce total costs by delaying the project Time Demand: Order option #1: 32 Order option #2: Choose the option that minimizes inventory cost = order cost + holding cost of raw materials

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

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.

Time / Cost Tradeoff Example
7 wks 15 wks Critical path with makespan 22 6 wks 10 wks Assume constant marginal crash cost, i.e. linear cost of crashing Assume task C cannot be crashed below 13 weeks

Time / Cost Tradeoff Example
Project Duration (weeks) Critical Path(s) Task(s) Reduced Total Direct Cost 22 Start-A-C-End - $320 21 A $328 Start-B-C-End 20 C $338 19 $348 18 A, B $361 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

Linear Time / Cost Tradeoff
Even where the duration of a task can be reduced by assigning additional resources to it, in practice there is always a lower limit on task duration. 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 =

Time / Cost Tradeoff Using LP
Assume marginal cost of crashing task j is bj = (CjC-CjN)/(tjN-tjC) > 0 Decision Variables: Sj = starting time of task j END = end time of project tj = duration of task j The following model allows us to minimize the total direct cost required to complete the project by time Tmax Minimize total direct cost = s.t. Sj ≥ Si + ti, for all tasks i that immediately precede job j tjC ≤ tj ≤ tjN, for all tasks in the project END ≥ Sj + tj, for all tasks in the project tj , Sj ≥ 0, for all tasks in the project END ≤ Tmax

Minimizing Total Cost Project duration Cost Overhead costs Direct costs Total cost Crash time Normal time Minimum cost solution Here we assume that overhead costs are proportional to project duration.

Minimizing Total Cost The following model allows us to minimize the total of direct and indirect costs 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.

Planning with Uncertainty
Chapter Planning with Uncertainty

The Effects of Uncertainty
The most obvious effect is that uncertainty in a task duration causes late completion of that task. Depending on the criticality of that task, this may delay overall project completion. Effective planning can reduce uncertainty or mitigate its effects. The more uncertain a task when it is initiated, the more monitoring and control are needed to ensure effective performance. There are three additional mechanisms by which uncertainty interacts with project management practice to create problems.

Uncertain Task Durations
It is widely assumed that, in many projects, task durations follow the beta distribution shown below Pessimistic time, tjp Most likely time, tjm Optimistic time, tjo Completion time of task j Time Probability density function Expected time, m

Standard Approximations for Task Durations
For each task, we need three estimates: most optimistic time, most pessimistic time, most likely time, In practice, how easy is it to estimate these? These formulas are designed to approximate (simply, but not very accurately) the beta distribution.

More Accurate Approximations
The approximations on the previous page are most commonly used in practice, because they are oldest and simplest. However, the approximations of Perry and Grieg (1975) shown below are more accurate. Note that these approximations require the estimation of slightly different data, which could be easier (or harder) to estimate.

Three Mechanisms by which Uncertainty Creates Problems
1. Parkinson’s Law 2. Procratinasting Workers 3. Schonberger’s Hypothesis

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 16.0 E(T1) E(T2) So the expected makespan is 24

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 T1 Values of T2 * * * E[T(D)] = 25 days *makespan expanded to fit deadline

Mechanism 2: Procrastinating Workers
A procrastinating worker waits until the last possible time to start (given the expected duration of their task). Set a deadline D = 24 days E’[T(D)] = E(T1) + E(T2) + E{max[0, D - T1 - E(T2)]} * Delayed by procrastinating worker, who starts tasks 1 day later. * We can show that E[T(D)] ≥ E’[T(D)] ≥ D. What are some possible solutions? Provide incentives for early completion, set tight deadlines However, unreasonably tight deadlines may have other negative effects (stress, loss of quality, turnover,…)

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.

Example of Schonberger’s Hypothesis
The longest expected path length = 14

Example of Schonberger’s Hypothesis
This is an enumeration of all possible events. Expected duration equals days Increasing the variance of Task A: Now, the expected duration = days

Traditional Model of Uncertainty - PERT
Program Evaluation and Review Technique Traditional Model of Uncertainty - PERT Task times are assumed to be random variables Assume all task times are statistically independent (when is this realistic?) Use values of mj, the expected time of task j, to identify the expected critical path The time of any event (e.g., ESk) is now the sum of independent random variables. So the Central Limit Theorem says that ESk is approximately normally distributed with mean E[ESk] and variance Var[ESk] Expected early start time of task , where S is a path from the start of the project to task k.

PERT Model Thus, we have several results: Expected project duration:
Variance of project duration: Using Central Limit Theorem and standard normal distribution: Look up the result in the z table Also: given on time completion probability, we can find Tmax.

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

PERT Example 1 See PERT example 1.xls Pr(z≤Zi)
Var(A)+Var(C) = ( )/Sqrt(7.36) E(A)+E(C)= Pr(z≤Zi) PERT expected duration = PERT variance = See PERT example 1.xls

PERT Example 1 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 PERT assumes that the path with the longest expected duration will still be the critical path when all the activity durations are known.

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

PERT Example 2 Expected makespan=12 + 3 = 15
Task B m B = 12 s 2 = 4 Task D D = 3 = 1 Task A A = 2 Task C C = 10 = 5 END START Expected makespan= = 15 Variance of makespan = = 5

PERT Example 2 START->B->D->END E[ESEND]=15 and Var[ESEND]=5
Classic PERT estimate 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: Thus, classic PERT overestimates the probability of completion on time (i.e., is too optimistic) 0.81*0.872=0.706

Example 3: Discrete Probabilities
μj Expected project duration from PERT = 19.3 weeks.

Probabilities of paths being critical
Example 3 This is an enumeration of all possible 36 combinations of events. Probabilities of paths being critical

Criticality Indices (probability of each task being critical):
Example 3 Length of CP's Prob. Cumulative Prob. 10 0.004 11 0.008 12 0.012 15 0.108 0.120 19 0.019 0.139 20 0.158 21 0.177 24 0.224 0.401 25 0.599 1.000 Since the analysis enumerates all events, these probabilities are exact. Criticality Indices (probability of each task being critical): Expected Project Duration = >> 19.3

Calculating Confidence Intervals
To calculate a confidence interval, we can use the sample mean and the estimated standard error of the mean. Using a normal approximation, a (1- a) two-sided confidence interval is given by: Example: =27.65, s=4.25, and n=200 trials, where s is the sample standard deviation and n is the number of trials. Project Makespan Lower Limit Upper Limit 95% confidence interval 27.07 28.24 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

Monte Carlo Simulation (PERT Example 1)
Beta Distribution Task Duration Criticality index for task B Recall that PERT expected duration = (i.e., much too optimistic) See PERT example 1.xls 95%: 27.14±(1.96)(4.095)/√200=27.14±0.58 99%: 27.14±(2.56)(4.095)/√200=27.14±0.76

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.

Critical Chain Project Management
CCPM Critical Chain Project Management Background A modern approach to dealing with uncertainty in project management (an alternative to PERT) Developed by Goldratt (1997) to apply concepts from the “Theory of Constraints” to project management The fundamental principle is to identify and protect the only thing that is critical – the overall project completion time

CCPM Critical Chain Project Management Critique of Traditional Project Management When individual tasks have slack built into them to deal with uncertainty, this slack proliferates and Parkinson’s Law applies. The proliferation of slack is due to: - poorly aligned incentives, sandbagging - need to allow for urgent external distractions - conservative use of statistics - assumption that all tasks may take longer than expected As a result, projects routinely (a) take longer than necessary to complete and (b) fail to meet due dates.

CCPM Critical Chain Project Management Eight Principles 1. Build the project schedule without safety time, i.e. use 50th percentile estimates of task durations. 2. Drop the notion of due dates and accept the possibility of delays. 3. Identify and protect critical resources (and don’t worry so much about noncritical resources). 4. Aggregate all the required safety time in a project buffer at the end of the critical path.

CCPM Critical Chain Project Management Eight Principles (cont.) 5. For the critical resources, identify their lead (i.e., startup) times. This information defines resource buffers. 6. Fast and slow completion of tasks will tend to cancel out, at least in part, enabling a reduction (possibly better than 50%) in the project buffer size. 7. For noncritical activities, the only priority occurs where they feed into the critical chain. Protect these points with feeding buffers. 8. The project is controlled by buffer management, instead of due dates. Monitor the amount of time remaining in buffers, and if necessary trigger contingency plans. See coursepack article: Patrick (1998).

Critical Chain Buffers
CCPM Critical Chain Buffers Project buffer End 1 2 2 days 1 day Task C2 5 days

Calculating Project Buffer Size
CCPM Calculating Project Buffer Size For those “who want a scientific approach to sizing buffers....” For task k on the critical chain, we can calculate the required project buffer using the following formula, assuming that the project will be completed within worst-case duration estimates around 90% of the time, and is the most pessimistic estimate of task k’s duration: Like PERT, uses only longest path For example 1, the buffer is: Sqrt[( )2+( )2+(7-5.00)2+(7-4.33)2]=9.51

CCPM Critical Chain Project Management Critique of CCPM 1. Overestimation of task durations, and application of Parkinson’s Law, are not widespread problems. Some empirical studies support this view. 2. Shortening deadlines reduces task managers’ motivation. 3. There is no scientific basis for setting buffer sizes. 4. It is not clear how much of a feeding buffer to allocate to different successor tasks when there is more than one.

CCPM Critical Chain Project Management Critique of CCPM (cont.) 5. Buffer calculations based on resource leveling output may be inaccurate, since this is a hard problem to solve. 6. What if the critical chain changes during the execution phase? 7. Buffers tend to clutter up Gantt charts and create confusion. 8. Resource buffer information obtained from outside contractors may not be reliable (especially if they are unusually busy). See coursepack article: Raz et al. (2003)

Chapter Risk Management

Introduction to Risk Management
Risk management is the practice of dealing with risk, which includes: Planning for risk Assessing risk issues Developing risk handling strategies Monitoring risk Risk management should be consistent with: overall project management, systems engineering, cost, scope, quality and schedule Risk management is often more effective and cheaper when proactive rather than reactive

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

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

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

Tornado Diagram Rank by largest cost range on top
Project Cost ($000’s) Rank by largest cost range on top

Sensitivity Chart Rank by correlation with total project cost, largest
Wage Rate Direct Labor Hours Material Units Needed Early Completion Bonus Material Unit Costs Interest Rates Energy Costs Overhead Rank by correlation with total project cost, largest absolute value on top

Simple Risk Analysis Risk Exposure (RE) or Risk Impact =
(probability of unexpected loss) x (size of loss) Example: Additional features specified by new client request Loss: 3 weeks Probability: 20 percent Risk Exposure = (.20) (3 weeks) = .6 week What are the limitations of this analysis?

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

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

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)

Managing Risk in Contracts
General Form: Payment to Subcontractor = Fixed Fee + (1 - B) (Project Cost), where B = cost sharing rate Cost Plus Contract Fixed Price Contract B = 0 Risk Continuum B = 1 Subcontractor’s Risk Client’s Risk

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

Risk Management Strategies: Overview
4 Types of Strategies Control (within manager’s control) Ex: schedule, budget, documentation Negotiation (partly within manager’s control) Ex: soft issues, interactions, relationships Research (further information required) Ex: undetermined technology and scope risks Monitoring (wait and see what happens) Ex: risks to business or market environment H. Taylor, Project Management Journal, 2006 205

Risk Management Strategies: Control
Best Control Strategies Perform detailed analysis of work breakdown structures Closely monitor each task’s progress Design contracts to control scope change Respond to schedule problems initially by increasing overtime Reschedule the remaining tasks following a delay 206

Risk Management Strategies: Negotiation
Best Negotiation Strategies Control scope changes through a detailed assessment of client needs Perform trust- and relationship-building activities Manage client’s expectations Balance cost, schedule and scope Perform team-building activities within the project team As a last resort, escalate problems to the client’s executive 207

Risk Management Strategies: Research
Best Research Strategies New technology risk is not viewed as threatening, because project staff find it interesting to work on Avoid customization if possible Avoid negotiation with internal developers Take no explicit actions (and just monitor the project) 208

Risk Management Strategies: Monitoring
Best Monitoring Strategies Maintain situation awareness using constant surveillance Apply triggers to initiate more intense monitoring when needed (such as when dealing with external contractors) Delay any decisions about how to respond to a problem until the problem materializes 209

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

Van Allen Company: Tasks

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

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?

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

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

Van Allen Company: Minimum Cost Solution (No Strike Considered)
Task Duration Immediate Predecessors Starting Times Finish Crash Time Cost (100$) Normal Slope Marginal Cost Incr START - A 5 3 60 40 10 B 1 50 30 20 C 6 7 70 24 D 2 4 E 12 F C, D 17 90 11 G 13 15 H I E, G END F, I, H Totals 530 310 74 Slope=(crash cost – normal cost)/(normal time – crash time) Indirect cost=$12*17 days=204 Total cost=$310+$70+$204=$588

Van Allen Company: Minimum Cost Solution (Strike Considered)
Task Duration Immediate Predecessors Starting Times Finish Crash Time Cost (100$) Normal Slope Marginal Cost Incr START - A 5 3 60 40 10 B 1 50 30 20 C 6 7 70 24 D 2 4 E 12 F C, D 17 90 11 G 13 15 H I E, G END F, I, H Totals 530 310 74 The same table as the previous page. Total expected cost: $588 + $12*3.8*0.7=$619.92

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

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

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

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)

Resource Leveling Example
Duration tj

Resource Leveling Example: Early Start Schedule
F F E E B B E D D D D D G G G G A A A G C C C C C C C C C The maximum number of workers needed is 21.

Resource Leveling Example: Late Start Schedule
F F A A A C B B C C C C C C C C Now the maximum number of workers needed is only 16.

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

Renewable Resource Allocation Example 1 (Single Resource Type)
Ta sk B 3 w k s D 5 ks A 4 E START END C 1 3 workers 5 workers 6 workers 8 workers 7 workers Makespan: 12 weeks Maximum number of workers available = R = 9 Resource allocation question: Is this schedule feasible?

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?

Resource Allocation Example 1: Early Start Schedule
Maximum number of workers available = R = 9 workers Worker-weeks needed = = 101 Minimum “wasted” worker-weeks at start of project = 3

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

Resource Allocation Example 1: Late Start Schedule
Maximum number of workers available = R = 9 workers Minimum “wasted” worker-weeks at end of project = 8

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

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 = = 97, which is less than the 101 required worker-weeks, so 9 workers cannot finish within 12 weeks At least = 112 worker-weeks are required to finish the project, so at least 112/9 = > 13 weeks are needed to complete the project using 9 workers At least 112/12 = > 10 workers are needed to complete the project in 12 weeks

Resource Leveling / Allocation Heuristics
Heuristics are simple rules of thumb for prioritizing tasks in resource leveling and resource allocation problems, and can be implemented in MS Project. Here are some heuristics for assigning priorities to available task j, where denotes the number of units of resource k used by task j. FCFS: First available task GRD: Largest resource utilization × task duration = GTS: Largest total number of successors

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

Resource Allocation Example 2

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 GC PC Makespan=20

Minimizing Project Duration
But, can we do better? Is there a better priority rule? Shortest Processing Time (SPT): C1 B1 A1 GC 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 C2 B2 A2 PC 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 Now the makespan is reduced to 16. Which heuristic works better depends on the project data.

Microsoft Project Solution (Resource Leveling Option)
A1 A2 B1 B2 C1 C2 Solution by: Microsoft Project Makespan=17 days (excluding weekends), but we know from the previous page that 16 days is possible!

Non-Renewable Resources
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.

Non-Renewable Resources: Comparing Solutions
Cumulative resources supplied (given) Cumulative resources required (using LS times) Cumulative resources required (using ES times) Using LS times always works best, since they allow the most time for resources to be delivered. Weeks

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?

Teaming Example A C B D Start End 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. Configuration 2: Bob and Barb work independently. Bob is assigned to tasks A and C; Barb is assigned to tasks B and D.

Teaming Example 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 = 30 -> 30/2 = 15, because they work twice as fast as a pair

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

Expected Project Makespan: 16.42
Teaming Example Bob and Barb work independently. Bob is assigned to tasks A and C; Barb is assigned to tasks B and D Expected Project Makespan: 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

Monitoring and Control
Chapter Monitoring and Control

Control Systems Formal systems: accounting, periodic status reports, scheduled milestone meetings, internal audits, client reviews, and external benchmarks Informal systems: meetings, , and just walking around and asking project team members questions

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

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 Managing Development Risk in Product Design Processes. Operations Research 47, See coursepack article: Staw and Ross

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

Control System Example 1
Week 2: Task expenses = 460 worker-hours Actual Is the task “out of control”? Planned

Week 3: Task expenses = 500 worker-hrs 100 200 300 400 500 600 1 2 3 4 Week Worker-hours Actual Planned Again, is the task “out of control”?

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)

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

Performance Metrics for Example 1
Week BCWS ACWP Percent of work completed (PWC) BCWP 1 400 420 23% 368 2 800 880 50% 3 1,200 1,380 85% 1,360 4 1,600 1,500 100%

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% 3 1,200 1,380 85% 1,360 160 4 1,600 1,500 100%

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% (80) 3 1,200 1,380 85% 1,360 (20) 4 1,600 1,500 100% 100

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% (80) 3 1,200 1,380 85% 1,360 (180) 4 1,600 1,500 100% 100

Time Variance (tV) Time Variance = (BAC * PWC) – Current Time
After week 3 tV =4 * 85% - 3 =0.4 (weeks) BAC: Budget at Completion PWC: Percent of Work Completed Week BCWS ACWP PWC BCWP tV 1 400 420 23% 368 (0.08) 2 800 880 50% 3 1,200 1,380 85% 1,360 0.4 4 1,600 1,500 100%

Earned Value Metrics Illustrated
Worker-Hours Week 1 Week 2 Week 3 Week 4 Week 5 Week 6 Present time BAC Actual Cost (ACWP) Earned Value (BCWP) Planned Value (BCWS) Schedule Variance (SV) Cost Variance (CV) Budget at Completion

Relative Measure: Schedule Index
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

Relative Measure: Cost Index
If CI = 1, then work completed equals payments If CI > 1, then work completed is ahead of payments (cost saving) If CI < 1, then work completed is behind payments (cost overrun)

cumulative

Progress report at the end of week #5: Cumulative Percent of Work Completed: Worker-Hours Charged to Project:

Progress report at the end of week #5: SV=BCWP-BCWS CV=BCWP-ACWP

Worker-Hours

Cumulative Percent of Work Completed:
Using a Fixed 20/80 Rule Cumulative Percent of Work Completed: Assume that 20% of a task’s work is completed when it is started, and 80% when it is finished SV=BCWP-BCWS CV=BCWP-ACWP

Using a Fixed 20/80 Rule Worker-Hours

Updating Forecasts: Pessimistic Viewpoint (Example 2)
Assumes that the rate of cost overrun will continue for the life of the project.

Updating Forecasts: Optimistic Viewpoint (Example 2)
Assumes that no further cost overruns will occur. Estimate at Completion (EAC) = BAC – CV = = worker hrs

Managing Multiple Projects
Chapter Managing Multiple Projects

Introduction Most organizations maintain a portfolio of projects in order to maximize and level resource utilization, and to diversify and minimize organizational risk Resources are sometimes shared among projects, so decision making in a multiple project environment is more complex than in the case of a single project Most project management software packages do not handle multiple projects effectively

Types of Project Portfolios
Task-oriented project portfolios Independent project portfolios Interdependent project portfolios Source: M. Dobson The Juggler's Guide to Managing Multiple Projects. PMI.

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

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

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

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

Outline Introduction Priority approach Multitasking approach
Team–designed approach Comparison of results Conclusions

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

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

Priority and Multitasking Approaches
How to prioritize among multiple projects? Consider two projects (A and B) that need to be performed by the same project team Priority Approach: A has priority over B Project A 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

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

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

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

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 2 3 5 4 6 7 8

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

Single Project Blue task A Blue task B Red task 1 Red task 2
Roll Value Blue task A Blue task B Red task 1 Red task 2 Green task Week Completed___

Priority Approach: Results
Single projects Completion time: Multiple (three identical) projects Total completion time: Makespan:

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

Multiple Projects: Multitasking Approach
Roll Value 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___

Multitasking Approach: Results
Multiple projects Total completion time: Makespan:

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

Multiple Projects: Team-Designed Approach
Roll Value Project R Week Completed___ Project S Week Completed___ Project T Week Completed___

Team–Designed Approach: Results
Multiple projects Total completion time: Makespan:

Multiple Projects: Comparison of Results
Priority Approach Total completion time: Makespan: Multitasking Approach Total completion time: Makespan: Team-Designed Approach Total completion time: Makespan:

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)

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?

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 tasks per project (average = 24); 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

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

Heuristics to schedule tasks: First in system, first served (FCFS) Shortest task from shortest project Minimum slack based on due date Minimum late finish based on due date Minimum task duration from the shortest remaining project

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 Evaluating Project Scheduling and Due Date Assignment Procedures: An Experimental Analysis. Management Science, 34, 1,

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), 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), Fox, T.L., J.W. Spence. Tools of the Trade: A Survey of project management tools. Project Management Journal, September 1998.

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), Hodder, J.E., H.E. Riggs. Pitfalls in evaluating risky projects. Harvard Business Review (1985), Mulder, L. The importance of a common project management method in the corporate environment. R&D Management 27 (1997), Oltra, M.J., C. Maroto, B. Segura. Operations strategy configurations in project process firms. International Journal of Operations and Production Management 25 (2005),

Cited References 3 Patrick, F.S. Critical chain scheduling and buffer management Pinto, J.K., O.P. Kharbanda. How to fail in project management (without really trying). Business Horizons, July-August 1996, 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,

MBA 820

Project Management a System approach to Planning Scheduling & Controlling - Harold Kerzner.

Similar presentations

Presentation on theme: "Project Management a System approach to Planning Scheduling & Controlling - Harold Kerzner."— Presentation transcript:

Similar presentations

About project

Feedback

Log in

Auth with social network:

Project Management a System approach to Planning Scheduling & Controlling - Harold Kerzner.

Similar presentations

Presentation on theme: "Project Management a System approach to Planning Scheduling & Controlling - Harold Kerzner."— Presentation transcript:

Similar presentations

About project

Feedback