The majority of the effort spent by a pre-sales team, sales guys, tech lead, business analyst, quality analyst, designer and developer in a software and web applications development firm is spent looking into and capturing clients’ needs, understanding clients need, executing the clients’ expectations. Hence requirement document is a binding thread and bible for a client and development company relationship. Making sure that the following quote and the image are engraved in every internal stack holders (read employees) mind will help you avoid a lot of pitfalls.
Quote: ”If I had eight hours to chop down a tree, I’d spend six hours sharpening my axe”
- The image may sound comical, but there is truth in it. If not why do we hear horror stories about
- How technology expenses overshoot the budget by an x%?
- How 45% of any application never gets used by the users?
- How a project worth few million failed or went down the drain?
- There is always room for improvement and fine-tune things
Is requirement gathering and requirement elicitation one and the same?
Requirement elicitation is not a common term even amongst people who engage in the process and people confuse one for the other. Even though the end result may be the same, which can be a Software requirement specification document (SRS). The quality of the output and the information unearthed may vary depending upon what is being done. The key difference is, requirement gathering is about collecting requirement from the customer, whereas requirement elicitation is all about collecting expectations, pain points and scope for improvement and requirement, from the end-users perspective.
What are the key techniques used for requirement elicitation?
Requirement elicitation can be done by the following methods
- Interviews
- Questionnaire
- User observations
- Workshops
- Brain torming
- Use cases
- Roleplaying
- Prototyping
The questionnaire, use cases and prototyping are the most effective engagement when it comes to engaging with clients who are trying to outsource the project to a service provider in a different location (where face-to-face interaction is not possible).
What is the role of the client in requirement elicitation?
- Going back to the image, the client plays a role which is depicted by the statement “what the customer explains” and “what the customer really needed”. The customer’s need is more a feeling/conceptual, than real requirement. Hence a certain level of paperwork and thinking through is essential from the customer before calling in service providers to reply to the RFQ.
- The customer should have spoken to the users or provide an opportunity for the service provider to speak to the users. This will enable the customer to get a holistic view of the requirement and share the same. If it is a brand new initiative or startup venture, then the customer should brainstorm with the service provider and think through from the shoes of all the users.
- Be clear about your budget and timeline expectations. It is very important that you get a grip of the fact that something built fast or cheap, may not be good and something that needs to be good cannot be built fast or cheap.
- The requirement once finalized should be adhered to with a single mindedness. As quoted earlier, sharpen your axe as much as you want, but once the cutting begins don’t stop.
- Don’t ignore the service provider’s questions and interest in getting to know more about your need, if they are relevant. They are trying to be a consultant and are trying to give you suggestions. Hence asking for the reason behind the questions is a good option, than ignoring the questions.
What is the role of the service provider in requirement elicitation?
- Be clear about your methodology and have a standard workflow for requirement elicitation. This will help the service provider to cover all things and collect requirements in a professional manner.
- Be relevant and specific. Generic or unexplained questions during elicitation will only frustrate the customer.
- Document the information gathered and share it with the client in short intervals, this is to make sure that the customer is aware of the progress made and can also revisit his expectations.
- Get the timeline and budget expectations as early as possible. This will help you to consult better. Also setting the right expectations by giving a perspective of the time and cost is vital.
- Get as many internal stack holder involved as possible, at least one stack holder from outside of sales is essential. This will help the service provider to look at things from a technical perspective and also give suggestions that are technically feasible and can fit the timeline.
- Get to know the clients business, either from a high level or build domain expertise.
