Home > Best Practices, Opinion > Why do our time estimates suck?

Why do our time estimates suck?

April 19th, 2009

Everyone dealt with it in some form of another. Either you have given your estimations and you missed it by a long shot or someone handed you some estimations and they grossly underestimated the amount of work. And when that mark is missed, its the wag of the finger and the rain cloud of shame upon you. Management has deemed you a failure. Way to go.

But why does it happen as often? Are they the same constant hurdles over and over? Is it management? Lack of tools? Bad team? Or dare I say, was it you? (Of course not, its never OUR fault). Who are making the estimations? Is it you? Your team leader? Marketing? Upper management? For me, I can see mostly from the developers point of view because, hey, I am not a manager. Here are some of the issues I have ran into over the various projects and possible ways to avoid them in the future.



Who made the estimations?

My first “project” I was given as an intern, I was told to take this big ole web application, strip out all the hard coded styles and replace it with a style sheet. Mind you at that time, I knew little about style sheets, less about web apps or anything about the application specifically, and for some dumb reason, I rarely asked questions when I had them. When asked how long it would take, I smiled and said “2 weeks!”, a random number completely pulled out of an orifice in my lower torso. Of course 2.5 months later, it was finally done. Lesson learned for me and that then instilled the fear of god in me when it came to making estimates for some time.

Why was I making the estimates though? I was the new guy. If it is a service patch, new version, upgrade, etc,the new guy should not make estimations. Especially if it is a large scale application. Intern or 10 years experience, it doesn’t matter. Why? Because the new guy knows nothing about the application. He doesn’t know about those nasty little hacks that were put in there, hidden away from anyone that wouldn’t know where to look for it. He doesn’t know anything about the data base schema or that all these changes need to work with legacy hardware. It takes more than a good developer to make an estimation on a specific application. He needs the knowledge of the full environment.

Out side of the new guy, there are two groups that also should not be making estimations. The first is upper management. Depending how many degrees of separation “upper management” has from the project will determine how much of a right they have to make these estimations.

Now I am not saying that they shouldn’t make estimations because they don’t know what they are talking about, but just because they are management does not mean they are the best person to make them. Whenever I ran into these situations, I feel the numbers came from a) how long it took that other guy that had to something similar on another unrelated project or b) “I’m under the gun so I told my boss that you could do it in less time to make him happy.”

Whatever the reason really is, it falls into the same category as the “The new guy”. The lack of in depth knowledge of how everything works puts these estimations further away from a realistic deadline.

The last group that should not be making anything close to an estimation is the worst in my opinion, which is marketing. They don’t necessary make estimates, but rather just sell a date to the client. This is about the worst thing anyone could possibly do. Not only have they made a poor estimation of time, but they have just sold it to the client, so kiss those hopes of reestimation out the window. This happened to me a few times in the past, but only once did it really blow up and cost the company a fairly large client.

Alright, well now we know those people aren’t doing estimations.
Now we have the right people making estimates, what could possibly make them off target now? Were you given the proper tools for the job? There have been enough times where that hasn’t happened. Sometimes it has been something such as lack of documentation. It’s my opinion, if its a an internal framework that lacks documentation, you SHOULD still have tools at your disposal. They are called coworkers. If you don’t have those, then yeah, you dont have what you need.

What about something such as a database schema? Not much you can do with out that. What about missing data all together? Sure there are plenty of projects where you can just mock up the data, but spending time doing that was probably not part of your original estimation. What about outdated tools? Some companies are very nervous about upgrading software or flat out will not allow it. How about outdated hardware? I am willing to bet when estimations were made, 5 minute compile time at every change you made a change (ie:large flex applications grrr), was not factored in. I’ve even had hardware stolen from my machine at work (although I like to think it was more of a “Man stole bread to feed his family” situation). All of these situations more than likely were not factored into the estimations.

Now we’ve got the tools, the right people, now what?
At this point, we seem to have everything. What else could possibly be holding us up? Let’s look at the team. There are some things that are totally out of everyones control and they really need to be labeled as “Shit happens”. People get sick. Family members pass away. There is nothing anyone can do about that. If anything, in your estimation, as hard as it may be, try to factor SOMETHING happening where you lose a team member for a small percentage of the time.

What you can do to provide better estimates
Management has come to you and asked you to come up with estimates on a new project. Here are some ways you can hopefully provide better estimates.

