Understanding Estimates, Plans, Targets and Commitments

Started to browse Steve McConnell’s “Software Estimation – De Mystifying the Black Art “and find the book very interesting, practical and could relate to what he says. I have given below the fundamental ideas from the book – ideas that are elementary and concepts that we always tend to mix-up or miss altogether, most of the time.

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.

It is very important for each software-professional to understand that businesses have important reasons to establish targets independent of software estimates and it is important for each business person to understand that a desirable target does not necessarily mean that it is achievable. This distinction is very important for all of us to understand and it is the duty of each of us to educate our customers about this.

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

Another important point about an estimate is that the number produced by an estimate has always a probability associated with it. Most of the time people tend to associate 100% probability with the estimate. McConnell suggests that we should ask for the probability when we see a single point estimate.

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.