Percentage of Completion – Is It Meaningful?
Percentage of Completion – Is It Meaningful?
By Satya Narayan Dash
In many companies, normally Managers report with percentage (%) of completion for the deliverables in a project. Is it meaningful? Does it really convey what has been accomplished?
As a matter of fact, it does not convey the reality of the project. Also, in the current economic environment, when every penny is important for a company and its customers, appropriate data tracking and reporting are gaining importance.
Note: Though the following discussion is done by keeping a Software Development Project in mind, the principles are applicable in many project development environments.
Now, let us check the theory of percentage of completion.
Why is it Meaningless?
Reason – 1:
First a question – what does it mean when a team member says that his/her work is 90% complete?
Does it mean that his/her coding is 90% complete or his/her unit testing is 90% complete or (s)he was waiting for someone’s approval and that is 90% complete? Or, is it a combination of all the aforementioned cases?
If it is combination of all the cases, then what are they? If any manager wants to write it down in a project report, then can (s)he really do it? Obviously, it is practically impossible to report on all the possible cases.
Reason – 2:
Another way to look at it, one day a developer in the team says that his/her deliverable is 90% complete. And the supervisor might think it will be complete in 3/4 days – considering the number of days allocated. After 3/4 days (s)he says it is 95% complete. Then, the revised assumption becomes – completion will be in 1/2 days. After couple of days, it is 99% complete – due to some other constraints. And it goes on.
So, what a manager can do to report correct status?
Remedies:
Option – 1:
Ask the team member how many days it is going to take for completion, in place of % age of completion. If it is going to take 20 person days and 12 person days are already gone, it means that 60% of work should be done.
It is easier said than done as software development never works in linear ways. Rather it is unpredictable. And perhaps that it what makes it worrying and exciting at the same time. It may be due to other constraints, assumptions for which it could not be completed.
Hence, ask the developer that how long it will take to complete, like: will it be come 10 more days in place of 8 or will it be 5 person weeks in place of 3 person weeks? Get that information and also ensure that you get a commitment for new dates.
If those dates are put in the project report, it makes sense. A sample can be like below:
Delivery Items | Owner | Start Date | Completion Date | Revised Completion Date |
X | John Rodman | 10-03-2009 | 21-03-2009 | 04-04-2009 |
Y | Sam Mistry | xx-xx-xxxx | xx-xx-xxxx | xx-xx-xxxx |
… | … | … | … | … |
Z | … | … | … | … |
Option – 2:
For certain kind of projects, micro-managing is important. Then, one can have them segregated by individual modules for each important deliverable: like document completion, coding, unit testing etc. It must be noted that in reality, developers also do all these work simultaneously in place of doing them one after another. Hence, it should be helpful to them.
The above table can be expanded to include sub activities with certain main activities.
Option – 3:
However, percentage of completion also works, if you are using EVM technique.
To know the status of the project, just a couple of question needs to be asked:
- What is the SPI (Schedule Performance Index) for the project?
- What is the CPI (Cost Performance Index) for the project?
If SPI and CPI are below 1.0, then the project is not in good health, i.e., not performing well. The calculation for these is also known as EVM, i.e, Earned Value Measurement.
Also from a schedule perspective, if the SPI is below 1.0 (let us assume it is 0.9), then it means the deliverable is actually 90% complete and it is behind schedule.
Conclusion:
If your project is using Enterprise Project Management Software and Methodologies, the best way to report on status of completion is to use EVM Technique. Otherwise, in place of reporting percentage of completion, the proper way to know the completion status can be Option -1 or Option -2.
Satya Narayan Dash is the Principal Consultant and Founder of Teleox® Consulting, Bangalore, India. Prior to that, he was Project Leader with Wipro® Technologies and a Project Leader with AdventNet®, Inc. He has rich experience of 8+ years in product development, and architecture in Java® and J2EE® based Telecom solutions. As a certified Project Management Professional (PMP®) from Project Management Institute (PMI®) and MS Project 2007®, he has trained hundreds of project managers and consultants. He holds a Bachelor Degree in Electronics and Communication Engineering from National Institute of Technology, Jalandhar, India. He can be contacted at email: ndsatya@gmail.com
I am a big fan of #3. Earned value is definitely the best approach.
Without the ability to do EVM I would suggest that you keep it simple and follow a couple of rules:
1. break the project down until all tasks are less than a week to complete.
2. use binary percentage complete. it is 0% complete until it is 100% complete. this takes the debate out of it and avoids the 99% complete symptom.
Tim
Thanks Tim. That is also an innovative approach. In fact, if you have a group of committed developers, your approach is the best.
In fact, I employ some more if EVM does not fit in. I’ll address them in my next piece.
Satya,
The challenge is the measure progress as “physical percent complete” in terms tangible evidence. In the aerospace and defense business, using EV, engineer opinion is not allowed. Nor should it be here. Only tangible outcomes are used as measures of progress. In most cases these are 0%/100% measures – either you’re done or you’re not.
The key is to size the durations of the measures of progress on the sweet spot.
Ask “howlong are you willing to wait before you find out you’re late?” Then make the 0/100 measurement points sufficiently fine grained to allow for cacth up processes – usually 1/4 the total time.
Glen B. Alleman
VP, Program Planning and Controls
Glen,
Thats a wonderful feeback and insight on Aerospace and Defence sectors. And it should be very credible form of tracking there – considering the money involved.
In software, now a days, project management evangelists are moving from Waterfall to Iterative to Agile/Extreme/RAD development. Here, the outcome is absolute. As you have said: it becomes – either you have done it or you have not.
I agree on the tangible evidence part, which may be challenging in some domain. However, in software, proof of your feature/deliverable (and hence evidence) comes in an automated weekly/daily build. And the motto – “Release Early and Release Often”, initially from the Open Source environment, is now finding its way into new management methodologies.
Nevertheless, to check whether the feature is really working, the Project Manager must be technically sound – which does not happen often in software (unless the manager is truly interested in the product or service). Exceptions are there in software product companies.
This is a realy nice article which need to be followed.
Thanks Uttam.