Techniques BABOK Guide v3, 10.50

Workshops

In short A workshop brings a focused group of stakeholders together, with a facilitator, to produce a defined result: agreed requirements, a model, priorities, or decisions. Done well, it reaches in a few hours an agreement that a round of separate interviews might take weeks to achieve.

Based on: IIBA, BABOK® Guide v3, technique 10.50 “Workshops”; Watermark Learning, BABOK v3 Study Tables (2016); Yu. A. Maglinets, Analysis of Requirements for Information Systems (in Russian), lecture 3.

On this page

What it is#

The BABOK® Guide treats the workshop as one of the most versatile techniques. You can use it for planning, analysis, scoping, eliciting requirements, and modelling solutions, and also to generate ideas for new features or products, reach consensus on a topic, or review requirements and designs. Beyond its direct output, a good workshop builds trust, mutual understanding, and strong communication among the people in the room.

The BABOK Guide describes four elements:

  • Prepare for the workshop: purpose, participants, agenda, materials, logistics, and any pre-reading.
  • Workshop roles: the sponsor, who owns the outcome and may open the session; the facilitator, who runs the process and stays neutral; the scribe, who records decisions, issues, and actions; the timekeeper; and the participants, who bring knowledge and authority.
  • Conduct the workshop: open, work through the agenda, record, and close.
  • Post-workshop wrap-up: send the notes, follow up on actions and open issues, and confirm the results.

Maglinets describes Joint Application Design (JAD), a group-session method developed at IBM in the late 1970s, with similar roles: a leader skilled in interpersonal communication who knows the domain but need not be an IT expert; a scribe; customer representatives, users and managers who shape the requirements and make decisions; and developers, who mostly listen in order to understand the domain.

Workshops appear in more BABOK tasks than almost any other technique: most of Business Analysis Planning and Monitoring; Conduct Elicitation (4.2), Confirm Elicitation Results (4.3), and Communicate Business Analysis Information (4.4); Prioritize Requirements (5.3), Assess Requirements Changes (5.4), and Approve Requirements (5.5); all of Strategy Analysis (6.1–6.4); Define Requirements Architecture (7.4), Define Design Options (7.5), and Analyze Potential Value and Recommend Solution (7.6); and Assess Enterprise Limitations (8.4).

When to use it#

Workshops reach agreement quickly, encourage collaboration and decisions, build a shared understanding, often cost less than a series of interviews, and give immediate feedback. Use them when:

  • several groups must agree on something, especially across departments;
  • views conflict and need to be worked through face to face;
  • time is short and decision makers can be gathered;
  • you need to prioritize, review a model, or confirm results with many people at once.

Use something else when:

  • the knowledge sits with one expert; run an interview;
  • people will not speak openly in front of their managers; interview them first or collect anonymous input;
  • stakeholders are many and widely dispersed; use a survey;
  • you cannot get the decision makers in the room; change the purpose or postpone.

Watch the known risks: getting the right people together can be hard, success depends heavily on the facilitator’s skill and knowledge, and too many participants or the wrong mix can derail the session.

How to do it#

Before

  1. Define the purpose and the deliverables: “By the end, we will have…”.
  2. Choose participants for knowledge and authority. Keep the group small enough for everyone to contribute, but make sure nobody who could veto the result later is missing.
  3. Design the agenda with timeboxes and a technique for each item, such as brainstorming, a model walkthrough, collaborative games, or prioritization.
  4. Send the agenda and pre-reading, and talk to key participants beforehand to learn their positions.
  5. Assign roles. If you must contribute content, ask someone else to facilitate. Appoint a scribe.

During

  1. Open: purpose, agenda, ground rules, and how decisions will be made (consensus, or the sponsor decides).
  2. Work visibly: models and notes where everyone can see them, a “parking lot” for off-topic points, and every decision and action captured with an owner.
  3. Close: read back the decisions, open issues, and actions, then agree the next steps.

After

  1. Send the notes within a day or two and ask participants to confirm them.
  2. Track open issues and actions until they are closed.

Example#

The Workshop, a fictional chain of bike-repair workshops, holds a three-hour session on booking rules for release 1. The owner is sponsor; two workshop managers, two front-desk staff, two mechanics, and the development team lead take part. The business analyst facilitates, and an analyst from the development team acts as scribe.

Time Item Technique Output
0:00 Purpose, rules, decision method Briefing Shared expectations
0:15 Booking scope Scope model walkthrough Confirmed boundary
0:40 Repair types and slot lengths Brainstorming, then grouping List of slot types
1:30 Break
1:40 Cancellations and no-shows Scenario walkthrough Draft business rules
2:30 Release 1 features MoSCoW prioritization Ranked feature list
2:50 Recap Read-back Decisions and action list

Two disputes, deposits for long jobs and weekend slots, went to the parking lot with an owner and a date. The notes went out the next morning.

Common mistakes#

  • No clear purpose or deliverable → write the “by the end we will have” sentence first.
  • Wrong people, or too many → invite for knowledge and authority, not for politeness.
  • A facilitator with a stake in the outcome → keep the facilitator neutral.
  • The most senior voice dominates → use round-robins, silent writing, and anonymous voting.
  • Decisions not recorded → have a scribe and read decisions back before closing.
  • No follow-up → send notes quickly and track actions to closure.

Template#

Template
Workshop: <title>        Date / time / place: <...>
Purpose: by the end we will have <deliverables>
Sponsor: <role>   Facilitator: <name>   Scribe: <name>   Timekeeper: <name>
Participants: <role - why invited>
Decision method: <consensus / sponsor decides / vote>
Pre-reading: <documents, by date>

| Time | Item | Technique | Output |
|---|---|---|---|

Ground rules: <list>
Parking lot: <item - owner - due date>
Decisions: <list>
Actions: <action - owner - due date>
Notes sent: <date>    Confirmed by: <names>

Sources and further reading#

  • IIBA. A Guide to the Business Analysis Body of Knowledge (BABOK® Guide), version 3. International Institute of Business Analysis, 2015, technique 10.50 “Workshops”.
  • Watermark Learning. BABOK v3 Study Tables. 2016. (study aid for the BABOK Guide), technique 10.50.
  • Yu. A. Maglinets. Analysis of Requirements for Information Systems, lecture notes (in Russian). Siberian Federal University, 2007, lecture 3 (JAD session roles).