By By R/DV/RS, Some Rights Reserved

Every time I hear of a big IT projects, with a big RFP, with a big upfront multi-months/years analysis … I think of what happened to my friend Gianmarco some years ago.

He bought a house. The house was already partially built when he bought it (quite common in Italy). As soon as he bought it, he had some choices to make like: where do you want the light switch in the kitchen?
Yes because in the contract the constructor left some flexibility in the form of multiple choices on some things:  in this way he can manage some of the changes the owner will need.
Now the problem is that Gianmarco wanted the light switch in a position and of a type that was not part of the options so … he had to pay an extra something (Change Request) and he did it ’cause it was his house, his dream.
As soon as he had time, so many things to do!!!, he went to the furniture maker who designed a great solution but … unfortunately they discovered the new position of the light switch was not good at all. Unfortunately the work to move the switch was already done and so some more money where need for another Change Request.
So two choices: have a ‘not such great solution’ or .. pay another something.
As it was his new house, Gianmarco decided to pay again.
That was a great period for Gianmarco as, few months before moving to the new house, his wife discovered to be pregnant! Great news!
The baby was born few weeks after they moved to the new house and quickly they discovered that this unexpected ‘event’ was not compatible with the brand new kitchen: there was no big table or proper position where to ‘sit’ him and have him under the watchful eye of his parents. So??? Another Change Request :)
Now, going back to my IT projects I have a question: why do we, as IT people, learn from the wrong examples?
PierG