Better Software - September 2008 - (Page 47) The Last Word Keys to Top-Notch Estimates by Howard Smallowitz and George Stark If the construction industry estimated projects as poorly as the IT industry does, we would still be living in mud huts. Yet inaccurate project estimates have become the norm in the IT industry. Consider the following facts: • According to the Standish Group, only 29 percent of all projects are successful [1]. • In one study of 250 software development projects, 175 had major schedule delays and cost overruns, or were terminated without completion [2]. • Several white papers have identified inaccurate project estimates as one of the top causes of troubled projects [3, 4, 5]. Sometimes estimates amount to nothing more than gut feelings. Project managers try to focus on trying to calculate a project down to the last hour of effort or budget dollar. Rarely is either approach successful. With the benefit of painful experience behind us, we believe that the following ten keys can actually turn project estimates into reasonable predictions of project performance. Find something that you can count that is a meaningful measure of the project scope. The literature is full of proposals: lines of code, function points, raised floor space, use case points, story points, etc. Just make sure that whatever you count is highly correlated to the amount of work to be done and can help to normalize the quality. Remember: Targets are not estimates. This is a hard one for many managers to understand. Just because someone would like the scope delivered by the end of the quarter, doesn’t mean it is possible. Use multiple techniques for computing the estimate and involve independent peer reviews. There are a lot of tools and approaches to estimating—topdown, bottom-up, spreadsheets, tools, heuristics, Monte Carlo simulation, etc. They all give different answers, but if you compare them and they can be delivered in are all “close,” you probThe earlier you are in precisely fifty-eight calably have a good estimate. endar days for exactly Let other people review the $123,956. You’ll avoid a project, the stupider trouble if you round up approach and the outcome in a formal peer review to such estimates to two ensure that no major mis- you are. So don’t expect your months and $125,000. takes were made. We have Make sure your esfound that a second set of timate is complete. We first off-the-cuff estimate to be don’t just mean that it eyes has uncovered potentially disastrous mistakes. should include all necLearn from the past; spot on. essary work items and don’t forget it. Collect hispeople. We mean that torical data on completed you must estimate evprojects and then actually use it when erything that needs to be estimated. Too making estimates for new projects. many people think a project is successful Without historical data, variation in pro- if it delivers on time and on budget. cesses, tools, and people cannot be visu- However, it is easy to meet a schedule or alized. Understand the impact of quality cost target by descoping work or delivlevel, systems engineering, and manage- ering garbage. Estimates should be clear ment overhead on the estimate. about the scope of the work to be delivTreat estimation as a process and take ered and the expected quality. steps to make it mature. Perform estimaDocument, document, document. Be tion maturity assessments, identify gaps, sure to document the assumptions and and take steps to improve. Measure esti- constraints that went into your estimate mation accuracy. Reduce common cause and include them with the estimate. It’s variation sources as much as possible. easier than polishing up your résumé. Iterate estimates. The earlier you {end} are in a project, the stupider you are. rEfErEncEs: So don’t expect your first off-the-cuff 1] PMI Today. September 2005. estimate to be spot on. Revise your esti2] Jones, Capers. “Software Project Managemates as you learn more. ment Practices: Failure Versus Success.” Always include boundaries that define CrossTalk. Software Technology Support Center, a range of possible results. The Project October 2004. Management Institute recommends that 3] “Troubled Projects.” CBP Research News. initial estimates, sometimes called orderwww.pmsolutions.com/uploads/pdfs/Troubled of-magnitude estimates, should have an %20Projects%20Research%20Summary.pdf accuracy range of -25 percent to +75 4] “Major Causes of Software Project Failures.” percent. Budget estimates, which often CrossTalk. Software Technology Support Center, are used just to get initial funding and July 1998. www.stsc.hill.af.mil/crosstalk/1998/07 project approval, should be defined as /causes.asp having an accuracy range of -10 percent 5] “Troubled Project Telltales” (White Paper). to +25 percent. Even final, definitive eswww.advalueservices.com/Advalue_White_Paper_ timates, prepared from well-defined, deTelltales_Troubled_Projects.pdf tailed data should specify a range of -5 6] A Guide to the Project Management Body percent to +10 percent [6, 7]. of Knowledge (PMBOK Guide), third edition. Avoid presenting estimates that Project Management Institute, 2004. promise levels of specificity you cannot 7] Project Management Professional Study deliver. For example, early in a project Guide. Osborne McGraw-Hill, 2003. it’s impossible to predict that the work www.StickyMinds.com SEPTEMBER 2008 BETTER SOFTWARE 47 http://www.pmsolutions.com/uploads/pdfs/Troubled%20Projects%20Research%20Summary.pdf http://www.stsc.hill.af.mil/crosstalk/1998/07/causes.asp http://www.stsc.hill.af.mil/crosstalk/1998/07/causes.asp http://www.advalueservices.com/Advalue_White_Paper_Telltales_Troubled_Projects.pdf http://www.StickyMinds.com
For optimal viewing of this digital publication, please enable JavaScript and then refresh the page. If you would like to try to load the digital publication without using Flash Player detection, please click here.