Solid effort and cost estimations are the basis for a successful project. That’s why you should go about effort estimation with great care.
In this article I’ll show you how to estimate manpower in a project. We’ll look at different methods and pitfalls you need to be aware of.
The reasons why estimates are often wrong
Do you know why estimates often turn out ot be completely wrong? It’s mainly because the scope and requirements were not 100% clear. Project teams rush into a project without taking the time to fully understand the customer’s requirements.
Later when the project is already going full steam, the team realizes that what the client wanted is actually a lot more complex. And tasks that were estimated with 5 days suddenly take 10 days or more. Or effort explodes, like for this poor guy:
A sloppy requirements analysis isn’t the only reason for bad estimates. Another reason is overconfidence.
Often the underlying reason for this is the desire of team members to impress their manager. Write an entire piece of software? “Easy, I can do that in three days!”. Don’t take such statements seriously and challenge them instead. You are not participating in a competition for the shortest time. You want to get realistic estimates!
I’ve create the following overview which shows you the factors that determine the quality of your estimations. Apart from your knowledge and experience in the subject matter, also any assumptions you make can influence your estimations. The assumptions could be wrong and consequently, your estimations too.
Also, keep in mind that pressure may affect your estimations negatively. If you are under pressure to deliver a project plan that’s bad because you’ll be less attentive to the details of the project and you’re more likely to deliver inaccurate estimations.
Things get worse when you have an overly optimistic boss who is putting pressure on you.
Who should estimate effort?
Any effort estimation should be made by the person responsible for the task. Not by the management, not by the client and not by other parties which don’t have the required expertise.
The project manager can help in the process to get a solid estimation. He can challenge the numbers. He can give context about the task and how it ties in with the overall project. He can ask other experts for a second opinion. And he can add contingency to make up for overly optimistic estimations (read more on how much project buffer you need).
But the effort itself should always be calculated by the person in charge.
Do you have a clear scope?
You must have a clear picture of what the project is supposed to deliver. In other words the project scope must be fixed. If you’re still unsure on what is expected from the project, go back and clarify with your stakeholders.
Make a list of tasks
I always start with a list of the tasks that need to be performed. It can be a simple Excel file like in the following screenshot.
For bigger projects you may want to create a work breakdown structure (WBS) first. It gives you an easy to grasp breakdown of the project deliverables and work packages. And then you can derive the necessary tasks from there.
One important point is that each task should be clearly defined. What work does the task involve? Where does the responsibility start and where does it end? Does the task include rework? If yes, how many cycles? These are questions you need to sort out first.
I also recommend you wait with estimating work until you’ve assigned a responsible person to every task. You can’t really make good estimations without involving an expert. Also, making the estimation part a mutual task creates the buy in that you need so much. You don’t want to adhere to an estimation that someone else has made for you.
Here’s another idea I want to share with you:
Why not begin with a study?
The biggest challenge to coming up with accurate predictions of labor effort is that we are usually still too far away from the actual project that it’s almost impossible to make good estimations. Coming up with estimates for tasks feels like playing Russian roulette. It could be totally wrong!
How can you deal with this situation?
One of my favorite approaches to this challenge is to make a small study before the actual project. A study is a “micro project” usually taking no more than 4-8 weeks. And its purpose is to take a closer look at the requirements, determine the scope and to get super solid cost and effort estimations.
The findings from the study are then used to plan the full project.
I encourage you to start with a study whenever possible.
My favorite estimation techniques
Depending on the work you’re looking at, you can use a different estimation technique. Some techniques are more suitable for specific planning challenges while others can be used in most circumstances.
Here are my favorite estimation techniques:
- Ask the expert
- Task breakdown
- Learning from other projects
- Optimist / pessimist view
Ask the expert
We already touched that method. You ask the person in charge — the one who’s going to do the task — how long he or she thinks it is going to take him or her. That’s usually the best estimate you can get!
Keep in mind that the quality of estimates you get largely depends on the quality of input you provide. The more specific the description of the task, the more reliable the estimate will be.
Here’s an example:
unspecific: “How long will it take you to upload the customer data to our IT system?”
specific: “We have a list of 45’789 customer addresses that need to be uploaded to the system. We’ve checked the data and removed duplicates. If we provide you the data in the right format, how long will it take you to upload?”
Make your guess: which request will give a more accurate estimate?
The bigger and more complex a task, the harder it is to make reliable estimations. Instead of hoping your predictions will be right, it is better to break those tasks down into smaller pieces. Then estimate each piece separately and add up the values.
This method is also called bottom-up estimation.
Here’s an example:
Imagine you had asked your technician how much time he would need for getting WiFi set up in a hotel. He would have looked at the building from outside and would have made a superficial guess: “Probably around two days”.
But a break down of the job into subtasks would reveal that the entire installation would take around 3 days. That’s a 50% margin of error!
And this is just a simple example and the extra day spent wouldn’t be too much of an issue. But imagine you are coordinating bigger tasks that involve dozens of person days, such as the assembly of a machine, the construction of a building or the development of software. Bad estimations for a single task can easily tank your entire project!
Learn from other projects
You may find it hard to make reliable effort predictions if the project or task is completely new to you and you can’t rely on past experience.
For those cases it’s a good idea to look for similar projects that you can take as a reference:
- Are you aware of any projects that are similar to yours?
- Do you know anyone who’s worked on a similar task or project?
If you don’t have a reference project to look at, you can do some research on the Internet and get in touch with other project managers who might be able to help you.
For example you can go to LinkedIn groups or other online discussion boards and see if somebody has done a similar project. If so, these people can give you input for your task estimation.
I’ve written a long post about the many ways to get help for setting up your project. Go read it
Let the optimist and pessimist speak
There is an easy way to improve your estimations: Let a number of people estimate the effort for the same task. Then take the average or median value from the resulting estimations.
This estimation method produces more reliable predictions because it takes into consideration the experience and psychology of a group of people and avoids bias from your own work.
Some people have more experience in the issue. They see things you forgot to consider in your initial estimation.
The other benefit of this method is that it balances out any bias caused by optimism or pessimism of the person estimating.
Estimations should be based on assumptions
Think about this: We are only able to make estimations if we make assumptions about the environment we are operating in. If we assume certain things to be true. For example:
- We assume a certain level of skill for the people performing the task.
- We assume that external conditions like weather or traffic will be as expected based on past experience.
- We assume that the tools we are using (like cars, trucks, computers or machines) will behave as reliably as we know it.
- We assume that team members will live up to their responsibilities.
Whenever you make an estimation you subconsciously assume that certain things are true. For example, if you are tasked to deliver goods from Chicago to Memphis you believe it will take the normal 8 – 9 hours that Google Maps is giving you.
You assume fair weather conditions and normal traffic.
So, your estimation should be linked to the underlying assumptions:
“We estimate delivery to take 8-9 hours, assuming good weather and normal traffic.”
Always communicate your assumptions to the client and to your management. This way you won’t look like a fool when something changes and effort rises dramatically for a task. Ideally you have set clear assumptions the estimation is based upon.
Then if conditions change — such as a winter storm coming up that leads to traffic issues — you can say to the client: This wasn’t expected and it is not within our control. Thanks for your understanding.
Conclusion: How to make hour estimations that you won’t regret having made
When estimating project hours, your first step should be to get a good understanding of every task that needs to be performed. The second step is to make reasonable assumptions for the process behind each task as well as the conditions a task is performed under. Finally you ask your experts in the project for effort estimations.
Keep in mind that estimations are always guesses and don’t expect to be right all the time!