Approaches to estimation in project management

There are different approaches to estimation practices in project management processes. We will discuss the BOTTOM-UP AND TOP-DOWN APPROACHES and the PARAMETRIC APPROACH.


Note that bottom-up and top-down approaches are not specific estimating methods, but two groups of estimating methods.

The bottom-up approach to project estimation

With bottom-up approaches, we break the task for which an estimate is to be produced into component sub-tasks and then break the component sub-tasks into sub-sub-tasks and so on, until we get to elements that we think would not take one or two people more than a week to complete. The idea is that you can realistically imagine what can be accomplished in one or two weeks in a way that would not be possible for, say, one or two months. To get an overall estimate of the effort needed for the project, you simply add up all the effort for the component tasks. See Estimating in Project management practices.

This method is also sometimes called analytical or activity-based estimating. Some people (especially software developers) find the name ‘bottom-up’ confusing because the first part of the process is really top-down!


Which planning product identified in Chapter 2 could be the basis for an initial bottom-up estimate? A bottom-up estimate is recommended where you have no accurate historical records of relevant past projects to guide you. A disadvantage of the method is that it is very time-consuming as, in effect, you have to draw up a detailed plan for the project first.

Of course, you are going to have to do this anyway at some point. However, it may be a very tedious and speculative task if you have been asked for a rough estimate at the feasibility study stage of the project proposal.


You have been asked to organise the recruitment of staff for the new network support centre needed as a result of the Water Holiday Company integration project. Identify the component activities in this overall task, as you would for the first stage of the bottom-up approach to estimating effort.

The top-down approach to project estimation

With the top-down approach, we look for some overall characteristics of the job to be done and, from these, produce a global effort estimate. This figure is nearly always based on our knowledge of past cases. An example of top-down estimating is when house owners make decisions about the sum for which they should insure their house. Project estimation is really related to the quality control and quality assurance at later stages in the project.

The question here is the probable cost of rebuilding the house in the event of it being destroyed, for example by fire. Most insurance companies produce a handy set of tables where you can look up such variables as the number of storeys your house has, the number of bedrooms, the area of floor space, the material out of which it has been constructed and the region in which it is located.

For each combination of these characteristics, a rebuilding cost will be suggested. The insurance company can produce such tables as it has records of the actual cost of rebuilding houses.

This is essentially a top-down approach because only one global figure is produced. In the unhappy case of a fire actually occurring, this figure would not help a builder to calculate how much effort would be needed to dig the foundations, build the walls, put on the roof and all the other individual components of the building operation. However, a builder may be able to use past experience of the proportions of total costs usually consumed by foundation digging and other activities.


The base estimate created when using a top-down approach can be derived in a number of ways. In the example of estimating the costs of rebuilding a house, a parametric method was used. This means that the estimate was based on certain variables or parameters (for example, the number of storeys in the house and the number of bedrooms).

These parameters can be said to ‘drive’ the size of the house to be built: you would expect a house with three storeys and five bedrooms to be physically bigger than a bungalow with only two bedrooms. These parameters are therefore sometimes called size drivers. As values of the size drivers increase so would the amount of effort, so these can also be called effort drivers.

Size drivers and productivity

Earlier we had an example where technicians were allocated the job of installing upgraded workstations in an organisation. Clearly, the more workstations there are, the bigger the job and the longer its duration. Hence the number of workstations is a size driver and an effort driver for this activity.


Identify the possible size and effort drivers in the Water Holiday Company integration for each of the following activities:

  • creating training material for users;
  • analysing business processes;
  • carrying out acceptance tests;
  • writing and testing software.

In order to produce an estimate of effort using this method, we also need a productivity rate. For example, in addition to the number of workstations we would need to know the average time needed to install the software on a single workstation. If the average was 12 minutes per workstation and there were 50 workstations, then we could guess the overall duration of the job would be around 50 × 12 minutes – that is, about 10 hours.

Ideally the productivity rate comes from records of past projects. Where these are not available, you can sometimes obtain ‘industry’ data that relate not to projects in a single organisation, but in a particular industrial sector. This kind of information can help managers to compare the productivity in their organisation with that of others – this is sometimes called benchmarking. If they find that they have much lower productivity, this may spur the search for more productive ways of working.

However, caution needs to be practised if the reason for using industry data is that local project data is missing; there can be large differences in productivity between organisations, because organisations and their businesses are so different.


In the earlier example about the time needed to drive to work, identify:1. the size driver;2. the productivity rate;3. other factors that may cause a variation in the time it takes to get to work.

The additional factors are called productivity drivers. A key productivity driver when it comes to developing and implementing IT systems is experience. When putting a figure on how long a technical activity is going to take, such as developing software code, more experienced estimators will try to find out how experienced the people doing the work are.

Productivity drivers vary from activity to activity, but other drivers often include:

  • the availability of tools to assist in the work;
  • communication overheads, including the time it takes to get requirements clarified and approved;
  • the stability of the environment – that is, the extent to which the work has to cope with changes to requirements or resources;
  • the size of the project team: there is a tendency for larger jobs involving lots of people to be less efficient than smaller ones because more time has to be
  • spent on management, planning and coordination at the expense of ‘real work’.
  • The problems that can affect productivity are often considered at the same time as risks to the project in general.

For more detailed information about the topics, read What is Project Management on the Brighton’s website.

Leave a comment

Your email address will not be published. Required fields are marked *