Let's take a look at the workshop requirements technique. This one and the interview technique are probably the two most popular techniques used for requirements. elicitation requirement workshops are structurally facilitated requirement meetings that are formal sessions that involve multiple groups, and you'll sometimes hear those referred to as Jad sessions. Jad stands for joint application development. The idea of these sessions is to get every group from every area and application in a room together, including developers for a certain number of hours or even days and elicit the requirements for the entire project. This can be more productive than having requirements meetings with individual groups because when you have separate meetings, you run more risk of having conflicting requirements that don't get resolved right away because you don't have all involved parties in the room.

Workshops can also be used to refine requirements, do quality checks and reach closure on requirements. So some benefits of the workshop sessions are they're effective at getting real requirements rather than perceived requirements. They can neutralize a predominant voice by creating ground rules for discussion and decision making. So everybody in the room gets the opportunity to speak and give their opinion on things rather than there being one strong person that is always kind of listened to and the others aren't getting to share their opinions on things. There is a greater chance of obtaining consensus because stakeholders are presented with the issues and questions at the same time, right so everybody's hearing everything at the same time. Feedback is immediate interpretation of the information you're getting is documented for immediate stakeholder confirmation.

Always make sure that for example, if there is a three day workshop, at the end of each day, I'm documenting what came out of that day. I'm sending it out. And then the next morning before we start the meeting, the first thing we do at the beginning of the meeting is to go over the information from the day before. So that way I'm able to get immediate feedback on any of the notes that I took. In case there's anything that I misinterpreted, you're also able to successfully get the requirements from a large group in a short period of time, right? You can get people in a room together for a few days, and get requirements that otherwise would take you weeks to do and documentation is completed within hours of the session.

Like I said, I would do it that day of and provided quickly to participants for their review. It's an excellent way of being able to quickly get a handle on the requirements for the project. some disadvantages of workshops, right anytime there's something good there's always something not so Good to consider, right? So disadvantages of workshops are things like the difficulty in getting appropriate stakeholders in one room at the same time. There are an increased number of global projects that pose logistics difficulties and adds complexity. So if you're working with people in multiple areas that can be difficult to do when you're talking about, you know, crossing country borders and things like that success of the session is highly dependent on the expertise of the facilitator.

So if you are not an experienced a meeting facilitator, then it may not go as well as it should. And they can also be expensive, right? Because you're bringing people in so there's travel expenses and things like that too, and taking people away from their jobs for X number of days. So those are things that need to be considered as well when determining if the workshop is the way to go. Let's look at some rules for workshops. You want to be clear on what the session will do.

Deliver. Some common topics for workshop discussions include things like events, actors, and a process for gathering requirements. So let's talk about events. in software development and event is defined as something that causes change in the environment that the proposed business solution must respond to a time related example would be, jobs need to be kicked off at midnight, payroll executed every other Friday. Some other things could be like request related things for events, people request cash from an ATM. The user presses submit on an enterprise portal, a satellite receives a transmission from Mission Control.

Those are things that fall under that event category. Some examples of things that fall under the actor category because remember, an actor can be a system or a person that is interacting with the proposal. So when you think about it in that way, a people act for example could be soldiers interacting with equipment. The public requesting information from an agency enterprise portal, senior executives requesting financial analytical reports any of those three could be people actor examples. Some system actor examples would be things like an interface to dependent systems such as payroll, pulling active employees from the HR system, or an online payment acceptance systems requesting and receiving a credit card authorization. So those are some examples of events and actors that could be discussion topics for workshops.

And the other thing to discuss in the workshop is the actual process for gathering requirements. So either a business process flow or a structured development process needs to be determined, and that should be talked about in the workshop about how you're going to go about gathering the requirements and then walking through that process, right? Are we looking at a process flow? Or are we looking at a more structured kind of process for that, and then sticking to that as you're going through the workshop. So let's look at some possible participants for Jad sessions so that if you're doing a workshop, and you need to make sure that you have everybody there that needs to be there. These could be some areas for you to consider whether or not you need to have representation from them in your session.

