INTERVIEWING USERS—TIPS

• Prepare to interview users by reading background documentation first.
• To reduce conflicts, identify user groups and ask the client to select official user representatives/subject matter experts who are authorized to speak for all the users they represent and who have current, working knowledge of the area to be discussed.
• Generate a written list of questions to help you interview. Provide them in advance so the interviewees can prepare. Information needed depends on the system, but some information to find out from users might include:
• What are the user types, their required skills?
• What work do they do; what do they authorize?
• What problems and irritations they have doing the work?
• What are the work cycles and timing; how often something is done and how long it takes; what is the criticality of its timing?
• What is the sequence of work steps or processing? (In addition to ensuring the system performs the work correctly, this information can affect project planning if the system will be made operational in stages.)
• What is the work product at the conclusion of each step? (In addition to tangible items, decisions, approvals, completed reviews, and other intellectual outputs are also work products.)
• Where is the work is performed?
• What organizational goals and objectives, legal requirements, or other needs does the work support?
• How the work is performed (don't assume it is done the same way you know from another organization)?
• What information is required to do the work; what are the sources?
• What parts of the work tend to change and how often they change?
• What the outcomes of the work are (decisions, reports, items, etc.)
• Is there any information that was missed by your questions?
• Watch for areas in the business process that use subjective decision-making. You will need to work with users or their management to clarify policy if this activity will be automated. Delays in agreement on the policy often occur and can stall your effort.
• Users may present a requirement as a solution. Find out why they want this solution by asking "what" that solution provides or does. Asking "why" makes it sound as if their request must be justified to you. More discussion and examples of avoiding unnecessary solutions in requirements.

  After much work had been done on the database, a user said the system must use the same ID for two different, but related accounts. The DBA clutched her heart. The analyst asked what that did (why was this needed). What the user really wanted was to associate one account with the other. The DBA recovered: the true requirement had already been met.

• Users resent being told the information they are providing is not needed. If the information is relevant to the topic, but too detailed for the current discussion, ask if you can return for that information later. Be sure to put in your notes that additional detail is available and from whom so you can come back for it without having to ask who has it.
• Requesting the same information over and over indicates incompetence. Users will complain to their management about this because it keeps them from doing their real work, and it will come back to you. Establish and index a library of documents that have been provided. Put meeting notes and minutes in the library. Ideally this will be an electronic repository so it can be used by the entire team. Do not go to users for information until you have checked the repository. Keep track of hardcopy documents, also.
• If possible, assign one analyst to take notes while another interviews. Keep track of issues and unresolved items during the meeting, get concurrence on notes taken during the meeting before the meeting ends. Reserve time to read notes back. It works better than distributing notes for comment after the meeting. People forget or try to insert agendas when no one else is there to object. You will also clear up misunderstandings while the subject is still fresh in everyone's mind. Assign/get volunteers to resolve issues. Obtain user prioritization of the requirements. Provide everyone with written notes from the meeting within a couple of days after the meeting.
• Remember, it isn't the users' job to tell you what kind of technology they need. If you want to know what kind of technical capabilities they might like, be prepared to give them examples.
• Try to see the work performed. Get copies of forms, outputs, and information used in the work, including help sheets and notes posted by the users at their desks.
• Identify all parties who will use the requirements (for example, testers, designers, architects). All of them, along with the users/subject matter experts, are responsible for reviewing the requirements and approving them. The formal review and sign-off may require additional revisions before the requirements can be baselined. Resolve requirements conflicts by prioritization, additional clarification of the requirements, and negotiations with affected parties. During negotiations, have everyone explain their roles to the other parties so all gain perspective on the effects of the requirement. More than one meeting may be required.
• In establishing responsiblities for the various reviewers, remember that approval of the requirements for baselining is not necessarily approval for implementation. Determining if a requirement should be scheduled for implemention is based on priority, cost, and other considerations. The decision is usually made by a project sponsor or project manager.

Read articles on requirements analysis, including handling requirements changes from stakeholders.