Estimates are like promises. You make them, and you need to keep to them. Your reputation depends on how good you are at making estimates.
There are many techniques and methodologies of producing estimates. Nevertheless, communication is still the key. Below you will find an example of communication between a project manager and his team.
Then, you will find 7 concepts that support creations of estimates.
Example of Producing estimates
Corwin is a project manager on a small software development project. One day he receives one of the numerous requests to assess implementation of a new feature. As always he quickly scans the document. Everything looks rather simple. He pings Peter – his team lead – to check who can handle this one. They agree that a new guy John can do it. It will be a good first task for him.
Corwin sends the email with the specification to John. Then he gets in touch via instant messenger.
Corwin: Hi, John. I have just sent you a specification. It describes a new feature we need to implement. I talked to Peter, and he wants you to take the task. So, as usually, please analyze the document, decompose the work and provide estimates. Please also note any questions that you have.
John: Hi Corwin. Got the email. It is a five pages document. It will take some time… about 4 hours.
Corwin: OK, take your time. Check the estimates with Peter before sending it to me. After that, we will discuss them together. Let me know if you need my assistance. Thanks!
Later this day Corwin gets the estimates. He takes it and walks back to John. It is much easier to discuss estimates face to face. Email and text messages always feel a bit aggressive when you talk about efforts.
Corwin: Hello, John. How it’s going? What do you think about the new feature?
John: Everything is fine, thanks. Well, it’s quite straightforward, but some aspects are not entirely clear. In general, I think users will like it.
Corwin: Great. Walk me through your estimates. What is it in “Update old controllers”? Sounds like a lot of work…
John: Yeah. Old code, a lot of places where we need to make changes. Plus, I heard about when you touched it last time. It was a mess. We need to re-write it from scratch.
Corwin: Not this time, I’m afraid. We need this in the app soon. OK, we expect troubles here. Let’s keep it that way. How about putting it as a risk?
John: Yes, I think we can do that. Let’s play it safe.
Corwin: OK. What’s next? “Read-Write” look OK to me, but what about “Conflict Resolution”?
John: Well, the spec is slim here. And there are too many cases there. I expect we will find them all only during testing… We will be pushing the task back and fore.
Corwin: If we get you a detailed specification, how much will it take then?
John: I think, seven days max.
Corwin: OK, then we need to get the updated specification before we get to this feature. It will save us a lot of time and nerves. I will handle it. But it is still quite a lot of work. I think you need to decompose it further. We need checkpoints of your progress. You know, to see if things start to take more.
John: OK, will do. But the full spec is a must here. The next one is also scary. We need to update the framework. We have not tried it yet. You know it is that third party thing. It is always buggy.
Corwin: Yes, that is a risk. And let’s handle it as a risk. Let’s assume that everything goes well. How much will it take?
John: One day, I think.
Corwin: OK, and if everything goes really wrong?
John: Well, I think in about nine days we can implement our own framework.
Corwin: Let’s take one day to implement, one day to debug and put a medium probability risk. With impact up to two weeks. I will talk with technical management, and maybe they know details, and we worry too much.
John: Agree. Then, assign me to that risk I will monitor and report on it.
Corwin: Very well. Please update the estimates and send me the final version.
John: OK.
Corwin: Thanks. See you later.
Corwin: Hello, Peter.
Peter: Hello, boss.
Corwin: I need a few minutes of your precious time. Have you seen the estimates from John?
Peter: Yeah, we need to explain our standards to him. Deeper level of decomposition, tasks no more than two days and more comments. Especially, for risks. But in general, he did a good estimate.
Corwin: Yes, and tell him more about to describe all the problems. We should not hide them in the numbers. So, what you think, are the numbers valid?
Peter: Well, yes. However, I would suggest adding a bit. I believe he underestimates the complexity of the UI implementation. I bet we will need an extra day. And testing. It is too little. We will need half a day more.
Corwin: OK, I will adjust the estimates.
Peter: As for the risks. That full specification you want to produce. You need to ensure I can have some time to review it and pass back questions and corrections. I expect two or three iterations on this.
Corwin: Very well. Let me put it down here. We will need to track this risk. It will be on me.
Peter: Super. I think we are good to show this to the client.
Corwin: Thanks. I will let you know their feedback later today. See you.
Corwin spends some more time to brush up the document and correct wordings. His documents always have a professional feel and touch. Even such small ones. He never sends estimates alone.
He writes a letter that explains that the team read, analysed, and discussed the feature. He goes on with any questions or assumption they have. And then goes the estimate. After that, he tries to shape up clients expectations. Corwin describes how this part of the work can be integrated into the project. He tries to explain possible options and impact of each one.
After the letter is finished, he saves it and lets it rest for half an hour. Then, he reads it again and checks grammar. His emails are always perfect. He clicks the Send button…
1. Scope goes first
To make a realistic estimate, you need to define scope fully first. Work is always lost somewhere between different work packages and deliverables. That is why I suggest preparing Work Breakdown Structure in a first place.
You need to decompose your product into deliverable and work packages. And then, decompose each work package separately. Performing decomposition and estimation at once is tempting. However, it is better to separate these activities.
First, you need to focus on identifying 100% of work. Then, estimating it.
As a project manager, you need to deliver what you were asked. No more, no less. If you feel that something can be a part of a project scope, you need to suggest that openly. If sponsor agrees, then it is a part of the project you need to deliver. Otherwise, it is gold plating. Even if it is for good.
“First, you need to focus on identifying 100% of work. Then, estimating it.”
– Nizhebetskiy Dmitriy
2. Estimates should do the person who will perform the work.
There will be two possible scenarios. Either you have a team, and they will do the estimates. Or you will need to acquire a team. In the latter case, you will need to define required skills and level of specialists first. Then, assuming their capabilities, you will produce the estimate.
In any case, do your homework. Find out the list of possible or desired candidates who can join the project.
Firstly, different people perform at a different rate. They perform differently doing different tasks. There is aways something a person likes to do more.
Assuming an average performance introduces serious errors and risks.
Secondly, when a person is involved in producing an estimate, he or she is more committed to meeting them.
Thirdly, people collaborate differently. In most cases, cooperation is a must. Ignoring personalities leads to unnecessary conflicts.
3. Days, Calendar Days, Effective Days?
For example, a working day is eight hours for a person. It will be a mistake to assume that an individual can work uninterrupted for eight hours in a row on a single task. There will be meetings, communication, coffee breaks, etc.
How many hours a person can actually work on a task? Six. Maximum. Though, even that is too much. I would aim at five or four per day.
So, at some point, you need to make an agreement. You need to clarify in what units do you provide estimates. Also, you need to know how they convert.
A task 24 hours worth. Will it take 3 calendar days to finish (24 / 8 = 3)? Or will it take 4 calendar days (24 / 6 = 4)?
It may look trivial. But there is no worldwide standardised approach here. Every organisation calculates estimates in the most convenient way for it. Do not assume that your clients and stakeholders understand this.
You must communicate the way you will make estimates to each team member and each stakeholder.
4. What goes into the estimate?
It is also known as a Definition of Done. What should a person do to ensure a task is finished. Should he perform testing, update documentation, or log efforts into task tracker before work is deemed complete. What part of work you expect him to do. When and how should he hand off his work to another team member. All of these should be clarified. In some cases, estimates can dramatically vary depending on what goes in.
This point is closely related to the previous one. Additionally, what about a risk of unexpected events? For example, a person who will perform the work falls sick. There is no one to substitute him. Should we compensate his absence with increased estimates? It brings us to the next point.
5. Buffering versus risk management.
When you and your team prepare estimates, some level of uncertainty is always present. You make assumptions. You interpret requirements, and you have constraints. You can hide all these problems into your estimates. Or you can perform proper risk management.
The idea is simple. You need to analyze the estimates and separate the actual work from uncertainty and fears. In can be an optimistic or pessimistic estimate of work to be done. It depends on the project and your preferences.
Then you need to log all uncertainties, fears, and assumptions separately. You need to keep them connected to a specific piece of work.
This way you can control your estimates on two levels. First, how accurate the estimates of work were. Second, how many identified risks happened and what was the impact.
We will be talking about Risk Management in details later. For now, I can suggest you to follow Harry Hall’s blog. He specializes in Risk Management.
6. The accurate estimate takes time.
It is important to understand that estimates take time to prepare. If you what to get numbers right on the spot, be ready they are not accurate.
In practice there are three major type of estimate accuracy:
Rough Order of Magnitude (ROM). This type of estimate is done at the project initiation. Typical range is -25 to +75 percent from actual values.
Budget Estimate. During project planning, we need to achieve this level of accuracy. It is -10 to +25 percent.
Definitive Estimate. When project is underway, a project manager can refine the estimates and should get to about -10 to +10 percents.
As a project manager, you need to understand that estimates are not a wild guess. The person doing the estimation should have to analyze provided information, verify his assumptions, investigate available solutions, etc. It should be a planned, facilitated effort. And it takes time.
7. Efforts do not directly convert to duration
It is a side note but often it causes a lot of problems. The effort is the amount of manpower required to finish the work. For example, a task requires ten man-days. It is ten working days for one person. But be aware that ten persons will not be able to finish this work in one day in most cases. Communication and coordination will reduce efficiency dramatically.
Ten tasks that are estimated for ten man-days each should be done in 100 days. Likewise, ten persons will not be able to finish these tasks in ten calendar days. Such estimates do not take into account possible dependencies between tasks. They might be sequential, it may be inefficient for several persons to work on one task, or not all can perform the task equally well.
Accurate estimates require experience and soft skills. A project manager should be able to work out estimates even without any expert knowledge of industry or technology. Though such knowledge usually helps a lot.
Leave a Reply