One of the most common questions about MSP involves these two features. Users often wonder why there are two fields if they are always the same value. The deceptive thing about these two fields is that they are often the same value. This article will explore the meanings of these two fields and explain why they are different and why they often appear to be the same.
Calculating these values
Percent Complete is a measure based on duration and Percent Work Complete is based on work. The two fields are calculated as follows:
- Percent Complete = Actual Duration/Duration (PC=AD/D)
- Percent Work Complete = Actual Work/Work (PWC=AW/W)
If a task has a duration of three days and one and a half days have been completed (one and a half days of days actual duration), then the Percent Complete will be 50 percent because 1.5/3 = .50.
The same is true with Percent Work Complete. A task with 40 hours of work and 24 hours of actual work will have a PWC of 60 percent because 24/40 = .60.
It is easy to dismiss these two fields as the same because, many times, their values are the same. This is because the work on a task is often evenly distributed across the duration of the task, so that when half the duration of the task is complete, then half the work on the task is also complete.
Take, for example, a task that was five days in duration with 40 hours of work distributed as five eight-hour days. If actual work is applied with the same distribution (eight hours a day or four hours per half day, etc.), the two percents will be the same.
When setting up test projects to look at values or examine how MSP does something, most people set up the project so that these work to duration ratios are even, so they never see the fields in the conditions under which they can be different.
When the values are different
A good example of how and when these two fields are different is a task like the one shown in Figure A. It is a two-week duration task and Resource A is assigned to do 20 hours during the first five days, and Resource B is assigned to do 50 hours during the last five days.
When Resource A reports his four hours per day for the first five days, the percentage complete for the task is 50 percent because half of the 10-day duration is complete.
However, the percentage of work complete is only 29 percent because the schedule was “back loaded” with most of the work to be done by Resource B in the final week.
The two resources evenly divided the duration of the task, but B had more than 70 percent of the work during her half of the duration. Seventy-one percent of the work was scheduled to be completed in the last 50 percent of the duration. So, when the first 50 percent of the duration was complete, only 29 percent of the work was done.
| Figure A |
 |
You can see A's 20 hours in the first week and B's 50 in the second week in Figure A. The duration measure of percent complete measures only how much of the duration is done. So when A finishes his 5 days of work, it reads 50 percent. In this example, even though half the duration is complete, there is still more than 70 percent of the work to be done due to the design of the project.
Planning time and ramping up can also change PC vs. PWC
These two calculations will be different in situations when one person is working on a task for a time and then the project ramps up and 20 people work on it for the rest of the task. In a case like this, the difference between the two percentages would be huge.
This difference more often comes into play in projects at the Summary task level, particularly at higher levels of summary tasks or the Project Summary, where there are lots of tasks under the summary. A great example of this is a software development project where tasks at the beginning of the project might be low work (few resources working alone) whereas the tasks after the midpoint of the duration might be high work (many resources working together).
The tasks at the beginning of a development project are often done by a single person or a very small team of product and program managers. They work alone on things like writing functional specifications. These tasks are relatively low work but long duration because of the low number of resources.
Then, as development work begins, there are relatively high work tasks or periods of time where many high work tasks are occurring at the same time. Many developers are working at the same time, coding the actual software. Because of the higher number of hours of work occurring in a relatively short duration, the later parts of the project are more heavily worked. So at the project level, when the specifications are done, the Percent Complete might be 20 percent or 30 percent but the Percent Work Complete might be very small, perhaps in the 10 to 15 percent range.
It is important to remember that in a project like the one above, Percent Complete would not be a good indicator of overall completeness of the project. That first 20 percent of Percent Complete was completed easily and without much risk. One person working alone writing specs is not the hard part of a software project. That comes at the end when all the developers are working at the same time on different parts. In this case, Percent Work Complete might be a better measure of how much work is left to do.
