PM Articles > Geof Lory > Percent Complete? Are You Kidding?

Percent Complete? Are You Kidding?

by Geof Lory

As a project manager one of my regularly scheduled responsibilities, anywhere from weekly to monthly, is to create external facing status reports that provide our stakeholders with an accurate picture of how things are going on the project. These status reports are not designed to directly help the team or manage the project. Their purpose is to provide those who are funding or providing organizational oversight for the project with some idea of how their money is being spent. While each stakeholder group seems to want their own format for the same data (a personal peeve of mine that I will save for another rant), the one common measurement everyone wants for gauging overall progress is project percent complete.

Percent complete can be interesting, but I struggle with it for many reasons:

  • "Complete" is rarely defined at a level of detail that assures mutual agreement
  • The measurement assumes no expansion or contraction of the original scope
  • The original or remaining work are typically inaccurate estimates (SWAGs)
  • Most people don't think in terms of effort, they think in terms of dates and work to deadlines
  • Most organizations do not track hours at the same level of granularity as they estimate
  • When it comes to hours, most people can't properly add to 40
  • Most people are working on numerous projects and have continuous interruptions, so providing an accurate amount of time spent or remaining is nearly impossible
  • What is done is not as important as what is left to be done or what could be done

Think about it. You have a fuzzy definition of complete, on which misguided workers using ill-defined terms create inaccurate estimates that are poorly tracked and don't add up. That is supposed to provide some comfort to our stakeholders about how we are doing? It doesn't make me feel comfortable and I'm the project manager! Still, I status on ... I Gantt therefore I am.

When I Was a Child ...

Growing up in an era when the interstate road system was brand new and flying was prohibitively expensive for a family of five, road trips were the only means of vacation travel for our family. Being an antsy kid, and perhaps a preview into my future career as a PM, I always wanted to know where we were, how far we had gone, and how long until we would get to our destination. My father would hand me the map (a Gantt chart for the drive) and I busied myself tracking every mile marker, crossroad, exit or town passed to calculate when we would eventually arrive. It sure beat playing license plate bingo, my mom's favorite car ride distraction.

This worked because the map (plan) was accurate, the speed of travel (capacity and productivity) was reasonably consistent (except for the bathroom breaks), and the end point (scope) was known and not changing. These are three basic things that are not true on most projects. To stay with the analogy, I suspect that most projects tend to get executed a little more like the Chevy Chase movie Vacation. The moment he backed out of the driveway, all plans and estimates became useless.

The Standard Approaches

When I teach traditional project management (yes, I am bilingual), we use traditional methods to calculate percent complete:

(hours spent)/(hours estimated) = % complete, (e. g. 32 / 40 = 80%)

