Bad estimates are amongst the top reasons for a project failure. Here are some insights to avoid fall into this pit.
There are several reasons for having a project failure. But, besides some problems emerging as the project goes by, project delays can be identified straight away on day two. So, why do project delays still happen so often? Due to bad estimates.
The lesson I learned, that sounds quite obvious – but I know it is still common place in several projects – is having task estimates fitting deadlines, and not the other way round. And how to avoid such ridiculous but still typical problem?
First, before getting your hands on aproject, understand what needs to be done. Obvious, right? No. So often, things are assumed, tasks aren’t clear and the team is too optimistic. And that’s a perfect recipe for failure.
You, as the leader, need to understand what’s expected (at least roughly) to pass to your team. Your team will get back to you with doubts (and that’s good) and you need to be able to give them objective answers. Having clear in your mind what’s required, how can you know your team got it correctly as well? There are several ways to validate information. I tend to ask back to the team – in their words – what they have to do and how they expect to accomplish the task. I perceive two good outcomes from this exercise when I apply it: it forces the team to think thoroughly about the issue, making them realize some unexpected issues down the road and also helps a lot when giving the estimates, as the task as a whole is clearer.
After this step, you and your team will realize how unclear tasks are. But you need to provide estimates and users have no time to clarify questions right now to help you to give more accurate estimates. What would you do? One thing that might help on this task is a quote lookup matrix. On it, the first column will present the tasks complexity and on the second, the confidence about what needs to be done. Both indexes come from very low to very high. Ideally, tasks considered very high must be split in two or more sub tasks; tasks with confidence very low needs to be discussed again with users as a priority. Besides, when you identify a task that you’ve already clarified as much as you could with users and it still sounds like high complexity and low confidence, get ready to have some padding on this estimate. On the other side of the spectrum, a task with low complexity and high confidence is likely to be delivered within the team’s estimations and you don’t need to worry about it. I thank Barry for presenting me the concept of this quote lookup.
Now you (roughly) know what to do and how long it will take. Probably, you will realize it can’t be done within the initial deadline. It’s time to go back to stakeholders and prioritize tasks between must have and nice to have, letting it clear – I. e. documented – what will be delivered on target and what may be delivered (in an optimistic scenario). From this step on, you’ll have your team focused on what’s required, avoiding the team burnout.
So, in short:
- Understand what needs to be done (avoiding assumptions)
- Make clear your team knows what needs to be done
- Break down the tasks
- Identify the ones that still need clarification
- Provide estimates, properly adjusting the most complex cases
- Review your deadlines and check if your estimates fits on it. If not, define with your stakeholders what the priorities are.