Dig out, not up
Late projects stay late. It’s terrifically rare to “catch up” on a late project. When projects run late, it’s because you’ve missed something in your original estimate: you’ve guessed that work will take
x
days, but it’s taking1.5x
, or whatever. For you to “catch up”, your estimate would have to be wrong about the rest of the project, but in the opposite direction. Even if you correct what led to the overrun, it’s terrifically unlikely that you’ll somehow make up time.— Jacob Kaplan-Moss
Don’t tell people you will get back on schedule by working harder or having better luck. As Jacob points out, there’s already evidence that your team’s capacity or luck aren’t harmonizing with your existing estimates and hopes!
Instead, talk about scope/time trade-offs that one could make to focus on what’s most important. Share the results of retrospectives.
Attempt to explain how you got here in the first place. Caveat, you’re unlikely to fully explain how a software project surprised you on the first attempt. You’re working from an estimate, a projection from wildly incomplete information. Now you have slightly more information, but still an incomplete model. (You won’t have a complete model until you finish the project, sadly.)
Share how you might avoid this surprise in the future. Caveat, the remedy is often worse than the disease. Particularly in software development, if we attempted to prevent or foresee every possible illness, the project would barely get off the ground before it was cancelled. See also: agile software projects accidentally reinvent waterfall when they seek to add more predictability and remove risk/surprises from the process.
Previously: Your estimates were wrong? Communicate!