THE 7 DISGUISED DANGERS OF PROJECT ESTIMATION

There are those times when we need to estimate various factors for a project. Right from its revenue, to its profitability, to how long it will take to complete – all in a bid to understand the project and its holistic viability.

In doing so, we need to correctly assess many parameters. However, what we forget is that at best we can only estimate. There is no way to predict everything correctly that is accurate each and every time. What’s more, the general guidelines we stand on to assess projects may not be very strong themselves.

It’s time we looked at some of these parameters and critically analysed them. I call these the disguised dangers of project estimation as they appear to be anything but dangerous. They seem like practical and understandable parameters to estimate projects on the basis of. However, nothing could be further than the truth.

Accuracy Estimate: An accurate estimate can never exist. The only time that we can accurately predict anything about the project, is when it is nearing its end. At this point, when all the variables are accounted for, and most (not all) mistakes have been overcome, nobody is truly going to ask for an accurate estimate, which makes the exercise futile. The only way to approach this disguised danger is to simply realise that an accuracy estimate has to lie somewhere around the point of project completion. This allows for executive decisions to be taken in a timely manner, while still realising that there is room to manoeuver.

Image source: https://www.researchgate.net/publication/220421314_Ten_unmyths_of_project_estimation

End Date: This ties in from the Accuracy Estimate. When asked for an end date to a project, it is easy to throw up a random date. However, with the way things are, the chances are high that the end date will be exactly that – a random date. There is always a piece of knowledge or an event that is likely to happen which will throw off the projected end date. There may be a last minute requirement, or a detail someone glossed over. However small, this could easily add months to any project. A good way to beat this is to provide a range rather than any specific date. Further, we need to keep updating the stake holders regarding progress, sprint over sprint with a possible date from there onwards.

Commitment: It is extremely important to have processes in place. Just like everything else, even the process to generate a possible end date needs commitment. This means that instead of guessing how much time parts of a project could take, we need to build a process to arrive at the answer and commit to the process. Following it rigorously time and time again will reinforce the process, and in turn, improve it. Simple steps, such as meticulously maintaining and updating a release backlog, and then moving to a time-boxed sprint, will quickly reveal defects or shortcomings in the product. Through multiple iterations, sprint over sprint, one can understand the commitment of a self-managed, cross-functional team.

The More The People: There is a popular saying about too many cooks spoiling the broth. While adding resources to solve a problem may sometimes enable an expedited delivery, more often than not this is untrue. There is a point at which knowledge accumulation is stagnant. Beyond this point, the only route is to fragment the information and then reassemble it later on. This just adds madness to the method rather than it being the other way around. The way to beat this disguised danger is it to maintain a strong team architecture in every project that utilises each individual’s skill and places responsibility upon each member.

Historical Data: We often bring up how long a project, or a part thereof, took in the past. Relying on this information, we project dates, numbers, revenue potential, and even plan for pitfalls. In the midst of all this chaos, we forget that not only was this the case for a completely different project, but also for a completely different time period. Further, we forget to account for the experience we’ve gained along the way. The only way to counter this is to realise that while certain variables of the past may hold true, some of them have to be tweaked for the present and the future.

Defect-Free: Given enough time, the project will be flawless, and without problems. The biggest problem of all is believing that a project can be flawless. It is in pursuit of this perfection that we push off actually releasing or using a product. Not only can we never test the software against every conceivable variable, but even if we could, it would take an infinite amount of time to gather the knowledge to do so, and then do it. We know it is the time that a software is ready when the value it holds exceeds the costs it incurs. This is easily explained by the well-known Pareto’s Principle.

Following this principle, once you have mapped out every scenario or possible point of defect in your product, focus on only 80% of the ones most likely to happen. This will solve the most common problems, faced by the vast majority of users. The remaining 20% can be included in the backlog as a task to be completed when there is ample time to do it, and resources to commit to it. If we work in a test-driven development environment, then the efforts of re-testing will fall drastically too, enabling us to truly focus on what is important.