What I've learned over the years is that the most important thing to do when I realize a project is late is to:
What other tips do you have?
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:
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".
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.
Good thoughts! @Lee how do you decide on the level of confidence %? Do you use some heuristics?