PERT REVIEW (last part of B: Ch 7) 4. Time and Cost Estimation

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

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) and uses a probability table to find its probability

PERT INPUTS A = most optimistic time M = most likely time
B = most pessimistic time

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

Activity and Project Frequency Distributions
FIGURE A7.1

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

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

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)

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

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

Estimating Task Durations

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.

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

Where does Estimating occur within PMBOK?
What process group? What knowledge areas? Can you name some of them?

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

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

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

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

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

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

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

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)

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

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

Missing Nonfunctional Requirements
Accuracy Interoperability Modifiabillity Reliability Reusability Scalability Usabiliity

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

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

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

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

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

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

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

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

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

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

Purposes of Estimating
For strategic planning—two to 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

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

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”

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!

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

Factors Influencing the Quality of Estimates
Planning Horizon Other (Nonproject) Factors Project Duration Quality of Estimates People Organization Culture Padding Estimates Project Structure and Organization

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

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

work package Feature Estimated weeks to complete Actual Effort raw error % of error Work 1 feature 1 1.5 3 -1.5 50% Work 2 feature 2 4 2.5 80% Work 3 feature 3 100% Work 4 feature 4 1 60% Work 5 feature 5 4.5 -0.5 11% Work 6 feature 6 6 33% Work 7 feature 7 2 -1 Work 8 feature 8 Work 9 feature 9 0.5 20% Work 10 feature 10 3.5 -2 57% TOTALS 27 29 7%

This is taking advantage of something you learned in statistics—the LAW OF LARGE NUMBERS
Decompose large estimates into small pieces so that you can take advantage of the Law of Large Numbers: the errors on the high side and the errors on the low side cancel each other out to some degree

Top-Down versus Bottom-Up Estimating
Conditions for Preferring Top-Down or Bottom-up Time and Cost Estimates Top-down Bottom-up Condition Macro Estimates Micro Estimates Strategic decision making X Cost and time important X High uncertainty X Internal, small project X Fixed-price contract X Customer wants details X Unstable scope X TABLE 5.1

Estimating Projects: Preferred Approach
Make rough top-down macro estimates. Develop the WBS/OBS. Make micro bottom-up estimates. Develop schedules and budgets. Reconcile differences between top-down and bottom-up estimates

Time Estimation--programmers
Naïve programmers have a notorious reputation for underestimating task durations and costs Programmer productivities are ‘all over the map’ Some of you can carve out 200 or more lines of code in an hour The rest of us take 10 hours to create 200 lines of code

Time Estimation—making time for creativity: SLACK
Keep in mind that customers may endeavor to put projects under extraordinary schedule pressure—more functionality for the same price. A consideration in schedule development is to take the tasks requiring creativity and place them on ____?!?

Too little time syndrome

Needed: A Rule-based Expert System for adjusting individual task durations
IF ESTIMATER IS SEASONED (EXPERIENCED) AND IF THE WORK PACKAGE REQUIRES CREATIVITY ON THE PART OF THE ESTIMATOR, THEN LEAVE ESTIMATE AS IS. IF ESTIMATER IS NOT SEASONED AND ESTIMATE APPEARS TO BE OPTIMISTIC, THEN INCREASE ESTIMATE BY 30%.

ANOTHER AI RULE IF ESTIMATOR IS SEASONED AND ESTIMATOR ASSERTS 90% OR ABOVE CONFIDENCE HE WILL COMPLETE WORK WITHIN HIS ESTIMATE AND IF WORK PACKAGE DOES NOT REQUIRE SIGNIFICANT CREATIVITY, REDUCE ESTIMATE BY 40% -- 50%

Time Estimation: Three distinct approaches not involving project team members
What are the three approaches to time estimation?? History database Relates to the organizational maturity Expert judgment Computer model or formula

Project Cost Management Processes
Plan Cost Management Estimate Costs: developing an estimate of the costs and resources needed to complete a project Determine Budget: allocating the overall cost estimate to individual work items to establish a baseline for measuring performance Control Costs: controlling changes to the project budget

Cost Estimating We need to speak the language and understand the terminology: ROI, IRR, NPV, Sunk costs Tangible and intangible costs Direct and indirect costs Learning curve theory Reserves ($ included in a cost estimate to mitigate cost risk; also called contingency reserves)

Cost Estimating An important output of project cost management is a cost estimate There are several types of cost estimates and tools and techniques to help create them It is also important to develop a cost management plan that describes how cost variances will be managed on the project

Top-Down Approaches for Estimating Project Times and Costs
Consensus methods Ratio methods Apportion method Function point methods for software and system projects Learning curves Project Estimate Times Costs

