Share with your network!

Project estimation can even make the best project management experts pull their hair out. The challenge with Project estimation in software development, unlike other industries, is that it’s often done with partial data and sometimes with incorrect data, too. Several techniques have been introduced over the years to make the process systemic and not a gut-based guesstimate. However, lapses still occur and this is still one of the toughest to-dos for a project manager.

In a blog series on Project estimation, this is the first part in which we will look at some common challenges associated with Project estimation.

  1. Poor design: While no one wants to admit it, poor design is time and again the root-cause that plays spoilsport even when the best efforts are taken. Often, people conjure up a tight design on the basis of a requirements document, that is misconstrued to be frozen and do not show the forethought to make the design scalable. A poor design results in unnecessary code tweaking and heavy-duty maintenance applying pressure on schedules.
  2. Not splitting the tasks enough: Most projects have a WBS (Work breakdown structure), but sometimes they are not broken enough to be conceptualised with clarity. Each task unit should be equivalent to an Agile story point. Lack of this usually implies that there is no proper basis for estimation and then well, it slips out into a subjective guess.
  3. Not factoring the dependencies right: Often, an external dependency or a decision point is missed out causing the project to suffer, this is termed as “coordination neglect”. For example, a vendor product’s license may be about to expire or a new version may be up for release which will require for your product to be tested with the newer version. A good understanding of mandatory, discretionary and external dependencies can help you plan the schedule well. Not to forget the dependencies on people resourcing and allowance for vacation and sick leave.
  4. How much buffer is the right amount? What is the right buffer to pad once you arrived at an estimate? This is a common challenge for Project Managers and there is no simple formula here. For example, you may have observed that new programmers usually provide aggressive estimates for the fear of being perceived as incompetent. Then they end up working long hours to finish the task. Although 20% padding is usually done, the best figure is arrived considering the people’s skillsets and complexity of the project.
  5. Top to bottom scheduling: This is a practical problem one needs to deal with. Instead of doing bottoms-up estimation, most projects start with – “I need this done in 6 months” and then a work breakdown is done where the task estimates are retrofitted inside these 6 months. It is okay to have a high level guideline, but it’s a dangerous trend if the management exerts pressure to submit unrealistic estimates.
  6. The risk of analogous estimation: Often, project estimates are done based on an expert judgment or from past projects’ experience. While picking an analogy and mapping the estimate might seem like an intuitive thing to do, it’s often risky because of the numerous variables in a project and the unique elements and dependencies, the people involved and their skillset, diverse tools and technologies adopted and the infrastructure and resources in place.
  7. Ignoring team capacity: There is a lot of debate about what unit, estimates need to be provided in – should we measure complexity, time or effort? Irrespective of what unit is followed, many Project Managers tend to ignore considering their team’s capacity. For example, imagine how different people take different time to cook the same dish. It seems obvious that different people would take different time to code, but when we draw estimates, we come up with a standard effort estimate. This inherently adds a risk layer which is going to make the estimate unreliable.

In conclusion, it’s important to recognise that project estimation is not a frozen piece of work. As the name says, it’s just ‘estimation’, the actual effort is certain to vary. So, after a few weeks of coding, get a sense of your team capacity and factor that in. Of course, frequent revisions are not a good sign, but if your schedule is rigid since the beginning, you are not reading into the project well.

Watch out this space for the next parts in this series where we discuss more specifically about the tools and techniques used in estimation.