Joint application design (also known as Joint application development, or JAD) is a term originally used to describe a software development process developed and deployed during the mid-1970s by the New York Telephone Company's Systems Development Center under the direction of Dan Gielan. Following a series of implementations of this methodology, Gielan lectured extensively in various forums on the methodology and its practices. Arnie Lind, then a Senior Systems Engineer at IBM Canada in Regina, Saskatchewan created and named joint application design in 1974. Existing methods, however, entailed application developers spending months learning the specifics of a particular department or job function, and then developing an application for the function or department. In addition to development backlog delays, this process resulted in applications taking years to develop, and often not being fully accepted by the application users. Arnie Lind's idea was that rather than have application developers learn about people's jobs, people doing the work could be taught how to write an application. Arnie pitched the concept to IBM Canada's Vice President Carl Corcoran (later President of IBM Canada), and Carl approved a pilot project. Arnie and Carl together named the methodology JAD, an acronym for joint application design, after Carl Corcoran rejected the acronym JAL, or joint application logistics, upon realizing that Arnie Lind's initials were JAL (John Arnold Lind). The pilot project was an emergency room project for the Saskatchewan Government. Arnie developed the JAD methodology, and put together a one-week seminar, involving primarily nurses and administrators from the emergency room, but also including some application development personnel. The one-week seminar produced an application framework, which was then coded and implemented in less than one month, versus an average of 18 months for traditional application development. And because the users themselves designed the system, they immediately adopted and liked the application. After the pilot project, IBM was very supportive of the JAD methodology, as they saw it as a way to more quickly implement computing applications, running on IBM hardware. Arnie Lind spent the next 13 years at IBM Canada continuing to develop the JAD methodology, and traveling around the world performing JAD seminars, and training IBM employees in the methods and techniques of JAD. JADs were performed extensively throughout IBM Canada, and the technique also spread to IBM in the United States. Arnie Lind trained several people at IBM Canada to perform JADs, including Tony Crawford and Chuck Morris. Arnie Lind retired from IBM in 1987, and continued to teach and perform JADs on a consulting basis, throughout Canada, the United States, and Asia. The JAD process was formalized by Tony Crawford and Chuck Morris of IBM in the late 1970s. It was then deployed at Canadian International Paper. JAD was used in IBM Canada for a while before being brought back to the US. Initially, IBM used JAD to help sell and implement a software program they sold, called COPICS. It was widely adapted to many uses (system requirements, grain elevator design, problem-solving, etc.). Tony Crawford later developed JAD-Plan and then JAR (joint application requirements). In 1985, Gary Rush wrote about JAD and its derivations – Facilitated Application Specification Techniques (FAST) – in Computerworld. Originally, JAD was designed to bring system developers and users of varying backgrounds and opinions together in a productive as well as 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. JAD has since expanded to cover broader IT work as well as non-IT work (read about Facilitated Application Specification Techniques – FAST – created by Gary Rush in 1985 to expand JAD applicability.
Key participants 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 strategy, planning, and direction. Subject Matter Experts These are the business users, the IS professionals, and the outside experts that will be needed for a successful workshop. This group is the backbone of the meeting; they will drive the changes. Facilitator/Session Leader 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/Modeller/Recorder/Documentation Expert Records and publish the proceedings of the meeting and does not contribute information to the meeting. 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.
… excerpt ends here. Continue reading the full article.
