Project Management Blog

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.

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.

Step 1: Create an accurate estimate of the project's overall size.

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.

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).

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.

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

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

Step 3: Convert the results of Step 2 to calendar months.

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

Step 4: Convert the results from Step 3 into dollars.

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.

* [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.]