What changed between two schedule updates? A review checklist

A monthly schedule update is easy to read on its own and hard to read in context. The finish date may hold steady while the path to it is rewired, float is used up, or history is quietly edited. Most of what matters in an update only shows up when it is compared with the one before.

Here is what to compare, roughly in the order it tends to matter.

The checklist

1. Data date. Confirm the update moved forward by the expected period. Two updates with the same data date, or a gap, change how every other comparison reads.

2. Forecast finish and key milestones. How far did each move, in working days? A finish that holds while interim milestones slip usually means float is being consumed somewhere.

3. The critical path. Which activities are newly critical, and which dropped off? A changed critical path with an unchanged finish deserves an explanation.

4. Total float. Look for activities whose float fell sharply. Float that disappears without a matching change in progress is often the first sign of trouble.

5. Logic changes. Relationships added, deleted or changed in type or lag. Logic edits can move the critical path without any change in the work.

6. Duration changes. Remaining and original durations that changed without progress to explain them, especially on critical and near-critical work.

7. Constraints. New or moved constraints, above all hard ones. A constraint can pin a date the logic would otherwise push out.

8. Calendars. Changed work weeks, added holidays, or activities moved to a different calendar. Calendar edits change dates without any visible change to the activities.

9. Actual dates. Actual starts and finishes from earlier periods that were edited. Past dates should not change; when they do, the record of what happened has changed.

10. Added and deleted activities. New scope, split activities, or work that disappeared. Deleted activities take their logic with them.

11. Baseline. Confirm the comparison baseline is the one agreed. A swapped baseline changes every variance in the report.

Why compare every update, not just the latest

Each change on the list can be legitimate. Projects re-plan, logic gets corrected, and scope changes. The problem is when changes are not explained, because months later, when the delay is disputed, nobody can reconstruct why the schedule moved the way it did. Comparing every update as it arrives keeps that record while people still remember the reasons.

How Schedule Cracker does it

Each update you upload is compared automatically with the one before it, and you can compare any two. The comparison covers the items above, and each finding opens to the activities involved, so the review meeting starts from the changes rather than from a hunt for them.

Questions

How often should updates be compared? Every update, as it is issued. A comparison across several months shows the total effect but hides when each change was made.

Is a changed actual date always a problem? Not always. Sometimes it corrects an error. It should always be explained, because it changes the project's history.

Which change is most often missed? Calendar edits, because the activities themselves do not change.