Business Process owners, which I would say should always be in the session, operations managers, client representatives, business analysts, business managers, end users, data administrators, system analysts, system designers, advisors and project leaders, auditors, security people, standards people, vendors, especially if you purchasing an off the shelf type of software you want them involved in the session. Quality Assurance, contingency planners, production planners, IT specialists, human resource representatives and trainers are all areas that you'd consider Do you need somebody there doesn't mean that you always need somebody there from office areas, but they are areas for you to consider and think about to make the decision about do you need someone from there? The executive sponsor is somebody that should always be included in your sessions. So, management commitment is really required for any needs or requirements gathering process to succeed. It doesn't matter how you're doing it. And it's very important for the Jad session team to have a management sponsor.

The executive sponsor can be a manager of the business area whose needs and requirements are being addressed during the Jad session. The sponsor does not have to actively participate in every Jad session. But their support of the project needs to be clear. So it might be advisable to have them attend the first Jad session to show support, and then the final Jad session to review the results and make comments. So if you're having one long session, right with maybe a three day or four day session, then you would want them there on the first day and on the last day, the sponsor should be available throughout the period of the Jad process so that they can solve any serious problems or issues that come up. And you as the facilitator, most likely you'll be the facilitator of the meeting will need to work closely with that management sponsor, and you want to make sure that you're providing them full briefings on the progress being made during the Jad session.

So if you're doing those reports, every day those meeting minutes and you're sending them out, you want to make sure they're included in that as well. Obviously, the business analyst who is probably also acting as the facilitator should also always be included in the session. The facilitator is the key person In the group and is responsible for planning, executing and managing the session, that person needs to be respectful. And they need to be a skillful leader with a good reputation within the organization, right, because you want the facilitator to be somebody that's being taken seriously. So if you don't fit that role, somebody else needs to be the facilitator. The choice of a facilitator can mean the difference really between a good session and a poor one.

So you need to look at that objectively and look at it from the point of view of the project. If you are not the right person to be the facilitator. It's okay to be the BA on the project and to be asking questions during the meeting, but allow somebody else to be the facilitator of the meeting. Jeff, the facilitator skills do not just happen by chance. And if you haven't learned them through specialized training and experience, then you just may not be the right person for that particular Jad session at that particular time. It's essential that the facilitator be given authority to work closely with the executive sponsor to achieve the objectives of the Jad session.

This is not the time for you as a facilitator to think, oh, they're the executive sponsor, it's too high up for me to talk to their VP or you know, a CEO or CIO and you feel intimidated by their title. This is not the time for that you can't let yourself be intimidated by executives simply because of their title. Remember that you are an extremely important piece of the project. And you play a critical role in project success. So it doesn't matter who it is that you're talking to. As far as what title they have goes, the focus should be on what do we need to discuss and what needs to be done in order for this project to be successful?

The facilitator is going to know how to direct people to be able to get to the best information, and jazz facilitators should be able to focus on the process, not the information content. To the Jad session, they should be unbiased and neutral and remain impartial. It's important that the reporting structure is such that the facilitator can't be influenced or biased. So you don't want it to be a situation where you feel like you can't say what you need to say because of who's in the room. Use organizational skills to lead groups and keep the sessions on track. Ensure that each subject under discussion is accurately recorded and completed to the stakeholder satisfaction before you proceed to the next topic.

And stop a sideline conversations you've got to be able to keep that meeting on track, especially if you have 20 people in the room. You don't want there to be 10 conversations going on at the same time. So you've got to be comfortable with putting a stop to that when it starts happening. The recorder is the person that is responsible for documenting the Jad session that has to be done in an interactive fashion and the recorder must work closely with the facilitator. Many ideas and suggestions are going to be discussed a large session meaning multiple recorders, right multiple people taking notes. The recorder must capture the important discussion and decisions being made and who made them and why.

