Avoiding trouble

Following post could be seen absolutely obvious mechanism to avoid unnecessary trouble in development process. But it was something new for me when several years ago I've firstly read it from the long term oracle-l list ex member Rachel Carmichael (unfortunately I've lost this e-mail) and now I've seen it is something new for many developers. In one sentence it is:
Inform your boss (customer, colleague or other responsible person) about possible trouble in a written and provable way.
OK now let's explain a bit more. There are three steps in this process:
1) Understand possibility for eventual trouble;
2) Fight for your right decision;
3) If you lost the battle inform responsible person about it explaining why you think there is possibility for trouble.
Let's see what each of these steps mean.

Understand possibility for eventual trouble

Here is the trickiest part. The first tricky thing is to understand that there might be possible trouble. Of course that comes with experience ;) Probably the first time you'll miss the eventual trouble but next time you'll be already smarter. The second tricky thing is to avoid never ending wretch syndrome. And here of course the main factor is your common sense - decide when to warn responsible person and when to not use false warnings.

Fight for your right decision

Almost always there is a possibility to fight for your decision. Of course here is also one tricky thing - you have to explain and motivate your decision. You can enforce your decision with test cases, examples, resources from books, Internet etc. You can find supporters among your colleagues and sometimes even usual opponents. Even if you'll loose at least you'll have clear conscience :)

Inform responsible person about it

This is the easy part. If you have decided that you should warn anybody then most of the time there is no need to seek for a notary. Usually a simple e-mail saved in your sent mails will be enough. You can of course consider possibility to add some more recipients to TO: or CC: fields. If it is a meeting protocol with customer a footnote with warning can be a solution. Of course if the possible consequences are quite serious you have to ensure that your insurance is at least as serious. One thing of course remains - the motivation has to be kept. Also in your written email, meeting protocol or whatever else.

The result

With above mentioned mechanism you've got two points:
1) Once again informed about your decision.
It might be possible that your boss simply missed your viewpoint. Probably he thought you are not serious enough. Probably he misunderstood you. Written text with appropriate explanation and motivation decrease such probability to the minimum.
2) Cover your a$$ (sorry for that expression but I couldn't resist :) in case of failure.
You will be able to point to your written message and say - I already warned you. Without it there are always place for different interpretations. Even the most ordinary thing - your boss probably simply fairly and honestly forgot about your warnings. With such cover even if you need to clean up the mess you won't pay for it. Your boss, your customer or whatever else responsible party being warned will pay for it.

Have I used that?

Yes, I have. I was lucky enough to have knowing and smart bosses till now so I haven't necessity to use such scenario (3rd step) inside my company. Either I could convince my bosses or the problem was out of my responsibility. But in communication with customers I've used this technique quite much along with catching their bad requirements. Sometimes that convinced them at last change their minds, sometimes not, but at least I and my company had very strong argument in case of failure.

Unrealistic optimism or just pure stupidity?

A while ago I've written a blog entry Where bad performance starts explaining that we as IT professionals should prevent customers from stupid requirements or at least strongly warn them that their desires will make much harder life both for customers and developers.

Some days ago I've spotted a nice estimate of a work task that takes the problem described above to the next level i.e. the core of problem is initiated even before the real project begins. Task was much bigger containing of many subtasks including:
1) three separated subtasks for three different reports. Each report was quite precisely explained;
2) a task formulated as follows: "Up to 20 reports defined more accurately in analysis phase". No more information was supplied, no more information was known to anyone.

So how do you think - what were the estimates for analysis and implementation? According to estimate analysis of each separated report should take 1, 2 and 3 workdays. Implementation estimate of each of them was 2, 3.5 and 3.5 workdays. And now the most interesting part: analysis and implementation of up to 20 unknown reports was estimated 15 days for analysis and 20 days for implementation.

So for known and quite precisely defined reports the average analysis and implementation work was estimated 2 and 3 days respectively for each report. BUT for completely unknown reports without any further information and/or restriction estimate was 0.75 days for analysis and 1 day for implementation.
BAHHH!
So what to think? What was thinking both analyst and programmer making such estimates? What was thinking PM allowing such estimates to be published and giving them to customer?Are they afraid of big numbers? Why are they being so optimistic? It is a real mystery...
I'd be afraid to give any estimate for such purely defined task at all. And if I'd give I'd take at least average or even probably maximum of other similar tasks and also warn my boss about quite big risk to give estimates of unknown tasks. Probably I've seen too much projects fail or at least delay due to overly optimistic estimates...