Project Management Antipattern 3: Guesses for Estimates

Basically, in IT work, we usually need to figure out, early on, if a project is "large" or "small" and budget accordingly... so we ask an experienced person or two to examine the requirements and figure, based on experience, how much it will cost.  Then, if you are in a high-ceremony process like TSP/PSP or RUP, you will go through an entirely seperate round of estimation later on, after the requirements are better understood, to figure out a "cost" to earn value against.

The first one is expected but unnecessary.  The second is simply foolish and wasteful.  Neither work very well.

A tool would be very simple to construct, using the notions of function points or story points, to meet both needs.  The basic idea of tools like these are to enter specific measurable aspects of the REQUIREMENTS into an interface, and have it produce a number of hours it will take to create the program.  These measurables can be the number of fields of data entry or data reporting, the number of new and changed user interface screens, the number of navigation pages, etc.  You actually avoid some, but not all, of the infrastructure, since those are usually choices that are made in a similar manner for each project.

You measure the first project, enter data, get a bad forecast, and use it.  Then you take the actual data from the END of the project and key it back in.  This makes the model more accurate.  You then use the estimation model to create the next estimate, this time a good one.  Keep this loop going.  After a few dozen projects (which in a large IT shop should take less than a year), you have a model that is ALWAYS more accurate than guesswork.  Always.

There was a time when using guesses for estimates was necessary.  That time is over.