Project Management Book

Chapter 6 - Estimating

Estimating is like getting rich: everyone wants an effortless way of doing it. Failing that, estimating can be done quite easily using sophisticated tools such as the one pictured.

Look up from the page at the wall in front of you. How long would it take you to paint the wall? What's your estimate? Twenty minutes? A couple of hours? You've got the job.

Because our 'paint the wall' task of course included:

• agreeing the colour with your partner (a 2 month task in its own right?)
• buying the paint from a boutique paint factory in Faro, Portugal
• preparing the surface
• tidying up

So our two hour job is actually more like a two or three month job.

This happens, usually by the coffee machine: "I've got to go to a meeting, can you give me a rough idea how long it would take to...?" and under pressure you say: "about two hours?" But when you find out what's really involved it is more like 3 months work. So the first message from this chapter is: don't guess. We will see later how we might resist the pressure to generate random numbers.

What's the worst way to estimate how much a project will cost? Get one junior person who has never estimated before to have a guess and then we all become committed to that guess. We'll see later how we might bring experience to bear on this difficult task of estimating project cost.

Suppose we are at the start of a year long project, can we estimate its cost accurately? Almost certainly not, there are so many unknowns. Until we have defined the detailed requirements and done the design it's very hard to say what the build might cost. When we're in the project definition stage we may conclude we can only estimate with any kind of accuracy Stage 1: Requirements and User Functions Design.

So, we will do a detailed, task by task, bottom up estimate for Stage 1 and a much softer, top down estimate for Stage 2. When we near the end of Stage 1 and have the design done we will then estimate Stage 2 task by task, bottom up, and provide an accurate estimate for it (we hope!).

Top down estimating is getting as good an idea as we can of total project cost and bottom up estimating is getting a precise estimate for the project stage we are about to start.

Let us first consider some techniques for improving the accuracy of top down estimates.

Good project definition

We were miles out with the wall painting project estimate because we didn't understand the project scope - we did not have an agreed project definition. Crystal clear project scope is an obvious prerequisite to good top down estimating.

Include all costs

Ask someone from IT what a project might cost and they will think about the programming cost and - if you're lucky - the testing cost, add the two together and give the result as the project cost. But in reality that is just the tip of the cost iceberg. Even if the estimates for the programming and testing costs are spot on, it's what's left out that makes the overall estimate way out.

How might we overcome that problem? Have a checklist of all possible costs a project might incur: project definition, requirements analysis, design, documentation, team meetings, change, project management, contingency, travel, plus a very long list of et ceteras. This makes it much less likely cost items will be overlooked.

A good checklist includes peripheral costs too: it's all very well quoting $50K to develop a little new system but if three other systems must be modified to interface to it, those costs have to be included somewhere. And suppose a data conversion would be needed to get old data into a form usable by our little new system - was that cost in the $50K project estimate? A good checklist makes you think very broadly about all of the costs associated with the project, not just the narrow development costs.

These checklists are relatively easy to develop by looking at where the time and money went on previous projects. If that information isn't available, sit down with two other people for an hour to draw up such a checklist: you will be amazed at what you end up with on that list that you would otherwise have overlooked when doing an estimate.

When you have such a checklist, try this. Ask someone for an off the top of the head estimate for a little project. Then give them the checklist and come back ten minutes later for their revised estimate: you will be surprised at the difference.

Break it down

Never accept a single global figure as the estimate for anything. Always get it broken down by the major steps the project will go through.

If someone came to you with a breakdown for a new-build software project and said the IT effort will be as follows, would you believe the estimate?

Total cost 20 man months of IT effort. 18 man months to get to the end of the design steps then 2 man months to do all the programming and testing for a new build software project - does that ratio sound right? If it cost 18mm to do the requirements and design what do you reckon the build and test might cost - in your experience, what percentage of the IT effort is spent in the build and test steps of a new build software project?

Suppose in past new build software projects the IT effort had in fact typically been distributed as follows:

Would you now believe the 20mm estimate in the example above? At the very least you would need a lot of convincing why this time the work distribution will be so dramatically different.

Your company might have a number of such models - yardsticks against which to compare future estimates. For example, in package modification projects the IT work distribution might be more like this:

Most types of projects go through a number of steps such as these. As a matter of principle, never accept a single global number, always get it broken down by the relevant steps the project will go through and compare to past experience as a reasonableness check. Benchmarks such as this only work, however, if projects apply a consistent development (manufacturing) process: if some projects do properly detailed and complete user functions design but other projects do UFD at a much vaguer, higher level the effort breakdown would obviously differ from project to project.

...next

Privacy Policy and Cookies