6 ESTIMATING

LEARNING OUTCOMES

When you have completed this chapter you should be able to demonstrate an understanding of the following:

6.1 INTRODUCTION

In Chapter 2, we explained how to draw up a plan for a project. This involved allocating an estimated duration to each of the activities to be carried out. This allowed us to calculate the overall duration of the project and to identify when we would need the services of individuals to carry out their tasks. In this chapter, we will explore the ways in which these estimates can be produced.

6.2 WHAT WE ESTIMATE AND WHY IT IS IMPORTANT

The success criteria for almost all projects will contain a required date for finishing the project and some constraint on the amount of money that is available for the project. Estimates of the duration of the project and its costs are therefore crucial.

6.2.1 Effort versus duration

As well as estimating the time from the start to the end of an activity, it is also necessary to assess the amount of effort needed. Duration should not be confused with effort. For example, if it takes one worker two hours to clear a car park of snow then, all other things being equal, it takes two workers only one hour. In both cases, the effort is two hours but the activity duration is two hours in one case and only one hour in the other.

There can be cases where the duration is longer: for example, where someone only works in the afternoons on a particular task. Often activities take longer than planned even though the effort has not increased. This may happen, for instance, when you have to wait for approval from a higher level of management before a job is signed off. This distinction between effort and duration can be particularly important when assessing the probable cost of a project, as on some projects staff costs are governed by the hours actually worked (typically where staff complete timesheets), while on others the costs are governed by the time people are employed on the project (even if there is not always work for them to do).

6.2.2 The effects of over- and under-estimating

If effort and duration are under-estimated, the project can fail because it has exceeded its budget or has been delayed beyond its agreed completion date. This may be so even when staff have worked efficiently and conscientiously. Allocating less time and money than is really needed can also affect the quality of the final project deliverables: team members may work hard to meet deadlines but, as a consequence, produce sub-standard work.

On the other hand, estimates that are too generous can also be a problem. If the estimate is the basis for a bid to carry out some work for an external customer, then an excessively high estimate may lead to the work being lost to a competitor. Parkinson’s Law (‘work expands to fill the time available’) means that an excessively generous estimate may lead to lower productivity. If a task is allocated four weeks when it really needs only three, there is a chance that, with the pressure removed, staff will take the planned time.

6.2.3 Estimates and targets

Identifying an expected duration is very difficult. If the same task is repeated a number of times, each execution of the task is likely to have a slightly different duration. Take going to work by car. It is unlikely that on any two days this takes exactly the same time. The journey time varies because of factors such as weather conditions and the pressure of traffic. Thus, an estimate of effort or time is really a most likely effort/time with a range of possibility on each side. Within this range of times we can choose a target. An ‘aggressive’ target may get the job done quickly, but with a stronger possibility of failure. A more generous estimate is likely to expand the length of time needed, but have a safer chance of being met. The target, if at all reasonable, can become a self-fulfilling prophecy; with the commuting example, if you know that you are going to be late you may take steps to speed up, perhaps by taking an alternative route if the normal one is congested. Estimating can thus have a ‘political’ aspect. Some managers may reduce estimates, either to gain acceptance for a proposed project, or as a means of pressurising developers to work harder. There are clearly risks involved in such an approach, as well as ethical issues.

6.3 EXPERT JUDGEMENT

Effective estimating needs contributions from experts with experience and knowledge of creating the types of product that the project is to create and the techniques by which they are created.

6.3.1 Using expert judgement

Where do you start if you want to produce reasonable estimates? Although estimating is treated as a separate, isolated topic in project management and information systems development, it in fact depends on the completion of other tasks that provide information for estimates. For a start, you need to know:

For example, to work out how long it will take to install upgraded workstations in an organisation, we need to know approximately how long it takes to install a single workstation and how many workstations there are. We may also need to know how geographically dispersed the workstations are. The best person to tell us about these things would be an expert familiar with the tasks to be carried out and the environment in which they are to be done. As a consequence, most guides to estimating identify expert opinion or expert judgement as an estimating method.

‘Phoning a friend’ can be a sensible approach, but how do the experts themselves derive their estimates? There is a possibility that they have their own experts they can call, but at some point someone has to work out the estimate based on their own judgement – and the likelihood is that they end up comparing current tasks with previously completed ones and using the actual durations from those old tasks as a basis for the new estimates.

The advantages of using expert judgement include the following:

There are, however, some balancing risks:

6.3.2 The Delphi approach

One method that attempts to improve the quality of expert judgement is the Delphi technique, which originated in the RAND corporation in the USA. There are different versions of this, one of which is ‘planning poker’, but the general principle is that a group of experts are asked to produce, individually and without consulting others, an estimate supported by some kind of justification. These are all forwarded to a moderator who collates the replies and circulates them back to the group as a whole. Each member of the group can now read the anonymous estimates and supporting comments of the other group members. They may now submit a revised estimate with its justification. Hopefully, the opinions of the experts should converge on a consensus.

The justification for the technique is that it should lead to people’s views being judged on their merits and reduce undue deference to more senior staff or the more dominant personalities.