Make sure you have EVERYTHING you need. This includes:

  • Man power. Not just man power but a team capable of completing the task at hand.
  • Tools to the job on both the hardware and software side.
  • REQUIREMENTS. I cannot stress this enough. If a project starts without clear and conscious requirements, you might as well consider it behind, because they will change as the project goes on. Sometimes it will be simply rewording something. Usually it is a large piece of functionality that the client has changed their minds on or you did not have a clear understanding of what they were asking. Regardless, the timeline usually does not change when the requirements change.
  • All the information you need. Beyond just the requirements, this also includes data. On smaller projects, this may not be a problem. Also not a problem if you are in charge of everything, including the data on the database. If you arent, stress that you can only do so much work with mock data until you get a real setup.

If you dont have these things, it will be difficult to meet any timeline laid out by you or anyone else. If you are missing these, you have one of three options.

One option is to pad your hours, which management is not a big fan of to say the least. However, if you are padding and you want to be realistic about it, stress that without everything you need, its going to be difficult to do it in a normal timeframe.

Another choice is you are going to constantly bring it up to management as the project continues in order to cover your own ass. If you are truly behind due to the lack of something you need, bring it up. Do not be condescending about it though. Let them know you are doing the best you can with the resources you have. If it is something that the client has not provided, take the initiative without management in order to find out what an ETA is and pass that information along. If it is requirements that are changing, this is something else that you need to bring up as soon as possible. It is out of your control and getting something done with changing requirements is shooting a moving target. In a happy world, everything would be fine. Realistically, it affects the schedule.

The third option is the worst option for you, which is to not do anything and suck it up. I have seen this (and done this) too many times. NEVER do this. I know I did this a lot when starting out. Yes’ing management on everything is a bad thing. I agreed to everything they said and a lot of projects I have been on went behind schedule. If you honestly believe it is not possible to get it done in a certain timeframe, bring it up and let them know why. It goes back to covering your own ass. Try your best to meet those deadlines, but at the end of the day, you brought it up that its going to be difficult to do. Its much better for management to know this at the beginning versus management finding out on the day it is due.

How to keep your team on track
I am no genius at this part, but the best way I have been kept on track or kept teams on track is through the use of a burn down chart. I havent used too many different ones, but I still prefer a simple excel sheet to track the progression of a project.

The best way we have dealt with it is before the project starts, break all the tasks down at a very high level. The break those tasks down further and more precise. Keep breaking it down into tasks of 1 hour at least and 8 hours at most. If a task is more than 8 hours, break that task down until 2 or more tasks. This will allow you to keep your time focused on a specific task.

It is important to take the chart seriously. The team will not see the importance of it if you do not take it seriously. It only takes a few minutes each day. The best way to do it is just have a daily scrum meeting with your team. All each team member needs to say is

  • What they did that day
  • What they are going to do tomorrow
  • Mention anything that is holding up their progress.

At the end of your meeting, remind everyone to submit whatever the remaining hours are for their tasks. This will give you a constant update of what work still remains and can quickly point out roadblocks in the project. Once you get everything, just send out an updated chart. Make sure the team is used to constant updates during the project. I have been on a few projects where we started out using one of these in one form or another, and within one month, everyone forgot about it and it was utterly useless. At that point, your status meetings are ‘yeah.. I think I am close to finishing it’.

Last thing I will mention is the issue of the Bad Apple on the team. Hopefully, the use of the burn down chart will help point these people out before its too far into the project. If someone is not pulling their weight on the team, bring this up to them. Either bring this person to the side and mention it in a very professional manner. If you aren’t professional, it will seem like you are attacking them or singling them out. Just mention that his tasks are falling behind schedule and offer to help out if you can. The other choice is to bring it up to management and let them talk about the bad apple. Either way, someone is going to talk to them. Do not sit on it. If you do, it boils down to YOUR team didn’t finish the project on time.

Providing accurate estimates is no easy tasks. Sometimes things are out of your control. Sometimes they are in your control. It is important though to make sure everything stays on track regardless of what happens. I could probably keep going on and on with this subject, but I feel I have hit enough bullet points. The most important thing I want to stress though is learning from past mistakes as time goes on. Have a postmortem at the end of each project. Try not to draw assumptions. Discuss with the rest of the team why they felt the project was behind schedule and just remember it for future projects.

Feel I missed something? Wrong on something? Feel free to comment!

