How long do you think it will take you to complete this task?
I should have it done in a couple of days.
Are you sure? I know you have (list activities here) due or on-deck.
Yeah – shouldn’t be a problem. I’ll get it knocked out in a couple of hours.
We set a mutually agreed-upon due date.
Meanwhile – I check my project plan to see when the “panic date” should be.
——————–
I venture back to the project team member the day before our mutually agreed-upon due date.
How’s it going?
Um…not quite done yet. (add excuse here – often the other activities due or on-deck took time and energy the team member didn’t account for, they are waiting for a piece of information from someone else, or they mis-calculated how much time it REALLY takes to complete a task).
We set a mutually agreed-upon due date.
I double-check the impact and make sure I didn’t agree to something based on the assumption of the first due date.
——————
Typically, the above scenario will repeat for a few rounds. We start having harder conversations as we get closer to the panic date.
I feel like a negative nellie when I question my project team member’s time estimates.
But I’ve lived through the above scenario way too many times to count.
From what I’ve seen, project team members regularly under-estimate how much time it will take to perform a task.
Common reasons:
- Accounting only for the time it actually takes to do the task, but NOT the thinking and design work that also needs to occur. Don’t be surprised if you hear “So is that just the time it takes to do it or does that include design time?” from my lips.
- Forgetting to set aside time for information collection. Especially if they need that information from others. If they are working in an environment where “knowledge is power” – that time needs to be extended even further.
- Forgetting to set aside time for approvals. I tend to work in politically sensitive environments, so I’ll often ask if there is anyone who needs to see their work before it gets turned in.
- Forgetting they are human. I’ve been fortunate enough to work with some really good people who want to be superheros. They will agree to do anything on the most impossible timelines. They don’t want to disappoint.
- These are the people who tend to be the most over-burdened. As a project manager, I frequently don’t have visibility into the resource’s other tasks. Often, these folks don’t feel like they have the power or right to say “no.” Asking for help feels like failure.
- Things will slip through the cracks, and it becomes tricky to determine the cause and how to help. The team member feels bad, I get stressed, and things don’t get done. No one wins.
——————
When estimating task times, I will often set two dates:
- The due date the project team member and I agree to.
- It’s important we both agree to the date. It’s part of establishing a feeling of ownership around the project for the team member. Furthermore, I often won’t have visibility into the team member’s other activities – so their honesty is critical.
- I don’t need a superhero. I just need to know when a task will get done and trust it will be done when they say it will.
- The panic date – often the date the task needs to be complete before impacting other tasks on the plan.
- The only time I tell people outright when the task is due is when we are under a really tight timeline and that task impacts other tasks on the critical path.
- The only other time – when that team member has proven repeatedly that they will miss dates for a wide array of really lame reasons.
If that task is on the critical path – missing the panic date means impacting the project go-live date.
—————–
I’ve talked about this before:
Leave a Reply