Project Management Book

...chapter 6 continued

In this rather hard-edged culture would you include the relevant percentages in your estimates? You would. (Incidentally, the percentages for things like change and contingency will usually be lower for small, simple projects, but could well be higher for large, complex projects).

So, you do a professional job of estimating and include the appropriate percentages. You then present your cost breakdown to the sponsor, even the Board of Directors. They are horrified at the cost and tell you to cut your estimate. What would you do? Offer to reduce project scope perhaps. But no, they want full scope, just a lower estimate.

You justify your figures by showing past project actuals but they don't want to know. They just tell you to reduce your estimate. Do you give in? No, you say something like this: "This is what I think it is going to cost. If you can find another project manager who will do it to your estimate please do. But if you want me to manage it this is the estimate."

Would you be taking a risk by saying that to your Board of Directors? Yes, but a very small risk indeed compared with the risk of being brow-beaten into agreeing a lower figure and then failing spectacularly. Another good example of why it isn't easy being a project manager and why it should be a well paid job.

It is quite right and proper that senior managers put in a hard challenge to your numbers: "Fifteen percent on quality? Surely that should be 5% shouldn't it?" Now he probably hasn't got a clue what it should be - he's looking for your reaction. If you immediately cave in and say you'll change it to 5% your whole credibility goes out of the window. But if you calmly explain why it's 15% and appear to have good reason the sponsor, Board or whoever you are presenting to are much more likely to accept the rest of your numbers. The random challenge tests whether you've just made up some numbers or whether you really do know what you're talking about.

So, since you are accountable for the accuracy of the estimate, you want to get it right but how do you estimate what a stage will cost?

Bottom up estimating

Project Definition


User Functions

IT Technical

Build and


  Stage 1

  Stage 2

  1. Identify the deliverables of the stage. Sounds obvious, but consciously stop and think: what must be delivered from the stage? If we are estimating Stage 1, the deliverables might be the requirements document, the UFD, a revised cost benefit case, the Stage 2 plan and agreement, a testing strategy document, a roll out plan... and probably several other things too.

  2. Write a very long list of all the work tasks you will therefore need to do in Stage 1 in order to deliver those things.

  3. Estimate how many hours of work each task will take, using records of how long similar tasks took on past projects. Think of any project task you like - it's been done before on a previous project. If you knew how long it took you wouldn't have to guess.

  4. Allow for 'investments'. Things like planning, time recording, team meetings, supervision, coaching.

  5. Adjust for skill level. If last time a task took 1 day but was done by an expert, a novice might take two, three or even four days to do a similar task. Clearly, the hours a task will take will depend upon who you give it to.

  6. Develop the draft stage plan. Sketch out who might do which tasks and when. This will usually reveal extra tasks that will have to be done but which were not on the list.

  7. Assess the risks. We know roughly who will do what and when. Now is the time to take a detailed look at the stage risks. This may result in adding risk reduction tasks into the plan (remember the handover tasks for those who might leave?) plus an amount of effort/money for anything else that might crop up that might mean tasks will have to be added to the plan once the stage is underway - in other words contingency.

  8. Validate the estimate. Never use just one person to do the estimate or just one technique. Use many people and come at the estimate in as many ways as you can: top down, bottom up, third party quotes, comparison to past projects, rules of thumb, etc.

Have you got a telephone directory handy? Try this. Estimate and write down how many names you think are listed in it - just a top down guesstimate.

Now estimate and write down these 3 numbers:

Now multiply those 3 numbers together to give you something akin to a bottom up estimate.

Next, look at the cover of the phone book (don't open the book). It says what area the book covers. Estimate how many houses there are in that area then subtract the percentage you think may be ex-directory. If the phone book includes businesses estimate how many of them there are in the area and add them.

You should now have 3 different estimates for the number of names in the book. Now, taking those three estimates into consideration, form a revised judgement of how many names there are in the book and write it down (and remember your next pay rise depends upon the accuracy of this estimate!).

Now open the book and multiply the actual number of pages x the number of columns per page x the number of names per column. (You may need to do separate calculations for the residential and business sections of the directory).

Your final estimate should be a lot closer to the right answer than your initial top down guesstimate. Your bottom up estimate (pages x columns x names per column) will probably have been the closest of your initial three estimates.

This little exercise doesn't always work, but it does show there are usually several ways of arriving at an estimate for something. Use many methods and many people, consider the results in the round and arrive at a more informed estimate.

Let us go back to that encounter by the coffee machine when you were being pressed to guess what a project might cost. Say: "I don't know, I'll get back to you." If it is a small piece of work gather a couple of colleagues round your desk, go through something similar to the phone book exercise, zip through your estimating checklist (if you haven't got one, start compiling one!) then arrive at an estimate. That number will probably be very different from the one you would have given beside the coffee machine. Of course, if you have been asked to estimate a large project it could take days or even weeks of work to arrive at anything approaching an accurate estimate: using rules of thumb, consulting records of past projects, consulting experts, talking to potential team members, getting external quotes, etc. The time it takes to produce a reliable estimate is clearly related to the size and complexity of the project.

Mandatory review

Many companies mandate that having produced an estimate using whatever techniques are appropriate, the project manager must get the estimate peer reviewed before quoting the estimate to the sponsor/client/sales team/senior management.

The project manager talks through their estimate with someone from project support. (Note, talks through. This is not a box-ticking exercise in which you send a document to someone who checks you have filled in a particular form.) The project manager describes how they arrived at the estimate - who was involved, which past projects the estimate has been derived from or compared with, etc. Project support will ask questions such as: "Where's the change budget? Why only 5% contingency? Where's the user training time? How much time's in there for quality assurance? Why no travel costs?" Etc.

Frankly it's easy for a project manager to con the sponsor (what does the sponsor know about what should be included in an estimate?) but you cannot pull the wool over the project support guy's eyes: he's been there seen it and done it (see the chapter on project support). No longer can project managers get away with a guess, they must show someone independent that they have arrived at the estimate professionally. (You're no doubt thinking that you would of course arrive at your estimates thoroughly and professionally without such a check. No doubt you would. Checks like this aren't for you, they are for those colleagues of yours who might otherwise be tempted just to guess...)

Once the project support person starts seeing several project estimates he will rapidly tune in to the errors people most commonly make and he can then issues guidance to project managers. For example: don't forget to include time for team meetings which is usually around x% of total project man hours.

It takes maybe half an hour to go through an estimate with project support - more for a very large project obviously - but if mandatory estimate reviews are put in place it can result in an overnight and dramatic improvement in the accuracy of estimates.

Project Management Book
Copyright M Harding Roberts 2012 2013 2014 2015 2016 2017 2018 2019 2020 2021 2022 2023 2024
This book must not be copied either as is or in modified form to any website or other medium

Home   Sitemap   Contact Us   Project Management Articles   Project Management Book

Privacy Policy and Cookies