It is also true that you quite legitimately think of features and functionality you would like after we’ve begun. You naturally assume something is “in” when we assume it is “out.” And, in the spirit of openness, can you honestly say that you've never tried to put one over on us? (Let’s not even talk about bugs right now; it just complicates everything.)
Frankly, given all of this, it is touching that you have so much faith in technology to deliver. But, when IT does deliver, boy, it delivers big. Look what it did for Bill Gates and Larry Page, or Amazon and FedEx. Isn't it interesting that when the IT industry develops things for itself, we end up with multi-millionaires. When we develop for other people, they end up loosing money.
How did we ever talk you into any of this? Well, we package up this unsightly mess and try to sell it to you. To do this, we have to hide all this unpleasantness. We start with a ritual called estimation—how much time we think the work will take. These “estimates” are little better than guesses. Humans can’t estimate. We've known this since at least the late ‘70s, when Kahneman and Tversky described the “planning fallacy” in 1979 and went on to win a Nobel Prize. Basically, humans consistently underestimate how long work will take and are overconfident in their estimates.
To make things worse, we have a bad habit we really should kick. Between estimating the work and doing the work, we usually change the team. The estimate may be made by the IT equivalent of Manchester United or the New York Mets, but the team that actually does the work is more than likely a rag-tag bunch of coders, analysts, and managers who've never met before.
Historical data—data about estimates, actuals, costs, etc—can help inform planning but most companies don’t have their own data. For those that do have data, most of it is worse than useless. In fact, Capers Jones suggests that inaccurate historical data is a major course of project failure. For example, software engineers rarely get paid overtime so tracking systems often miss these extra hours. Indeed, some companies prohibit employees from logging more than their official hours in their systems.
So, we make this guess (sorry, estimate) and double it—we might even triple it. If the new number looks too much, we might reduce it. Once our engineers have finished massaging the number, we give it to the sales folk, who massage it some more. After all, we want you to say yes to the biggest sticker price we can get. That might sound awful, but remember: We could have guessed higher in the first place.
Please don't shoot me, I'm only the messenger.
About the author
For over twenty-five years, Allan Kelly has held just about every job in the software world, including: system admin, tester, developer, architect, product manager, and development manager. Today, he is based in London and works for Software Strategy Ltd. helping companies adopt and deepen agile and lean practices through training, consulting, and coaching. He specializes in working with software product companies, aligning company strategy with products and processes.
