Requirement Workshop - What You Need to Know

In the real world, nothing is ideal, and we do not always have time to prepare for requirement workshops. However, when we do, it helps to create a structure and set clear goals and ideas of what we want to achieve. This preparation can also give us more confidence during the workshop, knowing what deliverables are remaining and giving us a guide on how to proceed.

In the following sections, we’ll cover practical ways to prepare for workshops, including:

• Studying the basic information about the company, stakeholders, and the project


• Researching the current state, solution, and competition


• Studying the materials received from the client


• Exploring similar solutions, external factors, laws, or anything else that can affect the project


• Writing down and organizing all the questions into topics


• Preparing workshop summary template in advance

Homework, what homework?

You are usually assigned to a project when you’re working as an IT business analyst, especially in agile environments. Your task, most often, is to hold requirement workshops to determine business needs and help set the project’s scope. But before jumping in and defining the business needs, you should always know the basic information about the client’s company, stakeholders, and project first, or in other words, do your homework.

When you have a good understanding of companies’ values and the motivation behind the project, you’ll be able to easily manage requirements and have valid arguments about why you think some requirements are necessary or not. On the mind map below, you can find questions you can try and answer as a part of the basic preparation.

Not every question can be answered beforehand; some of them you will need to ask during the workshop, but they are a good starting point.

Write your findings down using a bulleted list, mind map, or, even better, some online collaborative tool such as the Miro board. These online whiteboards are usually simple and flexible, and they let you easily organize, categorize and label the information you gathered. You can also share it with your team as needed. 

The image below shows an example of how the Miro board can be used for this purpose. 

Regarding the stakeholder category mentioned in the mind map (Image 1), writing this down can get tricky if many people are involved in the project, resulting in responsibilities not being clearly defined. If that is the case, try using the RACI matrix, which is a way of organizing responsibilities for each role. You can find more information and examples regarding the RACI matrix online, if needed.

What about the research?

Once you know the basics, you can finally get to the fun part – the requirements. The first step is to assess the current state, and here are some questions to ask to help you do so:

• Is there any documentation available?


• Are there any laws or external factors that might affect the project?


• What is the current business process?


• Is there a prototype or an existing design?


• Does the application or some other solution already exist?

If you have materials from the client, go through them thoroughly and write down questions. A good strategy is to sketch out the business process flow diagram if you have enough data for it and if the client does not provide it. You might think you understand the process, but when you start to decompose it, you will probably realize that there are some gaps.

Once you go through the materials provided by the client, and if you have time, you can research the competition and similar solutions to gain valuable insights and ideas on how to build a better product and avoid potential mistakes. Also, if some laws or external factors affect the project, it is always a good idea to get familiar with those at a high level.

If you don’t have materials from the client, you will need to be more creative, but you can still successfully prepare for the workshop. For example, suppose the project’s outcome will be to build a mobile application.

In that case, you can study the competition, install their apps, read the user reviews and identify the shortcomings or pain points of those apps for the users to make sure to avoid those in the application you will help build.

Prepare questions & topics

Now that you have all your questions, it is time to organize them into topics/epics you will discuss during the requirement workshop. If you have any materials that will help guide the discussion, include them and present them to the client; this can be screenshots of the current solution, diagrams, user flows, wireframes, etc. An example of how the Miro board can be utilized for this purpose is shown in the image below.

In this example, we have three epics – Registration, Ordering, and Contact. Each epic has questions or materials that need to be answered/confirmed during the workshop.

For instance, there is a flow diagram in the Ordering epic that can be discussed and confirmed with the client; in the Contact epic, there were some recognized issues with the contact form, so the wireframe is attached as a possible improvement suggestion.

This part can be done with many other tools as well; for example, at the beginning of my career, I even used Microsoft Excel to write down and categorize all the questions and their answers. The most important thing as a BA is that you are familiar with the topics, the questions are clear, and you can easily lead the client through them during the workshop. However, collaboration tools will always have far more benefits, and I recommend you use such tools whenever possible. 

For instance, you usually have many internal and external stakeholders in the requirement workshops, so why not utilize them and let them collaborate by adding notes and answers on the whiteboard during the discussion?

This way, they will actively participate in the workshop (and won’t be bored), and you will get much-needed help because you are leading the workshop and having discussions, so you don’t always have time to write all the answers down simultaneously.

It’s called requirement elicitation, not gathering!

Business needs should always be questioned by a business analyst and never blindly gathered. Instead, you should know why some requirement is needed and how it fits into the big picture and use the workshop to distill actual business needs from wishes. That is why this process is called requirement elicitation and not gathering, and here is where that good preparation beforehand comes into play.

Another thing you can do as a part of the workshop preparation is to set up a workshop summary template. Once the workshop is done, it is always a good idea to send a workshop summary with key conclusions to all the stakeholders to avoid misunderstandings later on. Information that I usually include in this document are:

• Name of the project


• Date of the workshop


• Purpose of the workshop


• Participants, their roles, and company


• Topics & Conclusions


• Next steps (Activity, Responsible person & Deadline)


• Attachments

Keep in mind that, in practice, not all the stakeholders communicate with each other, and if some are absent from the workshop, they might disagree with what was discussed. Also, you might think everything is going well and that you and all the stakeholders have an understanding, but when you send the summary, some points might get reopened.

Conclusion

Good preparation will give you enough confidence to lead the workshop in a structured manner while keeping in mind the goal you want to achieve. When prepared, you’ll have a firm grip over requirements because you will understand the whys behind each one. You will also be able to keep the discussion on track resulting in clients getting the solution they actually need rather than want.

And to top it all off, I will leave you with this quote by Bernard Kelvin Clive that perfectly sums up what usually happens whenever we overlook good preparation: “If you don’t prepare, you will repair.”