How 'Percent-Complete' Is That Task Again?

Students in my project management classes get treated to a mini-rant about the percent-complete method of measuring when a task or set of them are completed or not. So I thought I'd share it with the blogosphere. Simply put, this is a poor technique to measure task completion, and always has been.

Why? For starters, its too ambiguous. How many times have you sat in project status meetings and heard claims that some front-burner, critical task is '90% complete' and stays there for months? Or that the last 10% of some task takes much longer to complete than was originally scheduled? Happens all the time, and I plead guilty in my software developer past to doing the same thing.

This technique suffers from a number of problems beyond ambiguity: the 'system' it creates is easily gamed by project staff; the neophytes on your team usually don't have the experience and judgement to make reliable estimates in this fashion; and if you're using earned value analysis or other PMO-style metrics to track project progress, you can't come up with metrics that have much value or believability.

The ambigutiy is maddening at times. Can you put 80% of a software application into go-live production? Does 95% of a new product development have any immediate economic value to the business? Of course not, so why are we using this measurement?

Here's another way to look at this issue: tasks fall into two categories, with no gray area between them - they are complete, or they are not. No middle ground. No percentages. No promises that the remaining 6% will be completed by next Wednesday. This technique scares the hell out of people because it is a binary measurement of truth-in-project-status, and such accountability may be too harsh in the politics of a lot of organizations.

But the technique is very, very effective. If you decide not to use this in your daily/weekly project management scheme with your teams, I strongly suggest that you do it anyway for your own enlightenment on where things really stand with your projects.

Some caveats on using this technique are in order. First, the tasks need to be broken down into time-manageable chunks, such as a few days or, at most, a couple of weeks, without giving the appearance of micro-mangement to the project teams. This is particularly true in knowledge-intensive work like engineering, programming, research & development, etc. If you let tasks go on too long, you may be in for a number of rude surprises where task deadlines are coming up and you find out last minute that they won't be complete, with the corresponding risk and damage to the project schedule.

Then, you should make it perfectly clear to your team what the basis of task completion is. No hidden agendas, no unfair comparisions. If you explicitly state up front what the measures of task completeness and success are, you'll encounter little pushback from teams, other than the ones who know how to hide behind percent-complete random guesses.

As I mentioned before, if the above is politically unpalatable in your organization, you can make this assessment from your current project data by marking all tasks between 0 and 99% complete as 'not done' and those at 100% as 'done,' and see where you really stand. Believe me, you will probably find a number of issues to take action on when you make this type of assessment.

Accountibility and truth - such wonderful concepts.