Comments are closed.
Estimating Realistic Project Deadlines
June 28th, 2005
There’s an interesting post on Open Loops about the pitfalls of accurately-estimating project durations - and specifically the problem of over-optimistic schedules:
Many project managers can be myopic in this area and not see the potential pot holes in the road ahead of their projects. Being aware of these stumbling blocks and developing a system to accurately project deadlines can bring projects in on time and underbudget.
The technique is an interesting mix of mindmapping and focussing on next actions - in other words, ensuring that you’ve got a realistic and robust work breakdown structure - as well as a formulaic calculation. It’s not clear whether the formula is a rule-of-thumb or has been derived from data, but it’s probably a useful starting point.
I’m always a little wary of formulas - when there’s a calculation to come up with an answer, there’s always a temptation to rely on this as a definitive God-given answer that has to be correct to five decimal places - but if people are involved as a factor, there’s a danger that you’re lucky if the answers are accurate to an order of magnitude.
Nevertheless, it’s a good technique for creating quick-and-dirty “straw men” for planning purposes, and the breakdown steps are a good way of approaching the planning process.
Filed under Project Management |One Response to “Estimating Realistic Project Deadlines”
More important than a formula, I think, is buffer time. Always, always, always put in buffer time. How much? Depends on the size and scope of the project, but I wouldn’t hesitate to put anywhere from 10-30% buffer time into your project deadline estimates.
In my experience most people don’t use a formula. Instead they use their own experience and that of their team members to estimate how long a project will take. Depending on the familiarity of the project, available resources, and a host of other factors, you could be fairly accurate with this approach. But even still, buffer. That’s an absolute must, even if the project you’re about to work on is nearly identical to something you previously did. Buffer anyway. (Of course if that previous project already had a buffer, you don’t necessarily have to re-buffer.)
People are always hesitant to buffer because it looks like they’re covering their own rears - but in fact, the goal of buffering is to protect everyone’s expectations (boss, client, team, etc.) and to ensure that any potholes along the way (and there will be potholes) can be handled without losing control of the project, getting unecessarily stressed, and having a failing project.