How do you estimate time needed for a project? Do you work with the resources involved and look at the activities? Do you do a scientific calculation? Stick a finger in the air and use your experience? What’s the best way for you to get reliable and realistic estimates? And how often do they remain the same as the original estimates?

Estimating with any sort of accuracy can be exceptionally difficult because there are so many changing factors and possibilities which can cause a project and estimate to change or be wrong. When you become a PMP you work on accurate estimating through project documents, expert estimating, analogue estimating, parametric estimations, three point estimations and so on but when you get into the practicalities of project life, you’ll see how the cone of uncertainty really becomes a reality when working in any project where environmental factors play a role.

Source: https://www.promptworks.com/blog/why-cant-we-tell-when-software-is-done

When I try to explain to the Steering Committee about estimates, I often use a diagram similar to the one above to convey why our estimates initially should be taken with ‘a pinch of salt’ and why we need to wait until we have got further into the project to make firm and accurate estimations due to the nature of change. Working in an agile mindset, means that this discussion is often a lot easier to have because they understand that requirements may not be fully clear/detailed.

Working in a waterfall environment can lead to a more difficult discussion but I wanted to take some time to explain how I go through this discussion as this is often a question that I get asked.

1)      I start by using terminology that they understand rather than specific project management terms. I talk about the end goal of the project, what needs to be achieved and the business objectives that this project will meet

2)      I then discuss the level of detail that is currently known in the project. Normally, it is never detailed enough and I use this to explain why misunderstandings can occur or why when it is fully detailed that you can only get a good feeling for how long that it’ll take to deliver.

1. We often do not spend enough time at the start of the project working through the requirements and real ‘needs’ of the project and this can cause issues and is a major risk that requirements are not clear enough for projects.

3)      Furthermore, I go through why it’s completely normal for us not to know everything immediately as there are always unknowns in a project and then explain how the ‘enterprise environment factors’ play a role, always making it specific to the organisation and project. The next step is to explain the importance of contingency to ensure that the deviations are acceptable to the Steering Committee.

4)      I conclude the discussion by explaining what we’ll do to make ‘best effort estimates’ for the current state of the project. This will include expert judgement, existing project documents available and any tooling that I’ll use for my estimating (e.g. parametric, or 3 point estimating). I find it important to end on what you’re going to do to get the level of detail that you need.

This is often a discussion that a lot of Steering Committees and management do not want to hear because that simple uncertainty is a major risk and something that they do not want to deal with but I think that it’s critically important to be open and honest if you know that you’re estimates are likely to be unreliable. One thing that I do on a regular basis throughout the project is taking the time to re-estimate once the project landscape is a lot clearer and more visible. This gives me the opportunity to analyse if I need to make adjustments or to let the Steering committee that there will be a deviation.