Imagine this situation. It is a Friday morning. You are a delivery manager. You feel bit relaxed. The week-end mood is on. And then you see a mail from sales person. He is highly excited. He thinks a strategic new customer is keen on moving forward. The customer explained him the problem and wants a budgetary effort estimate and possible delivery date. There you see a potential problem. You plan to postpone the estimation to Monday. But the sales guy is quick. He calls you. What can be the estimate?
You try to avoid in vain. The sales guy pushes hard. “Give me budgetary figures. I will not hold your neck” he argues. You give him effort figure and possible delivery date. You are not so happy. But you managed the situation. Now how do you feel?
Isn’t it a regular situation?
Too many times we rely on our memory. We give some figures, but with very low confidence. If we quote optimistically we will win the project. But we will face music while executing. If we quote pessimistically then don’t worry. Anyway we are not going to get the project.
There are several reasons why we do not do estimations. Time to estimate is very small. Customer is not clear about the requirements. Quantum of work is not known. Tools and history database are absent. The list can be long.
But what should estimate include? Well estimate should give us size of work, efforts, duration, probable defect numbers, resource ramp-up/down and documentation efforts. Additionally can we give maintenance efforts? And this may be simpler for bespoke development projects. How about package implementations, data conversions, migration, reengineering projects? Life is spicy then.
There is one thing very paradoxical about estimation. We have minimum inputs available when the estimate matters most. When? You guessed it right. At the proposal time, off course. Then what do we do? Either we rely on our memory or open that smart looking spreadsheet estimator. The color full estimation spreadsheet gives us a lot of confidence. We think we have mastered the science. Have we really?
First point is any estimation tool (however smart / intelligent) does not do sizing. And size does matter. The major impact on all estimations is due to size. We will discuss this in some other blog. We are desperate in estimating quantum of work. It is hard anytime. And it is most difficult at proposal stage. So we do the standard work break down. Gather three experts. Get their estimation. And brainstorm when there is major disagreement about particular item’s estimate.
Isn’t it a scientific method?
We call this Delphi technique. We have often used it. But then what is wrong? The Delphi WBS does not consider sizing in terms of standardized units like function points (FP). Hence ability to use industry history database vanishes.
Secondly the method many times, do not consider many impacting factors. Competence of possible team members, requirement stability, reuse, etc. etc. are all forgotten. We also do not process risks. In turn we play the game of buffers. And arrive at an estimate, but it is really a guesstimate.
I hope you agree with me. We have to do something to manage these situations. But to begin with let us accept the problem. Then only we will start estimating to win more customers and contracts.
To learn more about art and science of estimation, follow our mails and join the webinar series.
Hurry up! Join the rewarding journey, by Registering with us.