Laptop computers, whiteboards, flip charts, and overhead devices are things that you can use as part of that recording of information. It's the responsibility of the recorder to distribute and file the documentation at the end of the Jad session, or as soon as possible after that, right. We talked about that before. It can be a difficult task, and it should not be underestimated. You may find yourself as both the facilitator and the recorder I have been in my Jad sessions, if so, make sure that you're also asking someone else to take notes as well, so that you can combine them to help ensure you haven't missed anything since you're also facilitating the discussion. It just makes sense that you're going to be So involved in some of the discussions that you actually forget to take notes.

So you want somebody else to also be taking notes so that you can minimize the content that gets missed. The recorder needs to have the following skills, knowledge of the stakeholder business area. So in order to record the results properly, they need to understand the concepts of what's being discussed. It can't be, you know, literally somebody pulled in off the street has to be somebody that understands the business area. They also have to have excellent analytical skills, they need to be able to analyze what's being discussed and presented in the Jad sessions. And they need to be experienced with any Jad tools if they're being used, and have good technical writing skills.

The tool that's being used, I just want to say can simply just be Microsoft Word or some other word processing software, it can be whiteboards, it can be, you know, a case tool, whatever the tool is, that is being used doesn't have to be an official Jad tool, but even if you using Microsoft Word, it's a tool, right? So whoever's doing the recording has to have knowledge and be able to use it effectively. stakeholders and business sponsors, of course, should always be included. I don't think there's anybody that doesn't think that it's necessary to have them there, right. That's who you're getting the information from. Without their involvement, the Jad session isn't going to be productive.

The whole point of it is to bring stakeholder and performing organizations together in a structured environment. So obviously, they need to be there. In order to make that happen. Stakeholders will rapidly gain a sense of involvement and ownership in the project or service development when there is a Jad session used. And this is vital to the overall success of the project. Most important, the stakeholders will get the product they want, and not one that has been designed poorly for them because we didn't understand completely the requirements.

So some tips for successful workshops. Create a plan to address known project challenges that have prevented project success in the past. The session is led by trained facilitator, again trained, trained, trained, and assisted by a scribe whose role is to document the workshop results. Participants include users, developers, me's and senior managers. Users can be individuals who are authorized to speak for the business or mission domain and who can make binding decisions for the project. Developers are key individuals responsible for design, construction and test of the solution who can provide high level architecture answers that speak to the technical feasibility of implementing requirements so they can tell you if you're way off track in the meeting about whether or not being able to technically do something right if it's technically possible for some of the things that's being discussed, to me, the subject matter experts of course, our process or technology experts who are able to provide immediate process economic or technical feasibility assessments to resolve any meeting conflicts or roadblocks that come up so you can have some ease on both the business side and the technical side.

Senior managers are individuals with the authority to commit organizational funds, and make real time binding vision and direction decisions or trade offs during the meeting. So it might be that there's a conversation that needs to be had to say, well, it doesn't look like this is possible. We've got this option and this option, we need somebody to be able to make the decision. Let's go with that option. You want to limit the meeting to key project participants. If project participants cannot be limited, then you may need to look and see if either the project scope or the meeting agenda is not sized correctly.

Workshops can be valuable for most projects. We want to look again at tailoring workshops just like we looked at tailoring surveys. So you Should scale the workshop activities to the project environment. If you have a small project with low risk, then that's really better handled within formal working sessions. moderately complex projects that have some risk are best handled with formal meetings that have predefined deliverables. And large complex products with high risk should use formal meetings with budgets and timelines for securing stakeholder approval on predefined deliverables.

So a large complex project you may end up with a Jad session with 40 people in it. That's an example of that. A moderately complex one may have 10 or 20 people. A small project you may only have five, but it's still a workshop, and it should still be considered as such, and still follow the same rules and guidelines.