Over the weekend, I was discussing a couple projects with the highly esteemed Nola who happens to work with me over at CaseySoftware and a regular contributor to CodeSnipers. 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 pair of RFP responses, so I thought I’d share my tactic for getting solid estimates:
Break everything down to the smallest steps/pieces you can.
That may sound simplistic, but that’s the point. You need to break the tasking into individual pieces that you and others can quickly wrap their mind around. Then you can determine which items are “easy”, “hard”, and can/can’t be compressed.
For example, how long does it take to get from where you live to where you work? For me to get to my biggest client’s site, it’s “about 45 minutes”, but there’s numerous steps involved.
First, I drive to the Metro station – 8 to 15 minutes depending on traffic.
Then, I walk from the parking lot to the platform – 2 to 3 minutes.
Then, I wait for the train – 0 (like this morning) to 10 minutes.
Then, I ride the train into downtown – 20 to 25 minutes.
Finally, I walk the two blocks to the office – 3 to 5 minutes.
Now, what I previously said as being “about 45 minutes” is actually more like “33 to 58 minutes”. What causes the huge range and what parts can or can’t be compressed?
The train ride is a fixed duration. Other than blocking the doors to prevent it from moving, there’s not much I can do to affect it. Also, the final walk from the station to the office is fixed as I can’t do anything about the traffic lights. These are two tasks have the smallest variances and can only be impeded, not compressed. Therefore, they’re irrelevant to a crunch. In a development project, this could apply to a Client signing off on the requirements or waiting for the Client to pay an invoice. You can affect these things very slightly and normally only at great cost/difficulty.
As frustrating as it is, waiting for the train is also non-compressible because the trains come at regular intervals. Other than catching an earlier train (aka starting the task earlier), there’s nothing I can do reduce this duration. In a development project, this would map to some of the early design efforts. By brainstorming early – as soon as the first round of requirements are being reviewed – you can begin to have good ideas rise to the top while getting bad ideas out of the way. In order to have a solid design, time must be spent on it now or later. As soon as I get an RFP and consider whether or not to make a response, I pass it around my team to get some first thoughts.
Therefore, the only variables to be adjusted are the first two items.
First – I’m addressing them out of order – I can run from the parking lot to the platform. This doesn’t buy me much unless I can catch an earlier train and therefore reduce the waiting from from 10 to 0-1 minutes. If I run and don’t catch the train, I have simply traded a walking minute for a waiting minute, the gain is nothing, and the frustration is high. All of us have pulled all nighters or put everything else on hold to deal with this *emergency*… and some of us have been cursed afterwards to find out that “it wasn’t really that important”. If you want to kill the morale of the team and quickly earn their disdain, do this. If you want your team to respect you and work hard for you, limit these and only do them when they count.
Finally, what can I do about that initial drive to the Metro? It’s responsible for 13-25% of the total travel time, but my routes are limited. I can’t drive through people’s yards, but I can use my previous experiences to dodge or trade the bottlenecks for other simpler ones. In product development terms, this might be a place where you trade custom production for the use of a COTS product or software library in order to simplify manufacture or to demonstrate a functional prototype. Regardless, this is the perfect place where you and your team can get *very* creative and adjust as the situation changes.
When you create your project plans, what sort of detail do you analyze? Do you say “Design Database” or do you say “Design User Profile Tables”? Do you say “Paint Bedroom” or do you say “Move furniture, Tape borders, lay down dropcloths, paint walls”? I would assert that the first is relatively meaningless and hides vital information while the second actually gives your team a clue and allows for detailed estimates and planning to commence.
And remember, just because you break it down to that level, doesn’t mean you have to hand it to the Customer.