Using the PERT estimation technique will keep you in the middle of the road paved with best case and worst case scenarios
Being an integration developer, or any kind of developer for that matter, is not all about writing the code – it is just as much about solving problems. One major problem in almost every integration project I have been a part of is that the customer – who pays you to solve their problems – wants to know, or at least get an idea of, the project costs before it starts.
Enter time estimation.
We all know that time estimation can be troublesome from time to time. To say the least. No other topic will generate the same amount of sighing and moaning from your team members. There are two backsides to this coin, with no obvious flip side.
- It is really hard to make a reliable estimate.
- You will most probably be held accountable if the estimate does not hold.
We all know this and still, we fail over and over again. In the following paragraphs, I will try to share my experiences on the topic, and how we can improve estimation by actually using some available tools, instead of just waving a wet finger in the air.
When it comes to the actual estimation I have two major points.
- Avoid being too exact. Always aim to estimate a time span, and round off to even hours or full days.
- Take time to really think through the estimate. The first thing that comes to mind will almost certainly be too optimistic. And so will the second. I think the reason for this is that we tend to estimate based on gut feeling and overconfidence in our own competency, instead of basing them on historic data and experience.
There are a lot of estimation techniques out there. I started out with the simple version of the “Three Point Estimation” technique, but further down the road I picked up the one I still hold on to, “PERT Estimation”.
PERT stands for Project Evaluation and Review Technique. A link to an excellent tutorial can be found at the end of this post. This estimation method is quite similar to Three Point, but I have found it to be, at least for me, more accurate and easier to work with.
PERT requires you to do three estimates: Optimistic (O), Pessimistic (P) and Most Likely (M), and that you will use those as a basis for an advanced calculation where (M) will have a weight of 4 times more than the others.
The optimistic estimate is where you put that first thing that comes to mind.
The most likely is where you put the number you have come up with after considering history and experience to find possible extra work that you didn’t think of at first.
The pessimistic estimate is where you put the numbers of when everything goes … well, sideways.
It is important to remember, though, that both the optimistic and the pessimistic estimate need to be realistic. You should not consider world war three in the pessimistic estimate and you should not consider supernatural help or pure luck in the optimistic estimate.
PERT estimation also takes standard deviation (SD) into consideration. In brief SD is a statistical measurement for variations in a set of values. In PERT, SD is calculated with the formula (P – O)/6. For larger projects with multiple tasks to consider, the calculation is slightly more complex. It is fully covered in the tutorial linked to at the end. PERT states that the confidence of the estimated value +/-2 * SD is approximately 95%, which is the span to use as the estimate.
A simple example
You are going to the “do-it-yourself”-station to wash your car, and you announce “I’ll be back in an hour, dear” as you go. This statement is based purely on assumptions and the desire to be efficient. Not on historic data and experience. In this example, I will show with 95% confidence that you will be gone at least an hour. Let’s put this example into the PERT estimation template.
- Go to the station, pick up the key and enter the washing room: 10 min.
- Wash the car: 30 minutes. (Yes, truly optimistic)
- Pay, leave the key and go home: 10 minutes.
- That’s 50 minutes, which is well within the hour. (Leaving room for an ice-cream bonus for work well done).
- Total estimate: 60 minutes
- Go to the station: 10 min.
- Pick up the key and enter the washing room: 15 minutes. (There might be a waiting line in the shop and for the washing halls.)
- Wash the car: 40 minutes. (Less optimistic)
- Pay, leave the key and go home: 15 minutes. Taking a possible waiting line in the shop in consideration.
- Total estimate: 80 minutes
- Go to the station: 15 minutes. Traffic situations in consideration. (Still realistic. Not considering a flat tyre, accidents or other non-probable events)
- Pick up the key and enter the washing room: 30 min. (Long waiting line to enter the washing room. If more than 30 minutes, I would probably go home.)
- Wash the car: 60 minutes. (Those bugs on the front…)
- Pay, leave the key and go home: 15 minutes.
- Total estimate: 120 minutes
Given the above we can use the formula (O + M*4 + P)/6 and come up with (60 + 80*4 + 120)/6 = 500/6 = 83,3. We will round this down to 80 minutes. As you see, after rounding, we are at the most likely estimate, so why not just go with that, since it seems accurate enough?
The simple answer is: because you wouldn’t. Without seriously considering all those paths, you would probably come up with something much closer to the optimistic. And also because when we do larger, more complex, estimations with lots of tasks and sub tasks, we will only round off on the aggregated level – The complete project estimate.
Finally, we want to consider the standard deviation. To do this we put them into the formula SD = (P – O)/6 = (120 – 60)/6 = 10. For the above example, you could, then, with a 95% confidence shout “I’ll be back in 80 minutes +/- 20 minutes, dear!”, or perhaps rather “I will be gone at least an hour, probably more than one and a half”.
The other backside of the coin, which also gives us a really good reason to make as accurate estimations as possible, is that we will almost certainly be held accountable to some extent when actual logged hours exceed the estimate. Given that estimates often are used as a basis for budget work, the requesters of the estimates often tend to consider them as agreements of the maximum time to be spent on the estimated projects or tasks, rather than actual estimates.
This is why I recommend giving estimates as spans of 95% confidence. If the receiver of the estimate does not accept a time span, I will give the upper boundary of the 90% confidence estimate (SD*1,645).
It is also utterly important to have an understanding from the requester that the estimate is not an agreement about a fixed number of hours.
So to conclude, estimation is a tough task, and there are lots of templates, methods and techniques out there. This was only one of them, which I have got used to working with. And it has helped me a lot in increasing the hit rate of my estimates.
The important thing is not the technique or the tool. The important thing to remember from this is that you need to put some real effort and thought into the estimation to make it good and trustworthy. And to get time to enjoy that ice-cream.