Where are the JAD Sessions (Requirements Gathering Workshops)?

Requirements Workshop, USer Story Workshops, Requirements Discovery SessionsAccording to a recent Gartner Group paper, “expertise in requirements gathering has declined as the use of JAD sessions (Requirements Gathering Workshops) fell out of favor in the late 1990s”1. For those not familiar with the concept, JAD stands for “Joint Application Development” (originally “Joint Application Design”, but over time it morphed).

The general idea of JAD (Requirements Gathering Workshop) was to assemble a cross-functional team consisting of subject matter experts and systems analysts/developers. Put this group off-site under the direction of a skilled and motivated facilitation team, this group could define high-quality business and stakeholder requirements in a week. What caused this decline in the use of this phenomenally effective tool? Let us examine the possible causes of its decline and suggest why the time is right to bring the JAD approach back into common use – albeit under a new name to account for the evolution in how IT solutions are developed today.

Why the Decline?

The decline was caused by a combination of factors. One of the main causes was the Y2K event that sidelined software development for four to six years. JAD sessions (Requirements Gathering Workshops) were not really applicable to the Y2K process because most of the requirements were defined by IT personnel and the need for interaction with the business community declined. Ergo, the exercise of JAD skills atrophied. The second was the “trimming” of the business community. Downsized business units no longer had the resources to devote the time needed for JAD sessions (Requirements Gathering Workshops). The third factor was the pent-up demand for software development. The backlog that has existed since IT’s infancy was exacerbated by the necessity for focus on Y2K fixes.

Where are we today?

OK, Y2K is just a distant memory and yet the surge in JAD (Requirements Gathering Workshops) usage is lacking. Outsourcing evolved as a potential solution. A seemingly unlimited pool of external resources can be tasked with development work while the IT department keeps things running on the home front. Unfortunately, for outsourcing to be successful, the requirements have to be much more clearly and rigorously defined then ever before. The increase in clarity and rigor is necessary to ensure the quality and the timeliness of the deliverable. To solve this dilemma, some organizations decided to eliminate their IT department’s involvement and have the outsourcing company determine the requirements themselves. This capitulation of responsibility is the IT industry’s version of the “fox in the henhouse” fable.

Along came Agile, an iterative and incremental development approach. Although very powerful, one of its weaknesses is that future, incremental releases can require a considerable amount of “refactoring” or rewriting of production code. This can only be avoided if the business requirements are clearly defined in the beginning of the project. If not, you are solving today’s problems by spending tomorrow’s resources.

The Current Reality

Both solutions fail without effective business requirements and the only reliable source of these is an informed, empowered subject matter expert (SME). SMEs have to be involved early in getting the requirements as right as possible (note that that we did not say perfect or complete). The alternatives are to involve them more often in creating the system via iterations (acceptable but not efficient) or in maintenance and change requests on the fly (a proven road to failure).

The Now and Future JAD (Requirements Gathering Workshops)

To get the SME’s involved at the right time in our projects, we need to rebuild our requirements discovery expertise and we need to make the most efficient use of the SMEs’ limited availability. JRP (Joint Requirements Planning) is a JAD-like approach that focuses on business requirements. The key success factors in a JRP are the facilitation team’s command of a complete set of requirements determination methods combined with the ability to plan and facilitate short, directed, time-boxed sessions. This is what we need to meet the conflicting demands placed on the business community and the IT resource.

Many organizations are realizing better business satisfaction with delivered information technology by recapturing the art and science of requirements discovery. JRP sessions deliver the right requirements. Better business requirements early in the project create a richer, more comprehensive base to draw upon for the iterative process that is at the core of the Agile movement. Outsourcing can also be a very lucrative alternative if the right business system requirements are defined up front.

1 Gartner # G00126310