In software world when we are asked to provide an estimate project, it often happens that the first estimate that we provide – our “first try” – is “rejected”: we are asked to revise the estimate, and often it is in the form of “Your estimate is quite large, don’t you think we could deliver sooner…?” It is often stated more implicitely than that, but it is the general meaning.
When we hear this, we understand that we need to revise the estimate so that the project can be delivered on a given date. Sometimes we can guess what would be a “good” end date even if it is not said explicitly.
With that in mind, we always find a way to hit this date…in our estimates. We add 2 or 3 developers, we reduce a little the duration of some tasks, and we finally produce an estimate that satisfies everybody. We then know that the deadline that was implicitely stated was the true deadline.
Surprisingly, during the project, if the team needs to do overtime during a certain time, or add one developer to meet the deadline, or adapt the scope, we are seen as a good project manager: we were able to raise the alarm in due time, and propose efficient measures to maintain the project on track.
The customer, after some hesitations, will accept to add some budget, or cut on some features, so that the project can be delivered on time.
This proves that it was implicitely acknowledged since the beginning that ourestimate was not very accurate, and was just made to agree on the implicit deadline.
This reasoning is based on my experience, and is at the basis of this reflexion: when we are asked to provide an estimate, we are implicitely asked to set the right deadline, that was in fact suggested to us. Then, when this is done, we are allowed to make all necessary adjustments during the project life to meet this deadline.
Sometimes we finally hit the deadline with just some overtime during the project. In most cases we achieve the deadline but with additional budget or scope adaptation. In the best cases, we are seen as wise projects managers who were able to propose adequate compromises during the project life. In the worst case, the verdict is given: “You underestimated”.
But as I will explain in my very next blog post, all this belongs to the past, because in today’s software projects we must replace deadlines by “ASAP!”, if we want projects to live.