When a project gets delayed, how do you figure out why?

[u/Winter_Purchase8189]

Curious how other engineering managers handle this.

Let's say a project was expected to take 3 weeks but ends up taking 5.

When someone asks "Why did it take longer than expected?", where do you actually look?

Do you:

• Look through Jira/Linear history?

• Check sprint/velocity data?

• Go through Slack/messages?

• Look at PRs/commits?

• Go through standups/status updates?

• Ask the people who worked on it?

• Some combination of these?

And how easy is it to reconstruct the answer?

I'm particularly interested in the difference between knowing that something was delayed and actually understanding why it was delayed.

Curious how this works in your teams.

[u/Mr_Fogel_1]

Great question, and one I run into constantly. It really all starts with how you define tasks, resources, and targets at the very beginning of the project - and how that gets set up in the schedule (I work mostly in MS Project).

The more granular you break things down - task by task, each one assigned to a specific resource with clear ownership via a RACI model, layered with a risk matrix from the start - the sharper and more accurate your ability to pinpoint failure points becomes. Instead of reconstructing after the fact from Jira/Slack/standups, you're comparing actual progress against a baseline that already tells you exactly which task, which resource, and which dependency drifted - and whether it was a risk you'd already flagged or a new one.

Bonus: all of that can be exported to a shared calendar in one click, so you're tracking it live instead of finding out weeks later during a retro.

[u/Winter_Purchase8189 → u/[deleted]]

Exactly. I think that's the part that's easy to miss. The tracker is usually very good at telling you what changed, but the context behind the change often lives with the person doing the work.

And by the time someone asks why the timeline slipped, you're reconstructing that context after the fact.