I’ll admit that the IT world has a little bit of a bad reputation. We are known for being stubborn, unavailable, arrogant, and sometimes, downright surly. But I think I can explain some of why IT folks don’t always play nice.
When you hire someone to mow your lawn, you come to an agreement with that person – for a set price, s/he will mow your lawn, probably trim around the trees and flower beds, and pick up the grass clippings. If you want something extra done, such as a flower bed planted with new flowers, you create a new agreement with the landscaper and an additional price is decided upon.
When you purchase a software product, you usually purchase a defined, packaged software product shared by many companies and users. If it’s a custom software package, a Scope of Work is written, and the specifications and price are agreed upon.
So, the customer has purchased a software package, and starts using it. The trouble begins when the customer will come up with a list of features/ functionality that s/he felt “should” have been in the software package purchased, regardless of the software specifications agreed upon.
“Well, I don’t understand why I can’t export reports into pipe-delimited format.” Nevermind that there are 14 other formats to choose from.
“Why doesn’t this application, by default, require the supervisor’s phone number, address, and email when asking for work history?” (It doesn’t matter that requiring that information drastically increases the number of incomplete applications.)
“Our organizational structure is division, then business unit, then location, all co-mingled so that a location can be in multiples of each and sometimes a business unit is subordinate to a location and sometimes it’s the other way around. Why doesn’t your application support that?” Huh?
I can understand that questions will arise as a user starts using a new product. That’s not a problem. The problem is when the customer berates support staff because a software package doesn’t include all of their various “needs”. I understand that business needs may require functionality different than the norm. OK. Then let’s design and agree upon new functionality that will meet your needs. And yes, it will cost extra.
IT folks get surly when they get brow-beaten by those who think the application “should have feature x as a standard feature.” A feature in a software package requires time to build. IT time is worth something – it is valuable. Yes, software should be upgraded frequently, and good software companies listen to their users when planning the next release, but when you buy a stock software package, you buy that package, you aren’t buying a programmer in your pocket for the next 10 years.
You wouldn’t ask your landscaper to weed the garden bed for free, would you? We just want to be treated as nicely as the landscaper.