Statusing Progress
Statusing progress generally takes the form of updating to either durations or work and includes updating the status of remaining work and network logic. A status date (or data date) denotes the date of the latest update to the schedule and thus defines the demarcation between actual work performed and remaining work. All work before and through the status date represents completed effort; all work beyond it represents remaining effort. Simply put, all dates before the status date are in the past and all dates beyond the status date are in the future. No dates in the past should be estimated; no dates in the future are actual dates.
Unless a status date is provided, the schedule cannot be used to reliably convey past and remaining effort. The status date is an input into the calculations used to update and schedule remaining work. Neither the date on which someone is viewing the schedule nor the latest save date should be used as a substitute for a valid status date (see case study 16).
Updating Duration of Work
Updating duration is the most common method of recording progress because it is the easiest to do. To update activity duration, an actual duration is entered into the plan to record the amount of time (typically working days) elapsed since the last update. If the activity began after the last statusing, an actual start date is entered as well. Next, an updated estimate of time remaining on the activity is entered. The scheduling software calculates percentage complete for the activity based on actual duration and planned remaining duration.40
While duration updates are widely used, team members can easily misconstrue them. Because the update applies to the activity duration, it specifically denotes the passage of time from the start date, not actual work accomplished on the activity. For instance, an activity could have used up 80 percent of its scheduled time yet have accomplished only 10 percent of the work. For this reason, it is important that realistic forecasts of remaining duration be updated—while taking into consideration the physical effort remaining to be completed—at the same time as the actual duration is recorded.
Accordingly, recording progress by entering percentage complete is not recommended, because scheduling software adjusts the remaining duration to yield the entered percentage complete. Estimating a percentage of work or time complete is an inexact science, whereas activity managers and schedulers are accustomed to estimating remaining duration. For instance, task managers may confuse inputs and outputs, assuming that if they have worked 7 days on a 10-day activity, they must be 70 percent finished. In addition, asking activity managers for information on actual duration and remaining duration is a more natural question than requesting a subjective measure of time passed. For example, a response of 80 percent complete on a 5-day activity may indicate that it is almost finished, even if the team has left all the difficult work for the last day.
The subjectivity of percentage complete estimates becomes more apparent the longer the activity’s duration. While 25 percent complete may be a viable estimate for a 4-day activity, it is an entirely ambiguous progress measure for a 50-day activity. Finally, percentage complete is based on the expected duration of an activity, which is variable. The exception is in updating level-of-effort activities that represent support activities that are not associated with any discrete product. Level-of-effort activities are typically described as percentage complete by the total duration of the activities they support.
Updating durations generally implies that work performed by a single resource or multiple assigned resources is completed at the same pace and, in terms of percentage complete, is equal to the time spanning the start date and the status date. That is, if the activity is 50 percent complete, then all assigned resources are generally assumed to have completed 50 percent of their work. This is a simplifying assumption that may work well for some program plans.
Other program managers may want to update work by resources to track actual effort by resource unit or group. Tracking actual work progress requires more time and is more complex than updating durations, but it provides more accurate historical data and higher-quality forecasts of remaining effort. Similar to updating durations, updating work progress requires entering actual work performed as well as forecasts for remaining work. The scheduling software then calculates percentage work complete.
Regardless of whether a schedule’s progress is marked by duration or work, data should be relevant and should adhere to the definitions set forth in the governing process. Team members and management should have consistent, documented definitions of what constitutes an activity’s start, its finish, and its meaningful progress. For example, the actual start date of an activity could be the preparatory research or it could mean only the start of significant work that directly affects the associated product. Likewise, the actual finish date could be the point at which no further work whatsoever is charged to that particular activity or it could simply mean the point at which the activity’s successor can begin. In general, opening an activity without the resources to do the work just to record some progress is a poor practice.
Updating the Status of Remaining Work
Time preceding the status date represents history. All unfinished work and activities that have not started should be rescheduled to occur after the status date. If unfinished work remains in the past, the schedule no longer represents a realistic plan for completing the project, and team members will lose confidence in the model. Case study 17 shows an example of activities within a schedule that were not properly updated.
Officials from the Transportation Security Administration’s Electronic Baggage Screening Program stated that they had conducted weekly meetings on the schedule and had updated the status accordingly. From the weekly meetings, officials generated weekly reports that identified key areas of concern with regard to schedule shifts and their potential effects on milestones. However, our analysis showed that 30 activities (6 percent of the remaining activities) should have started and finished according to the schedule status date but did not have actual start or actual finish dates.
In addition, the schedule’s critical path began in a data collection activity that was not logically linked to any predecessor activities, had a constrained start date, and was marked as 100 percent complete on June 18, 2010—2 months into the future, according to the schedule status date of April 16, 2010.
The schedule also contained 43 activities (9 percent of the remaining activities) with actual start and actual finish dates in the future relative to the schedule status date.
The schedule should be continually monitored to determine when forecasted completion dates differ from the planned dates, which can be used to determine whether schedule variances will affect downstream work.Appendix III discusses updating work duration in an EVM environment.↩︎