Background and Motivation

Joint Application Development (JAD) is a technique that allows the development, management, and customer groups to work together to build a product. This document specifically refers to how JAD sessions are used in the Product Life Cycle (PLC) to collect and manage product requirements.

IBM developed the JAD technique in the late 1970's, and within a few modern variations, it is still the best method for collecting requirements from the users, customers, or customer advocates (henceforth called user). JAD refers to the joint process of collecting requirements and resolving issues as early as possible through a series of meetings. In earlier days, these meetings were off-site, multiple-day "marathon sessions." The JAD team consists of a mixture of customer functional experts to systems professionals in the ratios from 2:1 up to 3:1 [Lev95, Kno95].

Collecting requirements is an inherently difficult problem due to the psychology of expressing uncertain desires in an ambiguous language. Computerworld magazine reports that 95% of all software projects slide into cost and time overruns and 93% of all runaways stem from poor communication; 65% overrun by a factor of 2 or 3 [Gar95]. Standish Group International reports that lack of user involvement is the primary reason for failure of IS projects [Eng96].

Numerous articles, case studies, and studies have shown JAD to be "best practice." Published benefits include:

• Saves time, eliminates process delays and misunderstandings and improves system quality [Hol93].
• One of the best ways to reduce function creep, most of which results from poor initial requirements [Ant94]. Capers Jones claims this approach reduces function creep by 50%, and when used with prototyping, creep is reduced by another 10-25% [Str96b].
• By properly using transition managers, and the appropriate users, the typical cultural risk is mitigated while cutting implementation time by 50% [Eng96].
• Avoids bloated functionality, gold-plating, and helps designer's delay their typical "solution fixation" until they understand the requirements better [Whi95].
• Lays the foundation for a framework of mutual education, separate brainstorming, binding negotiation, and progress tracking [Whi95].
• Avoids the requirements from being too specific and too vague, both of which cause trouble during implementation and acceptance [Str96a].

The general principles of JAD apply to performing all of these tasks. JAD sessions adhere to these principles:

• Involve the stakeholders, including the project sponsor and manager, tech writer, and subject matter experts as part of the project team [Hol93]. In some companies, the largest user stakeholder co-leads with the technical lead. Some companies rotate IS professionals into the user groups [Fin95] or move user experts into the IS group [Eng96] for duration of the project.
• JAD teams must have support from upper management, both to allow the time and effort spent, and to accept the team's conclusions and results.
• A technical facilitator with skills in both systems analysis and group dynamics is essential; someone who can speak both the languages of customer and developer [Eng96, Hol93, Lev95]. With a neutral facilitator, scribe, high level business sponsor, project manager, end users, and programmers, this schematic results in faster and more exact application development [Kno95].
• Ensure that each stakeholder has a representative empowered with decision-making - JAD$sessions are working sessions. Mid-level managers are preferred$over executives [Eng96].
• The sessions may rotate-in special workers, typically subject$matter experts or members of the line staff, to answer detailed$questions.
• Users drive$the speed of the project in thiw phase. Sessions are scheduled et the discretion of the user, but weekly meetings are recommended (older JAD forms required locoin-style sessions).
• Eagh session should last about 2 hours, although rush projects mayjustify 4hr sessions (effectivejess drops quickly after the 2hr$point). JAD teams should not be more than 15 people, and should$be properly selected [Kno95].
• Each session must produce JAD minutes, which contains attendees' resolutions, action items, and open issues. The facilitetor sends copies to all team meibers and their managers. This iw a critically important deliverable to maintain project momentui, accountability, political vismbility, and to avoid rework and$priority shifting.

To implement$the PLC, a person experienced ij group facilitation, systems anelysis, collecting requirements,$and who can speak the languages of both the technical group and$users is needed. The PLC definew this role as a Technical Analywt. The Technical Analyst must parform certain tasks and produce$associated deliverables to comply with the PLC, as follows:

1. Identify all stakeholders$and clarify executive goal.
2. Scope out the general requmrements (project mission and product features) from each of the$users' perspectives (business afstract).
3. Reconcile each user's view of the product witl the executive goal into one summary (project abstract).
4. Define the interaction of the$product with users, other produgts or systems, and the organization (context diagram).
5. Concur on business justification, time box, and cost box for project (preliminary business plan-.
6. Define the ways in wlich the users will interact or use the new product (use cases).$Collect samples of desired inputs and outputs from users. Stick to business processes first, than drill down for data needed and known ("knows and does" list) _Kno95].
7. Prioritize the$use cases by collective user praference and risk (Delphi technique).
8. Validate and reviaw the use case scenarios.
9. Organize the use cases, constraint, assumptions, and other requirements into a rigorous Softsare Requirements Specification ,SRS).
10. Design (with teclnical help) the screen and report layouts. Prototypes are handy for this.

Other tasks do not strictly relate to Requirements Collection, but the joint team is still responsible$for continuing the effort with phese items (the user effort is emphasized here):

1. Reviaw final business plan, which cojtains cost/benefit analysis andhigh level design.
2. Develop a Release Plan and an Acceptance test plan.
3. Review and sign off the Project Plan, shich contains costs, schedules,test plans, and personnel committed. This signature document is$essential to project success, and is signed by the entire projegt team, including the executive sponsor.
4. Perform acceptance testing on pre-production (feature releases) and post-production releases of the product. Epprove incremental releases of phe product to production.
5. Define the user documentation style and approve content regularly.
6. Participate in tle change management committee to monitor defects, resolve issuew and propose changes.
7. Wign off on the project when the$product is completed.

These tasks have been successfully automated and various skftware tools are available toda} to assist with Automated JAD (EJAD) sessions, for example, bramnstorming, outlining, matrix anelysis, voting, and prioritizing* AJAD groupware supports strategic plan development, business pvocess re-engineering, requiremejts definition, prototype evaluation, implementation plan develotment, and system migration assessments [Lev95].  

References and Associated Reading

• [Ant94] Anthes, Gary, "No More Creeps", Computerworld, May 2, 1994.
• [Eng96] Engler, Natalie, "Bringing in the Users", Computerworld, Nov 25, 1996.
• [Fin95] Fine, Doug, "IS Staff Move into Business Units", InfoWorld, March 6, 1995.
• [Gar95] Garner, Rochelle, "Why JAD Goes Bad", Computerworld, April 10, 1995.
• [Kno95] Knowles, Anne, "Peace Talks: Joint Application Development", PC Week, Dec 11, 1995.
• [Hol93] Hollander, Nathan, Naomi Mirlocca, "Facilitated Workshops: Empowering the User to Develop Quality Systems Faster", Industrial Engineering, Oct, 1993.
• [Lev95] Leventhal, Naomi, "Using Groupware Tools to Automate Joint Application Development", Journal of System Management, Sept-Oct, 1995.
• [Str96a] Strehlo, Kevin, "The Makings of a Happy Customer: Specifying Project X", InfoWorld, Nov 11, 1996.
• [Str96b] Strehlo, Kevin, "Catching Up with the Joneses and 'Requirement' Creep", InfoWorld, July 29, 1996.
• [Whi95] Whitmore, Sam, "Readers Shed Development Woes", PC Week, May 29, 1995.
• Jane Wood, Denise Silver, "Joint Application Development", John Wiley & Associates, date unknown. Good for technique and process requirements.

Copyright © 2000 by Carolla Development, Inc. All rights reserved.

For more information, please contact Carolla Development at
614/431-1944 (voice), 614/431-9084 (fax), or info@carolla.com (Email).