Time estimates: failure or success

August 4, 2009 at 1:36 pm

Ask any  developer, and they will tell you that they work longer hours than the time they estimated for that work. As such, we have a pretty universal set of procedures to estimate a task, usually 1/2 – 1 hour, and we estimate our job accordingly. We see that one is working far more than their time estimates and hence the project cost increase . Obviously that’s not optimal at all, and I’m thinking why there is a lag on one person’s time.

Why is there such a disconnect? Are we all terrible in estimating? Are we spending too much time checking up our google pals. That may be the case for some few colleagues most of the time, or some of us on our younger days, but it’s definitely not the case at mastiff on a typical day. Yet somehow I can sit at the computer from 10:30 am to 10:30 pm doing nothing but work, and walk away with just two task done of estimated 2 hrs.

There’s a lot of reasons why, but it becomes most clear when we examine what is entailed in a single simple project consisting of one task. Take the example of a pretty quick change where a redirect needs to be added to a site so that ‘/proxy’ points to a new url. It should be quick, after all it’s just opening a remote file, adding a line, and saving it. Should almost be completed in 10 mins, right?

Yet when all the time tracking is done, I find that I spend somewhere between 1/4 – 1 hour on such a request because of all the administrative overhead that MUST come with any project. You see the task being done is only one part of what it takes to move a project through an organization, even a small one like mine. So while we have read the simple version of what it takes to make the change, let’s examine how it actually plays out in the real world where I try to convert my time into money:

  • A change comes into my email inbox and I stop the work I’m on to immediately address the request. I know from experience that failing to immediately respond all my clients correspondence creates a bad atmosphere. This will delay the task that I’m already on somewhat, but I’ll usually discount that from the current estimates of my current task.
  • I estimate how much I think it will take time to finish and get back to what I was doing.
  • Another email comes in asking for an official estimate because the company has specific procedures.
  • I go and create an estimate. I let it sit for five minutes while I do other work, and come back to double check it, since experience has taught me not to send any numbers out  just after typing them.
  • I get another email that the estimate is approved and the work begins.
  • I Make the change, which involves looking up ssh and ftp settings for the site, using them to login, discovering the .htaccess file’s true location, editing it. I may need to look up the correct commands for VI editor, or make sure that this doesn’t mess up any hosting stuff.
  • I test the change, which means opening the browser to http://www.gigoptix.com/proxy and then clicking around the site to make sure nothing there is messed up.
  • I email that the change is complete and wait for confirmation that it’s correct.
  • I get either confirmation that the job’s done, or more often I get some “oh yeah”s.
  • Usually some small change or additional work is thrown in at this stage. I call it the “oh yeah” stuff, as in: “Oh yeah, can you also do that for these other long urls…” I typically do these without any estimates and don’t usually add much to the project scope.
  • I draft the time sheet and send it out.In the end, a 15 minute change actually invokes about an hour’s worth of residual work and time. So after reading all that, here’s some specific advice for you.

So how do we stay in business like this? I’m sure there’s lots of strategies to explore, and I welcome comment on them, but some that I have found wide-spread and useful are as follows:

  • Increment task: Divide the task into maximum subtask. This makes sure that you don’t spend the whole day running around chasing small work and increment yor task list as per the new task thrown.
  • COMMUNICATE. Let your managers know where they stand at all times. You can NOT be afraid of talking about your tasks nor can you expect your manager to be keeping track of what you are up to. It’s routine for managers to schedule meetings and not realize that this is consulting, or for a series of out of scope changes to rack up a big task in the heat of the project’s final week. If you feel that the task is increased, talk to your managers and log them. Failure to do so could land you in hot water with disputed, and inevitably low productivity on your end.

Entry filed under: Uncategorized. Tags: .

Ruby On rails Installation for developers Server Installation For Ruby From Scratch on UBUNTU


Calendar

August 2009
M T W T F S S
« Oct   Sep »
 12
3456789
10111213141516
17181920212223
24252627282930
31  

Most Recent Posts


%d bloggers like this: