JAD is a requirements-definition and user-interface design methodology in which end-users, executives, and developers attend intense off-site meetings to work out a system's details. JAD focuses on the business problem rather than technical details. It is most applicable to the development of business systems, but it can be used successfully for shrink-wrap and systems software. It produces its savings by shortening the elapsed time required to gather a system's requirements and by gathering requirements better, thus reducing the number of costly, downstream requirements changes. Its success depends on effective leadership of the JAD sessions; on participation by key end-users, executives, and developers; and on achieving group synergy during JAD sessions.
Efficacy
Potential reduction from nominal schedule: | Good |
Improvement in progress visibility: | Fair |
Effect on schedule risk: | Decreased Risk |
Chance of first-time success: | Good |
Chance of long-term success: | Excellent |
Major Risks
Unrealistic productivity expectations following the JAD sessions
Premature, inaccurate estimates of remaining work following JAD sessions
Major Interactions and Trade-Offs
Works best when combined with an incremental-development lifecycle model
Can be combined with rapid-development languages and prototyping tools
JAD stands for "Joint Application Development." The "joint" refers to the fact that developers, end-users, and other concerned parties together design the product concept. It's a structured process for requirements gathering and negotiation. The focal point of the process is a series of workshops that are attended by executives, end-users, and developers.
JAD leverages group dynamics, extensive use of visual aids, WYSIWYG documentation, and an organized, rational process to gather requirements in a short time. JAD is one of the most powerful requirements-specification practices yet developed, and it produces its savings in several ways.
CROSS-REFERENCE
For more on reducing time at the front end of the product-development cycle, see Where the Time Goes, Where the Time Goes.
It commits top executives to the software-planning process. JAD involves top executives from the beginning of a product's development. Early executive involvement shortens the product-approval cycle.
It shortens the requirements-specification phase. JAD reduces the amount of time needed to gather requirements, which shortens the overall development cycle. This is particularly useful because requirements specification can be an essentially unbounded activity that adds weeks or months to a project's front end.
It eliminates features of questionable value. By eliminating questionable features and making the product smaller, JAD reduces development time.
It helps to get requirements right the first time. Requirements analysts and end-users speak different languages, which means that the chances of them communicating effectively about software requirements are slim. JAD improves communication and eliminates costly rework resulting from mistaken requirements.
It helps to get the user interface right the first time. Some products require extensive rework because end-users reject the product's user interface. JAD-design sessions focus on user-interface design. Because end-users are involved in those sessions, the user interface that's developed is usually ultimately acceptable to end-users.
It reduces organizational infighting. Many projects are hobbled by conflicting objectives or hidden agendas. By bringing all the decision makers together to design the system, JAD brings these issues to light early in the project, when they can still be addressed effectively and before they've had time to do much damage.
JAD consists of two main phases, a JAD-planning phase and a JAD-design phase. Both of these phases deal with what is traditionally thought of as the system's requirements, but at different levels. In both phases, JAD focuses on the business-design problem rather than on purely technical details.
During the JAD-planning phase, the emphasis is on mapping out broad capabilities of the software system. The emphasis is more on business concerns than detailed technical concerns. The main outcomes of the JAD-planning phase are the system's goals, preliminary effort and schedule estimates, and a decision about whether to continue with further product development. JAD planning also sets up the JAD-design phase.
If the decision is made to go ahead with the product, the JAD-design phase comes next. JAD design elicits more detailed requirements, and its purpose is to create the user-level design of the software. In spite of being called "design," it does not focus on the functional design of the system, which is what you might think of when you think of "design." JAD design uses prototyping extensively, and the main outcomes of this phase are a detailed user-interface design, a database schema (if appropriate), and refined budget and schedule estimates. At the end of this phase, the project must again be approved before it can continue.
Figure 24-1. Overview of the JAD process. JAD planning and JAD design are organized into similar sequences of activities. Source: Adapted from Joint Application Design (August 1991).
As Figure 24-1 suggests, both the planning phase and the design phase are broken into three parts:
Customization—The session leader and perhaps a few other people take the out-of-the-box JAD methodology and tailor it to the specific project. This typically requires from 1 to 10 days.
Session—The session, the time when all the parties are brought together, is the main focus of JAD. It typically lasts from 1 to 10 days, depending on the size of the system.
Wrap-up—Wrap-up is the documentation or packaging of the session activity. Handwritten notes and visual aids are converted into one or more formal documents. This takes from 3 to 15 days.
Once the JAD-design phase is over, as much output as possible is carried electronically into the program-design and construction phases. JAD does not dictate any particular program-design or construction practices, but it is especially compatible with incremental lifecycle models and with the use of CASE tools.
Although JAD was originally developed for use in IS mainframe environments, it has been used successfully in client-server software development too (August 1991, Martin 1991, Sims 1995). The practice of bringing all the stakeholder parties together to thrash out a system's requirements is equally applicable to commercial products, vertical-market software, shrink-wrap software, and systems software. You can use the customization subphases of JAD planning and JAD design to adapt JAD to projects of virtually any size or kind.
JAD planning focuses on requirements and planning. Its objectives are to identify high-level requirements, define and bound the system scope, plan the JAD-design activity, publish the JAD-plan document, and obtain approval for the JAD-design activity. The JAD-planning phase is also sometimes called Joint Requirements Planning, or JRP (Martin 1991). The following subsections describe the customization, session, and wrap-up subphases.
The purpose of the customization activity is to tailor the JAD-planning session to the needs of the specific project. The main activities during customization are:
Orient participants to the JAD process
Organize the JAD team
Tailor JAD tasks and outputs to the specific project
Prepare the materials for the JAD-planning session
The people who participate in planning are usually not the same people who participate in design. The participants in a planning session tend to be higher up in the organization. JAD design makes use of participants who will own the system or work with it when it's built. If these higher-level people and hands-on people are all the same, you can combine planning and design into one phase.
The JAD session is what sets JAD apart from other requirements-gathering methods. Critical ingredients of the JAD session include leadership from a trained JAD leader, participation by the executive sponsor and other key decision-makers, use of a structured process, and an ability to work without normal day-to-day interruptions.
CROSS-REFERENCE
For more on the factors that cause teams to jell, see Chapter 12, Chapter 12.
As I mentioned earlier, a JAD session can last anywhere from 1 to 10 days. JAD is a team activity, so typical teamwork guidelines apply. It usually takes 2 days for a JAD team to jell (Martin 1991). If the JAD session lasts 5 days, the team will do most of its work on days 3, 4, and 5.
Regardless of the duration of the JAD session, the participants must attend full-time. If some participants attend only part-time, you waste time briefing them and re-covering old ground. To achieve the group synergy of a JAD session, all group members need to be present.
The JAD room is located off-site, ideally in a hotel or conference facility. JAD participants are normally key people in the organization, and key people usually have dozens of potential distractions. The facility should free participants from their normal distractions and allow them to focus exclusively on the JAD session. Allowing participants to respond to interruptions during a session suggests that the JAD session isn't important.
The JAD room for both planning and design should include visual-aid support, computer support, copy machine, notepads, pens, Polaroid camera to record whiteboard contents, name cards (if needed), and drinks and refreshments. This combination of facilities sends an important message to the JAD participants: "This job is important, and the organization is behind you."
A JAD session includes a number of people.
Session leader. The session leader is most instrumental in the success or failure of JAD, and the successful leader needs a rare combination of skills. The leader must have excellent communication and mediation skills. The leader must mediate political disputes, power struggles, and personality clashes. The leader needs to be impartial (arriving at the JAD session with no political baggage) and able to keep an open mind and control controversies. The leader should be sensitive to hidden agendas and able to redirect them constructively. The leader should bridge communication gaps. The leader must be comfortable speaking to and controlling a group of people that includes high-level executives. The leader should encourage quiet members of the group to participate and prevent strong personalities from dominating the sessions.
To achieve all this, the leader needs to have the respect of all the parties at the session, needs to prepare thoroughly, and needs adequate knowledge of the business area and development practices that will be used. Finally, the leader needs to be enthusiastic about JAD.
When JAD fails, it is almost always because of the JAD session leader (Martin 1991). Some organizations appoint different leaders for each project. The result is that each project uses an unskilled leader and realizes unsatisfactory results. An organization that intends to use JAD should train one or more JAD leaders and expect them to stay in that job for two years or more. It usually takes about four JAD sessions for a new JAD leader to become proficient.
Executive sponsor. This is the person who bears the financial responsibility for the system. This person is the focal point for the go/no-go decision that follows the planning session. Sometimes more than one executive sponsor will attend, especially during the planning sessions.
End-user representative. This is a key representative from the end-user community who should have the authority to make binding decisions about the program. Like the other participants, the end-user representative should be a good communicator. More than one end-user representative can participate, although the design session held later provides the main forum for end-user involvement.
Developer. This person's job is to assist end-users, to steer them away from specifying a "blue sky" system that is not implementable, and to learn the end-user's perspective. The developer answers questions about other systems, feasibility of proposed features, and costs. Developers should be careful to avoid saying "yes" or "no" to any user ideas. Their role is to provide information, not to make judgments. Developers must learn the system during the planning and design sessions so that they can hit the ground running after the JAD-design phase. More than one developer can (and often should) participate in the session.
Scribe. The scribe is someone from the software-development department whose primary responsibility is to record what happens during the session. The scribe is an active participant, asking for clarification and pointing out inconsistencies from day to day.
Specialists. These people are invited as needed to provide any special expertise required for the session. The specialist is an exception to the rule that all participants need to be present at all times. You can call in this person as-needed because the specialist is a resource to the JAD group rather than a full member of the group.
JAD sessions are subject to several common problems:
JAD sessions give an organization an opportunity to leverage the performance of its star performers. Great performers can work wonders during a JAD session, while mediocre performers can produce mediocre results. Sometimes an organization doesn't spare its stars to participate in JAD. Participation of all key people is essential. If you can't get key people to participate, don't do the JAD session at all. The chance of success is greatly reduced, and the key people who do attend the session won't appreciate having several days wasted if the session fails.
Observers are a risk at JAD sessions because they typically are not able to confine themselves to observer roles. If you need to allow observers, treat them as participants, and make sure that they attend the same training sessions other participants do and are adequately prepared.
Too many participants can keep the JAD team from jelling, which will impair the group's progress. The complete JAD group should have a total of 8 people or fewer (Martin 1991). Some experts have reported good success with as many as 15 participants (August 1991), but it is hard for the team to jell when it contains more than 8 people. If your organization is skilled at JAD, you might be able to approach the upper limit of 15 participants, but do so cautiously.
A JAD-planning session typically goes through eight main activities:
Conducting the orientation—Introduce the group to the purpose of the session, timetable, and agenda.
Defining the high-level requirements—Map out the system, including identification of the business needs the system is intended to address; system objectives; anticipated benefits; list of possible system functions; rough prioritization of system functions; and strategic and future considerations.
Limiting the system scope—Place limits on what the system can include. Your decisions about what the system will not include are as important to development speed as decisions about what the system will include.
Identifying and estimating the JAD-design phase or phases—This is the first step in planning follow-on JAD activities.
Identifying the JAD-design participants—Identify the people who will participate in the follow-on JAD-design phases.
Scheduling the JAD-design phases—End-users, development, and the executive sponsor agree on a schedule for JAD design.
Documenting the issues and considerations—Document the issues that were considered during the JAD-planning session so that you have a record of options that were considered and a record of the reasons that issues were resolved in the way they were.
Concluding the session.
For each of these activities, you go through roughly the same process. The JAD session leader presents the task, such as defining high-level requirements. Participants then generate ideas. The ideas are displayed where everyone can see them on whiteboards or overhead projectors. It's essential during this period that all team members participate, and a good JAD leader will make sure that happens.
Once the ideas have been generated, you evaluate the ideas. This is the time when the different points of view of executive sponsors, end-users, development representatives, and specialists come into play. The JAD leader keeps the group focused on the main topic, cuts through political disputes, minimizes the effects of strong and weak personalities, and redirects side issues that can't be resolved during the JAD session. During evaluation, participants often generate ideas that resolve conflicting needs in creative ways.
Finally, the group commits to whatever has been decided during the evaluation phase—system objectives, rough prioritization of system functions, restrictions on the system's scope, participants in the JAD-design phase, and so on.
The wrap-up follows the JAD session and produces a JAD document, which should look as much as possible like what was generated during the session. Output from the planning session includes:
List of system objectives, including strategic and future considerations
Details of possible system functions, including the functions themselves, the business needs that each function addresses, benefits of each function, estimate of the return on investment of each function, and a rough prioritization of each function
Limitations on the system's scope, including a list of functions that the system will not include
List of interfaces to other systems
List of issues that couldn't be resolved during the JAD session, including the name of the issue, the person responsible, and the promised resolution date
Plan for what happens next, including identification of follow-on JAD-design phases, JAD-design participants, JAD-design schedules, and rough target dates for implementation
In some JAD approaches, one of the outputs of the JAD session is a presentation to the executive sponsor, which includes all the information needed to make a go/no-go decision. In other approaches, the executive sponsor attends the whole JAD-planning session, and no such presentation is needed.
JAD design focuses on requirements and user-interface design. Its objectives are to define detailed requirements, define scope, design screen and report layouts, develop the prototype, and gather the editing, data-validation, processing, and system-interface requirements. It should also produce a design for the database schema if one is needed. The outcome of a JAD-design session is a JAD-design document, which is used to obtain approval for implementation.
The main activities during design customization are the same as they were for planning. Preparation for the session includes arranging for a session room, equipment, and supplies; preparing visual aids and forms; readying software and personnel for the documentation and prototype efforts; and setting up the session room. The session leader should also prepare a list of possible specifications before the session. These specifications should be treated as "proposed."
If end-users are not familiar with JAD, you should train them before they attend the JAD session. This will familiarize them with the objectives of the session, the roles of the leader and scribe, what they are expected to contribute, and any special diagrammatic techniques that you plan to use.
Critical ingredients of the JAD-design session are similar to those of the planning session: leadership from a trained JAD leader, participation by key decision-makers, use of a structured process, and freedom from interruptions. The design session is highly visual, using whiteboards, flip charts, overhead projectors, and large-screen monitors or projectors.
JAD-design sessions typically last longer than JAD-planning sessions, from a few days to 10 days or more, typically lasting about a week. The facilities needed are identical to those used for JAD planning.
The roles of session leader, development representative, scribe, and specialist are similar to what they were for planning. The development representatives are busier because they are required to participate in the sessions during the day and to build the prototype in the evenings. The executive sponsor is not required to be at the JAD session but may drop in from time-to-time to answer questions and offer support. Rather than use a single end-user representative, a group of key end-users should be present, end-users who can devote enough time to work with the details of the product from JAD design through program design, implementation, test, and release. The project manager might also be present but should not lead the session because the JAD leader must be absolutely impartial.
A JAD-design session typically goes through ten main activities:
Conducting the orientation—The session leader lays out the purpose of the session, timetable, and agenda.
Reviewing and refining the JAD-planning requirements and scope—You can use the session plan that came out of the JAD-planning phase as a starting point, but you will probably want to refine the plan before you move into the rest of the JAD-design session.
Developing a workflow diagram—Create a diagram that shows how work will be done with the new software system.
Developing a workflow description—Describe in words how work will be done with the new software system.
Designing the screens and reports—Design screen layouts and report formats. JAD-design sessions make extensive use of interactive prototypes, which are created by developers and end-users during and between meetings.
Specifying the processing requirements—Specify data volumes, rates, audit requirements, security requirements, and so on.
Defining the interface requirements—Specify the systems that the new system must interface to.
Identifying the system data groups and functions—Map out the system's data, including major data structures, data-structure components, and data-structure relationships. If the system is database-oriented, create a normalized database schema.
Documenting the issues and considerations—As with planning, you'll want to have a record of options that were considered and a record of the reasons that issues were resolved the way they were.
Concluding the session.
The group dynamics of design meetings are essentially the same as they were in planning. For each of these tasks, the team steps through a process of presenting the task, generating ideas, evaluating ideas, and committing to a resolution.
JAD design saves time because group sessions are more efficient than one-on-one requirements-gathering sessions. Traditionally, analysts come away from end-user interviews with incomplete understandings of the desired requirements. Later they try to second-guess what the end-user said or wanted. During a JAD session, end-users talk with analysts and each other about what they want. The group focuses its combined knowledge of the business area, the business problem to be solved, technical limits and possibilities, strategic considerations, exceptional cases, and especially difficult areas.
The time pressure of a JAD-design session helps the group to focus on the main task and reach consensus. Time pressure encourages the participants to work hard and cooperate.
CROSS-REFERENCE
For more on the beneficial effect that time pressure can have, see Chapter 39, Chapter 39.
JAD documentation takes the place of a traditional requirements specification, so carefully documenting the design session is important. Here are the wrap-up activities that follow a design session:
Complete the JAD-design document, which again should look as much as possible like what was generated during the session.
Complete the prototype based on the direction set during the session. In some cases it might be possible to complete the prototype during the design session itself.
Have all participants review the design document and prototype.
Present the results to the executive sponsor, including a summary of the design session, the JAD design, preliminary target implementation dates, and the project's current status.
It's important to move quickly from JAD design into functional design and implementation. If a project has to wait several months for approval after JAD design, the requirements can begin to get out of date, you can lose key participants, and you lose end-user support.