Tuesday, October 9, 2007

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 comment: