Joint Application Design/Development

Mei C. Yatco

System Analysis, Fall 1999
Management Information Systems (MIS) Program
School of Business Administration
University of Missouri-St. Louis

Introduction | Origin | Evolution | Other Names | Basic Components of a JAD session | Guidelines for Successful JAD | Benefits | Automated JAD (AJAD) | Conclusion | References


Information System Development (or even the broader Information Technology field) is a relatively new discipline compare to matured disciplines like mathematics, physics or philosophy. It is difficult to find an agreed-upon definition on even a widely used term such as JAD. It can mean different things to different people, and itís constantly evolving. In this article, I will discuss and compare different definition hence different applications of JAD. I will summarize the basic components and benefits of JAD, and guidelines to conduct JAD sessions. I will lastly discuss the new issue with JADóautomation.


Joint Application Design (JAD) was developed by Chuck Morris of IBM Raleigh and Tony Crawford of IBM Toronto in the late 1970ís. In 1980 Crawford and Morris taught JAD in Toronto and Crawford led several workshops to prove the concept. The results were encouraging and JAD became a well accepted approach in many companies. In time, JAD developed and gained general approval in the data processing industry. Crawford defines JAD as an interactive systems design concept involving discussion groups in a workshop setting. Originally, JAD was designed to bring system developers and users of varying backgrounds and opinions together in a productive and creative environment. The meetings were a way of obtaining quality requirements and specifications. The structured approach provides a good alternative to traditional serial interviews by system analysts.[1, 2]


As JAD attained popularity in the 80's, people start to use the term to describe different things. Sometimes just one aspect of JAD was explored and the usage of it expanded, but it is still called JAD. For example, in the 80ís, group facilitation and workshop techniques were also gaining momentum. Some dealt specifically brainstorming session with blank flip charts, large Post-it notes and placement exercises were called JAD.[with "storming, norming and forming" aspects of group dynamics and evolved into conflict management, brainstorming sessions and motivational meetings. These unstructured [1]

In more technical workshops, people focused on computer analysis and applied sophisticated tools in the process of gathering business requirements. These evolved as CASE tools developed into Rapid Application Development and other Development Methodology driven techniques. Sometimes, these CASE technology workshops were also claimed as JAD.[1]

Valiant Information Systems, a software development corporation, uses Joint Requirements Planning (JRP) to obtain requirements definitions and JAD to just define the user and application interfaces for a specific component of the project.[3] Kitty Hung also records the combination usage of JRP and JAD in her research work.[4]

As the popularity of JAD grows, its usage expands to functions other than the requirement gathering in the system development life cycle(SDLC). It is now used in all phases of SDLC and is defined as a system development method. University of Texas at Austinís Information Services defines JAD as "a management process which helps IS work effectively with users to develop information technology solutions that really work." It specifically defines the scope of JAD to cover the complete development life cycle of a system.[5] John Botkin of Public Service Company of Colorado suggests using JAD as one of the tools through out the system development process to keep the users involved all the time.[6]

As we can see, JAD was originally designed to address information system development. A JAD session usually involves some aspects of system design, or, at least, development. But now, the use of JAD techniques has expanded to handle a broader range of challenges. In recent years, it has become a joint venture among any people who need to make decisions affecting multiple areas of an organization Ė it is used even in non-IT related projects. In this case, JAD is defined as a structured workshop where people come together to plan projects, design systems, or make business decisions (whether IT related or not).[7] Today, JAD is commonly used for strategic business planning, strategic IS plans, IS architecture definition, re-engineering business processes, detailed system design, process and data modeling, and project management.[8] This might be the broadest application of JAD so far.

The definition is also expanding on another aspect of JAD -- the location of the session. In the earlier days, definition of JAD includes bring users and developers together in a same physical location[9]. But today, JAD is expanding to include facilitated virtual meetings too. So activities conducted with members located at remote sites using package software and method of computer-supported cooperative work (CSCW) can be called JAD too.[10] Even the physical location is no longer a limit of JAD. People might wonder, where is the end of this, what else will come up and be called JAD?

