Who should produce estimates?

Estimates Are Painful

Estimating is a bit of a pain and there are two reasons for this:

Firstly, you are asking people to think about something, and while people like to think about things, they don’t necessarily like to be told exactly what to think about.

Secondly and perhaps more importantly you are asking people to be wrong. No one likes to be wrong and putting out an estimate that depends on multiple factors that are hard to predict means it will probably be wrong.

When something is painful, people will shy away from it – it’s human nature. But when it comes to estimating, we can’t just put our heads in the sand and say nothing. Someone will need a reasonable idea of when something is going to be done and a response of “it’s done when it’s done!” will generally not be good enough. As a developer, team, company why should you care? Because usually that person is paying for something and if he is not happy he might stop doing so.

An estimate must be provided, but who should do it The sales person? The project manager? The team?

Project Manager, Sales or the Team?

If we leave the sales person in charge of estimating often you will get a ludicrous deadline. Sales are focused on selling and if they can sell today why wait for tomorrow? After all, they don’t have to deliver anything – so they will be happy to succumb to the customer pressure when they really want that pink fridge/freezer that also makes coffee. So, not Sales then.

What about the Project Manager? This person is not so pressured to agree with everything the customer wants. They might also be experienced enough to understand what’s possible and what’s not. Depending on their technical ability they might know enough to hold their own, however they will not be working (in the sense of hands on code) on it so having them dictate downward can be toxic for the team that don’t buy into a timeframe that they were not able to contribute to.

Finally, we have the Team (in this context the team is the developers and tester that will have hands on code). The team is perfect to estimate, they have technical know-how, they are the ones doing the work. Multiple people thinking about the issue enables different viewpoints and richer estimates. So, the team is the right place to go for an estimate. However, this is not the end of the story.

Having the Right Balance

There is a thin balance between too high level and too detailed. If you go too high level the probability of leaving some important detail out which will appear at some point and potentially clog the whole project is higher. However, going too detailed is not the answer either, as you can spend an awful lot of time scrutinising what needs to be done. Time that you could be using to get ahead in the project. The other thing about going very detailed very early is that things might just not be known, meaning you would have to start doing hard assumptions, and while assumptions will always be there, in a detailed context they become harder to back track. So, save yourself some time and do it at the right level. Obviously, it’s easy for me to say do it at the right level and not provide a more tangible description of when do you know that you got the right level, but let’s leave that for another blog post.

So, the team is your best bet to get an estimate, but should that estimate just bubble up to the customer? I would say not. It should be questioned and revised by someone before it is offered to the customer. Why? Usually the team is less aware of market pressures or customer constraints. After an initial estimation, there should be a discussion to see if the assumptions made at estimation time were sensible. If there are ways of delivering more value sooner, what is the degree of confidence in the estimation, etc. When everyone (sales, manager, team) is happy then an estimate can be put out.

Finally, this should always come as a date range and not a deadline. Estimates are estimates – if they are presented as deadlines, people will take them to be fixed.