Of palm trees and project life cycles

A couple of days ago, my project mates and I had a rather hilarious discussion about project life cycles.

We were returning back to office after lunch when someone started cursing about the time frame he was given to complete his module. He said that the estimated time was much less compared to the actual effort. He then asked another person about the basis of estimation, how it was done and the like.

The other person, a module lead, came up with an interesting analogy. "Look at that palm tree in the distance? The task is to climb it. From over here, you'll have to say whether you can climb it, and the time needed for it. That's the L1 (level 1) estimate. Of course when you get closer to the tree, you realise that climbing it was a tougher proposition that you thought it was. So you give a revised, more detailed estimate... and that's L2."

"After the client agrees to your estimate, or in most cases, to 20% of it, you start climbing the tree... fall down, start climbing again and somehow finally make it to the top of the tree. That's coding and rework. Of course, now comes the testing and quality assurance (QA) stage. QA is damn clumsy and they know nothing. So you'll have to get down and carry them on your shoulder back to the tree top. They then taste the fruit, and considering that we've helped them, say that the fruit could have tasted better. That's testing and bug-raising. You get what I say, don't you?" ended he.

Another module lead ended the analogy by saying, "And after all this happens, the fruit is presented to the client. He takes one look at it and says, 'Hey, this is okay, but I don't think I want this fruit. Can you get me a mango?' That's a Change Request!"

Welcome to the world of software!