Requirements Workshop

It is a structured and facilitated meeting that involves a carefully selected group of stakeholders like:

• End Users
• Subject Matter Experts (from Business and Technology)
• Project Managers
• Business (Managers and Executives)
• IT representatives

It is used when large groups or cross-functional groups have to work together as each group can have a part of the solution.

If they don’t work together then:

• You’ll have to elicit requirements separately from them
• Combine the requirements
• Communicate multiple times to resolve the conflicts
• Get approvals, etc.

There would be too many unnecessary round trips and also vulnerable to miscommunication which will result in incorrect requirements.

By having the groups together the requirements can be identified (discovered), clarified, verified & validated, and documented simultaneously. Moreover, consensus can be reached quickly.

You should have a set of approved requirements from different groups by the end of the meeting.

Unlike brainstorming, in this type of elicitation technique, you do dive into the details of a requirement.

In this technique, you don’t collect random requirements, rather you come prepared with predefined deliverables or work products for which you want clear and complete requirements. You want to either solve a problem and get a solution or you want to clearly understand a process or function. You work to attain an approved requirement set by the end of the meeting.

You start at a broad level of the agenda and then dive deep into the processes and functions.

E.g. 

Broad topic:

Understanding the overall needs of a potential system.

Narrow down: 

Individual components, Modules inside the components, individual functions inside the module.

Types:

Formal Requirements Workshop

This is the most commonly used.

They are highly structured and formal.

They are very targeted:

• Only a carefully selected group of stakeholders are invited
• Discussions are strictly catered around the predefined topic with minimum off-topic digression
• Conclusions on a predefined topic are reached

Requirements are

• Discovered
• Created
• Refined
• Verified and Validated
• Approved (Closure reached)
• Documented

Business Process Improvement Workshop

In this type, you dive into the details of an existing process

You guide the process from the current as-is state to the future to-be state

You suggest process improvements to solve the problems in the existing process

They are semi-formal

E.g.

You could use post-it notes to understand a process.

You depict the current process on a whiteboard using the post-it notes. The post-it notes stand for the action/event in the process

The post-it notes can be moved and rearranged by the workshop participants as per their understanding of the system. This way you don’t have to erase or redraw each time.

This method helps to understand & refine the process and also to identify the flaws in it.

Finally, you work on the flaws and resolve the issues by suggesting potential process improvements.

Agile Requirements Workshop

Agile favors conversations over documentation and hence these workshops are more unstructured and informal.

In agile the actual details of the requirements are deferred until the last moment before the development begins. Hence this type of workshop is held in the beginning in which the scope of the requirement is defined (in form of initial set of broad requirements) and then with each sprint, the requirements are elaborated.

Advantages of Requirements Workshop

• It is effective at getting real requirements instead of perceived requirements

Unlike brainstorming in this type of elicitation technique you get to dive deep into the details of a requirement and understand it thoroughly. Also, since you have the stakeholders that can approve the requirements you can also get the requirements finalized.

• Greater chance of obtaining consensus because issues and questions are asked in real-time

• Confirmation of requirement accuracy is immediate

• Successfully gather requirements from a large group in a short period of time

• Gain stakeholder confidence

Since we have solid and finalized requirements during the workshop itself hence you can document it within a few hours and quickly get it reviewed by the participants (stakeholders). This gives the stakeholders confidence that they could provide immediate value to the project.

Disadvantages of Requirements Workshop:

• It is difficult to get the appropriate stakeholders simultaneously in a room

• Logistical difficulty

There is logistical difficulty to conduct this kind of workshop if the groups are spread across multiple physical locations. There are great tools available to simplify this process but nevertheless it is still a complex process.

• The success of the session is highly dependent on the expertise of the facilitator

An experienced facilitator with great conflict-resolution & negotiation skills is required to efficiently conduct this workshop else things would escalate in wrong directions and the entire process will be derailed.

• It can be expensive as so many resources are required and blocked simultaneously

Best Practices

• Determine the type of workshop in advance

If it is the conventional type then you choose between the Formal Requirements or Business Process Improvement type.

If it is Agile then it is mostly to identify the high-level Requirements scope.

Be clear about the session deliverables

Have the end objective identified.

What are the key Requirements deliverables? (key things the requirements should deliver: requirements are the “needs” to solve a problem and so it’s deliverables would be the “what needs to done”)

What is the problem for which you need a solution?

How will the requirements deliverables or the problem solution help?

• Use modeling tools to visualize process and requirements 

Follow the adage: picture (visual representation) over words.

In a requirements workshop, the participants are from different backgrounds i.e business, technical, management etc.

It’ll be difficult for them to understand each other if each speaks in their own technical language.

Hence writing a requirement in a meeting that everyone can understand will be difficult.

Utilizing a modeling tool will help each participant to understand each other and the requirements without ambiguity.

Eg: Rough sketching on the board; using post-it notes; using diagrams like Venn diagram, etc.

• The facilitator should be experienced

A junior BA or a junior PM may find it difficult to run a meeting like this due to the presence of high authority individuals who may unintentionally derail the meeting. An experienced BA has developed good negotiation and conflict-resolution skills. He/She can guide the meeting and keep it from straying into unnecessary areas by guiding where to dive deep for details and where to stay at a high level. Also he/she can fetch the correct requirements from stakeholders by making them aware of the problem and keeping them focussed on it and doing the firefighting to keep the environment conducive for the meeting.

• Limit the meeting to key project participants

If you have a large group (e.g 20 participants) it will be difficult to get all of them to agree to a point.

Hence have one or two participants from each area i.e end users, SMEs, developers, senior management.

An ideal size would be between 8 and 12.

• Act as an analyst, not just as a scribe or facilitator

Don’t just randomly take the requirements as they are.

Challenge and question the participants to get a better understanding of the requirements.

Use your experience and expertise to work with and refine the requirements.

If there are conflicting requirements then call them out and get them resolved in the meeting itself instead of following up later. Get all the stakeholders to agree on a requirement without ambiguity or conflict. This is the right place to do it.

The post is  based on my notes and understanding from this BA tutorial