Monday, February 25, 2008

February 26, 2008 – Estimating Lessons Learned - Intro

“How long to add text messages to the data transfer communication link?” the director asked.

The project manager was obviously hesitant to give an answer. “We haven’t really considered it yet. Why do you ask?”

“I’m heading to a meeting and the question may come up.”

“I would need more time to think it through completely but just for discussion purpose, I would ball park the figure at roughly $50,000 and a 6 month effort. Don’t hold me to it, though.”

Unfortunately for the PM that was the number that ended up on the IT budget for the next year. It started as little more than a wild guess and suddenly became a commitment. Lesson 1 – never give an estimate over the phone.

Types of Estimates. There are many different names for estimates: Rough, Ball Park, SWAG, Big Picture, Budgetary and Final to name a few. Each name attempts to convey the accuracy of the figure. All of them fall on the continuum between three points: Rough Order of Magnitude, Budgetary and Definitive.

The accuracy of the Rough Order of Magnitude (ROM) Estimate ranges from -25% to +75% off. That means a $100,000 estimate can be as low as $75,000 or as high as $175,000. It is the type of estimate usually given when very little is known about the project but management needs to decide whether to move forward or not.

A Budgetary Estimate is put together at the time the Project Charter or Statement of Work is defined. At this point enough is know about what is in and out of scope that boundaries can be established. The accuracy range is between -10% and +25% ($90K and $125K for our $100K project).

The Definitive Estimate range is between -5% and +10% ($95K and $110). This estimate is done based on detailed project information that, in IT, comes after the Requirements or Design phases.

Lesson 2 – not all estimates are created equal…on purpose. This is a fact that needs to be communicated to management and business a like. Set their expectations up front. When they request an estimate, ask what type they are expecting and how they are going to use it. Explain the range of accuracy and the level of effort as well as information required to make it more accurate.

Lesson 3 – don’t confuse people with artificially accurate estimates. By announcing your “rough estimate is $1,633,284.16” you are implying that every paper clip is already counted. Estimates should end in zeros. Past PMs I have worked with issue initial estimates like 1433 hours. This accuracy is impossible even if your scope is well defined and resources are already assigned in your detailed project schedule at the task level. At least round the number to 1450 if not 1500. Ending in a 3 implies precision that doesn’t exist.

Next week we will look at estimating methods and learn that technique is only half the issue.

4 comments:

Badge number ? said...

On the contrary-publishing an estimate of 1,433 hours may be entirely appropriate, unless there's a general disclaimer and/or policy noting that all estimated in a named range are rounded up to the "developer day" (five or six hours) or to a calendar week.

Generally I avoid spontaneous schedule adjustments-over time, they'll distort the schedule and play havoc with historical analysis of estimating accuracy. Any moderately quantitative sponsor or executive stakeholder should question estimates that always end in "0", because it signals subjectivity in the estimating process, and that's somethign we don't want.

Thomas Cutting said...

See March 3rd entry for response.

Anonymous said...

I agree with the principles described.
Where did the accuracy ranges for the 3 levels come from?
For example I am used to Ballpark +40 -20%, Budgetary +20 - 10%, Definative +10 -5%.

Is there any general agreement on the ranges?

Thomas Cutting said...

I believe the percentages came from the PMI Body of Knowledge. The exact numbers are not as important as communicating to everyone what they represent. As long as everyone agrees you can pretty much name it whatever you think makes sense.