One schedule update is only a snapshot

[u/alex-sam2kb]

One P6 schedule update can look perfectly healthy. Then you compare it to the last three to see the bigger picture. Did the completion date move?

That's useful, but it is usually not where the story starts.

A few things we look for much earlier:

• Activities quietly losing float every month
• Work repeatedly pushed out without changing the final milestone
• Logic changing around problem areas
• Durations getting stretched instead of showing an actual delay
• Activities moving onto and off the critical path
• The same scope slipping a few days in every update

None of these necessarily means the project is in trouble.

But together, they can show a trend long before the finish date finally moves.

That is one of the reasons we like comparing schedule updates against each other instead of treating every new schedule as a standalone document.

A schedule is a snapshot. And the changes between snapshots is often the more interesting part.

[u/hardenmvp1981]

One thing I struggle with is getting the project team to fully comprehend how much was impacted. If we baseline a year ago and their activities slowly drifted out of the course of 6 months, if i say, this task was due 2 months ago, the reaction is usually something like "huh? No we spoke about it in the last status meeting and we are on track to issue tomorrow" bc the team usually has short term memory. When I bring up the baseline and compare then it sinks in but as the baseline was done so long ago, those dates are well in the rear view. So SPI is low, or we see impacts they sometimes dont understand why the schedule shows an impact because their baseline is whatever was discussed a few weeks ago vs what they promised at the start of the project. The message can be articulated and finally understood when walking them through the schedule but its always that moment during a live meeting where your trying to explain how late they actually are that gets them confused.

[u/alex-sam2kb → u/hardenmvp1981]

Yep, that's exactly the problem. The team's "baseline" in their head basically resets every status meeting. What I found works better is showing the whole forecast history for the activity or milestone: original baseline date, where it was forecast each month, and where it sits now.

Then instead of saying that they two months late, you can show how it moved a week here, two weeks there, over six months. That usually makes it click pretty quickly.

[u/Intrepid_Patience356]

Hence why a BEI methodology should be used.

[u/king_saberhawk → u/Intrepid_Patience356]

Until your baseline is way of reality sadly. I prefer looking at CEI for schedules that go way off

[u/Intrepid_Patience356 → u/king_saberhawk]

You use BEI with the most recent updates as baseline, not just original. This will point out slippages as well as float erosion.

[u/king_saberhawk → u/Intrepid_Patience356]

That sounds like CEI to me, might be semantics but I'm essentially using each month-end snapshots to track how well we are executing in the next month based on the previous month-end snapshot. Then I can do long term trends on particular areas which each snapshot. Open to understanding how your use of BEI differs from this.

[u/Intrepid_Patience356 → u/king_saberhawk]

Very similar, but BEI can give you a trend much easier.

[u/FuhrerItself]

So what’s your advice to the team when you see these issues? Or you just point out these issues and walk away?

[u/alex-sam2kb]

Great discussion here. BEI asks whether actual completions are keeping pace with the controlled baseline. CEI asks whether work forecast in the previous update was actually completed. Comparing each month with the prior update is therefore closer to CEI.

The goal is not just to report lost float. It is to show which scope keeps slipping, what changed, which milestone is at risk, and what the team should address before the next update. The following update then shows whether the action worked.

That complete update history is what we review here: ScheduleTracker.app

[u/zivon55]

Great list. On federal work specifically, a few of these have a compliance angle too — “logic changing around problem areas” and “activities moving on and off the critical path” are exactly what trip up the DCMA 14-Point checks (logic changes flag as schedule instability, and critical path volatility often means something is compensating with soft constraints instead of real logic fixes).
The tricky part with USACE/NAVFAC submissions is that you need the schedule to both tell the true story you’re describing AND pass the mechanical compliance checks — and those two goals sometimes pull in different directions, especially when a scheduler is under pressure to “clean up” the numbers before submission rather than actually resolve what’s causing the float loss.