Stereotypes and Customer Facing in IT

James L. Adams in his book "Conceptual Blockbusting: A Guide to Better Ideas" identifies "stereotypical" blocks, and warns us to stay clear of them. I agree that we shouldn't categorize people based on their race, language, etc. However, there do exist stereotypes in human life, albeit in a different, positive manner.

A stand up comedian in a local village in Punjab is not much different from the people in this list, as far as the basic traits of the profession are concerned. Similarly, a soldier is a soldier no matter what his fighting style, and choice of weapons are. A good fighter is fearless, irrespective of whether he uses nunchucks or katana.

Lately, I have come across some stereotypes in customer facing -- customer as in someone who has to see your final work and point out areas that need improvement before he can accept the delivered product. The most notorious are perfectionists. As Joel Spolsky says ,

the question is not 'X yes or no?' rather 'Is X worth your time?'

I have also come to appreciate the fact that with every piece of software waiting for customer acceptance (usually a phase termed as UAT), there are two types of issues: critical and non-critical. A critical issue is one which you wouldn't debate at all; you as a software developer would also understand the need for that. While for non-critical issues no matter how much the "end-user" would try to convince you of their importance, you would still feel that the end-user is just striving for "ultimate quality"---something which doesn't exist.

Remember, you always need to fix the critical issues. Sooner or later, you have to solve them. The more you procrastinate, the harder it will become to provide a remedy. But for non-critical issues, please read on for some great ideas:

Mavericks: The mavericks I have come across are imbalanced perfectionists. They give high priority to one facet of the project (that could be application response time, for example), while ignoring the trade offs (such as time to market, budgeting requirements, etc.) There is an easy way to handle maverick end-users: engage them in a different debate altogether. If they take out issues from your application response time, give them a network sniffer to play with and they will spend a lot of their time on this new toy without bugging you. Most of the time, if they are the end users, their job descriptions do not demand/ provide them with ample time to fulfill their techie desires.

Blabbering Businessmen: These will talk a lot about "their great ideas" with which your software will become the next big thing after Google. They will repeatedly tell you that without their "important" feedback your software was a piece of crap and you should be thankful to them for making it feature-rich. These guys, almost always, have no knowledge of software and provide feedback based on their domain knowledge only. I don't have any solution for except to come up with a very solid signed scope document to confront them with their "ideas" and reminding them that everything costs money and time. In the long run, engage them in some technical discussion --- hand them over an article on database design; discuss simple concepts like primary keys, and gradually they will come to appreciate the complexity of things you as a software developer are dealing with.

No-Clue Users: These don't have any clue of what they asked for during the requirements gathering phase, and they take an about turn on the requirements during UAT. Unfortunately, the phase where you recognize their style, it's already too late. The only precaution is to involve them very early using prototyping, and following at the least some guidelines of the agile methodologies.