Project Estimation

The three pillars for the success of any project are cost, effort and quality. The foundation of these pillars is based on estimation technique used for the project. However, historically it has been observed that lots of projects experience cost, effort and schedule overrun or poor quality. In most of cases, the project end up taking alternate paths to fulfill the budget constraint and ends up delivering an inadequate product/application/service.

Tip: A project’s estimate is an estimate; it is never the real value of the project. Though a good estimate should approach the actual value of the project after completion.

Before proceeding in the planning activities, you should estimate your project’s activities and tasks. Based on the WBS you created, you should start estimating the effort each task/activity will take regardless of the resources needed for the task. The project estimation exercise depends on the following factors:

• Project requirements
• Usage of correct estimation techniques
• Historical data for similar tasks/projects
• Experience of the people working on the estimation exercise

These factors control the accuracy of the estimate, so always try to have them on place.

Effort Estimation

Effort estimation is the process of predicting the most realistic use of effort required to develop or maintain software based on incomplete, uncertain and/or noisy input. Effort estimates may be used as input to project plans, iteration plans, budgets, investment analyses, pricing processes and bidding rounds.

Typically, effort estimates are over-optimistic and there is a strong over-confidence in their accuracy. The mean effort overrun seems to be about 30% and not decreasing over time. However, the measurement of estimation error is not unproblematic. The strong over-confidence in the accuracy of the effort estimates is illustrated by the finding that, on average, if a software professional is 90% confident or “almost sure” to include the actual effort in a minimum-maximum interval, the observed frequency of including the actual effort is only 60-70%.

Effort Estimation Approaches

There are many ways of categorizing estimation approaches. The top level categories are the following:

• Expert estimation: The quantification step, the step where the estimate is produced based on judgmental processes.
• Formal estimation model: The quantification step is based on mechanical processes, e.g. the use of a formula derived from historical data.
• Combination-based estimation: The quantification step is based on a judgmental or mechanical combination of estimates from different sources.

Below are examples of estimation approaches within each category:

Estimation Approach	Category	Examples of support of implementation of estimation approach
Analogy-based estimation	Formal estimation model	ANGEL
WBS-based (bottom up) estimation	Expert estimation	MS Project, company specific activity templates
Parametric models	Formal estimation model	COCOMO[1], SLIM[2], SEER-SEM
Size-based estimation models	Formal estimation model	Function Point Analysis, Use Case Analysis, Story points-based estimation in Agile software development
Group estimation	Expert estimation	Planning poker, Wideband Delphi
Mechanical combination	Combination-based estimation	Average of an analogy-based and a Work breakdown structure-based effort estimate
Judgmental combination	Combination-based estimation	Expert judgment based on estimates from a parametric model and group estimation

---

[1] Constructive Cost Model - Boehm - 1981

[2] Software Lifecycle Management - Putnam - 1979

Selection of Estimation Approach

The evidence on differences in estimation accuracy of different estimation approaches and models suggest that there is no “best approach” and that the relative accuracy of one approach or model in comparison to another depends strongly on the context. This implies that different organizations benefit from different estimation approaches. Findings that may support the selection of estimation approach based on the expected accuracy of an approach include:

• Expert estimation is on average at least as accurate as model-based effort estimation. In particular, situations with unstable relationships and information of high importance not included in the model may suggest use of expert estimation. This assumes, of course, that experts with relevant experience are available.
• Formal estimation models not tailored to a particular organization’s own context, may be very inaccurate. Use of own historical data is consequently crucial if one cannot be sure that the estimation model’s core relationships (e.g., formula parameters) are based on similar project contexts.
• Formal estimation models may be particularly useful in situations where the model is tailored to the organization’s context (either through use of own historical data or that the model is derived from similar projects and contexts), and/or it is likely that the experts’ estimates will be subject to a strong degree of wishful thinking.The most robust finding, in many forecasting domains, is that combination of estimates from independent sources, preferable applying different approaches, will on average improve the estimation accuracy.