Best Practices, Opinion ,

  1. April 19th, 2009 at 23:06 | #1

    Short answer: Because we over-estimate that which we think we know, and we under-estimate that which we think we don’t know.

  2. April 20th, 2009 at 00:26 | #2

    Good article and yes, software estimation, IMHO, is our industries “worst” best practice.

    A book worth reading: http://www.amazon.com/Software-Estimation-Demystifying-Practices-Microsoft/dp/0735605351

    And a tool worth looking at, particularly the model that is behind it: http://softwareindustrialization.com/COCOMOIIOnlineEstimationTool.aspx

    Best of luck!

  3. Tim Daly
    April 20th, 2009 at 00:42 | #3

    I have been programming for 38 years.
    I have never met anyone who could schedule software.

    I have participated in a 5-person, 5-month fixed cost
    contract that became a 10-person, 18-month failure.
    A lot of review went into that schedule. A lot of
    tracking was done on that schedule. The company failed.

    Don’t like Gantt? Try PERT charts, worked for NASA:
    Ferens, D.V. “Computer software schedule estimation: an appraisal”

    Think the problem is that companies don’t train schedulers?
    http://www.ieeeboston.org/edu/2009spring/course_estimating.htm

    I have a long list of war stories, all of a similar
    nature…make a gantt chart, break the project into
    8 hour chunks, track the project by day. Been there,
    survived that. Nothing works. Nothing.

    Find a thick piece of steel. Chisel this phrase:
    NOBODY KNOWS HOW TO SCHEDULE SOFTWARE.
    Mail it to management.

  4. April 20th, 2009 at 00:42 | #4

    I feel that estimations get exponentially less accurate, with the length of the actual estimate. That is, a month long project likely means that I’m ballparking it and likely don’t know just how many things could go wrong.

    On the other hand, I’ve gotten fairly good at giving accurate estimates on half-a-day to three-days scale. If someone expects an accurate estimate on a month long project, it would have to be broken down into 30+ steps implementation plan.

  5. noah
    April 20th, 2009 at 06:12 | #5

    Ever heard of the halting problem? Estimating software write time is exactly the same as determining whether a given program will terminate computation which is also the the problem of looking at code and determining what it does. It is unsolvable in the general case. You can either restrict yourself to some sub set of general computation (not necessarily useful). Try to actually understand your problem domain to discover the trivial solution (my favorite although you may not be smart enough to pull it off and it could turn out that there is no trivial solution and you’re screwed). Or you can work hard everyday invest in great QA folks and finish when you finish (this may not meet business needs).

    Of course you can always get lucky and with as many people in IT million to one shots happen every day. So good luck.

  6. Jacques Chester
    April 20th, 2009 at 06:24 | #6

    Good estimation is possible in scenarios where you have good historical data and a fair amount of practice in estimation.

    I don’t have the figures to hand but the SEI have a whole bunch of statistical research about what is and is not possible. A “mature” organisation — you know, one of those rare, sane businesses we all want to work for — can get estimate variation down to somewhere in the vicinity of +/- 20%. The SEI claim that teams following their TSP can get that as low as +/- 5%, but that’s for a really good team.

    As usual, it’s not that we don’t have ways of developing much better estimates, producing better code, preventing defects and all the other software engineering wishlist; it’s mostly that nobody applies anything that the academics have cooked up. I have a theory that tools, and not methods, drive industry improvement. If it’s not in a dead-simple tool, it doesn’t exist in industry practice, end of story.

  7. Jacques Chester
    April 20th, 2009 at 06:29 | #7

    Oh, and I heartily second the recommendation for the estimation book by McConnell. As usual he’s boiled a huge field down into a highly readable handbook.

  8. Tom
    April 20th, 2009 at 12:20 | #8

    2nd heading should be “well” not “we’ll” I think. Delete this comment after you fix if you like(or don’t put up if you screen them).

  9. April 20th, 2009 at 12:26 | #9

    @Tom
    Thanks for the heads up :)

  10. kl
    April 20th, 2009 at 12:55 | #10

    estimation is absolutely not like halting problem! you are not estimating how long algorithm will execute, but how much effort is required to write it. And you don’t have to be exact, which gets you out of paradoxes like estimating how long estimate will take.

  11. April 20th, 2009 at 13:49 | #11

    Comment here.

  1. April 21st, 2009 at 02:07 | #1