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