In addition, other factors such as ease of understanding and communicating the results of an approach, ease of use of an approach, cost of introduction of an approach should be considered in a selection process.

WBS-Based Technique

The estimate, depending on the nature of the project, should consider/include the following for each item in the WBS:

• Requirements Activities
  • Requirements gathering
  • Requirements analysis & use cases
  • Requirements documentation
  • Requirements review
  • Prototype
  • Requirements review with customer
  • Requirements signoff
• Design Activities
  • System design
  • UI design
  • Database design
  • Design documentation
  • Design review
• Development Activities
  • UI development
  • System development
  • Integration
  • Unit testing
• Testing Activities
  • Test cases
  • Functional testing
  • Integration testing
  • Security testing
  • Performance & stress testing
• Rework Activities
  • Bug fixing
  • Re-testing
  • Regression test
• User guides & help documentation
• Packaging & Deployment
• Demos
• Estimation
• Planning
• UAT (User Acceptance Test)
• Users training preparation
• Users Training
• Re-estimation
• Re-planning
• Travelling/Transportation
• Ramp up/Training
• Environment setup
• Hidden efforts for
  • Communication
  • Resource allocation
  • Team management
  • Project tracking
  • Project management
• Risks
  • Determined risks
  • Undetermined risks/Contingency

Tip: It is useful to conduct the estimation with the project team to have each members input and to consider all opinions.

Estimating Task Time

There are several ways to estimate the effort of a task, one of which is a formula that combines the optimistic time, the pessimistic time, and the most like time into a weighted average. The formula is:

The PM or project scheduler estimates the optimistic, most likely, and pessimistic durations and plugs them into the formula. For example, optimistic duration = 10 days, most likely duration = 12 days, and pessimistic duration = 17 days.

Expected Time = (10 + (4*12) + 17)/6 = 12.5 days

The formula (in this example, 12.5 days) becomes the starting point for further adjustment such as adding more time for contingency purposes or reducing time due to acquiring additional resources.

How else can a PM deliver tasks or projects on schedule? By decomposing tasks into small work packages that can have their progress measured by the day, week, or month. Being alerted that task delays have occurred within a day or two of when they are supposed to be completed (which is possible when tasks durations are short) greatly assists the PM in developing corrective action plans required for task schedule recovery.

Yes, project estimates are sometimes guesses. Being able to make an educated, consistent estimate using one of these methods, combined with your common sense, will set you apart from your peers.

Size-Based Technique

This estimation technique involves selecting one or two completed projects that most closely match the characteristics of your planned project. The chosen project(s), or analogues, are then used as the base for your new estimate by comparing the size of the feature to one another and to the other completed project. The size is then transformed to effort based on certain equations defined per company standards. A feature may have for example a small, medium or large size, and a comparative methodology is used to determine the size of each feature, then the sizes are summed up and then converted to effort. The sizing estimation is a high level and easy way to determine the project’s estimate and can be very helpful in the very early stages of the project, though the detailed estimation process is still needed.

Psychological Issues Related to Effort Estimation

There are many psychological factors potentially explaining the strong tendency towards over-optimistic effort estimates that need to be dealt with to increase accuracy of effort estimates. These factors are essential even when using formal estimation models, because much of the input to these models is judgment-based. Factors that have been demonstrated to be important are: Wishful thinking[3], anchoring[4], planning fallacy[5] and cognitive dissonance[6].

• It's easy to estimate what you know
• It's hard to estimate what you know you don't know
• It's very hard to estimate things that you don't know you don't know

---

[3] Wishful thinking is the formation of beliefs and making decisions according to what might be pleasing to imagine instead of by appealing to evidence, rationality or reality.

[4] Anchoring or focalism is a cognitive bias that describes the common human tendency to rely too heavily, or "anchor," on one trait or piece of information when making decisions.

[5] Planning fallacy is the tendency to underestimate task-completion times.

[6] Cognitive dissonance is an uncomfortable feeling caused by holding conflicting ideas simultaneously.