<em>While on the train heading to Paul Graham’s Startup School, I brought along quite a bit of reading material. I was hoping to sleep, but I was also hoping to catch up on some reading while I couldn’t be distracted with various tasking, email, etc, etc.</em>

For example, the first thing I read was an article on “Software Development Cost Estimating” and I dug into it with interest. I happen to have a very particular way that I do my estimating – which seems to be quite accurate by the way – but I’m always looking out for more and better methods. This wasn’t one of them… let me analyze this one step by step.
<em>Step 1: Create an accurate estimate of the project’s overall size.</em>

So in order to estimate the project, I have to estimate the size of the whole project? Hmm… sounds like time for a WAG to me.

<em>The two most common metrics for this step are determining either the number of lines of code (LOC) or the number of Function Points (FP).</em>

Alright, now this is more like it. I’ve never been a good LOC estimator – even when I’m writing the code – but Function Points is something that I can understand. I know that implementing a “Search by Name” function is probably trivial while a “Search by any subset of Name, Date, Shoe Size” is a bit more effort.

<em>Step 2: Estimate the number of person-months or person-hours necessary to reach the LOC or FP estimates.</em>

This screams “The Mythical Man Month” to me. Fred Brooks must be rolling in his grave*.

<em>Step 3: Convert the results of Step 2 to calendar months.</em>

Alright, put it against a calendar. Makes sense, let’s move on.

<em>Step 4: Convert the results from Step 3 into dollars.</em>

Multiply. Got it. And that’s it… those are all the steps described.

Now I admit that the core points of Project Estimation are covered… but this still feels inadequate.

Let me describe how my tactic varies. I do #2 completely, but I actually expand it and break each area down into smaller and smaller pieces consisting of classes, functions, modules, databases, tables, reports, screens, or even individual functions on a screen. Is this a bit neurotic? Quite possibly. Does it work? You bet.

In fact, it allows me and the rest of the team to track tasking to a finer detail and determine which tasks have run over/under and then ask why. If one task took double the projected time, we immediately know how that affects everything else. In addition, similar tasking can be grouped together and/or parallelized in order to benefit the project as a whole. I believe it allows us to track the project velocity and allows to be schedule tasking towards my team’s strengths from day one.

Personally, I feel the best when I can break tasking down into tasks of 5-10 hours each. It is enough to alow someone to get started, make progress and sometimes wrap it up in a day and other times have some time to think about it between starting it and finishing it. Now, just because I break things down to this detail doesn’t mean the client sees the end results.

* <em>[When I wrote this, I was pretty sure that Mr. Brooks was dead. I’ve now found out that I was wrong and am only keeping this in here to have a complete record. Mr. Brooks, I do not wish harm upon you and hope you continue sharing your insights and wisdom with those who have come after you. Thank you for what you’ve already shared.]</em>

Write a Reply or Comment

Your email address will not be published.