Beware of bad estimates
How many times has this happened to you: you're assigned a new project, or you sit with a new client and everything goes well until you get to the time estimate. More often than not, at least it's been my experience, that those for whom you work just don't understand how long it actually takes to do the work. It's normal, they're not web developers. But we are, and recently it seems to me that bad estimates are prevalent in our industry. From freelancers who don't respect the worth of their own time, to companies who sign contracts without consulting those who'll be doing the building first.
I'll give you an example. A junior member on my team this past week was given two tasks, both which were badly estimated. The first was for a couple of promo pages for a fairly large client. The deadline was looming, the project was near completion and with only a few days left they dumped these pages on him with an estimate of four hours to complete them. The second task was the integration of a blog template in Typepad, estimate: five hours.
Now that may seem reasonable at face value until you consider what's involved. First off, the guy's never worked with Typepad. Second, he's got to apply a design that someone else created (in the form of a Photoshop .PSD) to markup that he didn't write. Third, it's got to work on all modern browsers without any browser sniffing. And lastly, he's still learning so he can get snagged in bugs from time to time.
Why stress over impossible deadlines. Whenever possible, overestimate! Then that way, you can be the hero if you deliver early.
I'll give you an example. A junior member on my team this past week was given two tasks, both which were badly estimated. The first was for a couple of promo pages for a fairly large client. The deadline was looming, the project was near completion and with only a few days left they dumped these pages on him with an estimate of four hours to complete them. The second task was the integration of a blog template in Typepad, estimate: five hours.
Now that may seem reasonable at face value until you consider what's involved. First off, the guy's never worked with Typepad. Second, he's got to apply a design that someone else created (in the form of a Photoshop .PSD) to markup that he didn't write. Third, it's got to work on all modern browsers without any browser sniffing. And lastly, he's still learning so he can get snagged in bugs from time to time.
My rule of thumb is a minimum of 1 day per page. Taking into account the fact that 1 day translates into 7.5 hours (where I'm currently employed), it tends to go by pretty quickly. Especially if you run into bugs, have questions about the design and experience delays because even 1 page usually involves 3 to 4 people. Yes, that's right, you've got the producer who interfaces with the client, graphic artist who came up with the concept, the web developer who makes it a web page and possibly the programmer who's got to tie it into the back end. All of these aspects can affect your work. Sometimes, in mid course you need to check with the graphic designer about something, or you need to ask the producer something about the behaviour or a certain element and so on, and so forth. Of course if you're a one man show you won't have all those thumbs in the soup. But in your case it's even more important to remember that all that work still needs to get done, and now it's all up to you. One person who can't just focus on one task. You're responsible for it all. Thus, you need to add even more time to your estimate.My rule of thumb on estimation is: a minimum of one day per page and maybe more depending on complexity.
Why stress over impossible deadlines. Whenever possible, overestimate! Then that way, you can be the hero if you deliver early.
<< Home