Worst Practices: Confusing an Estimate with a Target

In software engineering, there is a subtle but significant difference between an estimate and a target. This difference is often overlooked, and can easily lead to conflict that disrupts the progress of a software project. With all of the other potential causes of disruption, software engineers have to eliminate as many risks of this type as possible.

Estimates

There are two ways to represent time when giving an estimate, effort and duration. Effort describes the actual person hours required to complete a task. Duration describes the amount of calendar time required to complete a task, taking into account the fact that people don’t work twenty four hours a day. Both formats are acceptable, as long as everyone understands which is being given.

The other important thing about an estimate is that it is intentionally imprecise. Estimates are meant to describe the uncertainty surrounding a task to help in project planning. Ideally, an estimate should consist of one value and a probability or multiple values with or without probabilities. Here are a few examples.

• 95% chance of delivery in two weeks
• Between seventeen and twenty four hours of effort.
• 50% chance of delivery in ten days, 95% chance of delivery in fifteen days

Targets

In contrast to the variety of ways an estimate can be expressed, a target must be represented as a single date or date and time. While estimates are used in the earlier stages of project planning, targets are used to set the final schedule and delivery dates of a project.

Although targets do not convey any information about the variability of a task’s effort or duration, that doesn’t mean that they can’t include uncertainty in their definition. Just as project a project schedule may have a managerial reserve allocated to handle unexpected challenges, a target may be built in the same way. Here are some examples of targets.

• The project will be completed by December fourth
• The project will be completed within 10 days

The Confusion

In my experience, very few people actually make estimates, and pretty much everyone wants a target, even though they call it an estimate. It seems, intuitively, that as long as everyone has the same understanding of the meaning of the words, this wouldn’t pose a problem. Maybe that’s true, but is it really worth taking the risk? One thing is for sure, a misunderstanding between parties can result in major difficulties.

Everybody in Agreement

Imagine a hypothetical project involving two people, Alan and Bob. Let’s consider a scenario where Alan must deliver an estimate or a target to Bob. Regardless of what terms are used, there are three ways for the scenario to unfold. The first possibility is that Alan gives Bob exactly what he needed. Whether it is an estimate or a target, they are both on the same page. This is ideal.

Estimate When a Target Is Needed

The second possibility is that Alan gives Bob an estimate when he really needed a target. Naturally, estimates are less accurate than targets, so it is very likely that Alan’s numbers will either be high or low. if his numbers are low, Alan may be in a tight spot when he winds up with a deadline assigned based on his estimate. If the numbers are high, Bob may balk at them and send Alan back to the drawing board. Worse yet, Bob might assign his own deadline arbitrarily. In either case, Bob may lose confidence in Alan’s ability to provide accurate information on the time required to complete a task. Over time, Alan’s “estimates” may begin to be second-guessed. This is likely to lead to open conflict and a large loss of morale.

Target When an Estimate Is Needed

The third way that the situation between Alan and Bob could unfold is that Alan gives Bob a target when Bob really needed an estimate. The results here may not seem as bad, but the effects are still detrimental to planning efforts. A target provides only a single point of data, with no information about its variability. A true estimate, while less precise than a target, offers some insight into the probabilities of the possible outcomes. In the environment of a project, there are relationships and dependencies between tasks. Variability information on the possible completion time of an individual task can be crucial for building a project schedule that is efficient, but still capable of absorbing time lost to uncertainty.

How to Avoid The Confusion

So what can you do to avoid these pitfalls? If you are Alan, the person being asked for the estimate/target, the most important thing is to understand exactly what you’re being asked for, regardless of what it is being called. In most cases, the only way to really tell is by seeing what gets done with the numbers you provide, and remembering that for the future.

If you are Bob, and must collect a target or estimate from a coworker, you are at an advantage. Since you are the one requesting the information, you have the perfect opportunity to include a precise explanation of what you need. If you are working with a target, be sure to make it clear that the information you are given will be used to define deadlines. In the case of an estimate, make sure the estimator knows that the variability information he or she includes in the estimate will be used to help plan the project.

Above all, keep the lines of communication open. Even if everyone isn’t on the same page the first time around, it is inevitable that another estimate or target will be needed soon enough. Being constructive is key in getting everyone to work together effectively, regardless of the terminology being used.