August 23, 2004

Are you done yet?

How far are you along with that task? Are you 50% done, 60% done, 77.77777% done? I hate this question, and after a little research I think I've come across an idea I like alot more.

We often have to do progress reporting for a task, and then estimate the percent complete for the task. This is a time consuming exercise riddled with unintentional misconceptions. Well, functional testing is 50% done, but we still have to test the other half of the application. Whose to say that half won't take twice as much time if a major issue is uncovered?

So what's the solution, it is pretty simple. There are three rules, 50/50, 20/80, 0/100, here is how it goes. For the x/100-x rule, when the task starts it is immediately completed by x percentage, only when the task is completely finished and closed out it gains the remaining 100-x percentage.

So for instance, for the task of functional testing, as soon as we start we are 20% complete. We maintain this status until we have completely finished functional testing, and at that time the task becomes 100% complete. A much more systematic method than random estimating.

Posted by Elyse at August 23, 2004 8:29 PM | TrackBack
Comments

good article Elyse, on my projects, I'm using the following rules:
- if a task is not started - 0%
- when a task start - 50%
- at the task completion - 100%

the advantage of this method is that is really quick to estimate the work progress without interpretations.
The negative point is that it is not really usefull if you have not a lot of tasks.
For small projects, I'm using a 0-25-75-100% rule.

Posted by: Fred at August 24, 2004 4:06 AM

"How far are you along with that task? Are you 50% done, 60% done, 77.77777% done"?

This question is a planning instrument. Based on the answer, other tasks and resources will be scheduled and fitted into the time line. However, planners and schedulers loose the basic understanding of the exercise problem, that this is at best an estimate or a guesstimate. They believe the numbers to be mathematical certainties. This is where exasperation, frustration, and heated tempers overwhelm us due to failed expectations and schedule diversions.

We loose sight of the fact that while the task is being performed, gremlins invade and the task goes from controlled expertise to higher complications and chaos. Something that was unknown during the planning phase has entered the activity and now heeds to be accounted for. There are many variables to cause this.

By employing a trick, we can account for these complications. The trick is simple. 1. We have to estimate the time it will take if the task is done efficiently. 2. Then we have to estimate what happens if the task is performed sloppily and factors do not come together as planned. 3. Average these two numbers together and that should be the benchmark to achieve. 4. Estimate contingency. What is the chance the task will have to be performed over? 1 time in 3, 1 time in 10, then convert this to a percentage and add it to the activity time. However, do not advertise this number. Also if the duration time to do the job fails the common sense test, stick by it as no one complains if a job is done too soon. Or make one of the factors affecting the task in question, a task itself. e.g. Parts and equipment are present for the task. We all know what happens if the task is not completed on time.

For the first estimate, parts and equipment are present for the task to be formed, the people who have excellent talent for doing the job are present, the task has number one priority, and no important resource will be pulled away.

For the second guesstimate, how long can the task take if the resources do not fall into place and inexperienced people perform the work?

Just my humble opinion.

Posted by: Steve at October 10, 2004 12:00 PM