Estimate acceleration: the law of doubling estimates

Saturday, August 27, 2011

Estimation is not a science, it is mostly guessing (hopefully based on prior experiences). In fact, a lot of web development is bespoke and and APIs change on a weekly basis.

Because of this, I’ve noticed that the process of estimation is handed off to various stakeholders which, in order to factor in estimation risks, inflates numbers at each level (which is okay).

In many cases an estimate originates with the folks expected to design and do the work: the Developer.

From there, its communicated to someone higher up who will spot check this for budgeting purposes: the Manager.

The estimate is then communicated (no matter the medium) to the folks responsible for the project: the Client.

This typically is elevated to someone higher up who owns the project success, budget, etc.: the Bosses.

An finally, if outsiders are to be affected (a website redesign, a new feature), some advanced communication is typically provided to: the Public.

At each step, someone is hearing a number (dollars, hours, months) and sometimes recalculating before they turn around and tell the next stakeholder. If I, the Client, hear the feature will be done “this week”, I will tell my Boss “next week” in case something (inevitably) comes up, changes are required, someone gets sick, a hurricane hits, etc.

This is not necessarily a symptom of mismanagement but an understanding that internal expectations are usually best-case. Hopefully the recipient’s experience has shown that “things happen” and any project may may have blind spots or unexpected events. Therefore, each person may turn around and double what they were just told. Some may see this as under-promising and over-delivering; I call it being realistic and conservative.

If you follow the flow from Developer to Public, you should realize that a “1 month” project set to complete in January should probably be communicated in the press release as a March launch. This may seem crazy or unreasonable to the uninitiated…

It’s much easier to have hard conversations about budgets or timelines early on (we are being intentionally conservative) than in the middle of a project (we didn’t expect this feature requiring this much work) or at the end when something isn’t quite done. This forces all kinds of pressure on everyone at each aforementioned level.

TL;DR: Estimates should accelerate at each level, from Developer up through Bosses because a bit of the “unexpected” needs to be factored in.