Apportion Method of Allocating Project Costs Using the Work Breakdown Structure
FIGURE 5.1

Simplified Basic Function Point Count Process for a Prospective Project or Deliverable
TABLE 5.2

Example: Function Point Count Method
TABLE 5.3

Bottom-Up Approaches for Estimating Project Times and Costs
Template methods Parametric procedures applied to specific tasks Range estimates for the WBS work packages Phase estimating: A hybrid

Table 6-2. Types of Cost Estimates--Kerzner

Estimation in General—COST or TIME
History data base Expert judgement a Model like CoCoMo—Constructive Cost Model Developed by Barry Boehm

Proposal Pricing Strategies--Kerzner
Type I Acquisition: One of a kind project with little or no follow-on opportunity win the project, perform well and make a profit Type II Acquisition: New Program with potential for large follow-on business or representing a desired surge into a new market win the project, perform well and gain a foothold in a new market segment, usually at a loss

Cost Estimation Tools and Techniques
4 basic tools and techniques for cost estimates (Schwalbe—Ch 6): Analogous or top-down: use the actual cost of a previous, similar project as the basis for the new estimate Bottom-up: estimate individual work items and sum them to get a total estimate Parametric: use project characteristics in a mathematical model to estimate costs Computerized tools: use spreadsheets, project management software, or other software to help estimate costs

Constructive Cost Model (COCOMO)
Barry Boehm helped develop the COCOMO models for estimating software development costs Parameters include source lines of code or function points COCOMO II is a computerized model available on the web Boehm suggests that only parametric models do not suffer from the limits of human decision-making

Stop here—will not test you on anything else

Lefkon’s Methodology 1. Divide the software project into as many individual steps/tasks/modules as possible. 2. Predict the level of effort required to complete each task and multiply that prediction by 2. 3. Add up the numbers and multiply by 2.0 again to account for testing and debugging. 4. Take the total and multiply by 1.25 to account for meetings, administration, and paperwork. 5. Multiply this level of effort by your company’s “magic number” for labor costs.

Lefkon’s Methodology 6. Present this to management as a range. Take the cost as predicted above and present the range as –10 percent and +25 percent. 7. Stand your ground and remind management that you did not arbitrarily come up with these numbers and they cannot be adjusted arbitrarily. You may have to suggest reducing scope and cost if management does not agree with your estimate. 8. Revise your project budget as you undertake and complete the project.

Typical Problems with IT Cost Estimates
Developing an estimate for a large software project is a complex task requiring a significant amount of effort. Remember that estimates are done at various stages of the project Many people doing estimates have little experience doing them. Try to provide training and mentoring. IT People have a bias toward underestimation. Review estimates and ask important questions to make sure estimates are not biased Management wants a number for a bid, not a real estimate. Project managers must negotiate with project sponsors to create realistic cost estimates

Table 6-3. Business Systems Replacement Project Cost Estimate Overview

Table 6-4. Business Systems Replacement Project Cash Flow Analysis

Cost Budgeting Cost budget involves allocating the project cost estimate to individual work items and providing a cost baseline For example, in the Business Systems Replacement project, there was a total purchased costs estimate for FY97 of $600,000 and another $1.2 million for Information Services and Technology These amounts were allocated to appropriate budgets as shown in Table 6-5

Table 6-5. Business Systems Replacement Project Budget Estimates for FY97 and Explanations

Designing the Baseline
One of the most crucial inputs to the pricing decision Baseline design should be started early so its cost estimates can be included in the proposal Effective pricing should begin a long time before proposal development Gives management an opportunity to terminate a bid initiative before too many resources get committed to proposal development, presentations, negotiations, etc..

Pricing Process This activity schedules the development of the work breakdown structure and provides management with two of the three operational tools necessary for the control of a system or project The third tool is the WBS

The WBS as price estimating tool
Provides the basis for effective and open communication between functional management and program/project management After pricing is complete the WBS forms the basis of a communications tool by documenting the performance agreed on in the pricing effort.

Organizational Input Requirements
After the WBS and activity schedules are established, an organizational meeting is called. The WBS is described in depth Responsibilities are clarified Costing information is solicited and collected from the responsible parties A short time fuse is usually involved in estimating/pricing which makes it all the more risky RFP’s sometimes require a response within 30 days of their submittal

Labor Distributions Functional units supply their input in the form of man-hours See Figure 14-2 Man-hours submitted are often over-estimated Man-hours are converted to dollars by multiplying by the labor rates Rates are only averages Base rates are then escalated as a % factor, based on past experience

Labor Distributions--Conflict Resolution
The reduction of man-hours is often the source of heated discussions between project and functional management Most common solution rests with the project or program manager This becomes the usual turf-fight How would you resolve all such conflicts???

