When will it be done?
– You say estimates; I hear deadlines
We all know the system administration rule of thumb about when a task will be done:
Estimate the time it will take you and double it. Then double it again and add some more.
This is not a baseless rule. You know how much it will take you to finish the task. What you cannot predict in this interrupt driven line of work that we do, is how much noise you will have to deal with simultaneously while dealing with the task at hand. Or what unexpected circumstances will unearth because of misinfromation, poor documentation or simply bad luck. So you need breathing space in order to complete the task. For when you give an estimate, users take this as written in stone. When you are of your estimate they view this as a broken promise, regardless of what caused the extra delay. They just do not care. All they care about is that you “promised” it will be ready at some time and it is not. And because they do not care, you always need more time than you think.
Sometimes this also has the added advantage that when you are lucky enough to work uninterrupted and finish within the time frame promised, polite users will thank you for your efforts to complete as fast as you could. They see this as a proof that you care about their pain and do your best. Oh, yes the rest again do not care.
Why was I reminded of this? Well because our DBA hang on his wall the following formula:
Where Tc is time to complete, b is the best time, w is the worst time and m is the most likely time. You can read more about the formula and its history here [pdf].