6.4 BOTTOM-UP AND TOP-DOWN APPROACHES

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

6.4.1 Bottom-up

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.

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!

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.

6.4.2 Top-down

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. 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.

6.5 A PARAMETRIC APPROACH

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.

6.5.1 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.

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.

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 problems that can affect productivity are often considered at the same time as risks to the project in general (see Chapter 7).

6.5.2 Function size measurement

There was a time when almost all IT projects involved writing software of some description. This is now diminishing for many reasons, one of which is the tendency to use ‘off-the-shelf’ software applications. However, there are still many cases where software has to be written, and can cause particular challenges for effort estimation.

If we use a parametric approach, the first question is what to use as size drivers. If IT is old enough to have any real ‘traditions’, then one of the longest established of these would be to use lines of code as the size driver for software development. (When software is written, the programmer writes the instructions – as lines of code – in a form which is comprehensible to human experts. This ‘code’ is an electronic document that can be changed, added to and printed. When the code is to be executed by the computer, the document is ‘read’ by a special piece of software which converts it into a format that the computer can interpret automatically.) From this very brief explanation it can be seen that:

Things are also complicated by there being many programming languages. Some are more ‘powerful’ than others – that is, they need fewer lines of code to define a particular procedure.

Rather than use this technical unit of size, which is invisible to everyone except the software developers, it is more convenient to use counts of externally apparent features of the software application as the size drivers. This would be rather like using the number of storeys, the floor space and so on to estimate the cost of a house, rather than the number of bricks. With software applications, this can be done by applying function points analysis (FPA).

6.5.3 Example of COSMIC FP counting

Within the Water Holiday Company booking system there is a transaction that records the final payment made by a customer who has already booked a holiday and paid a deposit. The details of the payment come from an external function that deals with payments by debit and credit cards. The key data items input are an account number, an amount and a date. The system checks that an account exists for the account number and, if it does not, issues an error message (see Table 6.1). Otherwise the new payment is recorded, and the amount paid on the account record is updated. A notification of the new amount outstanding on the account is issued.

Table 6.1 Example of COSMIC function point counting

What does a CFP count really mean? It was suggested above that it is an index value that gives an idea of the amount of processing carried out by the transaction.

We can use a CFP count to find out the relative productivity of development projects that have already been completed. We may find that the average number of CFPs implemented per day is around five. This may seem a rather small number, but ‘development effort’ here includes the whole development cycle, from requirements gathering to testing. When a new project proposal comes along, a preliminary investigation may suggest that the delivered system would have a count of about 250 CFPs. The estimated effort is therefore in the region of 250/5 days – that is, 50 days.

6.6 ESTIMATING BY ANALOGY

The FSM approach (and, indeed, the more generic approach of using size drivers and productivity rates) is based on the assumption that we have the details of the size driver values and actual effort of past projects. Often, however, such records do not exist. For smaller organisations particularly, the IT projects that have been previously implemented may all seem to have their own peculiarities. For example, some may have involved the installation of vendor-supplied applications, some may have required specially written software, some a mixture of the two, and so on. This seems to suggest that previous experience is not a stable basis for estimating the effort for new projects. However, in this kind of situation the analogy, or comparative, approach could be used.

The main steps with this method are as follows:

An analogy approach can be used to create a top-down estimate for a project. Where there is no past project that seems to be a useful analogy for the new project, an estimator can use analogy to select parts of old projects that seem similar to components of the current project (using analogy as part of a bottom-up approach).

As Table 6.2 shows, both analogy and the parametric approaches can be used either at the overall level of a project or for estimating the effort needed for components. The activity-based approach – breaking down the overall task into smaller components – seems almost by definition to be a bottom-up approach.

Table 6.2 Relationship between top-down/bottom-up and the three main estimating approaches

6.7 CHECKLIST

As a project planner you may often need to use the effort estimates produced by experts from technical areas in which you are not knowledgeable. Are there any ways in which you can realistically review these estimates? It may be possible to assess the plausibility of the estimates by asking the estimator the questions below.

SAMPLE QUESTIONS

POINTERS FOR ACTIVITIES

Activity 6.1

The work breakdown structure (or possibly the product breakdown structure).

Activity 6.2

Among the activities that may need to be carried out are:

This set of activities offers some good illustrations of the difference between elapsed time and effort. There will be some points – for example, when you are waiting for references – where little effort is expended but time will be passing.

Activity 6.3

The following are suitable answers:

Activity 6.4

1. The size driver would be the distance driven to work.

2. The productivity rate would be the average speed of the car (for example, miles per hour).

3. We have already suggested that the weather and the amount of traffic congestion could have an effect on the travel time. In this case, the weather and traffic do not increase the size of the job to be done – the distance to work remains the same. These factors are best seen as influences on the productivity rate. In order to assess more accurately the time it takes me to go to work, I could take account of these intermittent constraints on my speed. I may be aware, for instance, that the rush-hour traffic in the morning tends to be significantly less heavy during school holidays. I could therefore perhaps allow myself to start off to work a few minutes later when it is half-term. On the other hand, I may start earlier if it is foggy, as I know that this can slow down the traffic.