A Proposal Manager Integrates the activities of the program and functional managers Insures that a robust proposal gets submitted to the REQUESTER on time

Overhead Rates Program/project costs involve both direct labor and indirect (OVERHEAD) costs Each team member should understand overhead rates If overhead rates are more than 50% of direct regular time and not chargeable to overtime, then overtime at 150% regular time may be cheaper Overhead rates in manufacturing can be %

Elements of Overhead Rates (Indirect Costs)
Building maintenance Building rent Cafeteria Clerical Consulting Corporate Salaries Depreciation of equip. Executive Salaries Group insurance Holidays Moving/storage exp. Personnel recruitment Retirement plans Sick leave Telephone/Utilities Vacation

Why are Overhead Rates of Interest to Project Management???
These rates must be included in any project cost calculation!!! The contractor is going to pay both your direct and your indirect overhead costs if yours is the winning bid Where do the costs associated with bidding and proposing go? Does anybody pay for them or are they just a SUNK cost???

Let’s REVIEW: What are the Major Cost Components?
Salary structure Overhead structure Labor hours required Cost of materials and support

Cost of Materials?? Required Software Diet coke, pizza

Materials Support Costs
Are submitted by month for each month of the project An escalation factor for material costs must be applied

Pricing out the Work—STEPS (from Kerzner, p. 738)
Provide a complete definition of the work requirements Establish a logic network with checkpoints Develop the work breakdown structure Price out the WBS

Pricing out the Work--STEPS, Cont’d
Review WBS costs with each functional manager Decide on the basic course of action Establish reasonable costs for each WBS element Review the base case costs with upper-level management

Pricing out the Work--STEPS, Cont’d
Negotiate with functional managers for qualified personnel Develop the linear responsibility chart Develop the final detailed and PERT/CPM schedules Establish pricing cost summary reports Document the result in a project plan

Smoothing out Department Man-hours
Ramp-up at project initiation and Ramp-down at project completion cause step functions in manpower requirements, as shown in Figure 14-8 Functional managers attempt to SMOOTH this out QUESTION?? Does the department have sufficient resources to fulfill the requirements?

Smoothing out Department Man-hours
ANOTHER QUESTION?? Can the departments ramp-up fast enough?

The Pricing Review Procedure
Based on Kerzner’s work Remember only 30 days to get the proposal out and this is one of 13 steps Many contractors require the actual team members to be identified in the proposal What solution comes to mind?

Systems Pricing The project pricing model (also called the strategic planning model) acts as a management information system Also provides management with an invaluable tool for performing perturbation analysis on the base case costs

Developing the Supporting/Backup Costs
Some proposals require backup support When required backup support must be included in the pricing An issue is the type of contract

Types of contracts Fixed-price (developer assumes all of the risk)
Cost-plus (contractor pays for every hour invested and thus assumes all the risk) An infinite array in between these

The Low-Bidder Dilemma
The price of your contract will definitely affect the viability of your proposal A low price on cost-plus type proposals is suspect A low price on fixed-price contracts may be perceived as impossible and undoable, or if accepted will lead to a disaster

The Price on the Proposal is always relative to:
the competitive prices the customer budget the bidder’s cost estimate IN ANY CASE, LOW PRICING WITHOUT MARKET INFORMATION IS MEANINGLESS

If its a new market for the Developer:
Cost sharing may be an effective strategy Bidding below your actual costs is commonplace Contractor’s objectives might include system life cycle cost or unit production cost

The Bottom Line on Price
THE LOWEST BIDDER IS NOT NECESSARILY THE AUTOMATIC WINNER Makes project a risky image regarding cost, performance or schedule The ability to perform under contract is a definite consideration A compliant, technically and managerially sound proposal based on past experience, with realistic, well-documented cost figures, is often chosen over the lowest bidder

Special Problems Pricing must include an understanding of cost control--how costs are billed back to the project There are three situations: Work is priced out at the department average, and all work performed is charged to the project at the department average, regardless of who performed the work Work is priced out at the dept.. average, but all work performed is billed back to the project at the actual salary of the employees who performed the work Work is priced out at the actual salary of those employees who will perform the work, and the cost is billed back the same way. This is the ideal situation

This is as far as we will go with these slides—ignore the remainder

Estimating Pitfalls The “buy-in” decision is the most serious pitfall because it means that the project will be under-funded If the customer initially defines the requirements and you (the developer) further refine them and the customer doesn’t understand what you’ve done, whose fault is it?

