Approximately Right or Precisely Wrong?

An important question a client in the I.T. Services world seeks to know from a vendor is “How long will it take to finish this project?”.

No one dare responds, “It’s done when it’s done”; certainly, none of the vendors over there.

Welcome to the world of estimates.

The purpose of estimates is to help give a sense of predictability. It is about reducing or mitigating risk by making sure promises are not made about things that can’t be delivered. Setting expectations on the whole, is a team responsibility, and estimates is one way of communicating that message to stakeholders.

An estimate is a finite approximation of cost, effort and/or duration based on some knowledge (the basis of estimation). Estimates account for the work of the entire team, communication overhead, and delivery. Any work that people do should be accounted for in the estimate. Estimates are about sharing assumptions, predictability, and about making the best decisions possible with the information available at the time, with the people who are best equipped to make them.

There are different levels of estimates including budgetary (project level, an interval estimate), high-level estimate (for a specific release) and task planning (detailed, day level, point estimate).  

In an ideal context, for a project team, estimation is a tool used to understand how much work the team can get done without burning out. Plus, estimates get revised whenever there is new information available.

Unfortunately, even overall project level budgetary estimates are often viewed as a firm number that isn’t supposed to exceed the lower range value. They tend to get used as some form of a bat to beat the team with if they don’t deliver. Vendor teams are consistently flooded with requests for highly specific, all-inclusive point estimates based on complex and vaguely described requirements. When, in fact, they are mere educated guesses made when everyone (including the client team) knows least about the work involved.

More often than not, under duress, a vendor’s project team provides unrealistic or inaccurate estimates which have the potential to put to risk a project’s success by lowering quality, violating deadlines, or leaving the project incomplete as a result of budget overruns.

When the time for delivering an I.T. project is underestimated, as the deadline approaches the pressure mounts, the team starts to work extra hours, defect count spikes, and fixing defects becomes difficult. In such a situation, team members tend to burn out because of the overtime, and due to this even more issues crop up, and before one realizes, the project will be in a downward spiral. All issues impact each-other causing an enormous increase in cost, effort and time and a significant loss in quality.  Leaves everyone with a bad taste. Yet, strangely, these things happen again and again. Many a times due to the archaic ways of “vendor management”, plus the tendency of service providers to “win the deal at any cost” - even when unreasonable client expectations or unviable financials are staring at their face.

 In case of overestimation, even if something bad happens, there is usually time to recover. But in an outsourced, competitive situation, it is likely to throw a vendor out of the reckoning and also hurt carefully nurtured relationships.

In any case, accurate estimates are a rare phenomenon.

Once a project starts, if the frequency of estimations (and thereby, re-planning) is high, it affects the rhythm of project execution and the team’s productivity. Core team members end up spending a disproportionate time in understanding the change, evaluate the impact and estimating what it could take to deliver that change. Time is also spent in explaining, discussing and convincing stakeholders. The “irritability” increases in estimating for unnecessary changes and for valid changes that don’t get the nod. Such “futile exercises” result in the team deeming such estimation and planning as a waste. It is a no-brainer that the primary planned tasks from where they took their eyes and hands off, are likely to get into trouble. A double whammy. Most of the times, this painful reality is not seen and factored in an objective and dispassionate manner by the stakeholders.

However, all issues fade to the oblivion, when a mutually respectful and trusted relationship exists at all levels, between a client and its I.T. services vendor. In such relationships, both parties truly believe that estimation is a significant part of the budgeting and adaptive planning in programs and projects they undertake.

There is certainly merit in continuously improving the methods of estimation and estimation accuracy. Hashtag rallies around #NoEstimates have appeared at times for exploring alternatives to estimates for making decisions in software development. They haven’t gathered much steam. So, can software be delivered without doing estimates?  For now, there are no alternatives. Estimates are here to stay.