Project Estimating – Do Your Own Thing
Source –
After 30 Years of
Project Estimating, What Have We Learned?
Precise project estimating techniques are much like the Indian Rope Trick; everyone has heard about it but nobody has ever seen it. In the late 70’s, code-based or LOC (Lines Of Code) models laid the foundation for quantified analysis, but they became outdated with the advent of 4GL development languages and CASE tools. Function Point Analysis gained much notoriety in the late 80’s and early 90’s as THE definitive estimation technique, but its Achilles Heel was the conversion factor used to translate the function point count into durations that were meaningful for each development organization. A number of object-based estimating tools with a user query interface emerged during the same period, but just like Function Points, they relied on accurate historical benchmark data from the user organization. And Barry Boehm’s famous cost-driven CoCoMo model, even in its latest updated version, presupposes a traditional waterfall development and is useless for iterative or spiral life cycles.
The Rule of Thumb is
There is No Rule of Thumb
Many of these tools and techniques are still used today, and with some success. So which is the best to use? The answer is none of them. Or all of them. The key is to pick and choose and apply your own ‘house blend’ of methods to the project you are estimating, based on what kind of estimate the stakeholders want. They might ask for an initial ball park estimate, in which case you can use standard macro or ‘top down’ estimating methods such as ‘Analogous Estimating’ where you compare it to similar projects, or ‘Expert Reference’ from knowledgeable sources like vendors or consulting firms, or even company old-timers who know internal productivity rates. If your shop demands more than a +/- 75% ‘Order of Magnitude’ accuracy, then you will have to resort to various micro or ‘bottom up’ estimating methods. Let’s look at both approaches.
Macro Estimating - Size Matters
Top Down approaches tend to focus on only a few key project indicators to derive an estimate. The key ones are project size and complexity. As for project size, the most basic measures are simply small, medium and large, with a corresponding total effort/duration taken from industry standards for a particular type of development, such as C++ or Powerbuilder. Vendors or Web searches can often yield effort/duration statistics. The other part of the equation is complexity, usually expressed as some kind of numerical weight factor or multiplier.
So now you are ready to come up with a total project duration. Just take your project size duration and multiply it by your complexity factor. Of course, that assumes you can accurately assign size and complexity. Here’s where you must develop your own Personal Estimating Process, or PEP as we will call it.
Drag out some historical project
documentation on a few projects, between three and five, that were done in your
shop. If no documentation exists, find
out who were the PM’s or project primes on some past
projects and talk to them. Start with
the one with the shortest duration and compare it to the longest duration
project. Look for characteristics or
‘objects’ that differentiate the smallest from the largest project. Categorize them as either size related or
complexity related and turn them into queries that you can ask on new projects,
such as ‘How many
Micro Estimating – Objectify This
Once a project has got the approval to move beyond the Concept stage, detailed planning is required to set out the tasks and activities against which progress will be tracked, so accurate micro estimating, or ‘bottom up’ estimating is the right approach. Even more than macro estimating, there are many established techniques such as the IFPUG sponsored Function Point method or the LOC-based SEI sponsored technique. The common element among them is they all rely on empirical development quantities which are measured for each task. This is the right approach, but there are many tasks that are intellectual in nature and don’t lend themselves to numerical accrual.
The solution once again is to develop your own combo plate of techniques and add them to your PEP portfolio. For development type tasks, you can use one of the many code-based measurement techniques. You can also develop your own object-based estimation formula. To do this, pick a good development type task and ask a few of your programmers (one junior, one intermediate, one expert) how long it would take them to do it. Get them to tell you what factors or ‘objects’ they used to determine its effort and apply them to this simple formula:
(Num Objects) x (Effort per Object) x (Adjust Factor) = Total Work Time
The adjustment factor is a multiplier you can use to take other variables into account, such as the level of developer expertise, efficiency of technology, etc. So, for the above formula, say your senior developer says the task involves four modules and will take 8 days and your junior developer says the same task will take 12 days. Now you know that this type of task takes an average of 10 days, or 2.5 days per module object with an adjustment factor of 1.2 for novices or .8 for experts. Of course, there are many other factors which qualify as objects which you must build into our formula, but you get the idea. Add the formulae to your PEP repertoire and fine tune it with experience.
For tasks that defy all
quantification efforts, you must survey the best subject matter experts you can
find. You can apply one or both of two
established methods; the three point method, also known as weighted average,
and the nominal or
(Best
Case) + (Worst Case) + (Most Likely x 4) = Work Effort
6
The
The Politics of Accuracy
It must be remembered that precision estimating will not necessarily bring you the big rewards. Nobody wants to hear the truth when it comes to how long it will really take to do some work. Be mindful to differentiate the estimates that are for ‘show’ and those upon which your integrity as a project manager depend.