Joint Application Design

An introduction and application process 

By Hans Jonasson, PMP

           When you take a project management class, you are likely to be told about the three major constraints of a project – Cost, Schedule, and Scope. You will then spend an exuberant amount of time developing, analyzing, calculating, and optimizing the schedule. Likewise you will review budget categories, analyze depreciation, and determine acceptable variances. However, when it comes to the scope section, very often you will get a 15-minute mandatory session on change control and how to avoid scope creep.

            Okay... So what's my point? Please bear with me for a bit longer. In one of the classes I teach I do a teambuilding exercise where the students, in teams, brainstorm reasons that projects succeed. The one answer that always makes it up on the list, in some form, is "well defined requirements", in other words – SCOPE!

            So, if defining scope is a critical part of succeeding on a project (and I would argue that it is, by far, the most important of the three constraints!), why don't we focus more time and attention on it? Because it is difficult! Very often, customers don't know exactly what they want, the "I can't describe it, but I'll recognize it when I see it" syndrome, or the language barriers between the customer and the project team makes the communication of the necessary requirements a nightmare.

            That's the problem definition (stating that Scope is difficult would have been more to the point, but I'm an instructor so even the obvious takes time to state).

            Joint application design was pioneered by IBM in the late 1970's and the early 1980's, and popularized further by James Martin who made it a key technique for RAD (Rapid Application Development) projects.

            So, what is it? Well, consider a traditional project (I'll look at an IT project for example, since that is my background). First there will be a customer, often a functional manager, who will meet with you and get started, giving you some level project goals. Then you're sent out on the interview circuit – find out what the purchasing department needs, see if the finance group has any requirements (thy usually do!), talk to the material management department, and so on through all necessary departments and divisions.... After that you lock yourself in a room t compare all the requirements, identify the inconsistencies, and try to figure out best way to deal with them.

            In the best-case scenario, you make a few more rounds to all your stakeholders and get an agreement – at worst (and unfortunately this happens more often), you decide to "interpret" the requirements or maybe tweak them enough so they fit together. This will invariably result in a product that is less than the customer wanted.

    However, by using JAD you would bring the stakeholders together into a number of sessions (normally two or four), where they, with the guidance of a facilitator, will determine and come to an agreement on the requirements. By having the stakeholders actually discuss and come to a consensus on system requirements, you are starting out with a greater level of ownership up front. If you also choose to develop and review prototypes during these sessions, you will greatly help the users visualize what the end product will actually look like.

            To get started, select a core JAD team within your organization. Have them get up to speed on the various versions of JAD (as many as there are authors), pick one and start the education process, some of the key steps are:

1. Sell it to your management to the customer. If you don't get buy-in this will fail, so make sure you put together a good sales presentation.
2. Train your core team on the techniques you'll be using (could be Process Modeling, Data Modeling, Prototyping, etc.)
3. Train some facilitators (select people that can lead a discussion, not necessarily the ones that want to do the most talking)
4. Pick a pilot project. Pick something not too large, something that you can afford to learn one and work through.
5. Train all participants (the users in the sessions have to understand the technique)
6. Schedule and run the pilot session.
7. Do an extensive lessons and learned session.

    If you plan it right, you should now have a great foundation for many future successes with Joint Application Designs. Good Luck!