I’m loving PMBOK7. It’s far more pragmatic and helpful than previous versions, although speaking to other project management professionals (and trainers) they are reporting that students feel like they need the process stuff too, so they can actually get the work done.
I think I’m lucky in that I’ve got my personal ways of working kind of figured out, and over the years have built the confidence to tailor what I do to fit the project, and also the amount of time I have to spend on it.
I’m working on a lot of capex initiatives at the moment, so estimating projects for proposals is always top of mind. I turned to PMBOK7 to see what it had to say about estimating.
The book says there are 4 different aspects of estimating, each affected by where we are in the project lifecycle.
Range refers to how close you can get to what might be the final estimate figure. For example, in the early stages of the project lifecycle you probably don’t have a lot of detail about the tasks and therefore you might not be able to get close to some of your estimates.
Using ranges is useful because it helps present information when you still don’t have all the details. You can state a range like “between £80k and £120k”. As you get more information, you should be able to narrow the range, such as, “between £95k and £110k”. Eventually, you might be able to pinpoint an exact price.
To be honest, the exact price is often where we start from in capex, procurement-led projects, as the supplier provides a quote early on.
Accuracy is how correct the estimate is; how close to being “true” it is. A supplier quote – provided you have given the correct scope – should be pretty accurate. An estimate from the IT team about how long it is going to take to connect the asset might not be very accurate at all if they’ve never worked with this technology before. If it’s something they do regularly, they can give you an accurate estimate.
Precision is about how precise (obviously) an estimate is, or needs to be. Delivery dates for kit are often not precise at the beginning of a project, but as the stock comes in and suppliers can be more precise about when it will be shipped, the date estimates become more precise.
Confidence levels are useful to include in your estimates, and are especially useful for influencing culture. In my experience, they are helpful when you are working with experts who are reluctant to commit to timescales and dates. You can ask, “How confident are you that you can complete the work within a week?”
The more experience they have at doing that kind of work, the more confident they should be in their numbers. The more robust the estimating, the more confident they should be. Guesstimates have a low level of confidence.
Explicitly mentioning the confidence levels when communicating to senior stakeholders can make uncertainly more obvious to them. I’m sure we’ve all worked with stakeholders who, when you say, “some time during the month” expect it to be delivered on working day 1.
Not all projects will need all of these factors built into their estimates, and as your project progresses through the lifecycle, the way you create estimates will change. It’s worth bearing these factors into consideration so you can adjust and communicate about your estimates as you go.