Laws of Schedule Management

A project schedule’s ongoing reliability hinges upon the quality of the inputs, the care with which the schedule is maintained and its accessibility to team members. A project file with errors in the baseline or recorded progress can lead to false expectations of delivery or earned value. Such false claims, when exposed, can have material consequences for the project or program. A project schedule that is unreliable is considered broken, and is worse than useless to the project team.

Continued upkeep and reporting of a broken project schedule drains resources and sows distrust across the project. The Laws of Schedule Management are written to preserve trust in the schedule’s reliability. Master Schedulers must adhere to these laws at all times. 

Chronos, the Greek deity of time.

0. Do Not Change the Past

Baselined work that is older than the current reporting period cannot be altered. There is no exception to this law.1Just as the Zeroth Law of Thermodynamics comes before all other laws of thermodynamics, this is Schedule Management’s most basic law. 

1. Do Not Distort Reality

The first law of Schedule Management is necessarily broad. All project schedules make approximations to strike a balance between accuracy and manageability. However, a Master Scheduler must never record an expected finish date or task status that they know to be inaccurate or untenable. Distorting schedules for convenience or appearance creates a ripple effect that exacerbates problems and masks their root causes. A project schedule that does not reflect reality must be repaired or discarded without hesitation.

2. Do Not Manually Edit the Baseline

Changes to the baseline must only be made by first modifying the affected tasks and their dependencies, then using the schedule management software’s built in baseline management tool to update the baseline. 

Manual edits to the baseline destroy the integrity of the project file’s schedule logic and timescale data. 

3. Do Not Remove Tasks or Resources with Actual Work

Completed or partially completed tasks represent work that has been performed against the project baseline. The project’s past history is of vital importance for earned value, improving bases of estimates, and audit compliance. 

Exception Case: When a Project File exceeds 120 MB, or twenty thousand lines, Microsoft Project may have difficulty accurately recalculating the plan. In this case, the Master Scheduler can submit a request through the project’s Change Management Process to archive a portion of the project schedule. Activities can be archived if:

  • They do not include any incomplete work
  • They have no dependencies to any incomplete work
  • Their removal does not impact the project Baseline Start or End Date
  • All work was completed at least one full fiscal quarter ago (Two partial fiscal quarters do not add up to one full fiscal quarter.)

Circumstances that require archiving part of the Master Schedule are uncommon for baselines smaller than 200,000 hours. 

4. Do Not Declare Early Success 

Never declare a task complete before it is complete. If the reporting period ends on Thursday, Team Leads cannot close a task that they know will end on Friday, even if only a tenth of an hour remains. Tasks can only be closed if all work has completed prior to the schedule status date. 

5. Do Not Reopen Closed Tasks

Said another way, do not change the past. The prerequisite for closing a task is that there is no more work to perform. In principle, reopening a task is akin to admitting that the previous declaration of success was a lie. In practice, Team Leads who close tasks to later reopen them are distorting their project status, obstructing accurate resource assignments, and muddying root cause analyses of delays. If a task has been reported closed, work normally attributed to that task is recorded against the next open task.

Workaround: If a task “must” be reopened, take the following steps. 

  • Determine why the task was declared closed. 
  • Find the most recent version of the schedule in which the task is still open. 
  • Reconsider whether the task must be reopened.
  • Update the task with the current status.
  • Make all other schedule updates necessary to bring the schedule back up to date. 

Note that this workaround can require significant rework on the part of the Master Scheduler. Consider carefully the costs and benefits of “reopening” the task, versus keeping the task closed. The Master Scheduler retains final authority on whether to reopen a task.

6. Do Not Maintain Financial Data in the Plan

Keeping labor rates or other cost and financial information to the schedule has two significant downsides. First, financial data restricts who can access the schedule. The project schedule should be accessible all project team members. Second, while many schedule management tools have the capability to track financial data, it is not their strong suit. Large time phased project schedules have known difficulties when calculating project cost. The only workaround, verifying all total costs by repeating the calculations in a spreadsheet or other financial tool, is self-defeating. Using schedule management tools to capture cost data is never a recommended practice.