Estimating High-Risk Projects
Validity of historical estimates determine the difference between high-risk and low-risk projects Estimating high-risk projects is commonly done by means of the rolling wave or moving window approach For a 12-month project the first six months are estimated to level 5, while the last six months are estimated to level two only. As the project proceeds more and more of the last six months is estimated to level 5 See Figure 14-13, Kerzner

Project Risks RISKS--Factors that increase the probability that the project’s goals of time, cost and performance will not be met See Figures 14-14, and Table (Especially useful)

Common Risks include: Poorly defined requirements
Lack of qualified resources Lack of management support Poor estimating Inexperienced project manager

Tools to Aid in Risk Identification
Decision Support Systems Expected value measures Trend analysis/projection Independent reviews and audits

Six steps to risk management are:
Identification of the risk Quantification of the risk Prioritizing the risk Developing a strategy for managing the risk A contingency plan Project sponsor/executive review Taking action

The Disaster of Applying the 10 % Solution to Project Estimates
10% is taken from every on-going project to create a budget out of thin air The result is havoc on top of chaos Most high-level executive committees do not realize the impact of adopting the 10% solution A REDUCTION IN BUDGET MUST BE ACCOMPANIED BY A TRADEOFF IN TIME OR PERFORMANCE

The Disaster of the 10% Solution, Cont’d
90% of the budget generates 10% of the desired service or performance levels and the remaining 10% will generate the last 90% of the desired service or performance If there is FAT, i.e., padding, it may, however, be possible to sustain a cut in the project budget without major consequence Most projects do not have FAT

Cost vs. Performance I much prefer the word performance to quality here A 10% reduction in cost can be expected to produce much greater than a 10% reduction in performance

More on the 10% Solution 10% reduction solutions should be undertaken only after a careful impact study has been completed A far better choice is for the executive committee to cancel or de-scope some projects in order to release funds

14.19 Life-Cycle Costing (LCC)
These are the total costs to the organization for the ownership and acquisition of a product over its full life Especially appropriate for in-house software development projects, but is used in some (outhouse) contracted projects as well

Life-cycle cost breakdown
R & D Costs (Definition, Analysis) Production cost (Design) Construction cost (Programming and testing) Operation and maintenance cost Product retirement cost

Life-cycle costing process
Define the problem Define the requirements of the cost model being used Collect historical data-cost relationships Develop estimates and test results

Successful applications of LCC will:
Provide downstream resource impact visibility Provide life-cycle cost management Influence R&D decision making Support downstream strategic budgeting

Estimating Methods for LCC
Method choice is based on the problem context, operational considerations, etc. Informal estimating methods Judgment based on experience Analogy SWAG method, ROM method Rule-of-thumb method Formal estimating methods Detailed (from industrial engineering standards) Parametric

Figure 14-18 For every $12 DOD puts into R&D, $28 are needed downstream for production and $60 for operation and support After Conceptual definition and demonstration/validation, 85% of the lifecycle decisions are made and cost reduction opportunities are down to 22%

14.20 Logistics Support A frequent occurrence in software development where the developer is paid to provide after-market support in the form of operation and maintenance on the product (deliverable) Recall that after the design phase 85% of the deliverable’s life-cycle cost has been committed and the majority of the total life-cycle cost is still ahead >> 60%

Performance metrics for Products requiring Logistics Support
Suppportability--the ability to maintain or acquire the necessary human resources to support the system Readiness--measure of how good we are at keeping the product performing as planned and how quickly we can make repairs during a shutdown

Estimating -- An iterative process After Definition, 50-100% off
Definition, Analysis, Design After Definition, % off After Analysis, 25-50% off After Medium level design--within 10% A good WBS is absolutely essential to do estimating

Estimating Techniques
Professional Judgment Developer estimate History (database) Formulas

Use of Professional Judgment
Based on WBS, an expert judgment estimate is made for each work package Amazingly accurate when experts are available Often, however experts aren’t available

Developer Estimate The programmer assigned to the work package will make every effort to complete the task in the time he estimated it would take

Use of History Database
For this to work, your firm must keep a history database The database should record how long each task took and who did the task Break new projects up into tasks that have a history database 8 to 1 productivity ratio between best to worst professional

Questions, Cont’d How much of the total time does Brooks devote to Definition, Analysis and Design? 1/3 How much time to coding? 1/6 to Coding How much time to testing? 1/4 to component test and early system test 1/4 to total system test So how much time are you going to devote to testing in your projects?????

Use of Formulas COCOMO--project cost, effort, schedule, staffing for each of the phases: Preliminary design Detailed design Code and unit test System test COCOMO was developed by Barry Boehm in COnstructive COst MOdel

