Is reporting project progress in % to supervisors acceptable?

Question

Currently I am working as a Project Manager in a big software project.

Currently my supervisors require me to report each week to report the project's progress in percentage form, as in the example:

75% (out of 100%), where 100% means the project is finished, delivered to the client and the client will pay the final sum for it.

My aim with this question is to gather data from experienced project managers if such practice is acceptable and reliable or not in Software Engineering?

Is it something which might actually help to get an insight on the project progress or it is a door which leads to anti-patterns and misconceptions?

Answer 1

TL;DR

There are some other good answers here, but "percent complete" is not only tricky to calculate reliably, but it's often implicitly tied to scheduling. That makes it difficult to talk about it without talking about schedule variance, too.

Percentages of Tasks Completed

We've all seen software installers that zoom from 0% to 83% complete in a matter of seconds, and then sit there for a long period of time (minutes? hours?) before moving upwards again. This is an example of task-based completion versus time-based completion.

One way to address this discrepancy is to report your percentages based on "planned man-hours consumed" and "plan man-hours remaining." For example, if a project has budgeted 100 man-hours for a task, and you've spent 75 man-hours so far and have a reasonable level of confidence that you have 25 man-hours remaining, then it would be logical to report that the task is 75% complete.

Personally, I think that if you report percentages at all, you should report them as a task-completion range with a confidence interval. I'd much rather say "Task A is between 68-76% complete, at a confidence interval of 80%" than just throw a single number out there without context.

I'd also take pains to differentiate task-completion percentages from schedule variance, unless you're extremely confident that tasks remaining is accurately tied to time remaining in your project plan. For example, "Task A is 75% complete, but it's estimated the task will require another 7-10 days to finish" is likely to be more useful from a planning perspective than how fractionally-done the task is. After all, unless you can extract value by shipping a feature that's only 75% complete, the feature probably has no value until it's 100% done.

Your mileage (and organizational requirements) may vary. Adjust your reporting methodology accordingly.

Agile Percentages: Done or Not-Done

Agile frameworks like Scrum take a different approach, where tasks are either "done" or "not done." This makes reporting percentages simpler in the sense that you are simply reporting which tasks are 100% complete as a percentage of total tasks for the project. Because of the iterative approach, the percentage of tasks completed is assessed separately from schedule estimates, management targets, and variance.

This avoids the common pitfall of saying things like "60% of our tasks are 80% done." Such statements are often semantically null; they typically don't provide accurate information on tasks remaining, budgeted man-hours remaining, or schedule variance. This can lead to faulty strategic planning based on incomplete information.

Organizations that don't make the distinctions between task completion and schedule variance often assume they are the same thing, and this increases the risk of project failure. Agile methodologies attempt to make this distinction, but the difference still must be clearly articulated and successfully communicated to be useful.

Answer 2

Not only acceptable but expected in many environments. If you do project management for the US government, OMB & ECPIC absolutely require you to report progress in %.

There is a deeper problem however; not how you report the %, but how you measure progress. Glenn Alleman has many blog posts and at least one book that touches on the topic. (My only reservation in citing him is that there is too much good.) How you measure % complete can either make you look very good, or it can make you look like an utter fool.

There are a couple of conventions for reporting % complete. All of them assume that you first rate the smallest work package and then roll up the reporting (usually weighting the roll-up by duration so that a one month long work package is 4x more important than 1 week work package.

• 0/100 - a work package is either complete or it is not, and it is reported as 0% complete until it is accepted.

• 0/50/100 A work package is 50% complete as soon as someone starts real work, and 100% complete when it is certified finished.

• 0/33/66/100 - A work package is 33% complete once you start work. The work package is 66% complete when you enter the testing/customer acceptance phase.

• Planned Complete - the best situation is when you have planned the work so that every work package has a plan and schedule (an EVM anticipated burn curve). When you plan the work, you set out a schedule and at any moment you can compare actual progress to planned progress and report a % complete. This is easy to do for some things (I will produce 10 widgets/week for 10 weeks and produce a total of 100 widgets), and hard to do for other things, (" I will stare ferociously at the screen for 9 weeks and in the 10th week produce the great American novel")

In each of these cases you've got a plan (or a convention) that allows you to report % complete reliably and transparently.

NEVER ever make up the numbers. Sounds simple, but I've worked far too often with people who will pull the numbers out of the air, "I'm 63% complete". Unless you know and trust the person, ask "based on what? What would make it 65% complete? You never want to be in the position of defending a number chosen arbitrarily by someone who has left. I've found myself trying to explain why Joe Smith estimated 63% complete, then was fired the next day and his replacement estimates that we're 37% complete. That makes management very very angry.

Additional thought: I've read (don't remember where) that the better summary statistic is the time to complete. Management should be coached to not care about % complete. The conversation between the PM and the sponsor should focus on "When will we be done?", which is the business relevant question. "What % complete are we?" has no intrinsic meaning.

Answer 3

I don't think there's anything wrong with reporting percent complete so long as you have both a reliable and valid way of doing so. This means you have a performance measurement baseline against which to track progress, one which was developed using proven methods and is under control, and where tracking progress or claiming earnings is reliable and valid. For example, it would not be very reliable to simply collect the workers' opinion as to how much work they completed. Nor is it reliable to calculate it based on how many days or hours have been exhausted as compared to the total days or hours planned. It needs to be against something physical or tangible so that there is very little ambiguity about how much work was done.

Also, I think just showing % complete is only 1/2 the story. You need to report the variance to date, i.e., how much you completed compared to how much you had planned to complete by that date, and you also need to predict where you are headed. And there are better methods of forecasting than others so choose wisely.