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.