Dragan StepanovićThe idea of “on time” as a project health metric is deeply flawed. People get satisfied and excited about it when a project is “on time”, but it essentially communicates overconfidence of people and organizations trying to fit the inherently complex reality into a number they came up with. The truth is: the reality doesn’t give a damn about what we think of it.
You can put a number/deadline on it and not make it, but it doesn’t mean you didn’t succeed. The only thing you didn’t succeed at is fitting reality into a number. Congrats, because no one is able to do that. The only thing that trying to succeed at it brings you is anxiety, which makes things even worse, and you’re even less likely to succeed in the flawed goal you’re trying to succeed at.
To quote Peter Crone: “What happened, happened, and couldn’t have happened any other way… because it didn’t. It was precisely what was supposed to happen under given circumstances. Why? Because it’s what happened.”
The longer the timeframe we’re using to predict (estimate) it, the more unknowns there are that we don’t yet know of and that we’re going to discover along the way.
The focus should be on getting to the customer as soon as possible to validate ideas end to end and keep adding slices of value. Not predict what’s going to happen in 2-3-5 months time in a “project”. “On time” is often used as a proxy for predictability, but predictability is not about project timelines.
It’s about the predictability of customer value generated over time, and we minimize its downside risk and keep the steady pace by validating our assumptions sooner and discovering the ones we haven’t thought of sooner.
The only way to do that is to poke the system end to end, through delivering thinner slices sooner.