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 \u2014 so schedulers end up defending delays that were never really delays.<\/p>\n\n\n\n
So how would<\/em> a tool tell the difference?<\/p>\n\n\n\n An activity’s dates don’t tell you why it moved. The logic does.<\/p>\n\n\n\n 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<\/em> changed \u2014 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<\/em> by the link, not by anything it did.<\/p>\n\n\n\n That distinction \u2014 did this change originate here, or was it driven from upstream \u2014 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.<\/p>\n\n\n\n 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 \u2014 the chain actually controlling the finish date \u2014 through every window. A few things fall out of that:<\/p>\n\n\n\n Picture the monthly update meeting. Instead of a report that flags every activity that moved \u2014 and leaves you to explain, one by one, which slips were real and which were inherited \u2014 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.<\/p>\n\n\n\n The conversation moves from defending the schedule to explaining the project \u2014 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.<\/p>\n\n\n\nThe difference is in the logic, not the dates<\/strong><\/h2>\n\n\n\n
How Steelray Delay Analyzer separates the two<\/strong><\/h2>\n\n\n\n
\n
What that changes for the scheduler<\/strong><\/h2>\n\n\n\n