Monday, June 23, 2008

This Blog is 80% Complete

Copyright 2008-2009, Paul Jackson, all rights reserved

How many of you have sat in a weekly status meeting and heard the phrase “I’m 80% done with that task”?  Or 90%, 75%, 50%, etc.?

It’s at this point in a status meeting that my mind starts to wander to other things.  It might wander to the real work I need to do once I get out of the meeting or to the kayaking I plan to do over the weekend, but one way or another I’m not paying attention to these status reports any more.

Why?  Because, in my mind, the only valid status for a task is binary: complete or not complete.

If you have to report a percentage of an individual task in a weekly status, then your task wasn’t broken down enough to begin with.  Now a larger task made up of several steps might be 80% complete after a week of work, but that should be extrapolated from the completeness of its components.

What triggered this post was a status meeting where it was reported that a task was 75% complete – the line-item in Project was scheduled for forty (40) days.  It wasn't a rolled-up, summary task; it didn't represent another, more detailed technical schedule -- it was just forty days of some work.  And it wasn't alone -- there were plenty of twenty and thirty day tasks to keep it company.

God might have been able to accurately estimate Noah's deluge at 40 days of effort (and even He had to work nights to meet the deadline), but I think this is beyond the abilities of most software developers without breaking it down a bit.

In my opinion, forty hours is too large a task and should be broken down further -- just the act of thinking about the necessary steps will help drive a better understanding of the level of effort involved.  And that better understanding of the effort results in better, more accurate estimates.

Something I'm hearing more often in projects is a request for ROM (Rough Order of Magnitude) estimates -- as though changing the terminology from SWAG makes it somehow more acceptable or reliable.  Personally, I like the "magnitude" part -- like measuring an earthquake on the Richter Scale, ROMs are logarithmic.  The likely error in the ROM grows logarithmically as the initial ROM estimate increases.  E.G. the margin for error in a 40-day ROM is going to be logarithmically more destructive than that of a 1-day ROM ... approaching the catastrophic.

Also, like the ROM chip, once that estimate's written, it's read-only. That ROM's what you're stuck with and you'll be held to it.

I'm reminded of a place I used to work that did consulting for county government.  Everything the owner estimated was a ROM and every ROM was "two weeks". 

"Sure, we can do that for you.  Take about two weeks."

Time and materials later, it's amazing how many billable hours there could be in a two-week estimate.

The opposite extreme from the ROM is a schedule and status reporting that's so granular as to impact the ability to do work.  I worked with a project lead once who wanted tasks for his MS Project schedule measured in hours and status updates twice a day.  More time was spent providing updates (and justifying or explaining a deviation from the estimate) than was spent actually coding.  Luckily this didn't last long.

When I'm in charge of an effort, we break things down until the individual tasks are about a day's effort -- many less, some more, but the target's about a day.  Then the developers sign up for the tasks they're confident they can complete in each development iteration (typically a week or two) -- within the technical team we estimate the effort of the individual tasks, but from the Project Lead's perspective, they all have a duration of the iteration length.  Status at the project level is binary: done / not done.  I adapted this a bit from a process I found in Managing Projects with Visual Studio Team System:

If a task is 99% complete, it's reported as not done.  If all the tasks for an iteration aren't done, the iteration's not done.  Just like with a build -- if 99% of the projects build, the build's still broken.

This is what project leads should be concerned with.  Not "did every task take the estimated amount of time", but "is the project on track for completion".  Manageable iterations with manageable workloads accomplish this.

This blog is now 83% complete.

kick it on DotNetKicks.com

1 comment:

evilhomer said...

I could not agree more with this.

I like to break tasks down to the granularity that I know with reasonable confidence that I can complete it in that time-scale.

I believe that few have the ability to estimate with any level of accuracy beyond something they have done before or completely understand.

Great article, are you going to write more for the blog? I find it excellent.