This is done at each task level and rolled up to the summary tasks and eventually the project level to show percent complete to a milestone or for the overall project. Pretty straightforward, at least for labor-intensive projects where hours and dollars are pretty closely paired. It would seem that the thinking is that the average inaccuracy of the granular tasks will be compensated for by the aggregate inaccuracy to produce an overall accurate number. (Did I really just say that? I think I learned that in my first statistics class in college, and I didn't understand it then either.)

The second approach is to just ask the person doing the work what percent complete they are, record that at the task level and do the similar roll-ups. The challenge with this is that most tasks adhere to Pareto's Law, meaning 80% of the work is done in the last 20% of the time. Or more accurately stated, when you are 80% done you still have 80% of the work left. Of course, the math doesn't work. Roll these up to the project level and see how accurate that is. Probably no more accurate than the first approach.

A Better Approach

Unfortunately, few people are really good at accurately estimating work -- initial or remaining -- even when it is work they have done many times. However, the closer you are to being done the less work there is left to estimate. So, theoretically, as the task progresses your estimate for the remaining work should be better. Therefore, if I am tracking hours against estimates, my preference is not to ask percent complete or use the initial base estimate but rather take the actuals and introduce the estimated remaining hours into the equation:

1 – (remaining hours/(hours spent + remaining hours)) = % complete

When you do this on a 40-hour task after working 32 hours on the task with 8 hours left, it looks like this:

1 – (8/(32 + 8)) = 80%

This looks the same, and it is, as long as the original estimate and remaining hours estimate are correct and unchanged. But they rarely are. What is more likely the case is that after working 32 hours there are still 20 hours remaining (and that is probably generous given the 80/20 rule mentioned above), the formula would look like this:

1 – (20/(32+20) = 61.5%

I don't really know if this is any more accurate, but at least it will get the discussion started that may lead to a better understanding of the true percent complete since there is a big difference between 61% and 80%. Which one should you roll up and stick in your status report?

A Different Problem with a Different Answer

In both of the formulas above, the denominator -- either the original estimate or the remaining estimate or both -- is believed to be known and reliable. So, what do you do when the denominator is unknown or is an intentionally moving target, as it would be on an Agile project? This creates a problem with the percent complete mindset. Percent complete becomes difficult to calculate.

In these situations, velocity (actually speed, for the physics nerds out there), is much more important than percent complete. I'm all about empirical measurement to know exactly where we are, but measuring what is done is not as important and has little bearing on what is left to be done. Velocity or speed is what matters. Velocity is the collective measure of our ability to reliably chip away at the remaining work in a semi-predictable manner. Semi, because the future is, by definition, unknown.

So, as I log another year into the books and create my annual status report, this point seems particularly salient. I certainly could report on my percent complete of all the things I want to do, goals and items on my bucket list, but what seems more meaningful is to check my velocity. How much, how good, how quickly? I have never thought to ask myself what percent of my life I have lived. I'm not sure I would feel better or worse, or if I would even care to know. But I am working hard to increase my velocity. Ultimately, I think this is what our sponsors want, too.

Happy New Year!

Not all comments are posted. Posted comments are subject to editing for clarity and length.

I've never liked using hours as a means of determining the level of completeness. I have usually used work completed as a means of tracking status. Each work package contains a specific number of activities. An activity is either complete or not. Of course, it doesn't work on all projects, but nothing does. There is no one size fits all.

Not dissimilar to what Mr. Bridges said but a bit more rigorous is the measurement of deliverables. To do a meaningful (that is, useful), project plan you have to have completed a high level design. This activity always takes longer than the customer wants but until you have the high level design you don't have the knowledge to estimate the work involved. Once you have the design you identify what functions need to be delivered, what data they will have to work with and what data they need to produce. At that point I make my team members take that information and for every function estimate its complexity and its size - not in days or hours but real deliverables. I.E. this function will require a 3 page functional specification, the detail definition of n inputs and n outputs, n meetings with the user department and a HIPO of so many pages showing its role in the system architecture. In conjunction with the team you establish production rates for each type of deliverable/complexity combination. This makes the person doing the estimate really think about what is involved and in fact can be assessed by another person for accuracy so for critical tasks you can do double-blind estimates (two people estimate the same thing and resolve why they may think differently). The project manager and system designers can then add dependency data and do critical path analysis, resource allocation, project staffing requirements (staffing up and down) to meet desired deadlines. And percent complete in now really measurable because no task/deliverable combination is of interest until it is 100% done. All of your tasks are granular enough that partially done tasks are irrelevant as they are trivial to the overall project,
Oh I know, HIPOs went out of favor a long time ago. Big mistake. IMHO

The part I've never understood is why anyone wants to know percent complete in the first place. All I want to know is how much work remains to be done before we complete the project. And, in some projects, we don't even want to know that, because when the budget has been consumed, we declare that we are finished and take what we have to be what we wanted all along.

Post a comment

(Not displayed with comment.)

©Copyright 2000-2017 Emprend, Inc. All Rights Reserved.
About us   Site Map   View current sponsorship opportunities (PDF)
Contact us for more information or e-mail
Terms of Service and Privacy Policy

Stay Connected
Get our latest content delivered to your inbox, every other week. New case studies, articles, templates, online courses, and more. Check out our Newsletter Archive for past issues. Sign Up Now

Got a Question?
Drop us an email or call us toll free:
7am-5pm Pacific
Monday - Friday
We'd love to talk to you.

Learn more about ProjectConnections and who writes our content. Want to learn more? Compare our membership levels.