Percent Complete’s Limitations

The Percent Complete and Percent Work Complete fields in Microsoft Project were established as a convenient means of reading and recording progress throughout a project schedule. However managers can place too much significance on Percent Complete. Percent Complete does not include the rigor that Schedule Managers require to gauge a project schedule’s performance. Its limitations include the following technical and human factors.

  • Percent complete as a concept has multiple interpretations. A shared understanding of its meaning can be overlooked or not possible to establish. 
  • Percent Complete and Percent Work Complete in Microsoft Project alternate between calculated and manual entry fields. Individual application settings can also change how Microsoft Project presents Percent Complete and interprets modifications to the field. 
  • Percent Complete can be used to obscure a lack of meaningful progress on a Task. 
  • Percent Complete does not wholly answer the more fundamental Schedule Management questions how much work is left and when the effort will finish.

The opportunities for conceptual and technical misinterpretation of Percent (Work) Complete make it a less rigorous metric than SPI or Finish Variance. This article will discuss each of these concepts and overview the variables that should be analyzed to determine progress. 

Arbitrary Interpretations of Percent Complete

When is a Task 10% complete? When is it 27% complete? A Testing and Quality Assurance team may argue a regression testing effort’s Percent Complete is tied to the number of test cases completed, or perhaps only the number of test cases passed. A document reviewer may report Percent Complete based on the number of documents reviewed or the number of pages reviewed. A developer may base their progress solely on code functionality written, with no thought for peer reviews or documentation. One project manager may associate Percent Complete with the total number of Tasks regardless of size, while another bases Percent Complete on the total number of hours worked. 

When a project is progressing well, these separate interpretations are of little consequence. However when an obstruction threatens to impact a major milestone or delivery, misinformation between teams can lead to misunderstandings of a Task’s risk or criticality. Miscommunication exacerbates technical and logistical issues for a project in jeopardy. 

Schedule Management tools such as Microsoft Project attempt to solve this issue with options how to record and track Percent Complete, but the remedy also creates new problems. 

Idiosyncrasies in Schedule Management Tool Percent Complete Fields

Recognizing that Percent Complete is subject to individual interpretation, Microsoft Project offers three percent complete fields. Percent Complete and Percent Work Complete1Detailed explanations of Percent Complete and Percent Work Complete can be found here. convey similar concepts, but use different methods to compute their values. Physical Percent Complete2A detailed explanation of Physical Percent Complete can be found here. is independent of calculated Task progress and can be used for determining earned value. 

Microsoft project introduced the Percent Complete and Percent Work Complete fields as a convenient way to record and track progress. On properly resourced Tasks, increasing Percent Complete calculates and writes Actual Work to the Task’s timephase data.

Figure 1: Calculations of Percent Complete and Percent Work Complete for Tasks or Summary Activities.

Note that neither calculation references Baseline Duration nor Baseline Work. Percent Complete is often misinterpreted to measure progress against the baseline even though the metric was never intended for this function. 

Since both percent complete fields affect two other variables, adjusting one variable will impact at least another. This may cause unintended consequences. For example, suppose a two-day sixteen-hour Task is recorded as being 50% complete. In other words, one of the two days has passed and eight of the sixteen hours of work have been completed. 

Figure 2: Example two-day sixteen-hour Task that is 50% complete.

Now suppose the developer is unexpectedly sick for three days. Increasing the Task Duration stretches the Finish date, but lowers the Percent Complete from 50% to 20%. 

Figure 3: The same example Task with the Duration increased and the % Complete automatically reduced.

The Task hasn’t become any harder, there was simply a delay. So reporting a drop in Percent Complete can mislead stakeholders. Restoring Percent Complete to 50% corrects the reported progress, but changes the Actual and Remaining Work which is also inaccurate. 

Figure 4: The same example Task with the Duration increased and the % Complete automatically reduced.

This predicament has two workarounds, however they present difficulties of their own. The first workaround is to ignore Percent Complete in favor of Percent Work Complete. In the example above, Percent Work Complete is not impacted by the schedule delay. However, if a Task requires more effort than previously estimated, increasing the Remaining Work will reduce Percent Complete, which again risks misrepresentation. Furthermore, Project Managers loath reporting a progress decrease as it implies they have poor control of their project and their team. Percent Work Complete is also more difficult to modify safely than Percent Complete, as the value must be edited directly in a Task or Gantt view, rather than the split screen Task Form or the Task Information dialog box.3Microsoft Project exhibits different behaviors depending on where and how data is entered. Entries in the Task Form View and Task Information dialog box are least likely to create a Soft Constraint or other unintended consequence.

