Steve McConnell says that every software professional thinks that he/she knows what an estimate is. He goes on to say that an estimate is very different from what people think and a good estimate is even more different. He says that software professionals are not asked for a tentative or preliminary calculation – that is, - an estimate where people can change their mind later. Most probably, most of the times, when the executive asks for an estimate, he/she is asking for a commitment or for a plan to meet a target.
The distinction between estimates, targets, and commitments are critical in understanding what an estimate is, what an estimate is not and how to make estimates better.
An estimate is a prediction of how long a project will take or how much it will cost. People are requested to bear in mind that an estimation on software projects interplays with business targets, commitments and control. This is very important since this interplay can sometimes lead to change of the project assumptions, which make the estimation useless.
A target is a statement of a desirable business objective. Examples include the following
- We need to have software delivery by end of November
- We need to have this release stabilized in 3 months
- These functions need to be completed by July 1st so that we will be in compliance with government regulations.
While a target is a description of a desired business objective, a commitment is a promise to deliver defined functionality at a specified quality level by a certain date. A commitment can be the same as the estimate, or it can be more aggressive or conservative than the estimate. McConnell goes on to say that while estimation and planning or related topics, estimation is not planning and planning is not estimating.
Estimation should be treated as an unbiased, analytical process; planning should be treated as a biased, goal-seeking process. Estimates form the foundation of plans, but the plans don’t have to be the same as estimates. Both estimation and planning are important, but the fundamental differences of the two activities mean that combining the two tends to lead to a poor estimates and poor plans.
Here are some of the examples of planning considerations that depend in part on the accurate estimates.
- Creating a detailed schedule
- Identifying a projects critical path
- Prioritizing functionality for delivery
- Breaking projects into iterations
McConnell says that estimations real purpose is not to predict a project’s outcome; it is to determine whether a project’s targets are realistic enough to allow the project to be controlled to meet the targets. If the targets are realistic enough, then the project parameters can be adjusted to meet the targets. If the projects targets are not realistic, then the targets need to be brought into reality before the manager can control the project. This is one area where most of the projects fail. Bad estimates and unrealistic targets are always a recipe for project disaster.
McConnell defines a good estimate as an estimate that will provide enough clear view of the project-reality to allow project leadership to make good decisions about how to control the project to hit the targets. ‘Controlling the project to hit the target’, is what project management is all about and good estimate is absolutely essential for this. Understanding what a good estimate is, as mentioned above, helps a long way in achieving this.
I have always been a fan of Steve McConnell's books since i read 'Rapid Development' and 'Code Complete', I find this book also to be very interesting and i will share more interesting and useful information from the book as i read it.