27 November 2009

I hate 90% done

Posted by



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:

  2. 90% done = not done - it's binary!
    ReplyDelete
  3. 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 :-)
    ReplyDelete
  4. Yes, I feel the same way too.
    ReplyDelete
  5. thanks for the comments guys. How do you practically manage this project scenario out of your life
    ReplyDelete
  6. 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...
    ReplyDelete
  7. 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.
    ReplyDelete
  8. 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?
    ReplyDelete

Subscribe to: Post Comments (Atom)

Popular Posts

  • What is Project Scope? What should it be?
    I have been having a bit of a discussion over at the IIBA blog with Kevin (VP BOK) and Julian (Chief architect.) It’s migrated over to ...
  • User Story Template
    Due to popular demand I have aggregated some information on User Stories and created a simple template.  If you feel this would be useful to...
  • Change Request template
    Better Projects Templates I am uploading a couple of project document templates to Google Docs. As I add more I'll post them up here. You...
  • BCS forum on "Making Projects Work"
    You've heard many reasons why project fail.  Here is a discussion hosted by BCS on why projects work. The discussion covers four dimensio...
  • PDMs - Precedence Diagram Method
    The Precedence Diagramming Method ( PDM ) was developed in the early 1960s by H.B. Zachry in cooperation with IBM. It has largely repla...
  • Snowbird; Agile 2011 discussion on the BA
    In the below video some of the #10yrsagile participants discuss the role of the Business Analyst. A question for you; Do you agree or di...
  • Email, Whiteboards and Well-Caffeinated Wits
    This is a guest post by Jeff Hobbs.  Jeff is a project manager at ActiveState Software who provide pm and collaboration software. Email, ...
  • 7 Requirements Analysis techniques
    In one of the Carnivals of Business Analysts the theme was “ Requirements Analysis ." I searched the web far and wide and came up with a n...
  • An Introduction to Stakeholder Management
    The definition of a stakeholder is controversial. For example, project team members are generally not considered stakeholders, but in virtua...
  • The V-Model: Table of Contents
    I have written about the V-Model across several posts. The V model is a testing focused expansion of the software development lifecycle. In ...