There is No Such Thing as Percent Complete


Jason Yip's Hail Mary software development talks about what happens when you defer all the finishing to the end of the project. In the dashboard chapter of the book, I have a sidebar called “How Can We Have No Completed Work?” which talks about exactly the same thing.

The more serial your lifecycle, or the more you implement by architecture instead of by feature, the less completed work you have. Since I don't count partially completed work, it's possible to have 0 progress until the very end where things finally start coming together.

One of the assignments I gave my class this semester was to provide me a status report for the projects. Several of the teams decided to give me % complete measurements. I asked how they knew it was 80% complete. One team actually told me they'd done 80% of the work so far.

I told them to track the rest of the effort. I'm sure they fell or will fall into the 90% done schedule game.

Percent complete makes no sense. Features are done or not done. You can count done features and see how far along you are. You can't reliably count any percentage done.

Labels: measurement

6 thoughts on “There is No Such Thing as Percent Complete”

  1. Johanna,
    The difference between Physical Percent Complete and Percent Complete needs to be clarified. On software projects where the delivered features are produced through Work Packages the comcept of Physical Percent Complete can be used.
    The Work Package is a self contained set of requirements, resources and crieria for completion. E.g.:
    Work Package – produce payment list output for check writing. The tasks needed to provide this capability, the resources (dev, test, user acceptance, HW and SW environments, etc.) and acceptance criteria, etc. are all described in the Work Package.
    Either the WP is 100% done or it is 0% done – this assumes a short WP. For longer WP’s Apportioned Milestones can subdivide the 0/100 into 25/25/25/25 for example.
    Now the entire project has dozens and likely 100’s of Work Packages.
    With the apportioned budget spread across the project’s life, the Physical Percent Complete can be determined with the 100% completion of each Work Package.
    The key here is to NOT let a person tell you the percent complete, but have a quantifiable measure of “complete” measured in delivered value.

  2. Michael Lucas-Smith

    This is only a problem if you take the percentage as a percentage of time. A percentage of requirements fulfilled works just fine. If you try to give a percentage to time – you’ll fail. As we know, the last 20% of the requirements usually take 80% of the time.

  3. % complete is kind of on the same order of % dead or % pregnant.
    When you’re done, you’re done. When you’re not, you’re not.
    I know, I overly simplified.

  4. There is certainly such a thing as 0% complete–I’m there on lots of things. There might be such a thing as 100% complete. Any number between those two is highly subjective.
    I’m happy measuring “points” of work remaining (using burn-down charts) if the team has been at it long enough to have a reasonably stable velocity. A colleague uses burn up charts with variable bottoms. Seeing the bottom drop out of a chart is an immediate, dramatic way of getting attention.

  5. The problem with defining done often has to do with bugs. There are bugs/defects for features, and for the entire system (performance, etc). As we do more exhaustive testing on the system, we find more defects – meaning that features that were “done” are no longer done.
    Add to that the results of usability testing, and other ways of tracking the moving target.
    This is why release criteria is so important, in my opinion. We have different criteria for different kinds of releases – release to usability testing, release to pilot, etc. This means that sometimes after one release, a feature that was “done” isn’t any more.
    It seems that our vocabulary for discussing done-ness needs to advance a bit more before we can improve.

  6. Garrett Moffitt

    It seems there are two different things being discussed. Features and time.
    If I have a 100 foot trench to dig, then when I have dug 50 feet, I am 50% done with the goal, but not necessarily 50% done in labor or time.
    Maybe the first 50 feet was done with a backhoe, and the last 50 feet will be done by shovel.
    One of the things that I don’t like is the fact that very few people will go backwords on there completness measurement. So when the unforseen hits, I could find myself less complete then I was at previously.
    Which is ok. Many people will just stagger at 80% and never say “We had this happen, so we are now at 70%.”
    Complex projects need to be understood by the people managing them for any measurement to be worth while.

Leave a Comment

Your email address will not be published.

This site uses Akismet to reduce spam. Learn how your comment data is processed.

%d bloggers like this: