Workshops & JAD Sessions

Workshops & JAD Sessions

A one-on-one interview surfaces one stakeholder's perspective. A questionnaire collects many views in parallel. But neither technique creates the dynamic that produces the best requirements: multiple stakeholders in the same room, reacting to each other's statements, filling each other's blind spots, and reaching consensus in real time. That is exactly what a workshop — and its formal variant, the Joint Application Development (JAD) session — is designed to deliver.

What Is Joint Application Development?

Joint Application Development (JAD) is a structured workshop technique developed at IBM in the late 1970s. It brings business stakeholders, end users, and the development team together in a focused session — typically one to five days — to collaboratively define, refine, and agree on requirements. The core insight is that requirements written by analysts and then reviewed by users in documents are far less accurate than requirements negotiated face-to-face in a room.

Consider a clinic booking system. A traditional approach might have the analyst interview the receptionist, then the doctor, then the patient liaison — each separately — and later write a requirements document. A JAD session instead seats the receptionist, two doctors, the IT manager, the patient liaison, and the lead developer around a table for two days. Within hours, the doctors reveal that they need buffer time between appointments that the receptionist was already blocking informally — a requirement that never surfaced in any interview because each person assumed the other had mentioned it.

The Five Roles in a JAD Session

A JAD session is not a free-for-all meeting. It has defined roles, each with specific responsibilities:

1. Facilitator — A neutral guide who owns the process, not the content. The facilitator enforces ground rules, manages time, prevents dominance by loud personalities, draws out quiet participants, and keeps the session on track. Critically, the facilitator does not express opinions about requirements. In our clinic example, this might be a senior business analyst who works neither for the clinic nor for the development firm.
2. Sponsor / Executive Champion — A senior stakeholder with authority to make decisions and resolve escalated conflicts. Their presence signals organisational commitment and prevents "I'll have to check with my manager" deadlocks. For the clinic system, this is the clinic director.
3. Business Participants (Subject Matter Experts) — The people who understand the business domain: receptionists, doctors, billing staff, and patient liaisons. They define what the system must do and why. Typically 4–8 participants; too many dilutes focus.
4. IT / Development Representatives — Architects or senior developers who can answer feasibility questions on the spot ("Can we integrate with the existing lab system?" "How complex is real-time slot conflict detection?"). They do not make unilateral technical decisions during the session but prevent unrealistic requirements from solidifying.
5. Scribe — A dedicated note-taker who captures decisions, open issues, and requirements in real time. The scribe is separate from the facilitator so the facilitator can focus on dynamics, not documentation. In modern sessions, this often means a shared screen with a live document everyone can see.

Facilitating a JAD Session: Ground Rules

The facilitator opens every JAD session by establishing ground rules. These are not optional courtesies — they are the mechanism that prevents the session from degenerating into a status meeting or a shouting match:

• One conversation at a time. Side conversations are stopped immediately. Everyone hears everything.
• No rank in the room. A doctor's opinion about patient flow carries exactly the same weight as the receptionist's. The facilitator enforces this by actively asking quieter participants for their views.
• Decisions are made here. Participants must come with authority to agree, not just to listen. "I need to check with my boss" is discouraged; the sponsor is present precisely to resolve such impasses.
• Parking lot. Off-topic items are written on a "parking lot" list (a corner of the whiteboard) and revisited at the end of the day. This prevents scope creep while ensuring nothing is lost.
• Timeboxed agenda. Each agenda item has an explicit time budget. The facilitator calls time and moves on, even if a topic is not fully resolved — open items go to the parking lot.
• Requirements, not solutions. The session focuses on what the system must do, not how it should be built. When someone says "it should use a database with real-time sync," the facilitator reframes: "So the requirement is that all staff see appointment changes within seconds — is that right?"

A Realistic JAD Session: Logistics Firm

Imagine a logistics firm commissioning a new shipment tracking portal. The analyst schedules a two-day JAD session with eight participants: two operations managers, three dispatch coordinators, one warehouse supervisor, one IT architect, and the COO as sponsor.

Day 1 (Scope and context, 6 hours):

1. Facilitator reviews the agenda and establishes ground rules (30 min).
2. Sponsor presents the business driver: "Customers are calling us 200 times a day asking where their shipment is. We lose 15% of repeat business to competitors with live tracking." (20 min)
3. Participants map the current shipment lifecycle on the whiteboard — from order receipt to delivery confirmation. Three undocumented manual steps surface immediately. (90 min)
4. Scope boundary exercise: facilitator writes candidate features on sticky notes; group votes in/out for Phase 1. Eighteen candidates become nine. (60 min)
5. Deep-dive on the top three in-scope requirements, resolving contradictions between how dispatch and operations currently handle status updates. (120 min)

Day 2 (Detail and agreement, 6 hours):

1. Review parking lot items from Day 1; sponsor makes decisions on two escalated conflicts. (45 min)
2. Walk through each agreed requirement with the IT architect to flag technical risks and confirm feasibility. (90 min)
3. Scribe reads back the consolidated requirement list; participants correct and approve. (60 min)
4. Define acceptance criteria for each requirement — the specific, testable conditions that will signal "done." (90 min)
5. Sign-off: each participant and the sponsor signs the agreed requirements document. (15 min)

The result: a signed requirements document with 27 requirements and acceptance criteria, produced in two days with full stakeholder buy-in. The traditional document-and-review cycle for the same project typically took six to eight weeks and produced a document that no one fully agreed with.

When JAD Works Well — and When It Does Not

JAD is not a silver bullet. It is powerful under specific conditions and counterproductive under others:

JAD works best when:

• Stakeholders are available and willing to commit 1–2 full days to the process.
• Requirements are genuinely uncertain and need negotiation, not just documentation.
• There are cross-functional dependencies — decisions made by one group affect another.
• Senior sponsorship is available to break deadlocks.
• The project has sufficient budget; JAD preparation and facilitation are not cheap.

JAD struggles when:

• Key stakeholders cannot (or will not) attend in person — a JAD with half the decision-makers absent creates incomplete requirements and post-session surprises.
• Organisational politics make open discussion impossible — people say yes in the room and escalate objections to their managers afterwards.
• Requirements are already well-understood and just need documentation — a workshop is overkill.
• The domain is highly technical and business participants lack the vocabulary to engage meaningfully.

Practical Tips for Analysts Running Workshops

• Send a pre-read. Distribute a one-page agenda and a brief context document 48 hours before the session. Participants who arrive prepared need less time reaching shared understanding — saving hours of session time.
• Use structured techniques inside the workshop. Within a JAD session, individual elicitation techniques (brainstorming, dot voting, scenario walkthroughs) are used as tools for specific agenda items. A two-day JAD without internal structure becomes an unproductive free-form discussion.
• Capture the "why" alongside the "what." When a requirement is agreed upon, the scribe records not just the requirement but the business rationale. Six months later, developers who understand why a rule exists make better implementation decisions than those following opaque constraints.
• Follow up within 24 hours. Distribute the draft requirements document the day after the session, while memories are fresh. Ask for corrections within 48 hours. Requirements degrade in accuracy remarkably quickly as people return to their day jobs.

Workshops and JAD sessions represent the gold standard for collaborative requirements elicitation on complex, cross-functional systems. The investment in time and preparation pays dividends through fewer change requests, less rework, and — crucially — shared ownership of the requirements by the very people who will use and pay for the system.