Where Are We Coming From?
Way back in the 1980’s (for those of you old enough to remember that far back in time), we in the Information Technology industry spent a lot of time working out new and improved methods for helping the business community discover their needs. One of the extremely successful and powerful concepts was called JAD for “Joint Application Development” (alternatively, “Joint Application Design”), an approach developed and trademarked by a small, unknown organization named IBM.
The primary concept of a JAD session was to get a cross-functional team consisting of subject matter experts and analysts/designers/developers (depending on the focus of the session) locked into a room together with a facilitator (or, even better, facilitation team) that led the group to victory, as in the delivery of a sound, well-developed requirements definition document (a.k.a. RDD, just to throw another acronym into the soup).
The Pending Problem
In those days, JAD sessions were so successful and so popular (in some circles) that many within the IT community decided that this was finally the silver bullet for flushing out and capturing requirements. As a result, the number of JADs (and, obviously, a JAD by any other name smells the same) expanded exponentially until there were more JADs than there were suitable projects. The unfortunate result was a lot of poorly conceived, planned or executed sessions that not only failed to deliver on their promise but, eventually, ruined JAD’s good reputation and led to sessions that no one from the business side of the projects attended.
At the same time that JADs were becoming unpopular due to focusing too strongly on the technology, another minor factor called “Y2K” (for those of you young enough to remember that phase in your development) had a significant impact on the number of business development projects undertaken. Since “Y2K” was very limited in focus and ate up all of the IT departments’ resources, little time was left for gathering requirements for other projects, whether JAD was an option or not.
Reality As We Know It
In recent years, the IT industry has awakened from the doldrums of mediocrity in requirements gathering techniques and a new concept called “JAR” has emerged. As near as I can tell, JAR stands for Joint Applications Requirements Capturing (spoken with a silent “Capturing”). Two other terms that have surfaced are “JRP – Joint Requirements Planning” and “JADr (pronounced “jadder”) as in JAD for (r)equirements. Conceptually, JAR, JRP, and JADr use JAD concepts but focused strictly on business and stakeholder requirements.
“OK,” I can hear you think, “So just what is this ‘JAR/JRP/JADr’ thing and why should I care?” I’m so glad you asked or I would have nothing left to finish this post.
Things to Do in a JAR/JRP/JADr Session
Typical attendees at a JAR/JRP/JADr session include the Project Sponsor, Subject Matter Experts, End User Representatives, the Project Manager/Leader, Business Analysts (a. k. a. Requirements Analysts), plus relevant special interest groups (SIG’s) such as Data Administration, Audit, Security, Legal, and the like.
Common activities of a JAR/JRP/JADr session include understanding the AS IS situation, identifying current business problems, analyzing their causes, determining benefits and capturing the business requirements and/or business rules. These early project activities are often neglected in an effort to “save time”. Based on our experience (and studies too numerous to list), the time saved by skipping these activities usually leads to expensive rework or customer rejection once the system is delivered. The focus on the early project activities enables IT to deliver a quality business solution upon completion of the project.
What Else Do You Need?
There are a wide range of business analysis techniques that are especially effective in a JAR/JRP/JADr setting, e.g. Business Problem Definition and Reduction, Business Process and Data Modeling, Project Scoping Techniques, Cost/Benefit Analysis, Requirements Capture, User Story Definition, Requirements Clarification, and Requirements Confirmation.
Many of the most demanding techniques related to a JAR/JRP/JADr session are those that have to do with the session itself, from figuring out whether to do one for your project to the logistics of the session and on to successful follow-up activities once the session is over. If you decide that JAR/JRP/JADr is a viable approach for your organization, we recommend finding someone who has walked that rocky road before you and can help you avoid the pitfalls we have uncovered along the way. And, before you ask, yes we can help.
Well written article. No doubt JAD sessions have proved to help out many businesses to plan the project and complete it within the set time. It has proved to be a boon to many. JAD comes with a number of advantages and disadvantages too and I just found them in an article. I hope that can be useful to you too. https://www.weblineindia.com/blog/top-15-software-development-methodologies/
Thank you for reaching out to us. We offer training in JAD/R facilitation with the specific focus on defining IT applications. Obviously, many of the techniques we teach for facilitation are generic and would benefit anyone in that role, regardless of what type of session they are facilitating. I would be very interested in discussing this topic with you to better understand what PP facilitation entails, what methodology is currently used, and what problems these folks are experiencing. I am certain that our training approach would benefit them although it would most likely have to be tailored a bit to make sure it is the best fit. In case you have not yet read it, you might check out our white paper at https://businessanalysisexperts.com/Job_Aids_RSG/Facilitating_Requirements_Gathering_JADR_Sessions.pdf. JFI, the copyright for that document is Requirements Solutions Group, LLC. which was a company I previously co-owned. Once you have perused that document, please contact me directly at Tom.Hathaway@ba-experts.com or call me at 702-625-0146 to discuss how this methodology might be modified for your needs.
I am exploring the use of JAD/JAR methodology to support the Public Participation cycle of Environmental Impact Assessment (EIA). Historically PP has under delivered and been a permanent victim of constructivism and the polarized view points of the proposer, attendees, Govt. and public bodies. The feasibility of a program of facilitated workshops to enable PP is under review with the official bodies (Environmental Agency et al) and I am currently preparing a white paper and delivery model. I would be very interested to discuss how facilitators could be trained into a developed JAD/R methodology.
Thank you for your question. The terms JAR/JAD are basically interchangeable. The focus is on the requirements for an IT solution (e.g., app). You might use a JAR/JAD if you have a group of people who need to reach consensus on a set of requirements defining what the app should do.
Please let me know if you need more.
I am planing to design an application for a simple medical test available from the Java
Please let me know whether jar and/or jad concept should be used.
If both or one only can be used, then will the every type of Java phone accept such application
concept and how the user can find out which concept can be accepted by his phone.
I am not the IT specialist, please excuse my basic questions.
Kind regards, Janusz Nowosielski