JAR/JAD: Rejuvenation of a Requirements Capturing Concept?

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 business 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 business requirements gathering techniques and a new concept called “JAR” has emerged. As near as I can tell, JAR stands for Joint Applications Requirements Capturing Session (spoken with a silent “Capturing Session”). Conceptually, the JAR is an application of JAD concepts but focused strictly on business rquirements. The only minor problem I see is that searching for the term “JAR” on the Internet leads you to topics like canning, bumping against, and fruity ingredients, we need a better name, so we recommend calling it a JAR/JAD (kind of like calling a spade a spade).

“OK,” I can hear you think, “So just what is this ‘JAR/JAD’ thing and why should I care?” I’m so glad you asked or I would have nothing left to finish this article.

Things to Do in a JAR/JAD Session

Typical attendees at a JAR/JAD 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 and the like.

Common activities of a JAR/JAD 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 tools and techniques that are especially effective in a JAR/JAD setting, e.g. Business Problem Definition and Reduction, Business Process and Data Modeling, Project Scoping Techniques, Cost/Benefit Analysis, Requirements Capture, Requirements Clarification, and Requirements Confirmation (and, by sheer coincidence, we at RSG can teach you how to do all of these things.).

Many of the most demanding techniques related to a JAR/JAD 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/JAD 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. Check the side panel or our website for scheduled training dealing with this born-again topic.

On Our E-Learning

Based on our experience to date, we are reassessing how we should schedule our virtual workshops to ensure the most benefit for the most people. We are trying to get everything set up to be able to offer a series of workshops, each of which covers a topic of interest to you, our target audience, and that can be delivered on a single day to make your life easier. Feedback we have received from you indicates that this would make scheduling and, especially, completing our training courses considerably easier. As a result, we have not yet posted our schedule for June and beyond but we will be updating it and keeping you informed as soon as we possibly can. Please bear with us while we adjust our e-learning offers and we look forward to providing you with the quality of training you deserve as soon as we have figured out how to chunk it.

Thank you for your time and attention.

Tom Hathaway and Dan Myers
Managing Partners

Future Feature: "How Process Models Clarify Requirements"