Estimating versus Guesstimating
The estimating process is iterative, meaning your first estimate is a guesstimate unless you have hard data from prior work efforts that mirror what you are trying to accomplish. Most projects sit somewhere between “It has never been before now” and “We have highly accurate data because someone has done this so often there is little doubt of what it will take to complete the project.” So the question becomes, “At what stage does guesstimating become estimating?”
When the organization is just thinking about doing something, they use the coarsest form of guesstimating called a HOM (high order of magnitude) or ROM (rough order of magnitude) estimate. Some argue the ROM precedes a HOM. An order of magnitude is a factor of 10. This means the ±- estimate could be off by as much as 10 times its value. If my estimate was 100, I could be in a range of 10 to 1,000. It is a good rule of thumb to avoid written HOMs and give a range. For some reason, people lock in on what they want to hear and will try to keep you to a number you gave six months ago with too many unknowns and too many changes since you last spoke.
A common way to estimate is to use ranges that take into consideration probability. Without digging too deep, this form of estimating considers the probability of best case and worst case scenarios. I won’t go into the full theory of it, suffice it to say it considers risk and helps to resolve the understandable reluctance IT teams have when you ask for a number and they want to consider all the things that can go wrong. Seldom do IT teams want to talk about all the things that can go right because of their aversion to Murphy’s Law. Worst case helps them feel comfortable and best case enables you to have a “what if everything goes perfect” discussion.
PERT is my preferred tool for this type of estimating. PERT stands for program review and evaluation technique. It includes estimates for a best case (BC), a worst case (WC) and a most likely (ML) scenario. PERT takes into consideration risk and opportunity. Opportunity is the best case scenario. Risk is the worst case scenario. Most likely is in between where you believe you are most likely to land. Try to avoid the pitfall of assuming it always represents the midpoint between best and worst. The formula is (BC + WC + (ML*4)) ÷ 6 where the most likely scenario is weighted 4 times that of the other two and the sum is divided by six.
If you are really stuck, you can use the rule of -25% and + 75%. This takes your most likely scenario and reduces the estimate by 25% for the best case and flexes it to +75% for the worst case.
There are many tools we can use for estimating; they can range from an activity list to something as sophisticated as calculating function points. The road map to your estimating is the work breakdown structure or WBS. Without it, your estimating efforts risk missing key dependencies and integration points.
I see estimating as having three stages after project initiation. In stage 1, you would have business requirements and a high level design, with a goal of being ± 25% accurate. In stage 2, you have a more detailed design and know your dependencies, with a goal of being ± 10% accurate. In stage 3 you have completed your first round of coding and should have a good idea of how much effort testing should take. I try to use a a target of 5% accuracy. Keep in mind the above targets will change depending on the goals and sophistication of your organization’s estimating abilities. I have managed some projects where stage 1 was ± 75%, stage 2 was ± 25% and stage 3 was ± 10%.
So when is an estimate accurate enough? That is a topic for my next blog entry.
