When I’m working with customers to select systems or when I’m working with a system that I am implementing for a customer, the one thing that really bugs me are what I sometimes call “non-features.”
Non-features are those items that are listed as features but which do next to nothing. They are those items that are merely some screens and possibly some dropdown boxes, but which provide no actual functionality.
I sympathize with software vendors who say that they are providing something that is very basic because everyone wants something different and, this way, everyone can “configure” what they want. And we all then write a LOT of code to get it to do ANYTHING! While I agree with the problem, I disagree with the solution. Coming up with an item that provides no actual features and using it as a way to convince people that the functionality is somehow handled just dumps the problem on the implementer.
Product Selection Versus Implementation
When I am working with customers to select software, this is an issue only because it is just one more piece of noise for us to filter out. Customers are used to the fact that software sounds much more promising on paper than it ever really is when you apply its functionality. Thus, they are easily dissuaded that they should not become too attached to the responses they receive from software vendors on any paticular piece of functionality.
The real problem comes in implementation. By the time I come onto the scene with a customer to implement a piece of software, the customer is already entrenched with the mindset that the software they chose does whatever it is that they were told it does. In the cases where they have a feature that is really not a feature, their expectation is that they can just start using it. They do not necessarily react well to my suggestion that they need to spend time defining requirements for it, nor that implementing the item will take significant calendar time and money. In these cases, I sometimes find it my job to “unsell” the item, due to time and budget constraints, ending in the customer sometimes not getting that feature, at all.
Those people who implement systems who are reading this know what I mean. It is a problem with the gap between the sales and customer expectations created at the beginning of the project, and in the ugly light of daylight that shows every flaw in the product. What we probably all also know is that this problem is one we’ve always dealt with and won’t go away. All we can do in this is do our best to show customers the gap.
Gloria Metrick
GeoMetrick Enterprises
http://www.GeoMetrick.com/