Blogs
People often refer to estimation as a ‘black art’. This makes some intuitive sense considering that, at first glance, it may seem to be a subjective process. One person may take a day to finish a task that may, in fact, need just a few hours of another team member’s time.
So, when you ask different people to estimate the time a particular project will require, all of them are bound to come up with varied replies. However, eventually, we find that when the work starts off the time it takes is nowhere close to the estimate.
Below are a few scenarios that may lead to the failure of estimations:
“
The project is poorly examined. How can you estimate time on a project when you don’t know what the project is all about? Project scope statement should be clearly defined and it forms the basis for estimation.
Estimates become commitments or constraints. Whether you are doing a single point estimate or a range-bound estimate, it is important to note that they are still just estimates. They should not be confused with commitments or constraints and they should be used keeping that in mind. Unless this distinction is clear, the results will be disastrous.
Inadequate / unclear requirements. Projects start with a pre-determined release date and without well-defined requirements. Often we set the release date before the requirements are clearly defined. It is not possible to commit to a realistic delivery date before the requirements are defined. This is akin to building a house before the architectural drawings are done. Without these drawings, how can builders give you a date of completion? They cannot. Therefore it is ideal to start with complete software requirement specifications.
It is just a ‘guesstimate’? Estimates that are not based on historical project data, industry standards, or any other generally accepted rule of thumb cannot be considered as estimates, they are just guesses. Relying on a guesstimate for your planning and decision-making is, of course, a sure shot way to kill the project.
Development time is estimated by non-programmers. If you’re not a programmer, then don’t guess the development time. A project is doomed the moment a non-programmer writes a fictional estimate that he fancies.
When estimates are taken at a face value. Sometimes teams are either over-confident or overly pessimistic with their estimates. An experienced project manager has to validate and reconcile these estimates before using them as a source for planning or any kind of decision-making. We can bring in a subject matter expert or refer to historical data – these are good options.
Task dependencies are ignored. Some tasks cannot start until prior tasks are finished. This is particularly true of schedule estimates. We need to examine the dependent tasks carefully before setting a schedule estimate.
Estimates are not communicated. Like other project documents and deliverables, estimates also need to be communicated. An estimate without the buy-in from the respective stakeholders is worthless. Also unless estimates are communicated, there is a strong likelihood that any risks associated with the estimates will also go unnoticed.
Estimates are done alone. Estimation is not any one person’s responsibility, though a single person may be responsible for consolidating and communicating the estimates. A project manager or any other person alone should not be doing estimation for the entire project. Estimation is about getting consensus. The more involved the team is in gathering estimates, the better the chances of your estimates being accurate. Otherwise, estimates neither have the accuracy nor the team buy-in; they are just another recipe for project disaster.
Estimates are not revisited. Estimates, like risks, need to be revisited and re-validated as the project or initiative progresses. The estimates that were done during the initiation may no longer hold true – a dearth of programming skill might have pushed up the resource rates and would have thrown your estimation off track. Estimates might also have to be revisited as part of the change management process, thus it is essential to examine how sane your estimates are.
Are you scared to look into the mirror? Projects tend to skip post-mortem reviews at the end of the project. Therefore, they never learn what went wrong; never disseminate information that can help other teams avoid what happened. So, mistakes are often repeated. Post-mortem / inspection should happen at the end of each project (even of the successful ones) and the learning should be used for future projects.