Hi,

how often did you hear questions like those two:

1. How much time do you need to fulfill this Task?
2. When do you expect Project to finish?

Those two questions are most common when we talk about time in Project. And yes, they are regular, and expected. Where is the problem then? The problem is that someone who ask those question will rely on your answers. And if you are going to be late, that person (we also call them: Management, Customers, Clients) will tell you: “But you told me that you will be finished until….”

Let’s face it! When you are in IT, you know that it is impossible to promise that something will be finished as you told. Why? Because when we are preparing answers on questions mentioned above we are doing estimations! Read again – E S T I M A T I O N S!

What is estimation, anyway? Estimation (or estimating) is the process of finding an estimate, or approximation , which is a value that is usable for some purpose even if input data may be incomplete, uncertain , or unstable. The value is nonetheless usable because it is derived from the best information available.

Based on definition above, you will find that estimation is always unstable, because you are estimating something what should be done, what is unique (no matter how many times you did a similar task before). Yes there are many estimation processes. PERT is one of them. In PERT you will estimate Optimistic, Pessimistic ans Most Likely time, and standard deviation. For example your Task has:

1. Optimistic time = 1 day
2. Pessimistic time = 9 days
3. Most Likely time = 2 days

PERT is (Optimistic Time + Pessimistic Time + 4 * Most likely Time)/6 = (1+9+4*2)/6 = 18/6 = 3 days! And Standard deviation is (Pessimistic time – Optimistic time)/6 = (9-1)/6 = 8/6 = 4/3 = 1,333 days. So, your final estimation is 3+/-1,333 days which mean that in best case your Task will have 1,67 and in worst case  it will have 4,333 days of duration.

BUT! How did you get your Optimistic, Pessimistic or Most Likely time? You think, and think, and talk to you colleagues (if you have them, and if they have enough knowledge), and then – make an unreliable estimation. Something the real time spent on your Task will be very close to your estimated time, sometimes it will e far away, and sometimes (HURAAAA) it will be exact the same as estimated time.

Now, who should make the estimation? Of course – the person who will do the work on the Task (NOT YOUR MANAGER OR SALESMAN WHICH IS OFTEN A CASE). If there are many of them (persons who will work on the Task – not Manager nor Salesman :-)), then they should do the estimation together. But, what if estimation is made by senior or junior developer? They can overestimate or underestimate, and they often do (you know the story: “I am experienced and I can do it in a day, or I am young and I need 35 days). And what about risks? We are talking about technology here. So, we are talking about Murphy’s law: “Anything that can go wrong will go wrong.” How many times did you got something as: “Unexpected error c759$%lklk0400333%&&&”? Of course, clever guys will tell you that this should be in a Risk Register. And it should. But, you should also estimate contingency time for solving those errors. And then you are in the same problem: Estimation! What will you answer a person who will ask you: “If some unexpected error occurs on Task 345, how much time will you need to overcome this error”. Read this very carefully: For unexpected things you cannot estimate solving time? Why. Because they are UNEXPECTED, UNKNOWN, NOT PLANNED!

I could write about that a Bible. But I will stop right now. And I will tell you. When you are doing Task estimation, and then the whole Project estimation the only concern which you have is: HOW FAR AWAY FROM REAL TIME WHICH WILL BE NEEDED AM I?

And YES! Always expect delays!