Joint Application Development (JAD)
Developing Systems Requires Teamwork: JAD
Also called Joint Applications Design (JAD)
Designing and developing systems is much easier if the entire system can be built by one person. In fact, that is one of the strengths of recent tools—they enable a single person to build complex systems with less effort than in the past. However, many information systems, especially those that affect the entire organization, require teams of IS workers. As soon as multiple designers, analysts, and programmers are involved, everyone encounters management and communication problems.
MIS researchers have measured the effects of these problems. One study by DeMarco and Lister showed that on large projects, 70 percent of a developer’s time is spent working with others. Jones noted that team activities accounted for 85 percent of the development costs. There seem to be substantial areas for improvement in systems development by focusing on teamwork.
One of the most difficult steps in creating any new system is determining the user requirements. What does the system need to do and how will it work? This step is crucial. If the designers make a mistake here, the system will either be useless or will need expensive modifications later.
Prototyping and SDLC (Systems Development Life Cycle) take different approaches to this problem. With SDLC, analysts talk with users and write reports that describe how the system will operate. Users examine the reports and make changes. This approach is time consuming and difficult for users because they only see paper notes of the proposed system.
Prototyping overcomes some of the problems by letting users work with actual screens and reports. But use of prototyping is hard to expand beyond one or two users. Some companies overcome the problems of SDLC by prototyping each input screen and report with one or two primary users. Once the main concepts have been designed, the analysts formalize the system and get approval from other users. The designs are then given to programmers to create with the traditional SDLC development methods. An important reason for using SDLC is to obtain the views and agreement of many users. Using traditional interview methods and paper documentation, this process often takes several months. Each change has to be reexamined by other users, and disagreements have to be resolved.
A technique known as Joint Application Development (JAD) was created to speed up the design stage. With JAD the main system is designed in an intense three to five-day workshop. Users, managers, and systems analysts participate in a series of intense meetings to design the inputs (data and screens) and outputs (reports) needed by the new system.
By putting all of the decision makers in one room at the same time, conflicts are identified and resolved faster. Users and managers gain a better understanding of the problems and limitations of technology. The resulting system has greater value for users and managers because it more closely matches their needs. There is less need for changes later, when they become more expensive, so the system ischeaper to create.
The biggest drawback to JAD is that it requires getting everyone together at the same time for an extended period of time. Even for moderately complex systems, the meetings can run eight hours a day for three to five days. Most managers (and users) find it difficult to be away from their jobs for that length of time. Higher level managers are also needed at these meetings to ensure the system provides the appropriate reports and information. Finally, the meetings can succeed only if they are led by a trained facilitator. The facilitator keeps the discussions moving in the right direction, minimizes conflicts, and encourages everyone to participate.At the end of the sessions, the systems development team should have a complete description of the proposed system.
JAD sessions are somewhat obsolete and are not normally conducted in Agile at all. In an Agile project there is less of a need for formal JAD sessions because the Product Owner plays an important role to define the vision and direction for the project and to define and prioritize requirements.
