Chapter 23
Ten Tips for Estimating
In This Chapter
It’s not just you – estimating is seriously tricky
The huge value of historical data
Three cases when you’re unsure – best case, worst case, most likely
Estimating is notoriously difficult … in most industry areas anyway. If you find that estimating to be a problem you needn’t feel lonely. Some areas, such as IT, have a few techniques to help, but even there you’ll often find limitations. An exception is the construction industry. If you ask for an estimate for an extension on your home, a builder will come back with the total cost remarkably quickly. So how does he do that when most people struggle for ages with project estimates?
For a list of techniques, including estimating techniques, have a look at Chapter 20.
The answer to the building estimates question is rather simple. Your local builder looks at the different elements needed for the extension, and then he looks up the estimates in a commercially available book. For each item the book gives a unit, such as a square metre, and then the cost for materials, labour and total. Your builder works out the area of the concrete floor for your new extension, for example, and multiplies that by the cost in the book. When he’s costed all of the elements, there’s a tiny bit extra to add on for profit and cups of tea, then that’s the price.
You may wonder why I’ve included the construction explanation given that most readers won’t be involved with construction projects. Well, the construction example makes two extremely important points when it comes to estimating that could be of real help to you no matter what your industry or business area. Read on in the chapter to see where, and you won’t have to read on very far.
Where you don’t have recorded data, life becomes a touch more difficult. If you’re in the business community dealing with business projects the chances are that you won’t have anything much to refer to at all, apart from a few old project plans. Even if you do have some old plans, they may not be much help if the Project Managers didn’t keep them up to date with ‘actuals’ as their projects proceeded. However, read the tips in this chapter for help even if you’ve got good material to refer to.
Holding Historical Data
The most useful information you can have to help with estimating is ‘how long did it take us last time?’ So store metrics from your projects so you can use them in the future. Don’t lose this valuable data and then have to end up guessing all over again when you come to a similar project, or part of a project, in the months or years ahead.
Most organisations are awesomely bad at storing estimating data, either because they don’t see the need for it or because they don’t want to devote the resources needed to do it. That includes organisations where senior managers then criticise Project Managers when their projects don’t align with the estimates in the plan. Everything takes a different time to that which was guessed at for the plans because the estimates were indeed guesses, as there was nothing better to go on.
If your organisation won’t store metrics then you can for your own projects to get at least a limited base of data based on your own experience.
Thinking ‘Retrieval’
My wife, who I love dearly, has a strange way of storing information. When we lived in London we used to keep a menu for a Chinese food shop in a clip in the kitchen. One day, I couldn’t find it and asked her where it was. She got very defensive and said ‘It’s all right, I’ll get it.’ I said not to worry and if she just told me where it was I’d get it. ‘No, I’ll get it’ she replied. I got suspicious and said ‘Kath, where have you put it?’ She was very reluctant to say but finally admitted that it was in our home filing system in the ‘Schools’ folder. I was mystified and asked why it was in the filing system and, even if she thought that was the best place, why on earth under ‘Schools’? Her explanation was that that the last time we had ordered in a Chinese meal we had been looking at information to choose a school for our daughter. She had gathered up the menu with the school papers and put them in the filing system. Her defence for the filing was ‘But I knew where it was.’
Kath may have known where the Chinese menu was, but I didn’t and wouldn’t ever have thought to look for it under ‘Schools’. When considering data, you need to focus on the retrieval of information, not just the storage, and how other people will want to access it, not just you. When you’re storing estimating metrics, think carefully about future access and then store it accordingly. Most organisations that claim to have past project metrics available actually mean that they’ve stored the old project plans. When you come to look for estimating metrics for your new project, you then have to guess which of the previous projects did something similar and then scour the project plans to see whether you can find anything useful.
Going back to the construction industry and the estimates for your house extension, which I used as an example at the start of this chapter, the estimating data isn’t stored according to the building projects. Instead the data is held according to type, such as flooring, brickwork and woodwork; it’s stored according to the way it will be retrieved.
Maintaining Accessibility
Storing good estimating metrics is one thing, but then they have to be accessible. This tip is a simple but important one. The metrics must be readily available to all the staff who need them and especially Project Managers. It’s no good at all having the metrics locked up in the Project Management Office and the PMO staff then saying that they will look up what past metrics the project needs when it is being planned.
If a Change Request comes in, the Project Manager must assess the impact including time and cost. So the Project Manager will need access to the estimating metrics then, won’t he? To have to ask for them each time just involves more people, adds time and drives up project overheads as well creating enormous frustration. Besides which the Project Manager doesn’t always know exactly what metrics he needs. The task may be different to anything done before, so he’ll look at different estimating metrics before deciding which is the closest one to use as a guide.
Modifying Generic Data
It isn’t so much a question of ‘How long does it take?’ but rather ‘How long does it take here’? For some industry areas you can get hold of universal data that give the norm for particular work. In the IT industry it’s known in systems development, for example, what proportion of a systems development project is usually taken up with analysis.
In the USA the inventor of the superb technique of Data Flow Diagrams (used for mapping system functions), Tom DeMarco joined with Timothy Lister to do research on productivity. You can see the results of their efforts in their book called Peopleware published by Addison Wesley. They discovered that the best companies work 11 times faster than the slowest companies when doing similar work. The difference is extraordinary, but totally understandable when you read the book.
When you come to do the estimating for your project, then, the key factor is how long it takes to do that sort of task in your organisation. If you get hold of universal metrics based on an average, you may need to adjust them, in either direction, to take account of your own organisational circumstances and performance levels. In other words, are you one of the organisations that goes 11 times faster, or are you the slowest, or somewhere in between?
In passing, and because you are probably wondering, some of the factors uncovered by DeMarco and Lister were related to the working environment. That fact explains the emphasis in several places in this book on ensuring that your project staff have good working conditions, and taking action to change things if they haven’t. It can make a huge difference to staff performance and therefore to your project costs and final delivery, as well as to the wellbeing of the staff involved.
Adjusting universal metrics to the actual performance in your own organisation is vital, even if you get a bad feeling doing it because your organisation happens to be the ‘11 times slower’ one. Remember that the estimates are used to underpin the plan, and if the estimates are wrong then the plan will be too. Your project will veer off the plan almost immediately and it will be very hard to control.
Using the PERT formula
PERT is the Project Evaluation Review Technique and is one of the two forms of activity network. The other form which is the Precedence Network has almost totally overtaken the PERT since it avoids diagramming problems. Associated with the PERT technique is an extremely useful formula. If you’re not sure how long something will take, then ask people (see the next tip on the Delphi Oracle). Then take the results and apply the PERT formula.
This formula is a weighting and biases the most likely result against the two extremes of the most optimistic estimate and the most pessimistic estimates. As you’ll have guessed by now, the ‘M’ in the formula represents the most likely time represented by the majority view of the people you consulted. The ‘O’ is the most optimistic estimate put forward while the ‘P’ is the most pessimistic estimate. So the most likely outcome is weighted at four times that of the most optimistic and most pessimistic.
It’s a surprisingly good formula, but it’s better still because you can adjust it. Think back to the previous tip and the need to adjust estimates according to how long it takes ‘here’. If you find that the formula consistently comes up with estimates that are too high and your project teams are performing better, then adjust the formula. On the top line you might then have 2O + 3M + P.
When I started in project management I was involved in computer systems development. I came to do my first project plan and found that the site had no historical metrics at all.
I worked with my Senior Programmer, Paul, to find programs from past systems development that most of the programming team would know about, and then we selected a high complexity one, a medium complexity one and a simple one. I wrote to each programmer and giving the three examples I asked how long it would take them personally to code and test a programme of that complexity. I then looked at the system design and, working with Paul, categorised the programs into high, medium and low complexity. I applied the PERT formula to the estimates given by the members of the programming team, and put that in as the time estimate for each programme according to its complexity. That approach was the best I could do; I had nothing else to go on. When we finished the build, I compared the actual programming times with the original estimates derived from the PERT formula, and they were amazingly close.
Consulting the Delphi Oracle
If you were an ancient Greek and you had a problem, you might have decided to consult the oracle at Delphi. The way the oracle worked is lost in the mists of time, but one suggestion is that it was a group of wise people who would discuss the problem and then come back with a single answer.
If you need an estimate, you can get together with a group of informed people and simply ask them how long they think each of a range of activities will take. They write down their estimates, you collect them in and then calculate the average for each activity.
If you want to be a bit more refined, you can use ‘Advanced Delphi’. First, you do the estimating as before. However, you analyse the results while the group is still in the room. For each item you identify the most optimistic estimate and the most pessimistic one. You then ask those two people to explain the thinking behind their estimates.
The person who gave the longest time for an activity and was the most pessimistic might say ‘Well, I’ve worked on this sort of thing twice before, and both times we came across problems that slowed us up.’ The person with the most optimistic estimate may say ‘We tried a new approach on a previous project and it saved us time and I think it could work just as well on this one.’ Everyone listens carefully to the points, and then estimates again. You collect in the revised estimates, take the average and put it in your plan.
As you may have just realised in a blinding flash of inspiration, you can apply the PERT formula from the previous section to the Delphi results in this one.
Estimating When You’re Not Sure
With the best will in the world, sometimes you’re simply not sure about the estimates. That can be true where there are a lot of variables. If you find yourself in that position, there’s a simple way out when you come to write the explanatory notes in your Project Plan or in the Business Case. Simply record a best case, most likely case and worst case.
The correct name for this process is three point estimating. Three point estimating can be really helpful because it alerts people, such as senior managers, to the fact that you’re not sure about the estimates. It gives those managers the most likely outcome, but then also gives information on the maximum and minimum too. If the delivery is different from that shown on the plan, managers are not taken by surprise because you’d already warned them that it could be different, and told them the possible range of variation.
Stating Your Confidence Level
You should be very clear and open in your project plans, and that includes being open about the estimates. The people reading your plans, such as members of the Project Steering Group, will find it very helpful to have an indication of your confidence level.
To get the idea of this, imagine that I’m the Project Manager and you’re the Sponsor. You read my plans which say ‘I am 95 per cent confident that the estimates are accurate and that the activities will take the time shown in the plan.’ Compare that to your thinking if you read ‘We’ve never attempted this sort of work before and despite taking a lot of advice I am only 25 per cent confident that the estimates are accurate.’
In the first instance you will be confident in turn about assuring other organisational managers that the project will deliver on schedule. In the second instance, you are very aware that the project is going into the unknown and that the actual timing of activities may fluctuate considerably in either direction as the project proceeds. That fluctuation may be unavoidable, but the point is that as Sponsor you are prepared for it and won’t be taken by surprise.
Using the Three Strand Rope
Okay, prepare for ending with a touchy-feely bit and something that I include when delivering project training courses, though I haven’t yet seen it ever referred to by anyone else. It’s about your feelings and how they fit in.
You can think of the process of estimating in terms of three strands twisted together to make strong rope. The first strand is historical data and that’s both important and valuable. The second strand is techniques such as PERT.
Now comes the third strand of the rope, which is how you feel about the estimate. You may think that it sounds rather weird to have ‘feelings’ as a third strand until you pause and consider what you say to yourself sometimes. ‘Hmmm. I don’t know about four weeks for that bit of work. It just doesn’t feel right somehow.’ Your ‘gut feel’ for something isn’t anything to do with your gut at all but everything to do with your subconscious mind. The human mind is, of course, awesomely powerful and sometimes your subconscious is putting things together that your conscious mind hasn’t considered. Your gut feel of something being wrong is your subconscious flashing a red warning light.
If your ‘gut feel’ is telling you that the other two strands are wrong, then stop and try to determine why that is. If you have a fair amount of experience in the type of project then take the third strand all the more seriously. Try to resolve the conflict. More often than you might imagine, you’ll realise that your gut feel was right and that you missed something out when working on the other two areas.
This chapter has focused on activity estimating. However, you can apply some of the tips, such as using the PERT and Delphi techniques, to estimating risk and benefit levels too.