The Retrospector

The last few weeks I’ve come across a number of things that required some sort of estimations, so that everyone involved could get a set of expectations in their minds on what would result with each endeaver. (I’ve also noticed quite a few articles about estimation lately.) Tasks range from honey-do projects around the house, to components on an application in the office, to personal estimates on some little things I’d like to just get done.

Estimation is very simple in most cases, but it can get very complex for some things. I’m going to break down some of the issues that effect one’s ability to accurately estimate projects here and hopefully share some insight on how to find your most likely results when forced to think about quantifying your abilities.

Experience

If I had to sum up the art of project estimation in one word, that word would be experience. There’s simply no replacement for what experience can do for you when you have to think about tackling a problem.

If you were given a task of figuring out how to start a campfire, you would have learned the first time around some of the things that don’t work by trial and error. You may have spent an hour trying to get it started the first time, but this time you know you should give plenty of airways to the bottom of the fire to let it breathe while you put the tinder in the flame to get it going. There’s really no way to know that without having experienced it for yourself the first time around.

Case study

Let’s apply this to a scenario at work. Let’s say your boss comes to you and asks how long it’s going to take to get the florescent green with dancing monitors background CSS generator doo-hickey working. Now you know you really need to get this really cool background generator done this week, and if you could get it done today you could impress people. Not only that, but you quickly realize that it’s just some string parsing that you could do blind-folded because it’s just some little class with a few methods for generating color and monitor outlines.

What really happens later in the day? Well, you forgot about the other 3 responsibilities you’ve spread yourself thin with. Now that you’ve said you could just get the CSS generator done in a few hours, you realize there’s just no way you can get it done because you forgot that monitors can only show up on a purple background or none of the text will appear on the page using the API you picked. Life is about to suck because not only do you have to figure out what else you can do to hack this together while staying cross-browser compatible, but you have to do it now to try to save face to the others in your group.

Reflection

Wow, how could this have possibly gone wrong? It’s just a simple little text parser as far as you’re concerned!! Here’s what happened…it was your first time having to implement a CSS generator while working on 3 other components during the 2nd full moon of the year. Will you let it happen again? Maybe. But you sure learned something that you’re going to apply the next time you give an estimated time.

Effects

In the short term it may not have been fun to give an estimate that you couldn’t pull off. In my opinion the long term really isn’t effected too much by it. You, and everyone around you learn to compensate for your experience level. Everyone will also learn to adapt to your estimations getting more and more accurate over time as you get better with your growing experience. We’ve all been there, and we know everyone has to go through the trials and errors of learning our capabilities.

Going forward

Know that you’re not going to be a perfect project estimator right away. When you’re given an opportunity to give an accurate estimate, be generous on the “buffer” you give yourself because of the variance in things you’re not accounting for. Once you get better at managing the risk that could affect your ability to complete on time, you can start to narrow your estimates closer to the realistic “perfect scenario” timeframes with much more reliability.

I can’t say there’s any special formula for estimating projects. I would say for people very new to whatever technology they’re working with, think about the best case scenario in your head and triple it. As you get more and more experience, you can factor in on-the-fly risk factors and how much time they’ll add to give a more accurate assessment of how much more time you’d need beyond the “perfect case scenario” that you always visualize in your mind when making estimates.

What estimation practices do you use to keep accurate on projects? Is there a special formula you use when put on the spot that doesn’t make your manager jump down your throat? I’d be interested to hear what approaches you have to be successful.

Tags: estimation, estimating, planning, project+management, project+planning

   

Related Posts:

• Anticipating a Project Go-Live Date
• 5 Steps To Help Your IT Team Concentrate Part III
• On Team Building: How does building an egg catcher out of a pillowcase and popsicle sticks benefit my company?
• New Site Design
• Building a Reputation: Knowing When to Experiment and When to Deliver

Explore posts in the same categories: Technical, Programming, Design, Planning, Project Management

You can subscribe via RSS 2.0 feed to this post's comments. Feel free to comment below, or link to this permanent URL from your own site.