When you realize your project/task is going to be late, what do you do?

I would further add that you should have workstreams broken out, then detail estimates with level of confidence for each. If there is a workstream with significant risk or uncertainty, don’t give dates after an initial milestone or design spike, or give them 0% certainty, and specifically layout that this is the riskiest part of the project, and most likely to require more time. Breaking this down much more into smaller milestones that have decreasing certainty as they get further into the future can make it easier to catch if it’s slipping early and try to intervene.

Your list sounds good. The complication that I often run into, though, is that there are still significant unknowns at the point that I know the project will be delayed. So my strategy is to:

• Notify them of the delay and explain why.
• Then explain the various paths and unknowns, and for each path explain the tradeoffs and time/resources it will take.

The hard part about this is to make the options understandable to your team (including non-technical folks), given that they will not have all the same context.

The way you build trust in this exercise is by "meeting people where they are" and explaining the situation so that a reasonable smart person can say, "That makes sense why it got delayed, and here's my opinion on the options you presented".

Good thoughts! @Lee how do you decide on the level of confidence %? Do you use some heuristics?