Estimating project work for individual tasks or groups of tasks can be difficult – and it’s important to rely on the project team to either help with estimates or produce the initial estimates that you, as the project manager, then review and document. Is there a sure fire rule of thumb to project estimating? No way. Everyone bases their estimates on guesses, past experiences, and the advice of others…but nothing is perfect and no estimation will ever be 100% dead on…unless it’s by luck.
I do, however, think some people are much better at it than others. I’m of the opinion that estimating is more of a gift – you either have it or you don’t. It’s that ability to think somewhat abstractly on given tasks and figure out with some degree of accuracy what the level of effort will be. Of course, there needs to be a certain level of experience and expertise – but that experience does not always ensure that you’ll give good estimates. Over time, one can learn to be a good estimator, but it helps to have that gift.
From my experience, there are some key weaknesses or traps we can fall into when trying to produce good estimates. Being aware of these in advance can help the PM and team to avoid them, but it still won’t guarantee that you’re producing an accurate estimate. I’ve come up with a list of five that I think are the most common…
Weak requirements. Good, complete requirements are the basis for all of the work going forward on the project. Without good requirements, it’s difficult – if not impossible – to deliver an end solution that will be acceptable to the customer. And it’s certainly nearly impossible to accurately estimate the work that is going to be performed on the project. You may put together a great estimate based on the requirements you have, but if those requirements are poor or incomplete, then your estimate is worthless.
Too much optimism. If your estimates are always based on best-case scenarios, then you are always going to be surprised when you find your project constantly over budget. Risks and issues happen, some tasks end up taking longer than planned and sometimes customer issues come up that slow things down. If you always plan for everything to go smoothly, then you’re going to be frustrated time and time again with estimating failures.
Padding for the just-in-case scenario. Likewise, padding too much for the “what if’s” can be a bad thing. Estimates that are overly cautious present a picture of a greedy vendor to the customer and that won’t win you or your team any praise or confidence. Real estimates, based on what you know right now and what you think is likely to happen (with a certain degree of certainty), is the best way to produce good estimates. If you’re making assumptions on certain events possibly happening, write those down. But avoid padding too much for things that may not even occur. It’s a bad plan.
Not considering risks. Ignoring those risks that you diligently identified early in the project when it comes to estimating efforts is a bad idea. Not all will occur, but some will. And when producing estimates for the project work, it’s best to consider that at least some will cause your project a few headaches – especially the ones you considered to have a high probability of occurring. Be as realistic as you possibly can with your estimates – it doesn’t help anyone for you and your team to be too optimistic…or too pessimistic…with your estimates. Search for the right balance.
Rushing it. If someone comes up to you and says, “Give me a ballpark figure by the end of the day” and “Don’t worry, I won’t hold you to it,” look out! This almost always spells trouble. Never rush estimates for anyone. If it’s an estimate for work you’ve done a hundred times, that’s one thing. But if you need to put some serious thought into it, don’t let them rush you. Because, in all likelihood, you WILL be held to it. Be careful.
Summary
As I said, some people are great estimators and some people just don’t have a vision for it. I’ve always considered myself a good estimator and I am constantly testing that on development tasks by ball-parking task efforts and comparing them to what the experienced tech developers come up with on my teams. So far I’m still on track. But it is not an exact science. Avoiding these five common mistakes can help you and your team produce better estimates going forward.
