Last time, we left off with a problem: schedule-comparison tools flag an activity as “delayed” whether it actually fell behind or just inherited a late start from its predecessor. They can’t tell fault from inheritance — so schedulers end up defending delays that were never really delays.
So how would a tool tell the difference?
The difference is in the logic, not the dates
An activity’s dates don’t tell you why it moved. The logic does.
Go back to the finish-to-start chain. The predecessor finishes two days late; the successor gets pushed two days behind it. A comparison tool sees two slipped activities. But the predecessor moved because something about it changed — it took longer, started later, lost a resource. The successor moved only because its predecessor did. Nothing about the successor changed; its start was driven by the link, not by anything it did.
That distinction — did this change originate here, or was it driven from upstream — is exactly what a dates-only comparison throws away. To recover it, you have to trace the driving logic back from each change to find where it actually started.
How Steelray Delay Analyzer separates the two
That’s the work Delay Analyzer automates. Instead of comparing dates in isolation, it analyzes each update in the context of the schedule’s logic and calendars and traces the driving path — the chain actually controlling the finish date — through every window. A few things fall out of that:
- Driven movement is identified as driven. When an activity moved only because its predecessor did, Delay Analyzer sees the change came down the link rather than originating in the activity — so inherited slips aren’t lumped in with real ones. (And because it looks at what actually changed, a single slip isn’t double-counted as both a start and a finish delay.)
- Schedule changes aren’t mistaken for field delays. A finish date can move because a duration grew, a relationship was modified, or a calendar changed — not just because work fell behind. Delay Analyzer separates real progress slippage from these revisions.
- Only changes that reached the finish date count. A slip absorbed by float never moved completion, and the analysis reflects that. What surfaces is the short, honest list of changes that actually drove the date — not every activity that moved.
What that changes for the scheduler
Picture the monthly update meeting. Instead of a report that flags every activity that moved — and leaves you to explain, one by one, which slips were real and which were inherited — you walk in with the distinction already drawn. When a reviewer points at an activity, you can show it started late because its predecessor did, ran as planned once it began, and that the real driver sits upstream.
The conversation moves from defending the schedule to explaining the project — and the schedule stops looking like it’s full of delays every period, and starts looking like what it is: a well-maintained plan where a handful of real drivers explain the movement.
If you’d like to see how Delay Analyzer traces the driving path and separates what an activity did from what it inherited, you can learn more on the Steelray Delay Analyzer product page.