CertPal

I have seen a few estimation nightmares in my time and have been unfortunate enough to be in some of them. Let me narrate a few anecdotes first

Anecdote 1:

I used to work with a re-insurer. This company had a legacy application that was written in fortran. Yes fortran. It did some very important things. It was capable of making estimations for a given market and it crunched a lot of numbers into meaningful data. Because this application was written in fortran, finding the right engineers to maintaining it was difficult. So they decided to shift the application to a better supported platform / language.

The work came to IT and a manager said ‘Lets convert it to VB’. This person, did not know fortran and was not a master of VB either. No developers or architects were asked for advice. It was simply decided that the application should be converted to VB from fortran.

But wait, the fun is just about to begin. After making the decision to convert it to VB, a developer was asked to judge how long it would take to make this migration. This developer worked in Oracle technology and knew nothing about fortran and very little VB. This developer was chosen to do this estimate because the others were busy. A ‘ball park’ estimate of 4 months was given to the manager. The estimate was not based on any fact / data. It was arbitrary at best. The manager then went to the user and said ‘We will convert your application from fortran to VB in 4 months’.

The user could not believe what he was hearing. So much so that the business department said ‘If you cannot convert the application in 4 months IT will pay X dollars per day for each day that the project is defaulted’. The IT managers agreed and all hell broke loose. Two developers were assigned to the project and they worked like crazy over weekends and put in 16-20 hour days to finish the project. The project was delivered 3 months late and IT lost money implementing the project.

Anecdote 2:

An application cluster which housed 3 nodes had a problem. The cluster would simply shutdown without warning every now and then and had some applications that were used by external users. Here external users = internet users that are customers to the application. Since the problem involved external users it was of higher priority since a crash is an embarrassment.

I was assigned the task of finding out what the problem was. A manager called me up and said ‘Give us an estimate on how much time you need to fix this’. I had no clue, so I did some preliminary investigation and tried to find various root causes. I narrowed down some possibilities and was about to give her a number. She said ‘Your estimate has to be within X working days since I told the users we will give them an analysis by Thursday’. I was like ‘What !?‘. I still had to do tons of research and it would have taken me a few weeks to go through all the problems in all the applications in the cluster and try to figure out what was going on.

There were no logs indicating a problem and very little signs of what was going wrong. In the end I was forced to deliver a half boiled “analysis”. The problem was then forgotten. It came back to bite us several times until we finally solved it a year and a half later.

There are several other cases where an estimation nightmare caused losses in time and money. I have learned some lessons the hard way over the years.

• When your manager will not listen to your reason about why an estimate is high, run the other way quickly.

• Assert yourself. Projects will take time to get done. You do not have to lower estimates just because some one thinks it is high.

• Include contingency effort in estimates. This is usually 15-20% of the total effort.

• If you hit a road block, communicate it immediately. If you wait for the end date and then tell everyone that you cant deliver on time, they are less likely to listen to you.

• Do not be shy to say ‘It cannot be done within X days.’ There is nothing wrong with saying this. No one will think you are a bad developer if you take 5 extra days to get something done. If you overshoot by 5 days however, people will think ‘you missed the deadline’ by 5 days. This is a big difference.

• Always over estimate. If you think you can get something done in 5 days, you are probably thinking about the ideal scenario. Users will come up with feedback sometimes and will still expect you to deliver in 5 days.

I am not trying to blame managers or developers for under estimations. There are managers that know nothing about the technology in question and make estimates in place of developers. Then there are developers that make estimations based on an ideal scenario. Both are taking risks. Think carefully before committing estimates. Getting them wrong can cost you dearly.