OK, the article title is a little clickbaity; you should never ignore your customers, but certainly the customer is not always right. I find this is true under a number of scenarios, but today I’ve been thinking about Requirements Gathering.
Requirements Gathering is a term used in the IT field when referring to the process of finding out what your customer wants. It’s actually harder than it sounds because there are a number of things that influence the process. Such things include how you handle communication (you might have to hide information that is sensitive or controversial), the personality of the customer (they might be pushy and tell you things that they think you should do, rather than what they need), the capabilities of the customer, etc.
There are a number of other factors and this is a big subject, but it’s actually the last one on the above list that I’d like to talk about in this article: how the capabilities of a customer affect the Requirements Gathering process.
A customer will most likely understand their needs better than you will, however it is unlikely that they know the best way to service those needs, otherwise they wouldn’t need you, right? Given this skill vs knowledge difference, it’s often easier to learn the customers requirements than it is to have the customer tell you what they need or how you should present your service to them. Though at this point it’s worth re-emphasizing my earlier point that you should never ignore the customer. Work with them on this process and have them test and sign off at each iterative stage.
Let’s explore an example to illustrate the idea. Say you have a knowledge base system and the customer wants a report to get some specific information to do a task that’s part of their job. Certainly that’s a requirement/deliverable right there that needs to be satisfied. You could expediently satisfy that by creating a report for the user, but then they might come back next month and ask for the same report. Not a big deal, but if you have lots of customers wanting these reports, it would be better if the user can create the report themselves.
What happens if next time the user comes back and wants to report on something different? They’ll probably like how they can create their own report on the first type of data and request that you make the facility for them to pull a report on the other type of data they need. As they’re not capable of making their own knowledge base system, it makes sense that they couldn’t imagine that it could be possible for you to make a reporting system that enables them to make their own custom reports and report on anything that they want.
A better approach might have been to discuss the possibilities with them and involve them in the design process a little bit. Of course it’s in people’s nature to ask for the world, so make sure that you talk to a number of customers and scope the demand for the work to see if it’s worthwhile and confirm it’s the best approach and best bang for your buck in effort, when compared to other work you could be doing.