Basically, people would refer to almost any kind of meeting as a JAD. Eventually the differences became clearer as each adopted a brand name indicating the preferred technique and a following of practitioners. Examples emerged in 4RAM, Forum, Focus, Fusion, Wisdom, Breakthrough, The Method, RAD, JID, JIT, JED, BPR to name a few. Crawford differentiates his approach as Classic JAD. [1]

To add to the confusion, JAD is considered different thing among different people in relation to RAD(Rapid Application Development). Some defines JAD as a requirement gathering tool to be used in conjunction with RAD to compensate for the lack of requirement analysis of RAD, as advocated by Dan Kara in his article "Get It Right The First Time" written for the software magazine.[11] But Ralphs Grocery Co.ís Information Services VP Russ Robinson considered JAD as one phase of RAD that draw the user into the development process.[12] Yet other times, it is defined as an implementation of RAD, as in IT_Analysis.comís web glossary.[13]

Most of the time, however, JAD was used the way originally defined by IBM. Our text book adopted this view of JAD.[14] It is defined as a technique for developing business systems requirements by practitioners like Joy Matthews [15] and OSMC Consulting Services.[16] Dan Kara defines the goal of JAD as to quickly build a consensus regarding business requirements and solution options, and then identify and document the requirements.[11] The OASIS project of the Administrative Systems Renewal Program of the University of Alberta also defines JAD as "a multi-day workshop and is a joint venture between the OASIS project team and end users to analyze and design the requirements for implementing information systems."[17]

Other Names

As the use of JAD expands from the requirement gathering to other phases of system development life cycle, many people now refer to JAD as Joint Application Development. Some of them stick to the original definition of Joint Application Design and still primarily use it as system requirement gathering technique, as did Alan Cline from Carolla Development, Inc.[18] Others like John Botkin and practitioners at Barr Information Technology Services adopted the broader definition of JAD as system development method used through out the system development life cycle.[6,19]

JAD sessions, whether for Joint Application Design or Joint Application Development, have many other names, include: Accelerated Design, Facilitated Meetings, Facilitated Sessions, Facilitated Team Techniques, Facilitated Work Sessions, Group Design, Interactive Design, Interactive JAD, Joint Sessions and User Centered Design.[7] Walter Moeller, a senior consultant with Principle Partners, Inc., calls it Facilitated Information Gathering Session.[20]

Basic Components of a JAD session

Despite the different definitions and manes for JAD, there is one thing common among them -- the facilitated session. JAD is either defined as such a session itself, or contains such a session. The basic components of a JAD session is listed below[6, 20, 21]:

Executive Sponsor: The executive who charters the project, the system owner. They must be high enough in the organization to be able to make decisions and provide the necessary resources and support for the project. They might attend the opening and closing session.

PROJECT LEADer/manager: Generally the leader of the application development team answers questions about the project regarding scope, time, coordination issues and resources. They may contribute to the sessions as long as they do not inhibit the participants.

FACILITATOR/SESSION LEADER: Chairs the meeting and directs traffic by keeping the group on the meeting agenda. The facilitator is responsible for identifying those issues that can be solved as part of the meeting and those which need to be assigned at the end of the meeting for follow-up investigation and resolution. The facilitator serves the participants and does not contribute information to the meeting.

SCRIBE/MODELER/Recorder/Documentation Expert: Records and publish the proceedings of the meeting and does not contribute information to the meeting.

PARTICIPANTS: Customers in the business area directly or indirectly being affected by this project, who are experts in their field and can make decisions about their work. They are the source of the input to the session.

OBSERVERS: Generally members of the application development team assigned to the project. They are to sit behind the participants and are to silently observe the proceedings.

Besides people listed above, each JAD session has well-defined objectives,[6] detailed agenda and guidelines, visual aids, and a final document containing all the decisions made by the group.[22]

Guidelines for Successful JAD

