Statusing a schedule
Last reviewed 9 September 20262,406 words11 min read
The monthly update, done in an order that works
🟩 In one line There's a right order to a schedule update, and it's not the order most people do it in. Get the order right and the update takes a day and produces a forecast you can defend. Get it wrong and it takes three days and produces a forecast you'll spend the month explaining.
👤 Who this is for Junior planners taking ownership of their first live file. Mid-level planners whose updates keep getting bounced by the client. Anyone who has ever been asked "why did that date move?" and had to say "I'm not sure."
First, let's be honest about why this page exists
Nobody teaches this. You learn P6 on a course — activity types, relationships, F9 — and then you arrive on a project and someone says "the update's due Thursday" and hands you last month's file.
So you do what seems obvious. Open the file. Move the data date. Go through the activities typing in percentages from a spreadsheet site sent you. Press F9. Look at the finish date. Feel sick. Start adjusting things until it looks reasonable.
That's the process on more projects than anyone would admit. It produces an update, technically. What it doesn't produce is a record — a file where every change can be explained, every date can be traced to a piece of evidence, and next month's planner (who might be you, or might be an expert witness in four years) can see what happened and why.
This page is the process that produces a record. It's longer to read than to do.
🟨 The standard — what "good" looks like
The standards don't prescribe a click-by-click sequence, but they agree on what a completed update must contain:
- AACE RP 53R-06 — an update must record actual start and finish dates, remaining durations for in-progress work, and any logic changes, with the reason for each change documented.
- SCL Protocol, 2nd ed., Guidance Part B §1–4 — the contractor should keep the programme updated with actual progress and keep a record of changes made to logic and durations between updates. The Protocol is explicit that an update which silently alters logic is of limited evidential value.
- NEC4 Cl. 32.1 — each revised programme must show actual progress and its effect on remaining work, how the Contractor plans to deal with delays, and any changes to the previous programme. That last item is the one people miss.
- FIDIC 2017 Cl. 8.3 — a revised programme must be issued whenever the current one is inconsistent with actual progress, and must include the supporting report describing progress and any changes.
The common thread: an update is progress plus a change log. Progress alone is half the job.
Two practical rules that fall out of this:
- Status with remaining duration, not percent complete. Percent is an opinion. Remaining duration is a forecast. The forecast is what moves the dates.
- Every logic or duration change gets written down — activity ID, what changed, why, who asked. A one-line entry in a change log, kept with the file.
How it actually works
Here's the sequence. Twelve steps, in four phases. On a 2,000-activity job, done cleanly, this is a day and a half. Most of that is phase 1.
Phase 1 — Before you open P6
1. Save last month's file, untouched, with the data date in the name. ProjectX_Update_2025-02-25.xer. This is your evidence copy. You'll compare against it, and someone will ask for it in three years. Never update over it.
2. Collect progress against a cut-off, and only up to the cut-off. Site engineers, subcontractors, procurement, engineering, commissioning. Use a progress sheet listing every open activity with three columns: Started? (date), Finished? (date), If not finished, how many working days left? Not "what percent." Days left.
3. Challenge anything that looks optimistic before it goes in the file. "Two days left" on an activity that's said "two days left" for three months. "95%" on something the site photos show as half done. Fix it now — it's much harder to argue after the numbers are in the file and the report has gone out.
Phase 2 — Enter progress (data date still last month's)
4. Actual starts and actual finishes first. For every activity that started or finished in the period, enter the dates. Do this before touching durations or percentages — because as soon as an activity has an actual start, the % complete type kicks in and the fields start recalculating each other.
5. Remaining durations for in-progress work. Type the number of working days left. If the activity's Percent Complete Type is Duration, the % will recalculate itself. If it's Physical, enter the physical % separately from what site reported. Don't let P6's auto-computed % override what the site actually said. (See percent-complete-types.)
6. Zero the remaining duration on anything that's finished. Sounds obvious. It's the second most common mistake in updates — actual finish entered, remaining duration still showing 3 days. P6 will flag it in the log, but only if you read the log.
7. Look at what's now out of sequence, and decide what to do. Anything that started before its predecessor finished will show as out-of-sequence after scheduling. Before you schedule, decide: is the logic wrong (fix it and log the change), or did the site genuinely work around the plan (leave the logic, note it in the narrative)? (See out-of-sequence-progress.)
Phase 3 — Schedule and check
8. Now move the data date. Then F9. Tools → Schedule, set the data date to the cut-off with the correct time, confirm the scheduling options haven't changed since last month, run it.
9. Read the schedule log. All of it. Tools → Schedule → View Log. Look for: activities with actual dates after the data date; activities with remaining duration and no actual start scheduled before the data date; open ends that weren't there last month; out-of-sequence activities; constraints. If any of these surprise you, fix them and reschedule before going further.
10. Compare to last month. Tools → Schedule Comparison (Claim Digger in older versions). Last month's file against this one. What you're looking for is anything that changed that wasn't progress: added or deleted activities, logic changes, duration changes, constraint changes, calendar changes. Every one of these should already be in your change log. If one isn't, find out how it got there.
Phase 4 — Read the result and write it up
11. Read the schedule like the client will. Milestone dates against contract dates. Forecast finish against last month. The longest path — has it moved to a different chain? Float on the near-critical paths. Anything that jumped. For each thing that moved, you should be able to say which activity moved it and why, from your progress sheet.
12. Write the narrative, then issue. Progress this period, forecast, what's driving it, what changed in the file and why, what needs a decision. Then XER + PDF layouts + curves + narrative, in whatever the spec asks for. (See schedule-narrative and monthly-progress-report-structure.)
🟢 The one habit that matters most: Never adjust the file to fix the answer after step 11. If the forecast is bad, it's bad. The place to deal with that is a recovery plan — a separate, deliberate exercise — not a quiet duration trim on a Wednesday evening.
🟥 Where people go wrong
1. Statusing by percent instead of remaining duration. Site says 70%. Activity was 20 days, so P6 sets remaining to 6. But the last 30% is the part that always takes longest — testing, snagging, the bit that needs the client. Ask "how many days left?" and you'll get "ten." That's the real forecast. Percent is what's been done; days left is what matters.
2. Moving the data date first. Covered on the data-date page. Everything not yet statused gets pushed to the new data date. If you're interrupted halfway, half the schedule is wrong and you can't tell which half.
3. Using Update Progress / Apply Actuals. P6 has a feature — Tools → Update Progress — that statuses everything as if it went exactly to plan up to the data date. It exists for what-if work and training. On a live project it produces a fictional update that happens to match the baseline perfectly, and someone will eventually notice that your actuals are suspiciously identical to your plan.
4. Silent logic changes. An activity's finishing late, so a relationship is deleted to "unblock" the successor. No note anywhere. Two years later, in a delay analysis, the other side's expert runs a comparison between updates and finds forty logic changes with no documented reason. Every one of them now looks like manipulation, including the ones that were perfectly sensible.
5. Not reading the schedule log. It's plain text, it's ugly, and it tells you exactly what's wrong with the file. Actual dates after the data date. Open ends. Out-of-sequence. Every one of these becomes a client comment if you don't catch it first. Two minutes.
6. Trusting subcontractor progress without checking. Their 80% is your 55%, because their 80% counts material on site and yours counts installed and tested. Agree the rule of credit with each subcontractor before the first update, and check a sample every month. (See verifying-subcontractor-progress.)
7. Fixing the answer instead of reporting it. The forecast slips two weeks. A few durations get shortened, a lag gets removed, and the report goes out saying "on programme." Next month it slips again, and there's less left to trim. By month six the schedule has no relationship to the site and everyone knows it. The first bad month was the cheap one to report honestly.
⚖️ When you're challenged
"Why does this take two days? Just type the percentages in." "Typing the numbers takes two hours. Making sure the numbers are right, catching the logic that broke, and being able to explain every date change to the client — that's the other day and a half. If I skip it, we find out what's wrong when the client tells us."
"Site says 90% on the ductwork. Why have you got 15 days remaining?" "Because I asked them how many days, not what percent, and they said fifteen. The last 10% is pressure test and insulation, and the test needs the fire damper submittal, which isn't approved. The 90% is honest. So is the fifteen days."
"Can you just delete that link so the finish looks better?" "I can if the link is genuinely wrong — tell me why and I'll log it. If the link is right and we're just going to work around it, I'll leave the logic and note that site is proceeding out of sequence. Either way it goes in the change log, because the client runs a comparison every month."
"The subcontractor's update says they're ahead. Ours says they're behind. Who's right?" "Different rules of credit. They're counting delivered; we count installed. I've walked Levels 3 and 4 with their engineer and we agree on installed quantities — it's 55%. I'll send you the sheet."
📄 Related pages
- Data date — the field you set last
- Monthly update checklist — this page as a one-pager
- Percent Complete Types — Duration, Physical, Units, and why Way 3 above works
- Out-of-sequence progress — what to do when the actuals don't match the logic
- Retained logic vs progress override — the setting in step 8 that changes the forecast
- Verifying subcontractor progress — the argument in step 3
- Schedule Narrative — step 12
- Change Control in a Live Schedule — when the change isn't progress, it's a variation
✏️ Worked example
One activity, statused three ways, to show why remaining duration matters.
A410 — Install HVAC ductwork, Level 3. Original duration 20 working days. Percent Complete Type: Duration. Started 3 March (actual). Cut-off 25 March. Successor is the duct pressure test, then ceiling closure.
Site's progress sheet says: "70% done. Remaining works: last two branch runs, then pressure test prep. Fire damper submittal still with consultant."
Way 1 — type the percent. Enter 70% in Duration % Complete.
| Field | Result |
|---|---|
| Duration % | 70% |
| Remaining duration | 6 days (P6 calculates: 30% of 20) |
| Forecast finish | 1 April |
Looks fine. But the damper submittal isn't approved, and the pressure test can't happen until it is. Six days is P6's arithmetic, not anyone's forecast.
Way 2 — ask "how many days left?" Site engineer, when asked properly: "Branch runs, three days. Then we're waiting on the dampers — consultant says a week. Then test, two days. Call it twelve."
| Field | Result |
|---|---|
| Remaining duration | 12 days (entered directly) |
| Duration % | 40% (P6 recalculates from remaining) |
| Forecast finish | 8 April |
Now the % looks worse than the site's 70% — because Duration % is measuring time, not work. That's uncomfortable in a meeting. It's also correct: 12 of the original 20 days of effort are still ahead, even if 70% of the ductwork is on the ceiling.
Way 3 — separate the two. Change the Percent Complete Type to Physical. Enter Physical % = 70 (what's installed). Enter Remaining Duration = 12 (what's left in time).
| Field | Result |
|---|---|
| Physical % | 70% |
| Remaining duration | 12 days |
| Forecast finish | 8 April |
Both true, both recorded, neither overwriting the other. Progress report shows 70% installed. Schedule shows 8 April. Narrative says: "Ductwork L3 70% installed; remaining 12 wd includes 5 wd hold for fire damper approval (submittal ref. S-0287, with consultant since 11 Mar)."
That last sentence is the whole point of the update. The date moved a week, and everyone can see exactly why, and whose action closes it.
📖 References
- AACE International, RP 53R-06, Schedule Update Review
- SCL, Delay and Disruption Protocol, 2nd ed. (2017) — Guidance Part B §§ 1–4
- NEC4 ECC — Cl. 32.1, 32.2
- FIDIC Red Book 2017 — Cl. 8.3
- DCMA, 14-Point Schedule Assessment — Metrics 8, 10, 11
- Oracle, P6 Professional User's Guide — "Updating Progress"; "Schedule Comparison"
From the field
Experience from working planners. Unreviewed — read it as experience, not guidance.
Add what you know about statusing a schedule. What worked, what the consultant pushed back on, what you would do differently next time. A paragraph is plenty.
Contributors get their name and one link on the site — your own templates, course or consultancy. We take nothing and hold nothing.
Add your experience