Estimation philosophy: move dates early, hold them late
Situation
Project dates should be moved when new information is learned, rather than just dropping confidence when dates pass. Early SWAG dates should be updated once actual scoping begins. Red patterns in dashboards reflect engineers being trained not to move goalposts - this needs to change.
Reasoning
Dashboard red indicators are a symptom of cultural problem - engineers trained that moving dates is punished, so they keep outdated estimates. Early project dates should be fluid (move when you learn), late project dates should be fixed (slips show red). Accurate forecasting serves Release Plan map and Value Drivers, not aspirational fictions.
Additional Context
Builds on Justin 1:1 conversation (Jan 16) where Peter distinguished no new info = drop confidence vs new info = move date. Dashboard showing red patterns on Fuzzball items prompted this clarification.
Related Context
slack
The red patterns do not match my intuition. I think we have some work to do about how we handle missed dates... people have been trained not to move goalposts. I want us to move goalposts at least early on in a project so they are an accurate assessment of when things will get done
fathom
Ive worked at places where it was a sin to move the end date. Im not saying that here... If youve learned more about it, then go ahead and reset that.
Outcome
Closed without detailed outcome
Decision ID: 2bf6d785-6731-4364-85bc-5e2acf5415f1