How many of the following flights of fancy have you participated in?
You’ve been told when the software has to ship, so building the project schedule becomes an exercise of nipping off a day or two here, throwing more resources there, rationalizing that some dependencies don’t really exist, and hoping that nothing unexpected will happen. Voila, at the end of the exercise, you have a schedule whose end date corresponds exactly with when the software has to ship. Amazing coincidence? Not usually.
No matter where you are in the chain of command, you may have your own set of ‘fudge factors’ to apply to estimates. If you are a developer, they can go in either direction – you can repeatedly tell yourself that you won’t run into the problems that you have in the past and assume you will get things done twice as fast this time around, or you can anticipate that currently unidentified problems will occur and you can pad your estimates by a factor of two or more to build in your own contingency. As a manager, over time you will get to know your team and their performance against their estimates, and can build up fudge factors of your own – “Bob’s a 2.5 guy; his estimates are always way low.” Often the fudge game escalates from round to round as the players try to out-fudge their opponent – “Jane thinks I’m a 2.5 guy, so I’ll shave my estimates accordingly, but double them because she’s working us to a crazy deadline and I don’t want the short end of the stick…”. What ever happened to the thing we were originally estimating?
Other times, you may find that technology is your path to obfuscation. It may arrive in the guise of a new estimation tool or model that is all the rage, and is based on tons of industry data. Plug in your numbers, weak as they may be, and the results look impressive (and defendable). Worse yet, you may dive into the guts of the model to find the parameters that feed the model, and use it to provide the answer you are looking for (recall the first case…) – “…let’s see…I’ll just tweak up this Productivity Parameter, whatever that is, and hey! – there’s the answer I was looking for, that’s our ship date!” The phrase ‘the model told me so’ isn’t often defendable.
According to Webster’s Dictionary, a delusion “…is an erroneous view of something which exists indeed, but has by no means the qualities or attributes ascribed to it…” From my experience, I would suggest that the vast majority of what we call estimates in this industry fall into that category. By the time all the dancing is done, the estimates on which we base our commitments often have nothing to do with the scope to be developed at all.
We are often all contributors to the delusion of credible estimates, as we are blinded to some degree by our hopes, passions, and credulity. We need to be careful to respect an estimate for what it should be – a technically defendable view of how long it should take to complete a task, along with a perspective of the uncertainty associated with that value.
There is no room in an estimate for fudge factors, optimism, covering your butt, or any of the other elements that can drive us to delusion. Handled with care, estimates can become a strong tool to help you deliver successful projects. Handled poorly, the delusions will drive you down an unpleasant path every time. – JB