How to Run a Monthly Schedule Update

A monthly schedule update is not "change some percentages and print a Gantt." Done properly, it is a short, repeatable process: freeze a copy, collect actual progress, move the data date, recalculate, check what changed, fix what broke, and explain it in writing. This post walks through that process in the order you should do it, with the checks that catch most of the problems reviewers will find anyway.

Why the process matters more than the software

Most specs (including those built on CSI Section 01 32 16, covered in Reading a Schedule Spec) require a monthly update with a narrative, often tied to the pay application. Owners use it to judge whether the job is on track. Contractors use it to support time extensions later. If the update is sloppy, both uses fall apart.

The common failure is not bad math. It is inconsistency: progress reported as of different dates, actual starts that change between months, logic quietly edited without mention, and a narrative that says "no changes" when forty relationships moved. A fixed routine prevents that.

Step 1: Save a copy of last month's update

Before you touch anything, save last month's approved update as its own file or version, untouched. You will compare against it in Step 7, and in a dispute you will want the chain of updates exactly as submitted. Name it by data date, not by "final_v3."

Step 2: Collect progress as of a single cutoff

Pick the progress cutoff and stick to it. If the data date is the 1st of the month, every piece of progress you enter should reflect what was true at the end of the last workday before that date. Not what the drywall foreman told you on the 4th.

For each activity that was in progress or should have been, collect:

• Actual start date, if it started this period
• Actual finish date, if it finished
• Remaining duration for anything in progress, in working days
• Percent complete, if your spec or cost loading uses it
• A short note on why anything planned to start did not

Get remaining duration from the people doing the work. Percent complete alone is weak; a superintendent saying "80%" on MEP rough-in tells you little about whether it finishes in two days or two weeks. Ask "how many working days left?" and write that down.

Daily reports, inspection logs, and delivery tickets are the backup. If an actual date can't be supported by a daily report, expect a reviewer to question it.

Step 3: Enter progress and move the data date

Enter actuals and remaining durations, then move the data date forward to the new cutoff. The data date is the line between history and forecast: everything before it is fact, everything after it is the plan. The Data Date, Explained covers the rules in detail, but the short version:

• No actual dates after the data date
• No unstarted work forecast before the data date
• Remaining work on in-progress activities starts at the data date

Step 4: Recalculate and pick your scheduling option

Run the schedule. If any work happened out of the planned order, how the software handles it depends on whether you use retained logic or progress override. That choice changes the critical path, and it should be the same every month. See Retained Logic vs. Progress Override.

Step 5: Run quality checks

After recalculating, check the mechanics before you look at dates:

A DCMA-style check (see The DCMA 14-Point Assessment) covers most of this. schedule.construction runs these checks automatically, but any tool will do as long as you actually look at the results.

Step 6: Make revisions separately from progress

Progress and revisions are different things. Progress is recording what happened. Revisions are changing the plan: new activities for a change order, resequenced work, revised durations, split activities.

Keep them separate. A clean practice is to update progress first, save a "progress only" version, then make revisions and save again. That way you can show the owner exactly how much of this month's slip came from the field and how much came from plan changes. Mixing them makes the update impossible to review and invites the question "what are you hiding?"

Every revision should be listed in the narrative. If your contract requires approval of logic changes, get it.

Step 7: Compare to last month and the baseline

Now look at results. Compare this update to last month's and to the baseline:

• Forecast substantial completion and other contract milestones: how much did each move?
• Critical path: same activities as last month, or did it shift?
• Activities whose finish moved more than a few days
• Float consumed on near-critical paths

A worked example of the summary you should be able to produce:

If a milestone moved, you need to say why. Reading Schedule Variance covers how to trace a slip back to its source.

Step 8: Write the narrative

The narrative is what people read. The Gantt is what they flip through. A useful narrative is two pages, not ten, and covers:

1. Data date and the period covered
2. Forecast completion and milestone dates, compared to baseline and last month
3. Current critical path, in plain words ("steel erection, then metal deck, then roof membrane, then dry-in")
4. Work performed this period, by area or trade
5. Problems and delays: what happened, what it affected, who is responsible if known
6. Revisions made to logic, durations, or activities, with reasons
7. Planned work for next period
8. Recovery actions, if the schedule is behind

Write it like you'd explain it to the owner's rep across a table. "Curtain wall started six workdays late because embed plates were cast in the wrong location on levels 3 and 4. Remediation is complete. Curtain wall remains critical and now drives dry-in by three days." That paragraph is worth more than any chart.

Step 9: Submit and keep the file

Submit the native file (not just a PDF) if the spec requires it, plus the narrative and any required reports. Archive exactly what you submitted. If the owner rejects it, revise and resubmit as a new version; don't overwrite.

A realistic monthly calendar

If subcontractors can enter their own progress, the collection step shrinks. It still needs one person to review what came in before it goes out.

Common mistakes

• Changing actual dates entered in a prior month without explaining why
• Letting the data date sit while recording progress from different weeks
• Editing original durations to make the schedule "come out right"
• Adding constraints to hold the completion date
• Narrative that says "the project remains on schedule" while float dropped by ten days
• Skipping the update for a month and catching up later, which breaks the record

Key takeaways

• Use one progress cutoff, one data date, and the same scheduling option every month.
• Collect remaining duration, not just percent complete.
• Separate progress from revisions and document every revision.
• Compare to last month and the baseline before you write a word of narrative.
• The narrative is the deliverable people read; explain the critical path in plain language.