The practice of estimating in project management is one of
the most challenging. Whether you’re trying to figure out project effort,
duration or cost, given the inherent uncertainty of projects and their uniqueness,
we often end up “guesstimating.” This article provides techniques to use in
order to be as accurate as possible in doing your estimates. While I focus on
effort estimation, the same techniques apply to duration or cost estimation.

Let’s start with a reminder about how project time
management is articulated, according to the PMI® PMBOK® Guide
& Standards, Fifth Edition:

__Analogous Estimating__

This is, I think, the most common form of estimation. You
base your estimate on your experiences from previous projects, otherwise known
as historical data, based on lessons learned. This method is fairly accurate,
when the type of work is similar (same project type, same resources, etc.). The
calculation can be adjusted using parameters such as duration, budget,
resources and complexity. Also, this is the method to use when you have a
limited amount of information regarding the project, such as a lack of a
detailed task list. The disadvantage to this approach is that the organization
needs similar projects for comparison.

__Parametric Estimating__

This form of estimation uses a formula also based on
historical data. To make it clearer, here’s an example: You know from past
experience as a handyman that you require 10 hours to tile 20 square meters.
Today you need to estimate how long it will take to tile 40 square meters. Your
guess is 20 hours. The more sophisticated your model, the more accurate your
estimates will be. For example, you can define that for every 40 square meters
of tiling, you’ll also need one more hour to tile or clean or estimate that the
risk of having bad tile quality increases with the larger space. As your
formula becomes more advanced, your results will become more accurate. The
disadvantage is the same as the analogous estimating: no historical data, no
parametric estimation.

__Three-point Estimating__

The idea is to improve upon single-point estimating by using
three-point estimating, where three estimates are defined in order to take into
consideration risk and uncertainty. The first estimate is a best case
estimation, called Optimistic value (OP). The worst case scenario is called
Pessimistic (PE). The last estimate falls between the other two and is called
Most Likely (ML). Each of those may be defined using one of the previous
techniques (analogous or parametric). You can define the effort as an average:

*(OP+PE+ML)/3*

A variation of this technique is the Program Evaluation and
Review Technique or PERT analysis, which uses weighted averages for the
estimates:

*Expected Time = (OP+4ML+PE)/6*

The disadvantage of this technique is that it’s time
consuming because you have to define three estimates for each task.

__Expert Judgment Estimating__

In this approach you ask a knowledgeable expert to define
efforts for you, based on historical information they have. Its accuracy
depends on the expert and his or her background. The main pain points are two:
1) to find such an expert when you need one; and 2) to accept what the expert
is telling you even when there’s no apparent rationale other than “This is what
I as an expert think it should be.”

__Published Data Estimating__

Some organizations regularly publish their data about effort
from past projects, accessible by anyone who’s a member or an employee to
compare against their expected activities. While this approach can be highly
accurate, it also depends on many parameters (domain, company size, culture,
etc.), making it difficult to find information suited for you.

__Bottom up Estimating__

This is the Work Breakdown Structure (WBS) approach. You
decompose your work into small packages that are more understandable and
therefore simpler to estimate with greater accuracy. You aggregate those
estimates at a project level to understand the whole effort. If a work package
or decomposed activity can’t be estimated, you have to break it down again. The
inconvenience here is that the method is time consuming.

__Project Management Software Simulation__

Software simulation is used to model the level of uncertainty.
The best known example is the Monte Carlo simulation. Instead of using numbers
as input to a formula (whose result will also be numbers), the Monte Carlo
method takes a distribution of numbers (such as the normal distribution) as
input and gives a distribution of results as output.

Given the complexity of the implementation and the
application to several project tasks, this method can be time consuming.
(Practically speaking, I’ve personally never applied it to any of my projects.)

__Group Decision-making__

Not specifically a technique in itself so much as a
collection of techniques. The idea is to work with a group of people to assess
effort, duration or cost. The advantage is the sharing of experience and
knowledge and also the involvement of people from the project team, which
increases their commitment to the result.

__Delphi Method__

The Delphi method is a group decision making technique that
relies on interactions within a panel of experts. Participants give their
estimation to a facilitator in charge of providing an anonymous summary of
expert judgments together with the related explanation. The anonymity frees
participants from cognitive biases such as the halo effect or the bandwagon
effect.

__Planning Poker__

Also called Scrum Poker, this gamification technique derives
from the Delphi method, where a group of people try to reach a consensus on
effort (originally used in agile techniques for story point estimation). People
have a deck of numbered cards, each number corresponding to story points or
days. They’re invited to put face down the card corresponding to their
estimation. All cards are revealed simultaneously. The bigger and lower
estimates are removed. This action is repeated until a consensus is reached (of
course, anyone can modify the estimate he or she gives at each round based on
the going point of view). Usage of an egg timer can help to “mark off”
discussions.

__Other Techniques Worth Considering__

A quick browse of Wikipedia reveals any number of other
techniques to consider, none of which I’ve tried, but all of which sound
interesting for particular situations. Here are two that I found particularly
interesting:

**is an algorithmic software cost estimation model that uses a regression formula with parameters derived from historical project data and current and future project characteristics.**

*The constructive cost model*(COCOMO)**The**is an empirical software effort estimation model, in which software project data is collected and fit to a curve. The estimate is created by examining project size and calculating the associated effort using the equation.

*Putnam model*
If you ask me what I use, I’ll reply, “It depends.” I always
start with some basic estimation, either analogous- or expert judgment-based.
Then depending on the risks or complexity inherent to the project, I apply
parametric estimating or go through the work of three-point estimating. I’ve
found that breaking down tasks in smaller more understandable activities is
also a very good approach. Finally, group decision making techniques help me
fine-tune the estimates.

In other words, the appropriate estimation technique for
your project depends on your experience, preference and many other projects and
situation parameters. I recommend that you build your own technique based on
what you extract from any of these methods.

*Project Management Professional, PMP, PMI and PMBOK are all registered trademarks (®) of the Project Management Institute.*

*This article has been also published on mpug.com.*

## 2 commentaires:

Interesting... You need to take in account also nationality of the resources :))))

In general, I agree with you , that it's common sense and mix of several technics

Velocity of the resource in general is an important parameter

## Post a Comment