3

I go to workshop after workshop with the same one dimensional approach - too many people, everyone looking at the screen while someone is capturing requirements/assumptions etc, dry, boring, not engaging, requirements are missed because people want to be somewhere else, mobile phones and laptops litter the tables etc for capturing stakeholder requirements and providing an excellent solution to a stakeholders problems.

Yesterday I stumbled across Joint Application Development (JAD). It appears to promise the complete opposite to what I have been experiencing above. How can I implement this approach? Are there alternatives with the same end result of engagement and collaboration?

  • Hi Nev Harvey, welcome to PMSE. I edited to focus the question title on the problem that you're facing and hoping to solve. Good luck! :) – jmort253 Sep 5 '13 at 18:51
1

Regarding implementation, I can heartily recommend the book "Requirements by Collaboration" by Ellen Gottesdiener. It's also referenced in the bibiography of the JAD Wikipedia page.

This book will teach you everything you need to know on how to plan, conduct and assess facilitated requirements elicitation workshops in a JAD-like manner, which are interactive and fun.

I have used these techniques in the past with very good results, and I still use her workshop WBS as a checklist when preparing workshops to get things done.

Beware: this is hard work. The success of a good workshop depends on a large part on the preparation and follow-up activities.

Good luck Stephan

| improve this answer | |
0

TL;DR

Joint Application Design (JAD) attempts to formalize a process for gathering requirements and developing a design from those requirements. One way to think of it is as a merger of the Requirements and Design phases of the waterfall model, with some people-oriented agile principles mixed in to heighten engagement among the participants.

No Silver Bullet

Repeat after me: there is no silver bullet. Say that 1,000 times before spending any more time looking for a framework or process to solve your workshop problems.

Define Your Problems Explicitly

You already know what your problems are with your current process; you spell them out pretty clearly in your question. Let me highlight them for you:

  1. You have the wrong people in the workshops.
  2. Not everyone in the workshop has skin in the game.
  3. Your workshop model is a lecture, not a cooperative endeavor.

In other words, you're holding workshops that no one wants to participate in, and your meeting facilitator is talking at people instead of engaging them.

Evaluate Your Solutions

There's nothing particularly novel in the JAD approach to this issue. Adopting it simply formalizes an approach that focuses on increasing participation by:

  1. Defining clear goals.
  2. Selecting participants carefully.
  3. Ensuring that "chickens" (see Chickens and Pigs) are kept as silent observers or excluded from the process.
  4. Using an iterative model within the workshops to keep engagement high and give people a sense of accomplishment.

In fact, JAD isn't all that different from Scrum's underlying principles. Think Sprint Goals, Sprint Reviews, and daily stand-ups where only "pigs" can participate. In my mind, that's a fairly good model for what JAD is trying to accomplish—just limited to application design.

The JAD Facilitator Role

The key role in JAD is the facilitator. This person is a process referee and a group therapist rolled into one. For example:

  • Wikipedia says: "The facilitator must design workshop exercises and activities to provide interim deliverables that build towards the final output of the workshop."
  • One of the source references says: "The facilitator is responsible for ensuring that each person is heard and has an equal opportunity to influence the decision."

JAD and Potential Alternatives

JAD is focused primarily on the requirements-gathering and design phases of a project. It is not a full-fledged project management framework, so direct comparisons to other methodologies starts from a flawed premise. Still, there are some useful similarities and contrasts to be explored.

As mentioned above, JAD shares some principles in common with Scrum. One might even draw useful comparisons between an effective Scrum Master and a JAD facilitator, as both are fundamentally servant-leader roles.

Like Scrum, JAD isn't really all that prescriptive. There are some mandatory roles, some mandatory artifacts, and some mandatory meetings, but the implementation details are yours to create within the general framework.

Unlike Scrum, JAD is focused on big, up-front design. Many agile methodologies like Scrum do away with the need to hold multi-day design workshops because they focus on emergent design through iterative delivery. Every sprint involves a little analysis, a little design, and a lot of hard work, rather than trying to do all the analysis and design at the very start of the project.

If you aren't stuck with a waterfall development model, then I'd certainly spend some time evaluating the various agile frameworks. However, note that the organizational changes required to implement an agile framework effectively are generally more sweeping than the changes needed to implement JAD. Your mileage may vary.

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.