Researchers and practitioners not only recognize a similar list of JAD components, their lists of guidelines for successful JAD sessions have many commonality too. Not all JADs are successful, some are even disastrous.[23] These guidelines are based on research results and personal experiences and are given to avoid failures. They represent the critical success factors and they are to be followed carefully. These guidelines are summarized below:

After all, the most important thing for a project is to use a skilled facilitator. The most important thing for a facilitator is to do a good preparation. Thatís why in Jane Wood and Denise Silverís second edition Joint Application Development, three out of five defined phases of JAD sessions are pre-session activities.[25] These five phases are:

  1. JAD project definition
  2. Research on user requirement
  3. Preparation for the JAD session
  4. Conducting and facilitating the JAD session itself, and
  5. Predicting and obtaining approval of the final document that incorporates all decisions made.

If these 5 phrases are all carried out well, the JAD will be successful. Not one of them should be omitted.


If the above guidelines are followed closely, chances are, the JAD will be successful. A successful JAD session should provide these benefits:

Reduced system development time. In JAD, information can be obtained and validated in a shorter time frame by involving all participants (or at least a representative set of participants) who have a stake in the outcome of the session.[20] JAD eliminates process delays and has been shown to reduce application development time between 20% to 50%. [18,26]

Improved system quality and productivity. Much of the systemís quality depends on the requirements gathered. JAD involves users in the development life cycle, lets users define their requirements, thus ensures that the system developed satisfies the actual activities of the business.[7, 27] JAD is quoted the best method for collecting requirements from the users, customers, or customer advocates.

Reduced system cost. Much of the system development cost is in terms of man-hours of both system developers and business users involved. Reduced development time reduces the labor cost for developers, as well as users. Important process like requirement gathering requires the involvement and commitment of business area experts. The cost of taking them away from their daily operation is very high. JAD can reduce the involvement time of these business experts and hence reduce the cost further. Cost is also reduced by catching errors, misunderstandings and mistakes early in the development phrase. Studies have found that a majority of system errors result from early analysis errors, and the earlier these errors are corrected, the much less they will cost.[28] The JAD sessions let designers and users work together in the very early of the development cycle, defining the scope, requirements of projects, resolving conflicts among different user groups. It put much efforts early in the life cycle in order to improve the quality and increase productivity and to reduce cost.

Enhanced communication and relationship between business end-users and IT personnel.[20]

Cultivate ownership, easier acceptance (buy-in) and stronger commitment by users.[8] The involvement of business end-users is no longer on advisory or consultation spectrum. It is the participation and contribution in the project development life-cycle. The more users contribute to the system, the easier for them to accept it and commit to it.

Reduced function creep. It was cited by Gary Anthes to be one of the best ways to reduce function creep, most of which results from poor initial requirements.[29]

Enhanced education for participants and observers.[20] By participating in JAD and be the medium between other users and IT, the business end-users will be kept fully informed about the progress of the system development.[3]

Under the trends of emphasis on group work, quality and productivity, and attention shift from technology to business, the most frequently cited success indicators for applications were: timely delivery, achievement of business objectives, and building positive communications and relationships with customers. In the meantime, people are expecting higher productivity. Conducted properly, JAD can improvement all of these areas, and contribute greatly to development of a successful system.


Automated JAD (AJAD)

Use of JAD is usually coupled with use of computer aided software engineering(CASE) tools, because use of CASE integrated environments is shifting the bottleneck of systems development from physical design and coding to upstream activities, particularly requirements specification. However, whether to use CASE tools or other automation tools within the JAD process is a question many raised.

Some of the JAD tasks can be automated and various software tools are available today to assist with Automated JAD (AJAD) sessions. Traditionally, word processors are used by the scribe to record the essence of JAD sessions. Sometimes, CASE tools are used to capture models in real time. However, due to its complexity, the use of CASE tools usually slows down the process and becomes the bottleneck. So some practitioners recommend using a scribe who writes with a word processor and a modeler who captures the model with CASE tools. The modeler doesnít have to capture all the information in the real time. He/She can catch up with the help of the scribeís records when the session is going slow.