Inputs to COCOMO Monthly cost of staff involved
Factors indicating the general level of complexity of the software Programming practices and tools used Experience of staff Lines of LOSC--rendering COCOMO unusable

Function Points A user input User display Peripheral I/O
Restructuring data Condition checking Calculation Branching

Function point approach--BEFORE YOU LEAP
Vendor is Gordon Group It must know how many LOSC are required for each function point. It calculates LOSC based on function points it knows about and feeds this into the COCOMO algorithm

Estimacs from CA (Computer Associates)
Can take into account modern code generation tools Determines effort, but also Hardware required financial break-even analysis risk analysis maintenance costs Expensive > $20K

Estimating Programming: Function Points
D = C * ( G + J) D is the task duration in person-days C is the complexity of the task G is the assigned persons’ general experience J is the assigned professional’s job knowledge factor

Complexity Must break task down into its smallest possible repeatable functions Then add up the complexity of each function User input, user display, peripheral I/O, restructuring data, condition checking, calculation, etc. Repeatable functions are called function points. Function points are graded as SIMPLE, COMPLEX and VERY COMPLEX

Productivity Your average programmer gets a productivity factor of 1 for G Slower programmers get factors > 1 Faster programmers get factors < 1

Formula method conclusions
Will work if you develop accurate factors Can be used for any task from building a house to developing software Depends on how well you granularize

Estimating The Analysis Phase
Interviews Analyze Existing Documents and Systems Prepare Functional Specification Presentation

RATIOS PHASE PERCENTAGE Definition phase -- 10% Analysis phase -- 20%
Design phase % Programming % System test % Acceptance % Operation %

This breaks down to: PLAN -- 40% BUILD -- 20% TEST -- 40%

Another Rule of Thumb The time to design, document and code a module =
equals the time to debug it According to Gildersleeve

Can you use RATIOS for Forecasting?
Suppose you found that it took 20 days to do definition. How long, based on ratios will it take to do the project?

Estimating Rules Never use inexperienced persons to estimate
Get group estimates if possible Never force an estimate on a programmer Never take an average of different estimates Granularize down to one week or less Always add for contingency Always quote a range when giving estimates

Conclusions to Estimating
Our weakest talent Estimating is iterative Estimating is still an art

Scheduling -- Also assists with estimating, especially when PM software is used

PM software supports WBS Gantt PERT Calendar(s)
Resources and their assignments

PERT Use activity on node approach
doesn’t require dummy activities Understand what float is--it is slack Critical path is the longest path shows precedent activities, relationships doesn’t show what will be done when, by whom

Resource allocation Assign tasks to individuals whose skill level suits the task Assign similar tasks to the same person Assign time-critical tasks to your most reliable people Assign tasks that communicate to the same individual to minimize people’s interaction Don’t assign too many different tasks to any one individual

Reducing task duration by adding manpower
Add 20% direct time for each additional member on a professional team If it takes 10 person days for one person, it will take 12 person days for two people, 14.4 person days for three people, etc.

Cost effects of adding resources
More resources, gets the project done sooner, USUALLY But it also costs more The PM must come up with the best balance, depending on the priorities set by management or the user

Shortening the duration of projects
Fast tracking Crashing Adding resources to the critical path Allowing your current CP teams members to work overtime

Crashing projects Crash tasks on the critical path only, only as long as no other path becomes critical If other paths become critical, the analyst must crash those as well

Gantt Chart a time bar chart Invented by Henry Gantt in 1910
Determine the units of time Mark all known calendar events at bottom Schedule each activity from PERT

Use three sets of Gantt’s
one for yourself alone, with all float and contingency visible second for the individuals involved--their resource Gantt, contingencies hidden third for distribution to upper management--contingencies hidden Include a 10% contingency into all estimates

Conclusions to Scheduling
Use PM software--worth every penny Do at least one PERT and one GANTT manually, just to get a feel for the process

Recitation What is the probability of completing a project by its estimated completion time?? What is the formula for calculating the completion time for a PERT network? What is the formula for calculating the standard deviation of the completion time for a PERT network? Name some processes that are part of project integration management

PERT REVIEW (last part of B: Ch 7) 4. Time and Cost Estimation

Similar presentations

Presentation on theme: "PERT REVIEW (last part of B: Ch 7) 4. Time and Cost Estimation"— Presentation transcript:

Similar presentations

About project

Feedback

Log in

Auth with social network:

PERT REVIEW (last part of B: Ch 7) 4. Time and Cost Estimation

Similar presentations

Presentation on theme: "PERT REVIEW (last part of B: Ch 7) 4. Time and Cost Estimation"— Presentation transcript:

Similar presentations

About project

Feedback