Lesson 14. Is essential to any projects Is a response to uncertainty, (if you knew how long will an activity would take or how much it would cost –

Cost EstimationLesson 14

Estimation

• Is essential to any projects

• Is a response to uncertainty, (if you knew how long will an activity would take or how much it would cost – then no need to estimate but facts)

• An estimate is not a fact. It is inherent unreliable.

• One KEY aim is to establish the degree of accuracy and therefore the degree of variance

Estimation Approaches• The last time we did

this it took…analogous Estimation• Organizational

experience• Process assets• Personal experience• Similar activities

• If it takes 1 hours to build 1m then then to build 12m should take … Parametric estimation• Pilot • Test• Sample• Prototyping

Analogous estimating is done using similar past projects or activities to estimate cost. Parametric estimating is done by determining and using a unit cost calculated over a duration or quantity of units. Parametric estimating is usually more accurate and should result in a higher confidence level.

Estimation Variance• The difference between what was estimated and

the actual performance.• How accurate are you• r estimates and how confidence are you feeling?

• Factors:• The skill and experience of the estimator• The reliability of the source data• The method used• The time spent developing estimates

THE BASIS OF ESTIMATE (TECHNIQUES)Allows the organization to benefit in a number of ways:1. The stakeholders can quickly

see the degree of risk and estimates confer.

• If the degree of accuracy is 85% then the risk exists for 15%

2. During delivery, the team able to review the estimates and improve them as additional information becomes available.

3. At the Conclusion of a project, the estimates can establish and conclude on how accurate their estimates and the methods used to obtain them

• The method used• The name of the estimator(s)• The source of the data• The rationale behind the

estimated degree of variance

Starting the basis of estimate allows compound errors to be remedied quickly and allow the project organization to develop better estimating techniques.

Estimation Best Practice• Use the most reliable

data available• Spend as much time as

possible to produce reliable estimates

• Use appropriate methods

• State the basis of estimate

• Establish best practice through lessons learned.

AGILE ESTIMATION – VIDEORELATIVE ESTIMATES• Story Points (how

long)• People (developers)• Fibonacci Sequence (60% estimates)

• Value Points (how important)• Customer• Deliver value early•Measure value and time

• Bang for the buck• Value P/Story P• Gives you priority sequence

• Iteration1 - Velocity (speed-how long)• Get the highest velocity and make it constant• Deliver project before deadline

Estimation tools and techniques(Rahul Sudame, PMP)

Additional Helpful Video and Template• Cost Estimation CRM

• Estimating Template (Excel)

Samples

A 100 things to consider when estimating software project cost• 1. Distinguish between estimates, targets, and commitments.• 2. When you’re asked to provide an estimate, determine whether you’re supposed to be

estimating or figuring out how to hit a target.• 3. When you see a single-point “estimate,” ask whether the number is an estimate or

whether it’s really a target.• 4. When you see a single-point estimate, that number’s probability is not %. Ask what the

probability of that number is.• 5. Don’t provide “percentage confident” estimates (especially “% confident”) unless you

have a quantitatively derived basis for doing so.• 6. Avoid using artificially narrow ranges. Be sure the ranges you use in your estimates don’t

misrepresent your confidence in your estimates.• 7. If you are feeling pressure to make your ranges narrower, verify that the pressure

actually is coming from an external source and not from yourself.• 8. Don’t intentionally underestimate. The penalty for underestimation is more severe than

the penalty for overestimation. Address concerns about overestimation through planning and control, not by biasing your estimates.

• 9. Recognize a mismatch between a project’s business target and a project’s estimate for what it is: valuable risk information that the project might not be successful. Take corrective action early, when it can do some good.

• 10. Many businesses value predictability more than development time, cost, or flexibility. Be sure you understand what your business values the most.

• 11. Consider the effect of the Cone of Uncertainty on the accuracy of your estimate. Your estimate cannot have more accuracy than is possible at your project’s current position within the Cone.

• 12. Don’t assume that the Cone of Uncertainty will narrow itself. You must force the Cone to narrow by removing sources of variability from your project.

• 13. Account for the Cone of Uncertainty by using predefined uncertainty ranges in your estimates.

• 14. Account for the Cone of Uncertainty by having one person create the “how much” part of the estimate and a different person create the “how uncertain” part of the estimate.

• 15. Don’t expect better estimation practices alone to provide more accurate estimates for chaotic projects. You can’t accurately estimate an out-of-control process.

• 16. To deal with unstable requirements, consider project control strategies instead of or in addition to estimation strategies.

• 17. Include time in your estimates for stated requirements, implied requirements, and nonfunctional requirements—that is, all requirements. Nothing can be built for free, and your estimates shouldn’t imply that it can.

• 18. Include all necessary software-development activities in your estimates, not just coding and testing.

• 19. On projects that last longer than a few weeks, include allowances for overhead activities such as vacations, sick days, training days, and company meetings.

• 20. Don’t reduce developer estimates—they’re probably too optimistic already.

• 21. Avoid having “control knobs” on your estimates. While control knobs might give you a feeling of better accuracy, they usually introduce subjectivity and degrade actual accuracy.

• 22. Don’t give off-the-cuff estimates. Even a -minute estimate will be more accurate.• 23. Match the number of significant digits in your estimate (its precision) to your estimate’s

accuracy.• 24. Invest an appropriate amount of effort assessing the size of the software that will be built.

The size of the software is the single most significant contributor to project effort and schedule.

• 25. Don’t assume that effort scales up linearly as project size does. Effort scales up exponentially.

• 26. Use software estimation tools to compute the impact of diseconomies of scale.• 27. If you’ve completed previous projects that are about the same size as the project you’re

estimating—defined as being within a factor of from largest to smallest—you can safely use a ratio-based estimating approach, such as lines of code per staff month, to estimate your new project.

• 28. Factor the kind of software you develop into your estimate. The kind of software you’re developing is the second-most significant contributor to project effort and schedule.

• 29. When choosing estimation techniques, consider what you want to estimate, the size of the project, the development stage, the project’s development style, and what accuracy you need.

• 30. Count if at all possible. Compute when you can’t count. Use judgment alone only as a last resort.

• 31. Look for something you can count that is a meaningful measure of the scope of work in your environment.

• 32. Collect historical data that allows you to compute an estimate from a count.• 33. Don’t discount the power of simple, coarse estimation models such as average

effort per defect, average effort per Web page, average effort per story, and average effort per use case.

• 34. Avoid using expert judgment to tweak an estimate that has been derived through computation. Such “expert judgment” usually degrades the estimate’s accuracy

• 35. Use historical data as the basis for your productivity assumptions. Unlike mutual fund disclosures, your organization’s past performance really is your best indicator of future performance.

• 36. Use historical data to help avoid politically charged estimation discussions arising from assumptions like “My team is below average.”

• 37. In collecting historical data to use for estimation, start small, be sure you understand what you’re collecting, and collect the data consistently.

• 38. Collect a project’s historical data as soon as possible after the end of the project.• 39. As a project is underway, collect historical data on a periodic basis so that you can

build a data-based profile of how your projects run.• 40. Use data from your current project (project data) to create highly accurate

estimates for the remainder of the project.

• 41. Use project data or historical data rather than industry-average data to calibrate your estimates whenever possible. In addition to making your estimates more accurate, historical data will reduce variability in your estimate arising from uncertainty in the productivity assumptions.

• 42. If you don’t currently have historical data, begin collecting it as soon as possible.• 43. To create the task-level estimates, have the people who will actually do the work create the

estimates.• 44. Create both Best Case and Worst Case estimates to stimulate thinking about the full range

of possible outcomes.• 45. Use an estimation checklist to improve your individual estimates. Develop and maintain

your own personal checklist to improve your estimation accuracy.• 46. Compare actual performance to estimated performance so that you can improve your

individual estimates over time.• 47. 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.

• 48. Use a generic software-project work breakdown structure (WBS) to avoid omitting common activities.

• 49. Use the simple standard deviation formula to compute meaningful aggregate Best Case and Worst Case estimates for estimates containing tasks or fewer.

• 50. Use the complex standard deviation formula to compute meaningful aggregate Best Case and Worst Case estimates when you have about tasks or more.

• 51. Don’t divide the range from best case to worst case by to obtain standard deviations for individual task estimates. Choose a divisor based on the accuracy of your estimation ranges.

• 52. Focus on making your Expected Case estimates accurate. If the individual estimates are accurate, aggregation will not create problems. If the individual estimates are not accurate, aggregation will be problematic until you find a way to make them accurate.

• 53. Estimate new projects by comparing them to similar past projects, preferably decomposing the estimate into at least five pieces.

• 54. Do not address estimation uncertainty by biasing the estimate. Address uncertainty by expressing the estimate in uncertain terms.

• 55. Use fuzzy logic to estimate program size in lines of code.• 56. Consider using standard components as a low-effort technique to estimate size in a

project’s early stages.• 57. Use story points to obtain an early estimate of an iterative project’s effort and schedule

that is based on data from the same project.• 58. Exercise caution when calculating estimates that use numeric ratings scales. Be sure that

the numeric categories in the scale actually work like numbers, not like verbal categories such as small, medium, and large.

• 59. Use t-shirt sizing to help nontechnical stakeholders rule features in or out while the project is in the wide part of the Cone of Uncertainty.

• 60. Use proxy-based techniques to estimate test cases, defects, pages of user documentation, and other quantities that are difficult to estimate directly.

• 61. Count whatever is easiest to count and provides the most accuracy in your environment, collect calibration data on that, and then use that data to create estimates that are well-suited to your environment.

• 62. Use group reviews to improve estimation accuracy.• 63. Use Wideband Delphi for early-in-the-project estimates, for unfamiliar systems, and when

several diverse disciplines will be involved in the project itself.• 64. Use an estimation software tool to sanity-check estimates created by manual methods.

Larger projects should rely more heavily on commercial estimation software.• 65. Don’t treat the output of a software estimation tool as divine revelation. Sanity-check

estimation tool outputs just as you would other estimates.• 66. Use multiple estimation techniques, and look for convergence or spread among the results.• 67. If different estimation techniques produce different results, try to find the factors that are

making the results different. Continue reestimating until the different techniques produce results that converge to within about %.

• 68. If multiple estimates agree and the business target disagrees, trust the estimates.• 69. Don’t debate the output of an estimate. Take the output as a given. Change the output

only by changing the inputs and recomputing.• 70. Focus on estimating size first. Then compute effort, schedule, cost, and features from the

size estimate.• to estimate size, but remember both the general limitations of simple measures and the

specific hazards of the LOC measure in.

• 71. Reestimate.• 72. Change from less accurate to more accurate estimation approaches as you

work your way through a project.• 73. When you are ready to hand out specific development task assignments,

switch to bottom-up estimation.• 74. When you reestimate in response to a missed deadline, base the new

estimate on the project’s actual progress, not on the project’s planned progress.• 75. Present your estimates in a way that allows you to tighten up your estimates

as you move further into the project.• 76. Communicate your plan to reestimate to other project stakeholders in

advance.• 77. Develop a Standardized Estimation Procedure at the organizational level; use

it at the project level.• 78. Coordinate your Standardized Estimation Procedure with your SDLC.• 79. Review your projects’ estimates and estimation process so that you can

improve the accuracy of your estimates and minimize the effort required to create them.

• 80. Use lines of code

• 81. Count function points to obtain an accurate early-in-the-project size estimate.• 82. Use the Dutch Method of counting function points to attain a low-cost ballpark estimate

early in the project.• 83. Use GUI elements to obtain a low-effort ballpark estimate in the wide part of the Cone of

Uncertainty.• 84. With better estimation methods, the size estimate becomes the foundation of all other

estimates. The size of the system you’re building is the single largest cost driver. Use multiple size-estimation techniques to make your size estimate accurate.

• 85. Use software tools based on the science of estimation to most accurately compute effort estimates from your size estimates.

• 86. Use industry-average effort graphs to obtain rough effort estimates in the wide part of the Cone of Uncertainty. For larger projects, remember that more powerful estimation techniques are easily cost-justified.

• 87. Use the ISBSG method to compute a rough effort estimate. Combine it with other methods, and look for convergence or spread among the different estimates.

• 88. Not all estimation methods are equal. When looking for convergence or spread among estimates, give more weight to the techniques that tend to produce the most accurate results.

• 89. Use the Basic Schedule Equation to estimate schedule early in medium-to-large projects.• 90. Use the Informal Comparison to Past Projects formula to estimate schedule early in a

small-to-large project.

• 91. Use Jones’s First-Order Estimation Practice to produce a low-accuracy (but very low-effort) schedule estimate early in a project.

• 92. Do not shorten a schedule estimate without increasing the effort estimate.• 93. Do not shorten a nominal schedule more than %. In other words, keep your

estimates out of the Impossible Zone.• 94. Reduce costs by lengthening the schedule and conducting the project with a

smaller team.• 95. For medium-sized business-systems projects (, to , lines of code) avoid increasing

the team size beyond people.• 96. Use schedule estimation to ensure your plans are plausible. Use detailed planning

to produce the final schedule.• 97. Remove the results of overly generic estimation techniques from your data set

before you look for convergence or spread among your estimates.• 98. When allocating project effort across different activities, consider project size,

project type, and the kinds of effort contained in the calibration data used to create your initial rolled-up estimate.

• 99. Consider your project’s size, type, and development approach in allocating schedule to different activities.

• 100. Use industry-average data or your historical data to estimate the number of defects your project will produce.