I hate 90% done

Posted by Craig Brown




Always have.

I learned to hate it when I use to see people report their work was 90% done for weeks (even months) in a row, but I knew they were really wasting time on unimportant or at least less important things.

I have always had a streak of protestant in me that means I want to see value deliverred, religiously, to my clients.

So how can you avoid he 90% done syndrome?
  1. Make sure your deliverables are clearly understood
  2. Understand the tasks in front of the delievrable
  3. Make sure the required resources are all lined up and ready to go ahead of time
  4. Understand what done means to you and your client/boss/team
  5. Make sure the deliverable is scaled to the time period you are working to
If all else fails, report 80% done :)

(You might like this story of a 90% done project.)

Photo by Christopher Chan shared via CC at Flickr

 

Labels:

8 Comments:

  1. Gilad Lev-Shamur said...
    11:48 PM  
    The never ending project:)
    Anonymous said...
    9:05 AM  
    90% done = not done - it's binary!
    joapen said...
    1:32 AM  
    When some of the team members reach 80% or 90% of the time very quickly, I use to attend these numbers with more enphasis in order to make sure they are right and with the purpose of maintaining the good environment on the team.
    Sometimes it works, some others no :-)
    Sanand said...
    5:21 AM  
    Yes, I feel the same way too.
    Craig Brown said...
    9:19 PM  
    thanks for the comments guys. How do you practically manage this project scenario out of your life
    Shoumik said...
    4:47 PM  
    Nice thinking on this 90% syndrome...
    But can we avoid this because if we just enter 80% completed then it will start 80% syndrome.
    I think I saw this type of issues particularly when:
    - User struggles with particular coding issues(it might be blamed to a particular framework or application server not behaving properly or a Genuine coding issue)

    - A GUI or Feature requested by client and added to WBS without analyzing Technical Feasibility(This could be technically not feasible or not having resource with right skills or doesnt fit in the application design without tweaking)

    There could be other reasons but...most of the time I find is a able project manager will either force its developer to fix this issue by any means or force the client to change the requirement who ever stands weak ;-)

    But thanks for the article...and all the presentations you shared on slideshare...
    Mike said...
    8:45 AM  
    I agree with Anonymous. 90% done = not done. I now only measure completeness as 0% or 100%. A deliverable is only complete when the value has been delivered. Up to that point, all effort is simply cost.
    Craig Brown said...
    10:04 PM  
    Shoumik,

    Thanks for the kind words.

    My quip about 80% was facetious. I appreciate humour doesn't always travel well on an international blog.

    I agree with how you should deal witht his issue also; make sure the reqirement/work package is feasible before comitting to it.

    Any sugestions from readers on how to do this effctively?

Post a Comment



Subscribe to: Post Comments (Atom)