Dear Elizabeth: I work in a technical team as a project manager. We do a lot of projects that are innovative (for us), and my development colleagues always seem reluctant when it comes to project planning. They won’t give me timescales that will help me plan. How do you deal with a team that refuses to estimate how long tasks will take? I’m getting tired of hearing, “It depends.”
It depends on what?
Estimating can be done in several solid ways, and frankly, it sounds as if your colleagues don’t know how to estimate properly or are scared to give you the timescales that pop into their heads.
However, if you tell them that, they probably won’t want to work with you again, so let’s take a gentler approach to help them give you the information you need for the project planning. Below, I’ll give you some suggestions to try. They might not all work for this particular team, but hopefully, something will resonate with one or more of your colleagues. Then, they can start to give you something useful.
Break Down the Work
It is difficult to estimate when the task is too big. What does your work breakdown structure look like? If the tasks are too chunky, it will be too challenging to come up with anything like a realistic estimate. Can you break the work down even further?
You might not need to document this granularity on your work breakdown structure, but your team could go through the exercise to split out tasks into their component parts. Then, they can use bottom-up estimating as a way to create a more realistic estimate for the work.
Remove the Uncertainty
I agree that it’s hard to estimate with any accuracy if you haven’t done the work before. However, in most tasks, there is something you have done before or done in a similar enough way to give you grounds for a reasonable estimate.
For example, let’s say you were asking the team to build fingerprint recognition to log in to your latest mobile app for a client. You’ve never done this before. But, you have done the following:
- Put together requirements—you can estimate that part.
- Built the behind-the-scenes login features—you can estimate that part.
- Tested new features before—you can estimate that part.
- Gone through the release process—you can estimate that part.
All the stuff that you have done before can be estimated. Yes, it depends on who gets the job and how the previous tasks have gone and how many bugs you find, but even if they are guessing, they should be able to come up with something.
For the part that is truly unknown, try to relate it to something else they have done in the past—preferably something that was also truly unknown at the time. Ask them about a time that they had to build something else brand new and how long that took. Ask what challenges they faced and what contingency time they had. Use that discussion as a starting point for them to come up with estimates for this piece of work.
Using the data from previous projects to estimate timescales on your current project is called parametric estimating (and it’s my favorite way to estimate).
Where you can’t remove the uncertainty, add this as a risk to your project risk register. It helps raise the visibility of the problem and makes sure it is on the radar for some active management.
Let Them Use Predictive Scheduling
Teams often get hung up on the fact that project managers ask them to estimate to a fixed point. They think you want to hear 52 hours or 6 days. You don’t need this level of precision to be able to build out a plan.
Use project management software with predictive scheduling and give them a bit of wiggle room in the estimates. Use the three-point estimating technique to establish a range of most likely and least likely durations for the work. Then, use intelligent scheduling tools like LiquidPlanner to plug all that into your plan.
When people understand that they aren’t going to be fired for getting the estimate wrong by a few hours, they are more likely to give you something rather than nothing.
Pack In Some Contingency
Another way to help teams feel more confident about their estimating is to explain the principle of contingency. If you have done similar projects before, you’re likely to be able to estimate with a degree of certainty because you are repeating something you’ve already achieved. You don’t need as much (if any) contingency because you already have a good idea of how long the work will take based on last time.
If the work is unique and innovative, your appetite for contingency is likely to be higher. In other words, you want to include a time buffer that allows for your estimates to be wrong by a margin that relates to the riskiness of the project.
You can add contingency at the level of a task or phase or the project overall. Don’t add it to all three steps or your schedule will be bloated. It might be appropriate to add a lot of contingency to the uncertain tasks and less to the stuff you know how to do.
Tell your team this. Let them help you decide what contingency margin you should be adding to the project, and then go and negotiate that with your sponsor.
Contingency works for budgeting too. If you add in contingency for time, don’t forget to adjust your project budget contingency to make sure that if you do run into contingency time, you’ve got the budget to pay for it.
In my experience, people are reluctant to provide estimates when they think they are going to be held to them, and they expect that to reflect negatively on them. They would rather provide nothing because then they can’t be accused of getting it wrong.
This level of fear about how the data is going to be used is unhelpful for everyone. The more you can do to build trust in the team, the better. They need to know that you aren’t going to blame the whole project delay on them if they overlook something and the project slips by a week.
Note that this shouldn’t be an invitation for them to just guess at the first thing that pops into their head or do sloppy estimating. Assuming they can “show their working,” let’s give them the benefit of the doubt.
You can also build trust by implementing proper change management and risk management processes. Document your decisions. Explain to the client and project sponsor why timescales might change, and then let them know early when they do. The more your team sees you do this, with transparency and honesty, the more likely they will be to trust you with the data.
The next time someone on your project team tells you they can’t estimate because it depends, ask them genuinely, “On what?” Then, work with them to unpick those problems, add them to the risk register, plan out what they can, add in contingency, and come up with something you can use to create a schedule based on a ranged estimate.
Then, monitor the work and tweak the estimate as you go forward—trust me, it will be useful to have a record of the length of time the work actually took for the next time you do something similar!