Percent Complete – Are We Nearly There Yet?

June 6, 2013 | Author: PM Hut | Filed under: Scheduling

Percent Complete – Are We Nearly There Yet?
By Ian Webster

I’ve got this old watch at home. It’s broken – completely and utterly useless as a timepiece, but I can’t quite bring myself to throw it away, and at least it tells the right time twice per day. I wouldn’t use it to manage a project, though.

Percent Complete

Relying on percent complete as a true indicator of project progress is about as reliable as using a broken watch to tell the time. Percent complete has the same limitations. It can be correct, but usually just twice – at 0% and 100%. Everything in between simply cannot be relied upon as the truth. At best percent complete is the product of guesswork. At worst, it’s a lie… a broken watch.

The unwary project manager can easily get suckered in. Here’s how it goes. A task starts and the person doing the work reports progress regularly to the project manager. On the face of it, things move quickly early on. Progress moves from 0% complete, to 10% complete, 20%, 30% and so on. The project is progressing. It’s encouraging. The tracking Gantt is updated. Progress is reported upwards. Everyone is happy.

Then progress hits around 80% and things can appear to drag. People working on high profile projects don’t want to look like they’re dragging their heels, but they still need to demonstrate progress, so the percent complete increments keep coming, but they get smaller – 75%, 78%, 79%, and then they usually get stuck. The last 20% takes 80% of the time – that’s the Pareto Principle (also known as the 80/20 rule).

MS Project

There’s a rather convenient if little known feature in MS Project that enables you to set the % complete field to be precisely what it should be if things were going to plan. You don’t need to think. If the work on a task should be 57% complete by now, that’s what you can set the task to be – with a couple of clicks of the mouse. It creates the illusion that things are progressing perfectly in line with the plan.

In my early days as a project manager I’ll admit to using it once or twice. Some years later, in my early days as a program manager, when I inherited what at the time was a failing program, I discovered my whole team of project managers were using it to routinely report that progress was as it should be (when in reality it was anything but). They stopped doing so. We understood where the projects were really at, and we turned the thing around.

A Communications Tool

The problem is percent complete is lovely as a communications tool. You can draw sexy progress lines on a Gantt chart with it. It works to a point, for a while, then it starts to become meaningless. People confuse the amount of elapsed time that’s passed with the amount of progress that’s actually been made. They assume one is the same as the other. It’s quite possible to use up 100% of the time allocated to a task and for it be 0% complete. You’ve spent all your money. Burned all your time, but you’ve got nothing to show for it.


There are some psychological factors at play here:

  • People are over-optimistic when the original estimates are put together, and often don’t want to admit this when work gets underway

  • Project managers don’t like change requests so this persists the original plan

  • People lie (for any number of reasons, such as to cover their poor performance or to stop the project being seen in a bad light)

  • Work will generally expand to fill the available time anyway (for example, the amount of time countries have to prepare for major sporting events such as the Olympics or the World Cup is measured in years, but they’re almost always scurrying around at the last minute sorting something out – the project report has probably been stating that they’re at 99.99 something-or-other percent complete for the last few weeks).

What’s the Alternative?

Tracking the amount of work outstanding is usually a more honest and effective approach. Kids in the back of cars know this instinctively.

“Are we nearly there, yet?” they ask, followed by the qualifying question “How much further?” They’re not interested in how far you’ve traveled. They just want to know how much further there is to go.

Personally I prefer milestones. A milestone’s status is binary – it’s either complete or it isn’t. It’s a cleaner metric. You can’t be half pregnant with a milestone – there’s no mistake (which could ultimately mean much less irritation coming from the back seat on long car journeys).

Ian Webster, PMP runs blogramme. Blogramme is a new blog offering fresh, original thinking, opinion and content around the core subjects of project management, program management and business change.

2 people have left comments

I like the milestone approach as well. Until the milestone is achieved I use qualitative choices. I use SharePoint for project communication and the choices I use are:

Not yet started
Verify [this allows for “trust, but verify”]

Thank you for the post – here’s to more logic.

Toby Elwin wrote on June 7, 2013 - 4:48 am | Visit Link

I can’t agree more with Ian’s view on % Complete. I’ve spent time trying to accurately reflect how far we’ve come on a task by entering a percentage, and it can be a futile effort, particularly when you hit the 80% range. The problem is, some managers seem to love it and feel like they don’t know what’s going on if they don’t have that metric. I’ve started preaching that this metric is at best a rough estimate, and I’ve begun using only 5 possible values – 0% (delivery not started); 25% (delivery initiated); 50% (delivery well underway); 75% (delivery nearing completion); 100% (delivery complete). Still not perfect, and still prone to the same pitfalls, but a little more forgiving.

Jason McLellan wrote on June 9, 2013 - 8:38 am | Visit Link

feel free to leave a comment

Comment Guidelines: Basic XHTML is allowed (a href, strong, em, code). All line breaks and paragraphs are automatically generated. Off-topic or inappropriate comments will be edited or deleted. Email addresses will never be published. Keep it PG-13 people!

XHTML: You can use these tags: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

All fields marked with " * " are required.

Project Management Categories