Skip to main content

Common Mistakes in Software Estimation...

While doing software effort estimation, we should be concerned about 'what we have to do' aka tasks, and 'how long we take to complete the task', aka time. The tasks and time period ultimately gets translated into money, when we do the cost budget for the project. For some inexplicable reason, effort and money are viewed differently by all of us. People tend to forget that ultimately everything we do in a project has a cost associated with it. So ensuring that we get an accurate idea of what we have to do and how long it is going to take, is very important in getting a good effort estimate and a realistic cost budget in place.

At a high level, there are two types of mistakes that people usually commit regarding effort estimation. One is under estimating a task. Here we know the existence of a task, but budget for something lesser than what we actually end up spending. Underestimating can happen w.r.t time, nature of work and magnitude of work. The other is completely missing out on the existence of certain tasks. Problem is, forgetting certain task doesn’t mean that we can get away without doing them. We still end up doing these tasks and in doing so; we extend our working hours and hence the project duration. Managing underestimation can be done through smart Change Management / Risk management. But forgetting certain tasks is not like that. This is a classic case of being hit by something that was not even in our radar, all of a sudden. If you ask me, compared to forgetting certain tasks in the project plan, underestimation actually looks better.

‘Forgetting certain tasks from the project plan’ should always be treated as a risk and has to be handled accordingly. We can also ensure that we don’t forget certain tasks from the project plan through the use of a checklist. Steve McConnell, in his book "
Software Estimation – De Mystifying the Black Art" provides such a check list.

McConnell says that 20-30% of the errors come from not estimating certain activities. This usually leads to estimation that is off target by 20-30 % even before we start our project. Yes, even before we start the project, we are 30 % behind schedule and that will be limited to 30 % if our estimating techniques are correct.

To quote from the book, “One of the most common sources of estimation error is forgetting to include necessary tasks in the project estimates (Lederer and Prasad 1992, Coombs 2003). Researchers have found that this phenomenon applies both at the project plan level and at the individual developer level. One study found that developers tended to estimate pretty accurately the work they remembered to estimate, but they tended to overlook 20% to 30% of the necessary tasks, which led to a 20-30% estimation error (van Genuchten 1991)".

McConnell categorizes omitted work into three categories:

  • Missing requirements
  • Missing software development activities and
  • Missing non-software-development activities.
This list given below can/should be used as a check list by all project managers to ensure that they don’t make the same mistakes again. While some of it may not be relevant to the project that we do, it is better to check against this list at least once, to ensure that we don’t miss out on anything unknowingly.

Functional Requirements area

  • Setup/installation program
  • Data conversion utility
  • Glue code needed to use third party software or open source software
  • Help System
  • Deployment models
  • Interfaces with external systems

Non Functional Requirements area

  • Accuracy
  • Interoperability
  • Modifiability
  • Performance
  • Portability
  • Reliability
  • Responsiveness
  • Reusability
  • Security
  • Survivability
  • Usability
  • Software Development Activities
  • Management coordination/manager meetings
  • Cutover/deployment
  • Data conversion
  • Installation
  • Customization
  • Requirement clarification
  • Maintaining the revision control system
  • Supporting the build
  • Maintaining the scripts required to run the daily build
  • Maintaining the automated smoke test used in conjunction with the daily build
  • Installation of test build at user locations
  • Creation of test data
  • Management of beta test program
  • Participation in technical reviews
  • Integration work
  • Processing Change requests
  • Attendance at change control/triage meetings
  • Coordinating with sub contractors
  • Technical support of existing systems during the project
  • Maintenance work on previous systems during the project
  • Defect correction work
  • Performance tuning
  • Learning new development tools
  • Administrative work related to defect tracking
  • Coordination with testing ( for developers)
  • Coordination with developers( for testers)
  • Answering questions from quality assurance
  • Input to user documentation and review of user documentation
  • Demonstrating software to customers or users
  • Demonstrating software at trade shows
  • Demonstrating the software or the prototype to upper management, client and end users
  • Interacting with client or end users; supporting beta installations at client locations
  • Reviewing plans, estimates, architecture, detailed designs. stage plans, code, test cases and so on

Non Software development activities commonly missing from software estimates

  • Vacations
  • Holidays
  • Sick Days
  • Training
  • Weekends
  • Company Meetings
  • Department Meetings
  • Setting up new work stations
  • Installing new versions of tools on work stations
  • Trouble Shooting hardware and software problems


  1. That's interesting! Can you please share more about it? Thank you.

    Software Estimation Techniques


Post a Comment

Popular posts from this blog

Kano Model of Customer Satisfaction - Notes to Self

Note: What follows is the notes taken from my study of Kano's model of Customer Satisfaction. I came across this model when i wanted to know if there was a structured approach that would help me prioritize features for software product development. 

To evaluate a product or service, following parameters are very important

The value provided - this helps attract customersThe Quality offered - This earns customer respectProduct or Service innovation - This helps differentiate from competition
But these are not perceived directly, but indirectly through the product and it's features. Kano's model help to group product features into 3 categories ( 6 categories, but only 3 are important) and there by makes it feasible to deliver value at a promised quality while offering innovation. 

The 3 important feature categories are 
Basic featuresLinear featuresExciters or DelightersBasic features are that must be present in the product to be successful. They are also referred to as must have…

Knowns, Unknowns and Project Management...

This article is a draft of a paper i started to write in september 2007 and left it where you see it today.  The purpose is to to come out with a conceptual framework through which “the knowledge needed to successfully execute a project” can be viewed and gauged and presents a brief outline of the same. As always comments are most welcome...
Financial Resources, Domain, Technology, Communication, Cultural Differences, Organizational Structure, Organizational Culture and Power Play within an organization are some of the factors that have an ultimate bearing on the success of a project.
All projects come in shades of grey is a fact that has to be acknowledged. For example, when we start a project, very rarely do we know everything about Project Requirement, Scope and other factors that impact the project. There will be lot of ambiguity and this ambiguity has to be accepted and put to proper use.
But the problem is that people usually look at these factors in black and white. This may be ac…

Aggressive Schedules - Few thoughts...

During my early years in the software industry, i used to look at people who worked in projects with aggressive schedules, in awe. The people working in such projects talked about, long hours, working week ends and heroic endeavors in their projects. The people who worked in such projects were given more awards and rewards, compared to others. i thought that this was the way to be.

After working in projects with aggressive schedules, I realized that what I saw was only the silver lining and there was a big dark cloud behind this ( talk about what experience can do for you). The common thread that linked all the projects was that all of them exhibited one or more of the following.
Project ended up delayed by more than 100% Project got cancelled Project got de-scopedProject has a high cost of maintenance.  Having been burnt up by working in projects with “Aggressive Schedules’, (henceforth denoted as AS), I understand that projects with aggressive schedules cause more damage than what we …