A few years ago Joint Application Design (JAD) was all the rage, however lately I have heard nary a peep from the JAD front until recently. As a result of a couple of customer requests for JAD, I thought it would be appropriate to discuss JAD. Like most processes JAD is neither inherently good nor bad, it is simply another tool that you can use in your quest to create great requirements.
In “Joint Application Development” by Jane Wood and Denise Silver, the authors very succinctly describe what they believe is a problem with “Traditional Design”.
In most organizations, the systems development life cycle begins with the identification of a need, assignment of a project leader and team, and often the selection of a catchy acronym for the project.
The leader pursues a series of separate meetings with the people who will use the system or be affected by it.The leader continues these meetings over time. Often the key people involved are not so easy to reach. But eventually, having documented everything possible, the leader translates copious notes into a personal terminology. That’s when it becomes apparent that the requirements from, say Accounting, don’t mesh with what the Sales department wants. So the leader calls Sales and finds out the contact there is in the field and will not be back until tomorrow. Next day the leader reaches Sales, gets the information, calls Accounting, and of course the person in Accounting is now out of the office, and so on.
When everyone is finally in agreement, alas, the leader discovers that even more people should have been consulted because their needs require something entirely different. In the end, everyone is reluctant to “sign off” on the specifications.Other times, signing off comes easily. But when the system is delivered, it often has little to do with what the users really need.
So what is JAD? JAD was conceived in 1977 by Chuck Morris and Tony Crawford of IBM and centers around a single 3-5 day workshop session where all stakeholders are in a room and can hash out issues and problems without communications delay. JAD consists of 5 phases:
Project Definition – Meetings with the management stakeholders occur (those who requested the system). Out of these meetings, the basic requirements of the project are defined, open issues are identified, and assumptions (business rules) are listed. In addition, the project session is scheduled and the meeting participants are invited. A document is created which will be the foundation for the final document.
Research – Meetings occur with the actual users of the system. Business processes are mapped, design elements are gathered, screen shots are created, and design issues are considered the same way they would be with traditional design. Based on this research, the agenda is created for the session.
Preparation – Visual aids and other materials for the session are gathered and a working document which contains the proposed requirements is created which will be the foundation for discussion in the session.
The Session – This is the foundation of what makes JAD a distinct process. It is a 3-5 day workshop that will use the working document as a guide to define business processes, data models and perhaps even mockups. Agreed upon decisions are documented for the final document.
The Final Document – The information gathered in the session is used to produce the final document which is then sent to the JAD participants for final review in one or more review sessions.
Although there is heavy emphasis placed on the session itself, I would argue that the project definition, research, and preparation are actually the key to the JAD session success. Without good planning, the JAD session simply will not be productive.
Stay tuned for Part 2 where I discuss the roles in the session itself and Part 3 where I discuss JAD war stories.
