Most companies are trying hard to achieve predictable end dates.
So there is no way they would ask for a status report that would directly cause the project to take longer, right?
Unfortunately, the fact is that most companies do this all the time.
I’m talking about the ubiquitous “percent complete” metric.
It’s not only meaningless, it’s misleading and harmful as well.
Meaningless Metric
So let’s look at why it’s meaningless first.
Here’s an example of what a typical Gantt chart looks like that displays percent complete.
The dark shading on the left of each task represents the work that is done, and the light shading to the right represents the work that is remaining. That’s fine but notice where the line is that represents today.
Unless you have a time machine, any remaining work to the left of today can’t be completed in the past. So all of it has to be done in the future. You might say, “Of course, so what?”
But have you ever thought about what would happen to the resource loading or end date if you updated the plan so that all of the remaining work is in the future? It’s possible that moving a single task will move the end date directly. And even if that doesn’t move the end date directly, it’s also very likely that after you level the resource loading the end date would move as a result of that as well.
So what good does it do to have a metric that doesn’t tell you anything about when you will actually get done?
And there’s another issue…
Misleading Metric
In projects with a lot of uncertainty, how often do you learn that something is going to take more time after you have started it?
So if a task was originally estimated to take ten days, on the fifth day you would report that you were 50% complete. But what happens on the sixth day if you find out that it’s going to take two days longer (so twelve days total)? Are you going to report that you are 50% complete again? If you do, will they think you didn’t work on it so there’s still five days remaining? Or will they know there are actually six days remaining and the end date moved?
Or what if your two-week vacation is coming up and you won’t finish the remaining 50% until you get back? How and when will anyone know what kind of impact that is going to have?
Do you see how this metric is both meaningless and misleading?
It doesn’t tell you why it changed or why it didn’t, and it doesn’t tell you anything about your end date.
It only sounds like you’re making progress when the reported numbers are going up.
And there’s something worse...
Harmful Metric
Using "percent complete" as a status report is directly causing your projects to take longer.
Seriously.
Tom Peters famously said, “What gets measured, gets done.” (And that comment has been studied multiple times and proven to be true.) So when you tell someone that you are going to measure how much work they have completed at every status meeting, you are literally telling them…
“You should multitask so that your updates look good next week.”
Not only does multitasking increase the total amount of time the work will take (because of the switching cost), think about what happens if any of that work is on the critical path…
Critical path work is getting delayed 100% of the time the resource is doing something else.
(To see the detrimental impact this causes, and the formula for calculating the total amount of delay, watch this video.)
And how would anyone know what work is actually on the critical path if the plan looks like the one above? It is so out of date that the critical path is almost certain to change when it is updated. So it’s impossible for the team members to even know the relative importance of their tasks.
So they do what they are encouraged to do and continue multitasking…
And no one questions it.
(You can read about how to prevent multitasking and why it’s a negative regenerating loop in the previous blog post here.)
Glimmer of hope
The uselessness of this metric and the harm that it causes has bothered me for a long time, but I got a bit of encouraging news the other day.
I was talking with a contact whose company makes one of the largest and most complex products I can think of, and their projects are years long. And he mentioned that their primary metric at status meetings is now “work remaining”.
!!!😲!!!👏!!!
That was the first time I have heard that on a hardware project.
Small shift, huge difference
You might think there’s very little difference between “percent complete” and “work remaining”. After all, the formulas have the same variables on the right side of the equals sign…
Percent Complete = Completed Work / Total Work
-vs-
Work Remaining = Total Work – Completed Work
But they get us to focus on two entirely different things.
And “Work Remaining” is a metric that is both meaningful and useful.
For one, in order to update “work remaining” for a status report the individual doesn’t really use the formula. Instead, they have to actually think about what is left to do. And when they give an answer, that work has to be in the future in the plan. So it encourages any remaining work to be moved to the future which naturally makes the plan more accurate and also shows the impact to the end date.
And remember, “What gets measured, gets done.” So it also encourages them to focus on what’s left, and not just “getting a little done” on each task.
Our kids knew this
We would like to think we’re smarter than our kids, but don’t they always ask, “How much longer till we get there?” and not, “What percent of the trip have we completed?”
Apparently they know that’s a much better way to get an answer they care about.
(For the Agile guru’s, I realize that burndown charts are a form of percent complete. And they determine your velocity and predict your end date. This type of report can work (be predictable) in situations where the resources are very interchangeable and the work does not have a lot of dependencies or lead times. But none of those are true for hardware new product development projects. And I’m talking about percent complete for individual tasks, or small groups of tasks that a resource is updating as part of a status report, not the average velocity of a large batch of homogenous work.)
So what can we do?
The solution for this depends on your role in your company. If you have the authority, or are the one receiving the status reports, simply stop asking for this and ask, “How much work is remaining?” instead and watch what happens.
(Or if you really want to have fun, start asking “When will we get there?” and see what that triggers in all of the team members that have taken their kids on long road trips! 🙂)
If you can’t do that, forward the link to this blog post to some team members or project managers and see what they think. If you can get a few individuals to understand the uselessness of the percent complete metric, you can eventually get the company to drop it.
And remember, it might be a bit more difficult to get a “work remaining” estimate at status time, but if that forces you to think and plan a bit, that’s a good thing. The point is to finish the project on time, not to have an easy metric for the status meetings.
BTW, if your company absolutely needs a percent complete report because your contract requires it, Playbook can give you that answer very accurately, and it won’t have the errors due to out of date plans or unleveled resources. But “out of the box” we don’t have percent complete in any of our reports. And there was a very good reason for that.
If you would like to see more ways that Playbook helps you achieve predictable end dates and provides meaningful information along the way (that is up to date 24/7), watch this four-part demo series.
If you have any comments or questions about this topic or would like to learn more about the training and coaching we provide as part of our Free Trial process, schedule a discovery call with me. Helping companies solve problems is how we learn!
Here's to better metrics, happier teams, and predictable end dates!
