Below are a few simple guidelines for facilitating stakeholder participation in requirements. As with any guidelines, these should be tempered according to the business analysis practitioner, the stakeholders, the effort at hand, and the general environment.
2. Establish meeting guidelines and protocol early on. In addition to promoting a safe environment in which everyone can fulfill their respective roles, having guidelines also helps to keep the meeting on topic. For example, you may tell stakeholders they should not hesitate to ask clarifying questions during the meeting. You may further advise them that questions which cannot be answered right away (or that take the meeting off topic for more than 2 minutes) will be placed on a list for follow up outside of the meeting. If you discuss this approach up front, participants can feel free to ask questions. At the same time they fully expect the business analysis practitioner to rein the discussion back in, if a question takes the group too far off topic.
3. Inform participants of their expected roles. Clearly explain to your stakeholders what it is you expect them to do, in terms of requirements (and specifically with regard to requirements meetings). Reiterate the expected roles at each session, as needed. For example, you may have certain stakeholders who are the subject matter experts responsible to help define an automated process, whereas other stakeholders (perhaps those who manage the areas involved with the process) are expected to review and approve. Establishing, clearly communicating, and reiterating these roles sets the stage to have the process (and supporting requirements) defined by those who have the knowledge and right perspective to do so. It also facilitates approval by those who have the responsibility and proper authority.
4. Display your meeting accomplishments. When meeting with a group of stakeholders it is helpful to display (during the meeting) what is discussed and especially what is decided. Regardless of the specific technique used to later specify requirements (user stories, use cases, process models, statements, etc.), displaying key discussion and decision points during the meeting