The absence of a dedicated time now or data date parameter in Microsoft Project makes regular schedule updates painfully difficult compared to other project scheduling software, but reliable and relatively quick updates are possible using the Project Update dialog.
Elements of Schedule Updates
Using modern project scheduling software, a schedule update that conforms to best-practices includes three key elements:
- Update Date/Time. Also called time now, the data date, status date, report date, or cutoff date. This date/time value represents the temporal boundary between the past and future elements of the schedule.
- (Past) Progress. I.e. historical documentation of actual activity dates, durations, work, costs, and sometimes physical completion. All reported progress occurs before the Update Date/Time; that is, in the past. Any non-actualized task dates (i.e. incomplete work) in the past are invalid.
- (Future) Forecast. I.e. remaining (not actualized) project work, costs, and activities that are uncompleted as of the update date/time and must therefore be executed in the future. Any actualized task dates (i.e. completed work) in the future are invalid.
Generic Schedule Update Process
For a given update date/time, the past and future elements are defined through a two-step update process that endeavors to 1) update the status of each task to reflect the progress achieved (i.e. the completed work) as of the time now; and 2) update the overall status of the project by dynamically re-scheduling remaining work and forecasting the project completion in light of the current task status and sequential constraints. The forecast provided by this second step must encompass all remaining work, including any work that has slipped from previously-established dates and remains incomplete.
The first step of the process – task status updating – typically involves a mix of techniques leading to actual start dates, actual finish dates, and actual (and remaining) durations. In many projects, the accuracy of these actualized values is of only minor note, as the next step – re-scheduling the remaining work after time now – is considered far more important for day to day project management.
The second step of the update process – overall project status update (i.e. dynamic re-scheduling of remaining work) – is performed automatically by most schedule calculation algorithms. It typically requires nothing more from the user beyond resetting the time now date and clicking a function key.
Schedule Updates in Microsoft Project (MSP)
Unlike other modern project scheduling tools, MSP does not require any of the three elements named above, and the core updating functions seem focused on step 1, entering task progress (typically as duration %complete) against a static schedule. In fact, the well-developed options for configuring and displaying progress lines suggest a persistent reliance on such static-schedule updating methods among influential MSP users. [I first made progress lines about 35 years ago using paper bar charts hung on a corkboard, thumbtacks, and a weighted string. For a couple months I had the daily job of inserting a thumbtack on each bar to reflect the reported task progress at the end of the previous shift, then winding the string around the tacks to create the progress line. The line told everyone who was getting chewed out, but it said nothing about the current completion forecast or which work was most critical for the delivery. This static view of schedule progress made sense – for a week at a time in our version of pull-planning – back in the days when re-calculating a ship-construction schedule was much more labor intensive than clicking F9 is today.]
Task Status Updating
[Nov’20 Edit: I added this section after review with a colleague.]
MS Project provides a number of techniques for updating task status. I’ve listed the main ones here, generally in order of preference for project control…
- On a task-by-task basis, direct entry of actual dates, actual and remaining duration, and/or %Complete (which is definitely NOT preferred) in a user-customized task table, the default task Tracking Table, or the Task Details Form.
- For one or more selected tasks, direct entry of actual dates, actual and remaining duration, and/or %Complete using the Update Tasks dialog;
- For one or more selected tasks, clicking buttons on the Task ribbon with underlying wizards/scripts to enter a specific %Complete (0%, 25%, 50%, 75%, or 100%) or to Mark on Track (which automatically actualizes all progress as scheduled up to the project’s Status Date);
- For selected tasks or for all tasks in the project, using the upper portion of the Update Project dialog to “Update work as complete through:” any user-selected date. (This is essentially the same as Mark on Track, automatically actualizing all progress as scheduled up to the user-selected date, but defaulting to all tasks);
- For all tasks in the project, direct integration with timesheet entry systems (for actual start and actual work, on cloud-resident or server-resident projects only).
The program’s response to these inputs can vary widely, depending on overall program settings, individual task characteristics, and the order and timing of the entries. As a result, the methods for updating task status seem to vary widely between industries and even between competent professionals in the same industry. Some even use progress lines, though not for the same purpose I described earlier. The end objective is similar for all methods, however: the designation of specific tasks and parts of tasks as being completed (i.e. actualized), and therefore in the past.
Project Status Updating
The project status update first requires that all uncompleted tasks (and parts of tasks) are dynamically rescheduled to take place in the future. In a major difference from other tools, MSP does not directly incorporate a dedicated time now parameter in the schedule network calculations – like the data date in Oracle P6 and other software or the report date in Elecosoft Powerproject. Instead, the forward-pass calculations always begin at the project start, and the restraining effects of time now are achieved only by imposing external start-no-earlier-than (SNET) date constraints (for un-started tasks) or by delaying Resume dates (the start of the remaining duration for in-progress tasks.)
[Nov’20 Edit: I added the next paragraph after review with a colleague.]
In practice, some experienced MS Project schedulers explicitly effect these modifications on a task-by-task basis as part of the task status update above. Thus, when a task that should have had progress instead has none, the scheduler manually imposes a new SNET constraint either on the status date or on some other (later) promised date. Similarly, the actual and remaining durations of tasks with partial progress may be manipulated to straddle the status date. This manipulation can be done either manually or automatically, with the latter accomplished by entering task %Complete while the move start of… and move end of… advanced calculation options are enabled. (As a rule, however, any entry of task %Complete is normally to be avoided, and these advanced options can be more trouble than they are worth.)
MSP’s Update Project Dialog (2)
When the necessary constraints and Resume-delays on incomplete work are not imposed during individual task updating, the lower part of the Update Project dialog can be used on selected tasks. With “Reschedule uncompleted work to start after…”, the program compares the existing schedule Start/Resume dates for each task (in the selection or in the whole project, as indicated) to the update date that the user has specified. If the task’s Start/Resume date is a) not actualized and b) earlier than the specified date, then a SNET constraint or Resume-delay is imposed. (The latter action will be taken only if the schedule option for split-in-progress tasks is checked, the default setting.) The next time the schedule is re-calculated, the new constraints will be imposed on the early dates, thereby simulating the effects of an explicit time now.
Issues with Update Project
- Although the Current Date or the project’s Status Date (if present) are pre-populated in the dialog, the Update Date is not limited. The user may choose any other date for re-scheduling any task or group of tasks. Thus, the schedule effect of a singular time now is susceptible to user interference, intended or not.
- Since MSP only allows the use of a single constraint for each task, the tool fails to re-schedule tasks with conflicting constraints. A SNET constraint with an earlier (non-conflicting) date will be replaced, but if a task with a late start, late finish, or early finish constraint is delayed, the new SNET constraint can’t be applied. The user must then either abandon the existing constraint or impose a delay using new synthetic logic.
- By default, the actions of the dialog are applied to the “Entire project,” and changing the option to “Selected tasks” only, if desired, must be repeated each time the dialog is opened. Using the default option with Reschedule uncompleted work to start after… typically imposes superfluous SNET constraints on tasks whose logical predecessors are similarly delayed.
- Since reliance on external date constraints is generally considered poor practice, the SNET constraints imposed during normal schedule updating in MSP may be flagged by schedule quality monitors. Users are tempted to evade such flags by introducing synthetic logic – especially on high-float tasks that are “riding the data date.”
- The numerous SNET constraints imposed through multiple schedule update periods need to be monitored and removed (after actualization) if the original project plan (i.e. logic and constraints) is to be maintained.
- Reschedule uncompleted work to start after… is not compatible with resource-leveled schedules. All resource leveling delays must be cleared before the tool is run, and the leveler should be called again only after the subsequent recalculation of the schedule network.
For a more comprehensive look at schedule updating in MSP, P6, and Elecosoft PowerProject, have a look at Paul Eastwood Harris’s detailed paper on the subject.
