The Mindset

Are you in control of the projects you manage?

OK. Let’s start again with a simpler question: do you generally estimate the work that has to be done before you commit to a delivery date? Do you make sure you have the required resources and that they are available for your project before saying “I guess I can do that in two months…”?

I am quite sure that some of you are saying “of course!”. However many of you out there probably wonder why bother with estimating the required work if deadlines are being dictated by someone else to begin with.

In many cases, deadlines are in fact being dictated before a real estimation of the work has been done. Why is that a problem? Because, in many of these cases, the considerations for setting these deadlines had nothing to do with the technical and professional challenges that will be part of the project once it starts. If only someone had taken the time to consult the technical staff before setting the deadline, he would have realized that the deadline is not realistic. But no one did, and the deadline was “arbitrarily” set.

So, why indeed bother with estimating the actual work needed?

Reason 1: The Power of Figures

Straight from our Optimistic Desk comes reason number 1: maybe, just maybe, coming up with real solid and reasoned figures will cause whomever it is who set the deadline to change it. If the deadline is not reasonable, and is technically difficult (if not impossible) to meet, someone might come to his senses and provide you with additional time or additional resources. The perfect time to do this will be before the project starts, and not after it is already late.

The fact is that most software projects are late. There are many explanations for why projects do not meet their schedule, but I argue (without any formal research, I admit) that a significant part of these overdue projects are late because their deadline was not realistic to begin with. This, of course, does not stop us from being surprised when such a project misses the deadline.

Being late has a cost: in reputation, in competition and in the quality of the product. Most of this cost does not derive from missing the specific deadline that was set, but rather from the notion of missing a deadline. If the deadline had been realistic to start with, most of the damage would have been prevented.

Coming up with real numbers is stronger that just saying “I need more time than that”. If the other party you are talking to is reasonable, he has no choice but to accept your backed-up-with-numbers argument. Otherwise, you will both find yourselves in a project post-mortem meeting trying to understand what went wrong this time.

Reason 2: Setting Priorities

If this doesn’t work, and the deadline is carved in stone, your work estimate can help you and the person who came up with the deadline assign priorities to different tasks in the project. There is a good chance that not all the features requested, for example, have the same priority. Some might be “nice to have” features, which could be postponed to a later release. If that’s the case, the deadline will remain in place, but the scope of the project will be reduced.

Again, coming up with real data about the required work will not only prove your point, but will also help you figure out what can be achieved in the given time frame.

Reason 3: Improving Your Estimation Skills

If nothing helps, and your estimation still clashes with the given deadline, at least you can have the benefit of improving your estimation skills. Keeping track of your work estimate, and comparing it with the actual work that has been once the project ends, will help you in the estimation of your next project. Maybe in that next project someone will actually come and ask your opinion before setting the deadline…