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.
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.
% 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.
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.
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.
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.
Commenting by HaloScan
