Analyzers

Stop Getting Blamed for Delays You Didn’t Cause

Every scheduler knows this meeting. You submit the monthly update, and someone — the PM, the owner’s rep, sometimes your own management — pulls up the schedule comparison and points at an activity: this one slipped three days. What happened?

Half the time, the honest answer is: nothing happened. The activity ran exactly as planned. It just started late because its predecessor did — and the comparison tool doesn’t know the difference.

Comparison tools can’t tell fault from inheritance

Most schedule-comparison tools — including the built-in compare views in P6 and general-purpose tools like Acumen Fuse — work the same way. They look at an activity’s dates in the current update, look at its dates in the last one, and flag the difference. Started later? Start delay. Finished later? Finish delay.

That sounds reasonable until you follow it through a simple finish-to-start chain. Predecessor finishes two days late. Successor gets pushed two days and finishes two days late right behind it. The comparison tool now flags both activities as delayed — even though the successor did exactly what it was supposed to do the moment it was allowed to start.

For the scheduler, this shows up as two separate headaches every period:

  • You’re defending updates you shouldn’t have to defend. Every flagged activity is a conversation. Multiply that by the dozens of activities that move every period purely because something upstream moved, and a big share of your update-review time goes to explaining delays that were never really delays.
  • Your schedule loses credibility it didn’t earn. When the same activities keep showing up “late” period after period — even when the crew hit every date they controlled — it gets harder to convince reviewers the schedule is being maintained well, regardless of how sound the logic actually is.

And there’s a second, quieter problem hiding in the same comparison: double-counting. If an activity starts late and finishes late for the same reason, a naive comparison counts that slip twice — once as a start delay, once as a finish delay — inflating exactly the numbers people are going to ask you about.

None of this means your schedule is wrong. It means the tool doing the comparison was never built to separate what an activity actually did from what it merely inherited. That’s the gap Steelray Delay Analyzer was built to close – we’ll walk through how in an upcoming post.