August 27, 2009

Is It Done Or Not?

One of my graduate classes was taught by a retired project manager who worked at a large, well-known software company during its heyday, and his lessons were sprinkled with advice and best practices from his years of experience in the industry. One of his comments, though, really jumped out at me, and I immediately took it to heart.

When talking about how people report on the status of tasks, my instructor mentioned that he only wanted to know whether the task was finished. He wasn't concerned about what percentage of the task was completed; he just wanted to know if it was done - a simple yes or no. His argument was that a task might be 95% done, but that remaining 5% might be complex or require the most time. So reporting the percentage of a task completed can be misleading and even trivialize the amount of work that actually still needs to be done - causing managers to believe that a task is close to being finished when it may not be. Reporting the percentage of a task that's done could also spur the developer or management to overlook or try to bypass the remaining work that needs to be finished for a task, when we should instead be focusing on ensuring that all tasks are "done done done".

So instead of giving a percentage, I try to simply state that a task is not done and then describe any obstacles that might be impeding my progress. Management then knows that work still needs to be finished but doesn't have any unrealistic expectations that the task is close to completion.

Posted by Tom Wessels at 9:43 PM
Labels: ,

5 comments:

  1. Tom, my response will be disjointed; will not "flow". Most likely when include somewhat sophomoric language. My apologies in advance.

    You're recount of the professor's ideology touches me in me privates because I can identify with it so well. What's worse, the incessant "what's the status" (the expected answer should be given in % form) pervades my life outside of the office. I now find myself volunteering inaccurate % because I've been brainwashed into believing that that is what others (who depend on your work) expect.

    Here's my problem: I don't have the patience (and have too much disdain for the requesters) to explain, in non-% terms, how much work remains. I cannot attempt to demonstrate that the work cannot be broken down into 1% increments. That the remaining 5% may take 200% as long as the first 95%, nor why the first 95% took 50% less time than the requester (and, perhaps, I) anticipated.

    Further, it is quite often that I do not know how much work remains (it's the particular nature of my job). Person: "I have a problem" Me: "Ok (shit! you bastard! Die! I hate you!), I'll gladly look into it." Person: "Can you tell me when you'll have an answer for me [because I'm too stupid to speak to [insert name of person to whom my pesterer must report] until you tell me verbatim what to regurgitate [as my own opinions, of course].

    However, sans the % response, I'm left with two options: (1) pretend I didn't hear the question (i.e. leave my headphones in and turn up the volume), or (2) explain that the "task is not done and then describe any obstacles that might be impeding my progress". This opens up the proverbial can of worms, as the person to whom I am speaking is typically indubitably ill-equipped to comprehend sentences exceeding 5 words in length. Throw in the obligatory techronym or two and suddenly I'm arm-shifting in my chair to dodge gravity's effect on the saliva puddling in the crevices of [insert person's name] mouth. And in doing so, I've lost valuable minutes/hours, that which is so necessary to satisfy the inquisition.

    So, I resort to the familiar (and, again, expected) %-based response, for no other reason than to simply dismiss the person, and in the process, subsequently reaffirm that I am destined to never again experience that thing that many other humans refer to as "vacation".

    Do you find that it is as simple as "management knows that work still needs to be finished but doesn't have any unrealistic expectations"? They just go "hmph" and walk away, never to bother you again? From my perspective, they remain dissatisfied, and therefore will continue to request these ambiguous status reports until they receive the answer they wanted (and probably unreasonably expected) beginning with the first time they asked.
    ReplyDelete
  2. I failed to mention that my response would also be sprinkled with incorrect spellings, run-on sentences, misplaced commas, nested brackets, and generally poor grammar. But it is 1:21 AM. If you expected me to be 100% correct in all aforementioned areas, your expectations were unreasonable.
    ReplyDelete
  3. @Chris
    Good answer! But please get some sleep.

    @Tom
    At some point, I decided that what people wanted wasn't a percentage complete for a task, but when the task will be done.

    So I started reporting that, based on my estimate of how many work hours remain and my velocity.

    The trouble with that is it takes time to track and compute. Sometimes it's worth taking that time and sometimes not, depending on the size and importance of the task.

    Also, yes estimates are just that—estimates. Sometimes, I estimate that I'll be done with a task tomorrow, but when tomorrow comes, my estimate of when I'll be done has changed. Then I might need to explain why my estimate changed.

    I'm not saying I think this is an ideal way for things to work, just that sometimes it's useful.

    I agree with Chris, that though it depends on the team and how it works, usually when I'm asked for status reports, the person asking wants more information than just whether or not I'm done, but not as much information as what my obstacles are. Sometimes they care about what the obstacles are and how they can help resolve them. And sometimes, they just want to know when I'll be done and don't have time to help with obstacles until those obstacles threaten their commitments.
    ReplyDelete
  4. Chris -

    I'm often fortunate enough to simply state that something isn't done and have that be enough for the person requesting status from me. Yet I have been pushed for a percentage before, and in those instances I've tried to stick to my guns and reiterate that the task simply isn't done, but then also state the work that still needs to be completed - not as a percentage, but an actual enumeration of the unfinished steps.

    Your situation (troubleshooting) is particularly ill-suited for percentages. How do know what percentage of a problem has been figured out and then solved? And what does the percentage (e.g., "I've debugged 20% of this issue") even denote?

    Could you also benefit from simply enumerating work that's been done and needs done - for instance, "I've tried this, now know this, and will be trying this"? This seems like it would be more beneficial than a percentage - though it would require more effort on your part than a basic guesstimate of percentage.
    ReplyDelete
  5. Amy -

    That's a great point. When people ask for a percentage, they often really mean that they want to know when something is done. And using estimates coupled with velocity is great for this. My only concern would be the time required to calculate and then re-calculate these estimates. I guess determining whether the time spent estimating is worthwhile depends on the importance of the task (and possibly who is requesting a status update).
    ReplyDelete

Subscribe to: Post Comments (Atom)