The slightly better solution is to adjust the Resume Date4A detailed explanation of the Resume Date can be found here.. Extending the Resume Date by three days will split the Task, and not impact Duration or the Percent Complete fields. But manually editing the Resume Date can create artificial constraints and affect Microsoft Project’s ability to accurately determine Slack, Finish dates and resource loading. Furthermore, having to determine the criteria for postponing a Task by changing the Resume date or extending the Duration adds tedium to the Schedule Manager’s effort.

Further complicating the matter, settings in Microsoft Project affect whether the Timephase Actual Work calculated by adjusting Percent (Work) Complete is recorded against the overall Task Duration, or the against the current Project Status date. If multiple Schedule Managers are adjusting Percent (Work) Complete with differing application settings, this can lead to inconsistent Finish Date predictions. 

Meaningful Progress Metrics

When work is stagnating, Team Members may attempt to feign progress via negligible increases in percent complete. Beware of false prophets. 

A project team held daily project schedule meetings with over forty developers, managers and clients on the call. One day, a developer reported that the status of a single eight hour Task improved from 97% to 98%. The next day the Task improved to 99%. The literal implications are extraordinary! 1% of an eight hour task equates to 4:48 minutes of work. Did the developer work five minutes on the Task yesterday, and another five minutes today? Why is the developer so busy that they can only devote a cigarette break to finishing this Task? If the developer leaves the call, can they complete the Task before the end of the meeting? Alas these and more important questions were never raised. When the Schedule Manager recorded the progress, they failed to recognize that this Task had actually been stalled for three days and would soon impact the next delivery Milestone.  

While the above example comically illustrates a worst case scenario, it is not hypothetical. Percent Complete changes as high as 15% against any size Task can still mask the reality that no meaningful progress has been achieved. Recording an insubstantial Percent Complete can be as dangerous as a project manager reporting everything is on track with no verification. 

For reporting purposes, Percent Complete holds questionable value. Executive stakeholders typically ask for overall schedule progress, and whether key Milestones will be met. Schedule progress at the executive level is almost always reported in terms of the Schedule Performance Index or SPI. Impacts to key Milestone are reported as projected Finish Dates or Finish Variances estimated in days or weeks. 

For tracking purposes, the variables that predict a Task’s Finish Date are Remaining Work, and Resource Units (i.e. availability). This relationship is described in the Work Equation below.  

Figure 5: The Work Equation used to calculate a Task’s Remaining Duration and consequently its completion date.

Even when tracking Actual and Remaining Work, the Schedule Manager depends on Task Leads to provide credible information. However, the accountability is improved and signs of stalled progress are easier to spot. 

Mitigating Percent Complete’s Impact

Only the most mature PMO offices and programs are able to ignore Percent Complete entirely. This requires tracking of Actual Hours against Tasks and weekly meetings with Team Leads to discuss resource loading, remaining duration and remaining work. Despite its risks, Percent Complete’s convenience is sometimes the only practical method for recording progress against a large schedule.  

To ensure that the convenience is not offset by Percent Complete’s risks, several mitigation steps can be taken within any project schedule:

  • Adhere to the 4/40 or 8/80 rule.5The 4/40 rule of thumb (and similarly the 8/80 rule) states that almost all tasks should require no less than 4 hours and no more than 40 hours of effort to complete. This helps prevent any single Task with an inaccurate status from misrepresenting large portions of the overall project. 
  • Use the Percent Work Complete field instead of the Percent Complete Field, and record Actual Hours where possible. This ensures that the Remaining Work is unintentionally misrepresented by adjustments to Duration or Percent Complete. 
  • Require status updates in 25%, 50%, 75% and 100% increments. This simplifies both reporting responsibilities and accountability. For projects built with sufficient detail, these increments should provide sufficient accuracy. 
  • Avoid reporting Percent Complete to stakeholders. SPI, Schedule Variance and other metrics convey a more accurate picture and provide information better suited for making informed decisions. 

Next Steps

The goal of Schedule Management is to provide the most accurate and reliable project status with a manageable, affordable level of effort. Understanding Percent Complete’s tradeoffs between convenience and reliability are fundamental to picking a schedule tracking strategy. Technical reading and practice manipulating established schedules are recommended to better understand the risks and limitations of recording and tracking by percent compete.