1 / 168

PERT Estimation for Project Time and Cost

Learn about the PERT technique for estimating project time and cost, and how to use MS Project for crashing activities. Explore concepts such as task mean, standard deviation, project variance, total project duration, and more.

glove
Download Presentation

PERT Estimation for Project Time and Cost

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. TODAY PERT REVIEW (last part of B: Ch 7) More MS Project Crashing (B: Ch 8) 4. Time and Cost Estimation

  2. PERT (Program Evaluation and Review Technique) B:Ch 7 & S:247 • Last part of Burns, chapter 7 • Not supported by MS Project 2013 • Gives you probabilities of completion of a project by a certain time • Calculates a standard normal random variate (as the sum of the task durations which are beta-distributed) and uses a probability table to find its probability

  3. PERT INPUTS • A = most optimistic time • M = most likely time • B = most pessimistic time

  4. PERT formulas—uses a Beta Distribution • Task mean = (A + 4*M + B)/6 • Task Std. Dev. = (B-A)/6 • Project mean = sum of all the task means of tasks on the critical path • Project std. Dev = sum of all the task standard deviations of tasks on the critical path

  5. Activity and Project Frequency Distributions FIGURE A7.1

  6. The Beta Distribution • Is a better fit that any other distribution to the natural randomness of the task duration • Finite tails • Skewed—not symmetric

  7. ````finalized PERT numbers``` • Total project duration = sum of all task durations of all critical tasks = sum of all tasks durations on the critical path---this is a random variate that is approximately ‘normal’ even though the individual task durations are beta-distributed • Total project variance is the sum of the individual critical task variances • From these numbers and a standard normal table we can find probabilities of project completion by a certain date

  8. In MS Project, the tool that is used to establish sequencing among the activities is the ________. • indent arrow on the tool bar • linking tool on the tool bar • resource assignment tool • insert link menu item under the insert tab

  9. In MS Project, the tool that is used to designate subordination as displayed in the WBS is ________. • indent arrow on the tool bar • linking tool on the tool bar • resource assignment tool • insert link menu item under the insert tab

  10. In MS Project, by default, working weeks are assumed to be • eight-hour days • five-day weeks • no work on Saturdays or Sundays • all of the above

  11. In order to see total project duration and total project cost as well as meta-task durations and costs, it is recommended that you ________. • include a project summary task as your first task under which all other tasks are subordinate • insert a cost column in the Entry table • replace the Entry table with the Cost table in the Gantt view • a. and b. only

  12. In MS Project, by default any link between tasks (activities) is assumed to be ________. • Finish/Start • Finish/Finish • Start/Start • Start/Finish

  13. ________ is a probabilistic scheduling technique while ________ is deterministic, with ________ being most widely used in commercial software. • CPM, PERT, CPM • PERT, CPM, CPM • CPM, PERT, PERT • PERT, CPM, PERT

  14. Free slack and Total slack (S:240-241) • Free slack—the amount of time an activity can be delayed without delaying the early start date of any immediately following activities • Total slack—is the amount of time an activity can be delayed from its early start without delaying the planned project finish dates (without delaying the entire project)

  15. Crashing (Discussed in Burns, Ch. 8) • 1) Enumerate all of the paths in a table showing duration of each • 2) Pick an activity on the CP (Critical Path) with the lowest crash cost per day and crash it to its minimum duration if possible, but not so far back that the critical path is no longer critical and not so far back that you exceed the budget • 3) Show the effects on each path’s duration in the table

  16. 4) Reduce the budget by the amount spent on the crashing step • 5) Continue with steps two through four until all of the budget is used up. • NEVER CRASH THE CRITICAL PATH BEYOND THE POINT WHERE IT IS NO LONGER CRITICAL (THAT IS, SOME OTHER PATH HAS BECOME CRITICAL).

  17. Estimating Task Durations

  18. Estimating: A Definition • Forecasting or approximating the time and cost of completing project deliverables. • Balancing the expectations of stakeholders and the need for control while the project is implemented.

  19. Why Estimating Time and Cost Are Important • To determine how long the project should take and how much it should cost. • To support good decisions. • To schedule work. • To determine whether the project is worth doing. • To develop cash flow needs. • To determine how well the project is progressing. • To develop time-phased budgets and establish the project baseline. EXHIBIT 5.1

  20. Where does Estimating occur within PMBOK? • What process groups? • What knowledge areas? • Can you name some of them?

  21. Answers • The initiating and planning process groups • In the Time Management and Cost Management Knowledge Areas • Time Management • Estimate Activity (Task) Resources • Estimate Activity (Task) Durations • Cost Management • Estimate Costs

  22. Estimation • What are the inputs to these processes? • What tools and techniques? • What are the outputs

  23. Process: Estimate Activity Durations INPUTS 1. Activity list 2. Constraints 3. Assumptions 4. Resource requirements 5. Resource capabilities 6. Historical information TOOLS 1. Expert judgment 2. Historical data 3. Analogous estimating 4. Simulation OUTPUTS 1. Activity duration estimates 2. Basis of estimates 3. Activity list updates

  24. Tools and Techniques for Estimating Processes • Calibration and Historical Data • Individual Expert Judgment • Decomposition and Recomposition • Estimation by Analogy • Proxy-based Estimates • Expert Judgment in Groups • Software Estimation Tools • Use of Multiple Approaches

  25. Estimation Methodologies • Most firms have their own methodology • Standard Procedures, established by the PMO (Project Management Office) • Once again, what do we estimate? • Resources • Time • Cost • Effort

  26. Some Bad Methodologies • Guessing • Intuition, hunches • Unstructured expert judgement • Informal analogies • THESE ARE USED 60% TO 85% OF THE TIME

  27. WHAT IS MORE IMPORTANT?What does your firm value more? • An optimistic forecast? • Lower cost? • Less time? • NO! A predictable, reliable forecast IS MORE IMPORTANT!! • Commitments depend on reliable estimates • Commitments to customers, investors, suppliers, the marketplace and other stakeholders

  28. The Cost estimation Story—Steve McConnell • You can’t tell exactly what its going to cost until you know exactly what IT is. • (Which is why we spent so much time talking about thorough product requirements)

  29. Estimates depend strongly on requirements • If you are estimating the cost of a new house, features are an important issue—fireplace? Granite countertops? Glass backsplashes? Ceramic tile tub-surrounds? Stainless appliances? • If it’s a 15-digit phone field to support direct, long-distance international dialing, then will the client want phone number validation? Cheap version (USA only) or expensive (international)?

  30. Missing Functional Requirements • Setup/installation program • Data conversion utility • Glue code needed to use third-party or open-source software • Help system • Deployment modes • Interfaces with external systems

  31. Missing Nonfunctional Requirements • Accuracy • Interoperability • Modifiabillity • Reliability • Reusability • Scalability • Usabiliity

  32. Software Activities Commonly Missing from Estimates • Ramp-up time for new team members • Mentoring of new team members • Cutover/deployment • Data conversion • Customization • Requirements clarification • Supporting the build • Creation of test data • Management of the beta test program • Participation in technical reviews • Integration work • Processing change requests

  33. Software Activities Commonly Missing from Estimates • Attendance at change-control meetings • Coordinating with subcontractors • Performance tuning • Learning new tools • Administrative work related to defect tracking • Answering questions from quality assurance • Creating user acceptance tests • Demonstrating acceptance tests to users • Demonstrating software at trade shows • Demonstrating prototypes

  34. Non-software Development Activities Commonly Missing from Estimates • Holidays • Sick days • Training • Company meetings • Department meetings • Installing new versions of tools

  35. In your project plans…. • Include the above non-software activities as contingency • Add 10% to your project cost and duration • You will not be showing this on your MS Project charts • You will do this external to MS Project

  36. Differentiate Estimates from Targets and Commitments • “We will have it done in three months” • “Why three months???” • “Because that is when the trade show happens…” • This is a target—NOT AN ESTIMATE

  37. A commitment is NOT an estimate • “It absolutely has to be done by August 1, 2016!!” • “WHY?” • “Because that is when it was promised to the customer!!” • THIS IS A COMMITMENT—NOT AN ESTIMATE

  38. Is it better to overestimate or under estimate Effect Cost Schedule Underestimation Overestimation <100% 100% >100% Target as a Percentage of Nominal Estimate

  39. A Rule of Thumb with regard to Estimation of Testing • The time to design, document and code a module = • equals the time to debug it (TEST IT) • According to Gildersleeve

  40. Estimating Rules (Rakos) • Get group concensus estimates if possible • Never force an estimate on a programmer • Never take an average of different estimates • Granularize down to FOUR or less weeks, roughly • Add 10% for contingency • Always quote a range when giving estimates • Especially for strategic and budgetary estimates

  41. Rakos’ Conclusions to Estimating • Our weakest talent • Estimating is iterative • Estimating is still an art

  42. Purposes of Estimating • For strategic planning—twoto five years out—rough—for calculation of ROI, IRR, NPV—portfolio and program management • For budgetary purposes—two years out—more detailed, specific, accurate • For immediate execution of the project—the most accurate, based on actual assigned resource hourly rates--Definitive

  43. Review: Project Time Management Processes • The time management knowledge area involves the processes required to ensure timely completion of a project. Processes include: • Plan schedule management • Define activities • Sequence activities • Estimate Activity resources • Estimate Activity durations • Develop Schedule • Control Schedule

  44. A Task Duration Process when no history database and no expert is available • Assign the task to a project player • Ask the player how long it will take him or her to complete the task (This gives the player ownership in the planning) • Player provides their best estimate • The player understands that they will be required to complete the task within their estimate—their feet will be “held to the fire”

  45. Player Time Estimation: Goldratt • Claims team players add safety to their estimates • What is safety?? • Safety is NOT slack • Safety is the extra time that you add in order to be completely certain that you will get it done on time—like taking your estimate and doubling it!

  46. Estimating Projects • Types of Estimates • Top-down (macro) estimates: analogy, group consensus, or mathematical relationships • Bottom-up (micro) estimates: estimates of elements of the work breakdown structure

  47. Factors Influencing the Quality of Estimates Planning Horizon Other (Nonproject)Factors ProjectDuration Quality of Estimates People OrganizationCulture PaddingEstimates Project Structure and Organization

  48. Top-Down versus Bottom-Up Estimating • Top-Down (Macro) Estimates • Are usually derived from someone who uses experience and/or information to determine the project duration and total cost. • Are made by top managers who have little knowledge of the processes & resources used to complete the project. • Bottom-Up (Micro) Approach • Can serve as a check on cost elements in the WBS by rolling up the work packages and associated cost accounts to major deliverables

  49. A bottom-up approach using WBS • An expert is asked to estimate how much effort in weeks is required to complete a WBS consisting of 10 work packages • His estimate—22 weeks, considering the project in its entirety and not the work packages • A team of non-experts is also asked to estimate, but they did it on a work package-by-work package basis • Their estimate—27 weeks//ACTUAL: 29 weeks

More Related