Companies like, a provider of products and services for electronic meetings, meeting facilitation, group decision support, and collaboration, develop their own software and provide facilitation services using their own tools.[30] Those tools are as easy to use as word processors and provide better functionality than word processors. They provide model tools and better integration of data captured during different phases of JAD session.

There are also groupware designed for brainstorming, outlining, matrix analysis, voting, and prioritizing in an AJAD session. AJAD groupware supports strategic plan development, business process re-engineering, requirements definition, prototype evaluation, implementation plan development, and system migration assessments. Ventana Corp.'s GroupSystems V is such a groupware most widely used today.[31]

The use of Group Support Systems (GSS) or sometimes called Electronic Meeting System (EMS) during the JAD session is also often advocated.[2, 32] A research has done by Dennis, Alan R., Hayes, Glenda S., Daniels, Robert M. Jr. The results indicate that the GSS technique reduced the time required to build models in JAD sessions by about 75 percent. Models built using GSS and the traditional JAD approach had similar numbers of syntax errors. Parallel communication enabled by GSS reduces blocking, enabling participants to contribute simultaneously, so that information is collected faster. Anonymity enabled by GSS encourages participation. A group memory provided by GSS enables members to better integrate information and reduce problems that occur when they inaccurately remember issues previously discussed. However, communication through GSS is less "rich" than face-to-face verbal interaction and it is more difficult to resolve differences among participants with GSS. So the combination of JAD with GSS and traditional JAD might be the best solution.[2]

The Internet and the Web have created many new opportunities for group work. It is now possible to include participants from many remote locations, so that, in theory, the size of the user group can become quite large, including participants from anywhere in the world. Indeed, it would be possible to conduct the entire JAD session over the Web without the need to meet in person. However, verbal discussion remains very important in resolving the differences of opinions among participants and also helped ensure that all participants shared a common understanding of the process. So conducting an entire JAD over the web might not be desirable. Nonetheless, it may be possible to use the Internet selectively to involve a wider set of business users, even outside experts and consultants at specific points in the process. This has the potential to involve users(and those who must ultimately approve the model) earlier in the JAD session to ensure that the session can benefit from a much broader range of opinions to better enable the earlier identification of problems.

According to the advocates of AJAD, it can greatly facilitate the generation, analysis, and documentation of information.[31] It is said that automation adds so much to the JAD workshop, in relation both to the productivity of the session and the quality of the resulting design, that it helps to realize many of the objectives of the AJAD concept. After all, the basic objective of JAD is the positive interaction of all players involved in the systems design process. The automation of the JAD is promoted to be able to facilitate the creation of a team "language," assists in the negotiation process when competing interests surface, and promotes group ownership of the resulting system design. It is said that many organizations have found success in requirements elicitation using automated requirements analysis tools in conjunction with facilitated JAD sessions. [11]

But Crawford, one of the originators of JAD, expresses concerns about the automated workshops. He warns that when inappropriate automation tools drive the pace, failure is more likely to happen. When progress outpaces the learning curve and the ability to absorb, learning and acceptance can be adversely affected. It is also dangerous to try to automate thinking. [32]


