In a previous article, we offered advice to newcomers to project work: record how long it takes you to do typical project tasks. Here, we will show how that idea relates to the estimating techniques given in the Project Management Institute’s Guide to the Project Management Body of Knowledge (PMBOK® Guide) and we will review those techniques.
Building up an understanding of how long typical tasks take allows you to provide “Expert Judgement” to the Project Manager. If you have been through several projects previously, you will be able to draw on that experience and give confident estimates. As we saw previously, breaking down your work into components and allowing iterations to cope with mistakes, will enable you to have confidence in your estimates.
However, you should be aware of other alternatives. The PMBOK® Guide lists the following (as well as “Expert Judgement”):
- Analogous Estimating This is a similar idea to what we have suggested – basing estimates on previous, similar work. However, the context given here is estimating the overall duration of a project based on a similar previous one. Although this is easy to do, the Project Manager needs to be aware that all projects have some unique aspect to them, so s/he needs to ensure that the previous project is similar in fact and not just in appearance. Accuracy is expected to be in the +/- 15% range.
- Parametric Estimating. This works well if you are dealing with known quantities and where there is a lot of repetition. For instance, you might have to send some of the team to a foreign location and need to provide accommodation for their visits. All you need to do is find out the cost of one room for one night and then you can scale up to several nights and several team members. However, hotel rates are dynamic, so you would need to know weekend versus weekday rates and holiday rates. If you are planning to do lots of business with the hotel, there might be a quantity discount but it is better not to factor this in during estimation. Another application for this technique is when hiring contract workers. It these have a fixed daily rate, then the staffing costs are easy to calculate – assuming that you have reasonably good duration estimates for the work you want them to do. In general, parametric estimating works well for resource costing; it does not offer much to help time estimating. It is much better to make contingency explicit. If the Project Manager had said that there was three days to do the task, it is more likely that it will be done in three days. If there are problems, then the team member has to ask explicitly for more time to complete the work. Now the Project Manager knows that there is an issue and can use this to review the estimates and refine the process on subsequent projects.
- Three-Point Estimating: This is very useful because it is based on three estimates for each task. There is the “Optimistic” estimate which is basically the least possible time an activity will take. This is really worth studying, because you are asking for the length of time this would take if everything worked properly, first time out. The next estimate is the “Pessimistic” one. Here you want to know how long this will take if Murphy’s Law is strictly applied – what can go wrong will go wrong. This is an interesting exercise, because the difference between these two estimates is the risk associated with that particular task. Now you have to make a judgement call – or carry out risk analysis if you prefer – and decide how likely are these disasters to occur. This thinking will lead to a “Most Likely” duration. The figure the Project Manager then uses as the estimate is based on the formula [Optimistic + Pessimistic + Most Likely]/ 3. Although no longer mentioned in the , there is a more elaborate form of the three-point estimate called the Program Evaluation and Review Technique (PERT). This uses the same three estimates as Three-Point Estimating. However, it uses a different formula that puts more weight on the “Most Likely” estimate. So, calculate the “Optimistic”, “Pessimistic” and “Most Likely” estimates as before, but now plug them into this formula: [Optimistic + Pessimistic + (4 x Most Likely)] / 6.
- Bottom-up Estimating. Instead of trying to dream up an estimate for the entire project – by using analogous estimating, for instance – the bottom-up approach involves dividing up the work into smaller portions and coming up with estimates for these. This is often easier to do, because team members should be familiar with component tasks and how long they are likely to take. Once estimates are obtained for each component, they are totalled together to generate an estimate for the total project. Bottom-up estimates tend to be accurate but, be warned, they are time-consuming to create. Having said that, getting the team involved in the estimation process is a great way to get buy-in for the project, so this can be time well spent.
- Reserve Analysis: Because of the inherent uncertainty in projects, Project Managers like to add some contingency to the schedule. Traditionally, this is done by padding out the individual estimates. This approach falls foul of Parkinson’s Law (work expands so as to fill the time available for its completion). If the estimate for a task is three days and the Project Manager pads this out to five days, then one of three things can happen: (1) it actually does take five days because of problems with the task. The Project Manager can take a bow at this point, having prepared for this eventuality. (2) It takes longer than five days. This is a lesson to be learned – more padding is needed or, better still, improved estimating. (3) It actually does take three days (or less). In this case, the project team member is likely to deliver after five days anyway, giving no advantage.
At Velopi, our PMP® exam preparation courses cover Project Schedule Management and these estimation techniques. They also cover the other nine knowledge areas needed to obtain the PMP® accreditation. For more details of these courses, please visit our training page, or contact us directly.