Your team members get a bit wiggy in giving you an accurate estimate for a lot of reasons. Maybe they have no idea how long the task will take, or maybe they’re afraid they’ll get pulled away to fix the CEO’s email account for the third time that week.
You can help your team members feel confident in giving you accurate commitments by asking for a range of dates for delivery.
A range of estimates doesn’t mean you adopt the latest date, just to be on the safe side. Parkinson’s Law says, “Work expands so as to fill the time available for its completion.” If you give most of us more time than we need to do a task, we will often use that extra time to make the task “better,” by adding features, doing additional testing, etc. While obviously good intentioned, this kind of “gold plating” will make the project take longer than it should, and may introduce new issues and risks.
The best way to get a range of estimates for a task: Instead of asking Joyce when her task will be completed, as her for a best-case scenario, worst-case scenario, and most likely scenario. Discussing the rationale behind her numbers will bring up risks and issues. Also, now that Joyce feels like she doesn’t have to deliver it at the first opportunity, or to be safe and pick the last possible date, she will feel more confident committing to a reasonable date, which she has 90% confidence of achieving.
In order to get a good range of dates, allow each team member enough time to think through the problem before getting a commitment. If you ask a team member to estimate a task on the spot, he will probably make up a number quickly just to make you go away. Giving folks the time to come up with a careful estimate will pay off in greater accuracy in delivery.
You can also get around padded estimates by asking for task effort, instead of duration. Let me explain.
If you ask your team members, “When can you get this task done?” their answer will vary, as they calculate other projects they might be working on, other issues that might come up. Instead, consider asking, “Ok, pretend you can work uninterrupted, nonstop on this task, with all the caffeine you can drink. What’s the number of hours you need to get it done?” Once you know the amount of effort required, it allows you to add in all the variables to come to a real duration. Your team member shouldn’t have to do that calculation on his own. Be sure that the estimate you develop together takes into account the skill level of the folks doing the work. Just because it might take a normal person 3 days to complete this task, doesn’t mean that it will take Alice three days. It might take her one afternoon, because she has specialized skill, or it might take her a week, because she needs to come up to speed on some underlying concepts before she can really get going.
No one works 100% of the time. By acknowledging this in our estimation process, we can get to more accurate duration estimates.
By explicitly examining and working through all the buffers needed, you get the information you need to estimate as accurately as you can during planning. The more uncertainty, the greater the buffer. You can have contingency amounts for a particularly risky work package, or for the project as a whole.
The size of the contingency, and whether it is at the work package or project level, is entirely dependent on the risk inherent in the project at the time the schedule is developed. So you see, padding isn’t always bad – just as long as YOU’RE the one doing the padding!
Help your team start each of their tasks as soon as possible in the schedule, as this will also reduce risk and uncertainty.
And above all, make sure that some externally mandated date doesn’t drive the thought process for your team members! You need to understand what it really takes to deliver on tasks, not drive your people to a death march. This can be tough, as some of your shareholders may assume that everyone pads their estimates, so they may want you to cut the commitments you’ve made. This is not a game you want to start playing! Be ready to carefully defend your schedule if challenged.
If estimates for some tasks are still fuzzy, it might be a sign that you need to break that task down into lower level tasks, in order to get to a clearer estimate. If your work breakdown structure is flawed, your estimates will be inaccurate, so it might be a good time to make sure you don’t need to refine things a bit.
Great post! I think one of my biggest crusades as a project manager is getting people to understand the value of ranged estimates. I learned the hard way years ago how a single point estimate made early in the project can be completely unreliable as you get deeper into the project.
I really like what you bring up about task effort vs duration. It’s not just meetings,informal discussions and other various project related distractions that will pull the team member from their work on that task, but fixing the CEO’s email for the third time, like you mentioned. This is a harsh reality in many teams, like in the one I work with now where we end up being the IT support for our non-technical co-workers when our IT guy in the other office isn’t available.
Nobody wants to accept that there are distractions that will pull a person off their task and make it take longer. And at the same time, these are the people who make the distractions most of the time. It’s almost funny.
I think it would be interesting to come up with an algorithm for each team member, taking into account all of the potential distractions that they might have. So, it’s a very personal thing, and would be used to come up with the real duration (ranged of course) for their tasks.
I can’t comment on a topic like this without making a plug for my most favorite online project management tool, LiquidPlanner. LiquidPlanner is the only tool that I know of that is built around ranged estimates, creating a schedule that is much more reliable and includes that critical level of uncertainty. I wrote about it (including that time where I learned the lesson the hard way) here: http://thecriticalchain.blogspot.com/2009/05/story-of-my-never-ending-love-affair.html