JAD is a useful process to gather cross function information and different opinions effectively. Its usage keeps expanding thus its definition keeps changing. Although different people might have different understanding and application of JAD, the essence of JAD is the facilitated session. The basic components of JAD sessions are recognized and agreed-upon by JAD practitioners. They also provide some guide-lines for conducting JAD sessions. Properly following these guide-lines can increase the success of JAD sessions. Automated JAD, especially used in conjunction with Group Supporting Systems, looks very promising, although some experts remains skeptical.




  1. Roman Soltys and Anthony Crawford. "JAD for business plans and designs". Last update time unknown. Accessed Nov. 29, 1999.
  2. Dennis, Alan R., Hayes, Glenda S., Daniels, Robert M. Jr. "Business process modeling with group support systems". Journal of Management Information Systems. 115-142. 1999 Spring.
  3. Valiant Information Systems. "Joint Requirements Planning and Joint Application Design Meetings". Last update time unknown. Accessed Nov. 1, 1999
  4. Kitty Hung. "A Dynamic Business Object Architecture in an Iterative Life-cycle Environment for Information System Development". Last update date unknown. Accessed Oct. 29, 1999.
  5. The University of Texas at Austin, Office of Human Resources Information Services. "Joint Application Development (JAD) What do you really want?" Last update date unknown. Accessed on Nov. 12, 1999.
  6. John C. Botkin. "Customer Involved Participation as Part of the Application Development Process." Last update date unknown. Accessed Nov. 9, 1999.
  7. Adrian Damian, Danfeng Hong, Holly Li, Dong Pan. "Joint Application Development and Participatory Design". Last update date unknown. Accessed Nov. 1, 1999.
  8. Bill Jennerich "Joint Application Design -- Business Requirements Analysis for Successful Re-engineering." Last update time unknown. Accessed on Nov. 14, 1999.
  9. Anonymous. "JAD basics." Journal of Systems Management. 1995 Sep/Oct.
  10. Nobuhiro Kataoka , Hisao Koizumi, Kinya Takasaki and Norio Shiratori. "Remote Joint Application Design Process Using Package Software". Last update time unknown. Accessed on Nov. 14, 1999.
  11. Dan Kara. "Get It Right The First Time". Last update time unknown. Accessed Nov. 11, 1999.
  12. Russ Robinson. "Put the rapid into RAD." Datamation, Feb 15, 1996 v42 n4 p80(1).
  13. "Glossary I-P" Last update time unknown. Accessed Nov. 11, 1999.
  14. Jeffrey A. Hoffer, Joey F. George, Joseph S. Valacich. Modern Systems Analysis & Design, Second Edition.
  15. Matthews, Joy. "JAD to the rescue." Computerworld. 1995 Dec 4.
  16. OSMC Consulting Services. "Services". Last update time Unknown. Accessed Nov. 14, 1999.
  17. Administrative Systems Renewal Program in University of Alberta. Last updated: April 06, 1998 09:31 AM. Accessed on Nov. 14, 1999.
  18. Alan Cline. "Joint Application Development (JAD) for Requirements Collection and Management." Carolla Development, Inc. Last update date unknown. Accessed Nov. 21, 1999.
  19. Barr Information Technology Services. "Joint Application Development". . Last update time unknown. Accessed Nov. 11, 1999.
  20. Walter E. Moeller. "Facilitated Information Gathering Sessions: An Information Engineering Technique". Last Update time unknown. Accessed Nov. 11, 1999.
  21. Bill Jennerich "Joint Application Design -- Business Requirements Analysis for Successful Re-engineering." Last update time unknown. Accessed on Nov. 14, 1999.
  22. Creative Data Inc. "Development Methodolgy - Joint Application Development". Late update time unknown. Accessed Nov. 14, 1999.
  23. Jill Dyché. "New Rules for Business Discovery".
  24. Weldon, David. "The ultimate insiders." Computerworld. 1995 Oct 16.
  25. Jane Wood and Denise Silver. Joint Application Development (2nd Edition) 1995.
  26. Hammond, Glandon & associates. "Course Listing". Last update time unknown. Accessed on Nov. 14, 1999.
  27. Hollander, Nathan, Naomi Mirlocca, "Facilitated Workshops: Empowering the User to Develop Quality Systems Faster", Industrial Engineering, Oct, 1993.
  28. Kenneth C. Laudon and Jane P. Laudon. Management Information SystemsóNew Approaches to Organization & Technology. Fifth edition.
  29. Anthes, Gary, "No More Creeps", Computerworld, May 2, 1994.
  30. MeetingNetworks. "Application Descriptions". Last update time unknown. Accessed on Nov. 14, 1999.
  31. Leventhal, Naomi S. "Using groupware tools to automate Joint Application Development." Journal of Systems Management. Sep/Oct. 1995.
  32. Yihwa Irene Liou and Minder Chen. "Using Group Support Systems and Joint Application Development for Requirements Specification." Journal of Management Information Systems, Winter 1993/1994 p: 25-41.