Over the weekend, I was discussing a couple of projects with a highly esteemed colleague of mine ;0). She was putting together an estimate for a company on a complete site redesign and functionality upgrade and was having problems putting together a solid estimate. In the meantime, I was in the thick of putting together a RFP response myself, so I thought I’d share my approach for creating solid estimates:
For your web development project, make sure your project manager helps you break everything down to the smallest steps/pieces possible.
Break the tasks into individual pieces that you and others can quickly wrap your heads around. Is each task “easy” or ”hard” or “compressible.”
AN ANALOGY
For example, how long does it take to get to work? For my colleague to get to her biggest customer’s site, it’s “about 45 minutes”.
First, she drives to the Metro station - 8 to 15 minutes depending on traffic.
Then, she walks from the parking lot to the platform - 2 to 3 minutes.
Then, she waits for the train - 0 to 10 minutes.
Then, she rides the train into downtown - 20 to 25 minutes.
Finally, she walks the two blocks to the office - 3 to 5 minutes.
The estimate of ”about 45 minutes” is actually more like “33 to 58 minutes”. What are the variables? Which variables are easy, hard, or compressible?
The train ride is a fixed duration. That’s easy. Also, the final walk from the station to the office is fixed due to the traffic lights. These two tasks cannot be compressed. Translation: Therefore, they’re unaffected by a crunch or deadline.
Waiting for the train is also non-compressible because the trains come at regular intervals. Other than catching an earlier train, there’s nothing she can do reduce this duration. Translation: In a web development project, this would map to some of the early design plans. By brainstorming early during the first round of requirements, good ideas will rise to the top while eliminating bad ideas at the same time.
Therefore, the only variables to be adjusted are the first two items.
First, she could run from the parking lot to the train platform. This doesn’t buy her much unless she can make an earlier train and reduce the waiting from from 10 to 0-1 minutes. If she doesn’t make the train, she has simply exchanged a walking minute for a waiting minute, the gain is zilch, and the frustration is high. Translation: In a web development project, it is best to limit *emergencies* and only request them when they are absolutetly necessary.
Finally, are there any variables about the drive to the Metro? This drive is 13-25% of the total travel time, but the routes are limited. She can’t drive through people’s front yards, but she can use her previous experiences to find faster routes. Translation: In project development terms, this would be an opportunity to save time (when needed) on custom development and use a web tool (web software) library in order to demonstrate a prototype. Regardless, this is the perfect time to get creative and adjust as the situation evolves.
The moral of this quick analysis: When you create your personal project plans, what kind of detail do you analyze? Do you say “paint the bedroom” or do you say “compare and contrast paint colors, coordinate the paint day, analyse what tools are available and what tools or supplies need to be purchased, move the furniture, tape the borders, lay down the dropcloths, and paint the walls”? I would assert that “paint the bedroom” is all but meaningless and conceals vital information while the second decription actually gives your project crew a clue and allows work to commence in an effective and efficient manner.