Common mistakes when estimating project work - Part 1Estimating isn’t an exact science, that’s for sure. And just like the football quarterback who can read defenses quickly – you either have it or you don’t. You can fake it till you make it often, but it can be painful getting there and you may lose a project or two along the way. What I’ve always found to be helpful – at least in terms of all the IT/technical projects I’ve managed – is to have a background that gives you good insight into the work being done. My background is technical – I used to be an application developer (programmer) as well as a manager of application developers. That has a definitely served me well when estimating project work such as the entire project, testing work, and project change order work that comes up from time to time.
If you don’t have this ability, then surround yourself with trusted team members who can give you solid estimates on your projects or make alliances with colleagues who can do this. Favors are ok things to call in when needed.
I’d like to discuss some common mistakes that project managers and team members make when estimating work on projects. To be exact, I’d like to discuss the following 9 potential mistakes over the course of two articles:
- Poor or incomplete requirements
- Pressure from management
- Not considering risks
- Too much optimism
- Omitting key information
- Miscommunication between estimator and implementer
- Estimate padding
- Not enough time
- Failure to ask the right person
For this Part 1, we’ll look at the first four items above…
Poor or incomplete requirements. If the requirements are not detailed enough or the scope of work is poorly laid out, then it’s nearly impossible to provide an accurate estimate. You can try, but estimating the unknown is extremely difficult and you’re usually setting yourself and the project up for failure. Go back and put more detail into the requirements before putting together a detailed estimate that you’re going to sign your name to.
Pressure from management. Never, never, never back into an estimate based on difficult targets and timeframes that senior management hands down to you. Depending on the organization, I’ve seen this happen rarely to a lot. Be careful and push back when possible. That said, if you are forced into this situation, be sure to let them know that there is risk factor in that estimate and you’re not comfortable with it. It save your job if things go horribly wrong, but you need to
let them know so they can make more informed decisions going forward.
Not considering risks. Uncertainty and risk must be taken into account. I’ve never had a project or a change order that didn’t have at least some degree of risk and uncertainty. Always revisit risks when estimating project work and be sure to factor that into your estimate based on the likelihood a particular risk event could happen. It isn’t easy, but it is necessary. And make it a meaningful factor, not a standard factor you plug into every estimate you create.
Too much optimism. When the estimate you make or receive is based on truly best case scenarios across the board, then your chances of meeting that estimate are slim or at least are definitely at a big risk. You would not make a household budget based on everything going perfectly all the time with no risk of an appliance breakdown or a car repair, would you? Right. So don’t do it here. Issues arise. Risks are realized. Don’t go overboard accommodating the risks and potential issues, but make the estimate realistic.
In Part 2, we’ll discuss the next five items on my list above.
This is a guest post from Brad Egeland who is an IT/Project Management consultant and author with over 25 years of software development, management, and project management experience leading initiatives in Manufacturing, Government Contracting, Gaming and Hospitality, Retail Operations, Aviation and Airline, Pharmaceutical, Start-ups, Healthcare, Higher Education, Non-profit, High-Tech, Engineering and general IT. Brad is married, a father of 9, and living in sunny Las Vegas, NV. Visit Brad's site at http://www.bradegeland.com/.