Nenad Trajkovski

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!

Hi,

I’ve got a comment from my friend and fellow MVP Peter Kestenholz:

“Hi Nenad, great article. I believe that not all in sales are like this. Especially the last years things have changed a lot. On the other hand, selling a timebox/agile delivery would solve most of the issues you address. However, this requires procurement to stay out of the negotiations as they are always pushing for a locked scope.”

Well, yes Peter you are right. And wrong at the same time. First of all, I think that Agile approach in Software development is great. Just great. And if you compare Agile approach against Waterfall approach it is even greater. BUT! For agile approach several serious prerequisites must be fulfilled.

First and most important is TRUST! and in this Post I will cover only this prerequisite, because without this one, everything else doesn’t matter, and with it everything else is much much easier.

When you have external project (e.g. Project with external customer for which will pay for the Project), than Budget, Scope and Time are important. In the region where I live it is very hard (I didn’t use the impossible word), to get approval for this approach. Why is it so? Because customers want to know upfront three things:

1. Wat are we going to get (e.g. each and every Deliverable)
2. Where are we going to get them (e.g. Project finish date)
3. How much is that going to cost us (e.g. precise Budget)

And to fulfill those three thins you must have strict PROJECT PLAN, and Agile is exact the opposite thing. Agile is all about role wave planning. It means that, because in IT Projects, especially Software development one, the scope is impossible  to define upfront, and then it is also impossible to define End Date and Budget. Scope is define for few Sprints (iterations), and based of results of each previous Sprint, next Sprint with desired functionalities is created. And therefore it is impossible to predict Project End date, and Budget.

On the other hand if you have restricted budget and time, in Agile approach Customer will get what is possible to get in limited timebox and Budget. but he is able to decide what are the best functionalities (or TOP funcionalities) which will suit for him in those limitation.

But, when you have customers like I do which want to know EVERYTHING upfront, than the only thing you can do is to have so called Hybrid approach. And this approach is:

1. The whole Scope is predefined
2. The Scope should be split in Iterations (Sprint)
3. After each Sprint – Sprint Review should be don to show to the Customer what is done
4. If customer wants to change the Scope – follow strictly defined Change request procedure,and change the Scope. In that case estimate cost of those changes and Time, and do the negotiations to your customer and change the Project plan

In most western Europe countries, and USA, Canada etc. Agile approach is accepted and adopted, and this “chemistry” is unnecessary. But, here in my region there is a long way to accomplish that.

All the Best,

Nenad