I think the BA needs some foundation in the underlying business process to ensure that quality questions are posed to the users in those meetings and to help everyone remember details about the existing process that they may not otherwise remember when sitting in a conference room. Those details are sometimes the difference between getting the requirements right or delivering a half-baked solution.
What do the experts say?
In past engagements, the personalities of the individuals attending the session will have significant impact on the success of that session. Strong personalities dominate group sessions and can derail the entire session. Some individuals will choose to remain quiet on certain topics as a result. Ineffective control of the session by the facilitator is perhaps the biggest negative to workshops.
In facilitated sessions, tools that help define and manage requirements details are highly recommended. Capture the understanding of the business flow while you have a room full of business experts. Document the flow in a diagram that readily communicates your understanding of the process just described by the users. Storyboard presentation of the documented business flow is a very useful and worthwhile technique.
If your organization has little experience with peer reviews or one-on-one interviews, then it may be worth a bit of time to investigate the effectiveness of this technique within the organization. Experiment and learn from the many possible activities that drive toward a complete set of requirements. Many times throughout the requirements lifecycle, analysts will attempt five or more defined techniques in order to reach a clear understanding of the business need.
For the typical analyst, it is necessary to align with someone knowledgeable about the workings of the business. How this is accomplished varies greatly. The bottom line is the analyst must understand all he can about the activities and flows of the business processes to effectively communicate this to the design and development organization.
Development methodologies affect interaction with users
An agile approach to software development vs. a traditional waterfall approach will alter the techniques of interacting with users.
In the traditional waterfall methods, the business users and the analysts spend countless hours trying to understand every detail of the business process. For this approach, a long-term product roadmap combined with a thorough requirements documentation practice is necessary. The requirements practice and its defined techniques should align the skills of the analysts with the methods of the software organization.
In a more agile approach, details of the product are uncovered as the system develops. Relationships and record of accomplishment builds the confidence of the user community allowing software development to begin even before the system is fully defined. Workshops have a place in an agile approach but are less common practice than in waterfall methods. Product owners define the path to understanding the needs of the business, and they are often the one guiding and directing the interactions with the business users throughout the requirements elicitation and analysis process. The product owner seeks to uncover as many user stories as possible, which add to the product backlog or business/functional requirements.
In an agile environment, the individuals that participate in the definition of the user stories are similar in title to those in a waterfall environment. The subject matter experts (SMEs) exist in each type of development methodology. How business users and IT interact along with who might be the facilitator is what might change.
Many businesses do not formally document all of the practices they will employ in the software lifecycle. For example, in the requirements lifecycle, it may be acceptable to conduct informal and unplanned peer reviews of requirements. While it is normally good practice to plan and document the results of these types of sessions, good quality requirements is the result you seek! The point here is to align the analyst with the business SME. This may be a formal relationship with scheduled meetings, planned deliverables, and complete and polished requirements details. It may also be informal and be conducted as time permits, working more as a friendship that shares every detail about the business rather than a formal business relationship.
From experience, developing informal relationships and purposely aligning with the business SME is a big step in improving the knowledge within the business. Develop relationships that foster trust and confidence between you and the business. This will go a long way in growing your knowledge, business awareness, and management confidence.
Use the workshops when necessary, but do not restrict your elicitation and analysis to one approach. Use your own initiative to grow your knowledge of the business through the relationships within the user community. Gaining the users' trust and the confidence of your management will promote improved communication for the sake of the business and for the attitudes of both business and IT.