>>We have a slightly different approach. For customized software (so if there is any code that is done specifically for the client) they have to continue with the "Maintenance Contract". As long as they pay the yearly fee, we provide the service they need, and we ensure that employees are trained
>
>Here's an interesting point: how many times do you train the workers? (I hate the politically rectified "employee" - are they there just to suffer the employment or to get some work done?)
>
>In today's rat-race workplace, many clients tend to run a high turnover workforce. Whatever you taught them pretty much evaporates in a couple of years, which is my estimate for the time when 50% of the workers there have been replaced. The newbies have never seen your app, and whatever you did to accommodate their needs may now be worthless, as the people who asked for certain features are now gone, and the newbies don't even know how to use them.
>
>In the early nineties I had a case where in the morning I installed a feature they were screaming for, and got a first support call just as I arrived back at the office. Why? Second shift didn't have a clue about it.
>
>Now if people who work in the same office, just at different times of day (and they did reshuffle a lot and switched shifts frequently and they all knew each other) didn't even tell the other shift about a new feature in software they use all day, imagine how much information gets passed from those who are leaving (voluntarily or not, gruntled or dis-) to those who come to replace them.
>
>I even had some customers where I knew more of their history than their current staff did.

It's rare when we don't know more about what goes on at a client than most of the staff.
You can thank Henry Ford and his division of labor idea. It works well, but we often find people at a client who don't know what someone at the next desk is doing.
Systems people usually see a broader cross section of the business.