Join Haydn Thomas for an in-depth discussion in this video Interviewing to gather requirements, part of Business Analysis Foundations.
- We have all been to a job interview or seen a talk show chat where host asks questions, and we await the answers before making our assessment. With user involvement being cited as one of the top three reasons for project success, interviewing provides users the opportunity to get involved in the project by providing detailed information, and in doing so deliver better quality requirements. Analysts often forget that in the interview they must maintain a questioning, learning, investigative attitude, instead of jumping to a solution.
We want to learn more about the actual problem or opportunity, and about the people who make it work in the real world, we are fact finding. Structuring the interview process is important in building rapport, understanding and instilling trust with the user. Firstly we need to prepare and schedule the interview. Send out a meeting request with a defined purpose, agenda, and any supporting material that'll assist in eliciting requirements from the interview. Secondly, capture requirements.
The use of questioning techniques reign in this area, using questions, helping us gain information, and using the following four questioning techniques will help gain a full understanding of what is going on. Starting with open questions, always start with an open ended question. These questions begin with who, what, when, where, why, and how, and used to get people talking and providing information. For example, someone might say, "What is the main reason behind "wanting to make this change?" "Who else would be involved?" They're always trying to use how questions last, to prevent delving too early into a solution.
Next, move onto closed questions. Use these questions when clarifying information and asking for preferences, such as would you prefer A or B, if this of high or low importance? Factual questions are used to gain specific information like how many widgets are produced an hour, how many concurrent logins are required, and finally uncovering pain points, concerns and impacts are sourced through the use of emotional questions. For example, tell me about the last time you were frustrated with the current process.
While asking questions is a very powerful way to elicit information, next you need to be listening for requirements to capture. Once you've asked a question be quiet and listen. Do not be afraid of silence. This time lets the user think and answer the question you posed. Ask only one question at a time. Also, listen with your eyes and watch facial expressions and body language. Using eye contact, body language, and watch for nonverbal cues such as nodding of the head in agreement or disagreement is active listening, and shows you are interested and engaged.
Learn to listen completely. Listen without judgment or criticism. The reason we are doing all this is to gather their requirements. During the interview process requirements come in two forms, explicit and implied. Explicit requirements are the easiest to hear. The user is very specific about their need or suggestion for improvement. Such as, "I need to achieve a throughput "of 50 widgets a minute" or, "Our service must comply to ISO standard XYZ, "Section 15, clause 4.2." As opposed to implied requirements, these are raised as a complaint or frustration relayed by users that imply a requirement.
For example, "Why do I have to enter all the vendor "information in again if it's already stored elsewhere? "Surely there is a more productive way." By listening to these emotional responses, asking factual questions, and closed questions will help create a stakeholder requirement. Such as, "The user (sales support) requests "a customer lookup function, "based on the vendor's trading name, "to retrieve vendor information "already stored in the ABC system, "including Name, Address, Delivery Details, "and populate these details in the "Sales System for all new orders." This requirement has now been transformed into an explicit requirement, and ensures that you're specific, measureable, achievable, realistic, and traceable.
Finally, the information gathered during the interview should be captured immediately and validated with the user. Do not rely on your memory, even the best analysts need a little assistance remembering the key points. Having the user verify what you have interpreted enables the refinement process to capture issues and redefinitions earlier in the project lifecycle, and provides the analyst with a better understanding of what is important and why they are necessary. A good analyst asks insightful questions, and listens for requests, needs, concerns, comments, suggestions, ideas, thoughts, guidelines, issues, rules, and metrics to develop a list of potential requirements.
Next time you're gathering requirements through the interviewing process what technique will you be perfecting to capture quality requirements?
Discover where business analysis lives in the project life cycle, how to initiate a project, the best way to gather requirements, and smart strategies to monitor results and test outcomes.
Lynda.com is a PMI Registered Education Provider. This course qualifies for professional development units (PDUs). To view the activity and PDU details for this course, click here.
The PMI Registered Education Provider logo is a registered mark of the Project Management Institute, Inc.
- Understanding what business analysts do
- Defining business opportunities and objectives
- Identifying stakeholders
- Gathering requirements through observation and brainstorming
- Validating requirements
- Developing project acceptance criteria
- Implementing, testing, and closing your project<br><br>
- The PMI Registered Education Provider logo is a registered mark of the Project Management Institute, Inc.