The Electronic Discussion on
Joint Application Development
From the Electronic Discussion on Group Facilitation
The compilation of posts collected on the JAD (Joint Application
Development) approach was generated by a post from John Walker.
John collected the responses.
In addition, I posted to John a very lengthy reply of my own
which because of its length is supplied in a separate post along
with John's reply to it. Mary Margaret Palmer
From John Walker ..... e-mail: firstname.lastname@example.org
Some weeks (months?) ago, I put up an outline of a JAD for
discussion in the newsgroup misc.business.facilitators and
the Breakthrough Thinking list and received several excellent
Thank you for your many interesting comments. It isn't possible
to replicate all the replies here so forgive me for picking
comments from each. Note that I have separately posted Mary
Margaret Palmer's vast reply in full, so it is not included here.
Here is the outline without comments of my original proposed agenda:
IDENTIFY ORGANIZATION'S MISSION AND OBJECTIVES
IDENTIFY SYSTEM PURPOSES
CREATE SYSTEM VISION
IDENTIFY DECISIONS SUPPORTED
LIST SYSTEM FUNCTIONS
ANALYZE FUNCTIONS [repeat]
-------------------------------- SELECTIONS ----------------------
From: Bill Lawless email@example.com
JAD is most commonly associated with James Martin. He is a
consultant, author and has contributed a significant amount of
literature on the subject of System Life Cycle and CASE tools.
JAD in its complete form extends throughout the development
cycle and usually teams users and analysts through the whole
process not just at the beginning. The minions you reference and
the analysts will make the system successful in operation once
the critical business rules are set by the senior team. Both
need the be very careful of getting to the proper requirements.
What you are practicing are the early steps in the process. Any
time that you can get the senior stakeholders to even consider a
common subject where they get to contribute to the design is a
plus and the positive results you have experienced are a result
of the interest you have in their input. Since you are dealing
with the senior people it is always good to establish the
business policy rules up front with a least some documentation.
As the process gets more detailed assumptions made as to policy
and business rules are often incorrect and result in serious
From Peter H. Jones <firstname.lastname@example.org>
...I would look into the early pre-supposition in your process that
assumes a "system", meaning a solution. By focusing on the system
aspects so early in your process, you allow the stakeholders to escape
discussion of the true business problems involved.
If this is #1: IDENTIFICATION OF ORGANIZATION'S MISSION AND
Then #2: Might be: Brainstorm/Facilitate discussion of business and
process problems - Find out where they perceive the problems and
sources are. List these, prioritize them, maybe do a fishbone diagram.
Then #3 could be: Potential solutions - again, brainstorming, etc.
You want to have this stuff out to open up thinking about solutions
other than traditional IS - People want a silver bullet, and sometime
some of their problems are organizational, human, process-oriented.
When they decide that at least part of the overall solution "approach"
at this point is some type of system:
PURPOSE OF THE SYSTEM
Various purposes of the system are defined, and arranged in order of
priority. The method of prioritization is made explicit and examined
VISION OF THE SYSTEM
From: Bill Chandon <WChandon@aol.com>
A sketch of the future system is envisioned, but not drawn in detail.
The aim is to think beyond the immediate needs, and to anticipate
features that might well be a necessity by the time the system is up a
running. The vision is verified to fulfil the Purpose(s) of the System.
There is a precursor to this that should be accomplished, but usually
isn't. That is, there should be an effort to look at the business
process and be sure that the new system will not be automating
ineffective business process. That sort of work is best accomplished by
a small number of very knowledgeable business architects and information
technology architects. It's typically not good "committee" work.
Barbara Ann Sherman <SHERMABB@SNYBUFAA.CS.SNYBUF.EDU>
I am aware of a firm who is using JAD as their technique for Business
Process Reengineering...in fact...they are specifically using JAD to
help them correctly identify the process to implement - rather
than the proverbial "paving the cow paths"...
so...in response to the individual who expressed concern that the wrong
process might get implemented...it all depends on how the group
approaches it... the success of a tool/technique is as good as the
underlying team that is using it to help implement a solution....any
tool or technique can be used or abused accordingly...
FUNCTIONS OF THE SYSTEM
From: Rachel Bodle<email@example.com>
Here, as above, I wonder whether prioritising the functions loses
something from the point of view of their connectivity? Or is your
prioritised list of features able to encompass key attributes of the
You're certainly planning to achieve a lot in one day - I'm interested
in the practicalities here. How many people? Will the group have worked
together before? How long can you spend on your first three stages,
up to the shared vision of the functioning system? How do you record
what comes out during these stages so that it can be a resource to
those who have to follow through?
Andrea Tannenbaum <IntraGroup@aol.com>
I have done many JAD sessions, years ago. They varied in format and
length from project to project. I am concerned about how much you are
trying to achieve in 8 hours. As Rachel suggests, so much depends on
what has preceeded the session.
SOME RESPONSES FROM ME
A Number of interesting ideas came out the responses to
the JAD. There are some aspects of this particular session
that I should have explained.
1. This is a medium sized enterprise. JADs tend to be run
in the formal systems environment of large organizations
and so I have had to telescope the usual process down to
fit both the budget and the scale of the resulting system.
2. This means that it is not difficult to get the branch
managers involved. However, they do not have a great
deal of technical (IT) expertise.
3. I was fooling around with some ideas from Breakthrough
Thinking, and noticing what a close fit there was between
the two approaches. Some BT ideas are included here.
4. It turns out that an RFP has already gone out, and so I
need to turn this into a process for evaluation of replies
to the RFP!
5. I have about 20 years of systems experience in my
background, and have participated in two JAD's myself.
Summary of Responses
All of the points made are valuable. In the following summary
I've tried to relate some of these to the specific situation, which
I didn't really make clear in the first place.
Several people underscored the need to begin with the business
solution first. Some even suggested that this should properly be
preceded by a review of the business processes themselves lest
we "pave the cowpath".
These are excellent caveats. My own leaning is to take the
discussion to the highest level purpose of the organization
and then work down,
This revealed two broad divisions in JAD, and these are
not irreconcileable. The first approach aims high in the
organization, to get the senior people involved, so that the
system is designed from the very top down, and at least the
preliminary session is aimed at the "business design". The
second approach is not so different, but it achieves this goal
in "pre-scoping" and "scoping" sessions with senior people,
and the JAD itself is aimed at the finer details of design.
My experience, and preference in this case, is for the first
approach. This approach is only practical in small/medium
sized organizations, when the CEO's and VP's are close
enough to the details to "meddle". If you don't get them
involved, they'll try to get their needs met indirectly, which
is a disaster. Ideally, I'd then go onto a second session with
less senior people, who now have the big picture to work
within, and can fill in the details.
In very large organizations, the executive group is often too
far removed to care about the details, and are content to
delegate their responsibility fully. Here, the pre-scoping gives
the broad brush strokes, and the "team" fills in the details.
Being a large environment, with a keen need for properly
interlocked systems, the requirement for formalization is
greater, and the focus on the second "phase" appropriate.
Concern about hierarchy of Purposes? this was an idea that
I took from Breakthrough Thinking, and I'll have to consider
this. Is there a downside to ranking the purposes?
Function Analysis: I'll use a structured systems approach
to diagram the functions, and the data flow between them.
Concern about amount of Time: Yes, this group has worked
together before. I expect them to be quite open about their
needs. They also have a strategic plan, so I expect only to
be doing a 10-15 minute review in the first few steps. We'll
be into the function analysis within 2 hours, and I've asked
for a second day, if we find that we need to run over.
BENEFITS OF THE JAD
We tend to divide between those of us who are goal oriented
and those of us who are process-oriented. The goal oriented
people tend to view the quality of the document produced as
the key to the process, and there is definitely something to
Usually I'm more goal oriented, but in JAD and strategic
planning, I sometimes feel that I should be able to throw
away the document, and have the participants still feel
they've had incredible value from the process.
Again, this seems to divide along the lines of big vs small
organizations. With large organizations, the document is
essential, and has to be high quality. Small organizations
are not used to this formality, however, and sometimes
the document details are useless.
What's valued is the process of communication, and clari-
fication that has taken place.
In this case, the client is embarking on a system spec that
in my view, doesn't have a broad enough scope. The
exercise is for them to see, perhaps in sketch form, the
beginning of a more formal top-down, future-in approach.
If I overdo the formality, they'll OD and I'll lose them.
Once again, thank you all for your great ideas. They have
helped quite a bit.
From Mary Margaret Palmer <firstname.lastname@example.org> Ellen Gottesdiener:
Rather than trying to reply to the specifics of your proposed agenda
(The JAD Process) I will describe my own approach to a client who wants
a JAD for an off-the-shelf system. But first let me assure you of my
credentials on this. I got into facilitation through JAD first as a
documentor and then as a facilitator. I have had training in Atlis PRI's
The Method and in Gary Rush's FAST methodology, both of which are rooted
in JAD. I also highly recommend that you obtain a copy of Tony Crawford's
"Advancing Business Concepts in a JAD Workshop Setting." Tony you might
say is the father of JAD and his book is the final word on current day
applications of JAD. It also contains detailed documentation guidelines
for the documentor which brings me to my first reaction to your description
of JAD. You didn't mention that a JAD results in a design document which
IMHO is the most important product of a JAD. If the JAD results in a
poorly written document, you might as well as not had the JAD.
The other thing that I would like to point out before moving on to the
JAD process itself is that in the actual JAD workshop or workshops
(depending on the size and complexity of the system) the participants
should be those with profound and/or expert knowledge of the functions,
processes, and data the system will address. This is not necessarily
the VPs or managers. In fact it usually isn't. I always want to have
he "real" users of the system present. The VP and manager types I
usually involve prior to the workshop(s) by holding a scoping meeting
which I will describe below.
A few words of warning about JADs for pre-packaged software. I have
found that at least 2 or 3 of the participants will have a particular
package already in mind when they walk into the workshop and they will
try to influence the JAD participants to define a system that looks like
the one they want to purchase. It can be a challenge to get these people
to even consider other possibilities but it can be done. Also I have yet
to see an organization purchase an off the shelf package that didn't
require modfications before it could be used--so you end up having to
define just about everything you would if the system were being built in
Overall the major steps or phases of the JAD process (as I approach it)
include the prescoping meeting, the scoping meeting, workshop preparation,
the actual workshop or workshops and the validation meeting. Each are
discussed in detail below. (and I do mean detail)
-the pre-scoping meeting (the initial meeting with the client which may
or may not be the one paying the bill) I assume you have done this and
that is where you got the information to start building your agenda.
-the scoping meeting (a documented meeting that usually takes about 3
hours) here the executive sponsor (the bill payer), the project leader,
and other high level manager types (those whose departments will be using
the system) meet to define the following: (note this meeting should be
*The purpose of the JAD or design workshop (note: not the system)
*The objectives of the JAD
*The scope of the JAD (really important for you as the facilitator).
The scope defines what can and cannot be discussed during the design
workshop. Typically it is what is out of scope that you need to pay
attention to. For example, one thing that might be out of scope (should
be IMHO) is brandnames. Another might be funding. Should other systems
be in or out of scope.
*The risks and rewards of developing or purchasing this system
*A complexity diagram (which is optional depending of the complexity of
the system) For complex systems it is a must. The complexity diagram
is a matrix that identifies on one axis the major business functions the
system must address and on the other axis identify the organizations
(business units) that will be impacted. Then check off the boxes where
the organization participates in a function. This will help identify
participants, the next step.
*The workshop participants--all the checked boxes in the complexity
diagram should be represented.
*Deliverables--the information the final document should contain
*Relevant documents that need to be made available to participants
*Workshop(s) dates, times, and locations
*Send invitation and scoping document to participants
*Prepare tentative agenda
*Interview participants taking with you the tentative agenda and a list
of the participants if it is not included in the scoping document. In
addition to discussing their issues and concerns and answering their
questions about the JAD process, you will want their feedback on the
agenda and also the list of participants (is anyone missing?)
*Finalize agenda and workshop design
*Meet with documenter
-The Workshop(s) itself (for really large and complex systems I have had
workshops that address nothing but the functions or the data which can
takes 2 or 3 days by themselves) But overall these are the components of
the JAD process (the agenda) that I would include for your particular case.
*Workshop administrivia--ground rules, decision making rules, etc. You may
also want to employ running lists of assumptions, constraints and issues as
*Review of workshop purpose, objectives and scope (is everyone singing
from the same hymnal?)
*Define the purpose of the system. Keep it simple.
*List System requirements--because this is for the purchase of a system
these requiremnts should be written so that they can easily be inserted
into a RFQ or RFP. You might also want them to identify with are required,
desired, optional using their terms which are usually standard RFQ
language. Requirements answer questions like
How the system must perform?
What must it be able to do to satisfy the user and management?
What must it interface with?
What platform(s) must it be able to run under?
What are the time and cost requirements?
What must it contain?
What hardware must it run on?
What software must it be developed in?
*Identify Critical Success Factors--CSFs are those things that must occur
or be in place for the project to succeed. They either fall into the
category of "Do or Die" or into the slightly less critical category of
Really Important Management Issues (RIMIs). Not doing a RIMI will hurt
the project but it will not cause it to fail. However, collectively,
RIMIs can cause failure.
The difference between requirements and CSFs is that requirements focus
on what the system must do or be and CSFs are focused on what must occur
within the organization and the project in order for the system to be
realized. For example, a system requirement might be that the cost of
development not exceed 100K, whereas a CSF would be that the funding (the
100K) must be allocated.
*Create a context diagram with the system in the center and all those
organizations, systems, and individuals that either provide input to the
system or receive outputs from the system around it. Arrows identify which
way the information flows. This is high level diagram only. Detailed
definitions of the inputs and outputs are captured later in the JAD as
part of interface requirements--if you go to that level.
*Identify current workflows (processes) and improve them. This is OPTIONAL
service I provide and I only do it if it has become obvious from my analysis
that inefficient and ineffective processes exist. As I tell them you don't
want to stick a new system on top of outdated inefficient processes. This
can be done using any of several process improvement methods. I use high
level block diagramming.
*Now I am ready to do the functional decomposition. The following is from
my training manual:
The functional decomposition diagram is used to identify the functions,
activities, and tasks that the system is to perform. The information
identified in the context diagram, system requirements list, and the
process models will help guide this process. Using a brainstorming
approach, the participants are asked to identify all the activities that
must be performed in order to fulfill the system purpose. The focus is
on WHAT those activities are, NOT on HOW they will be performed. You must
continuously reemphasize that what you want them to identify has nothing
to do with technology. The activities should be described in a way that
does not indicate whether a machine does them or a human being. For
example, an activity might be "Find out who had a birthday during the past
month." It is NOT "Update birthday file."
Gary Rush advises telling the participants, "You no longer have an
organization and computers to do the work. You now have a warehouse with
100,000 clerks. What would they do?"
This is a bottom-up approach. Some methodologies employ a top down
approach identifying functions first and then the activities and tasks that
fall under them. Each activity starts with a meaningful action verb and is
recorded on an individual piece of paper, magnetic, or post-it. Providing
participants with a list of possible action verbs can be of some assistance.
Either the faciltator working with the whole group or the participants
working in small groups records the information. In either case, all output
is displayed before the whole group. Only exact duplicates are removed.
Occasionally stop and read what you have collected so far. Don't attempt
to group them in anyway until all have been posted. Remember to remind the
participants to print with large, legible letters.
The next step is to start grouping or "rolling-up" the activities posted
using the following guidelines.
Look at the activities for common nouns and group them together.
Pick an activity from the grouping and ask, "Why do you do this?" Then ask,
"Are there any others in this group that you do for this same reason? If
there are, roll them up together into one activity. You may have to write
up a new card. Continue this process of grouping, rolling up, and
validating the groups.
Each grouping represents a function. Have the participants name
the function. Function names are usually "gerund phrases. That is, a
noun followed by a gerund with is a verb acting as a noun and usually
ending with "ing," "ment," or "tion." Examples are Inventory Management
and Order Processing. Avoid meaningless functions such as Management
Reporting, they have no specific goal. If the group includes a number of
these, have them define the goal. If they cannot, write these as a side
list of "concerns" and continue with the functions.
You may find that sometimes you end up with several activities that
are actually performed as part of another activity. These activities can
either be listed as tasks under the activity or included in the activity's
Each function is numbered 1.0, 2.0, 3.0, etc. Each activity starts
with the number of the function it falls under followed by a decimal and
its place number in the list, i.e., 1.1, 1.2, 2.1, 2.2. A task is assigned
a third number that identifies the function and activity it falls under,
i.e. 1.1.1, 1.1.2, 1.2.1. The order of the functions is not critical
although there should be some kind of logical flow to the final listings.
When the group agrees about the functions and the activities that fall
under them, you are ready to move on to defining them. Defining the
functions, activities and tasks identified in the previous process can be
accomplished in several ways depending the amount time available during
the workshop for this process.
If there are not many items to define, the definitions can be generated by
the group as a whole with the facilitator and/or documenter capturing the
input. One approach is to connect the documenter computer to an LCD display
panel and display the definitions as the documenter captures them.
If there are many items and/or not much time the items can be defined by
small work teams organized by areas of expertise. The teams record the
definitions on forms and the definitions are either read to the participants
for validation or entered into the document where they can be reviewed prior
to the validation meeting. If the latter approach is used, make sure the
person recording the information on the form, puts his/her name on the form.
Whatever method is used, the information that should be included for each
function, activity, and task is
the function/activity/task number
the descriptive name assigned to the function/activity/task
a detailed definition of what happens or is accomplished
for activities, who is responsible for that activity
for tasks, whether it should be automated, performed manually, or
Note: For tasks, the descriptive name is often sufficient for a definition.
Because of this you may want to only define functions and activities and
list the tasks with their associated activity definition.
*Identify the data I notice you didn't address this but this is as
important as the functions. If the new system will be absorbing any
smaller systems especially if several smaller systems are addressing
duplication data this needs to be addressed. I did a JAD several months
ago where numerous systems were going to be replaced with one mega system
and although these small (parochial) systems contained much of the same
data, the names,formats, and attributes varied greatly. From what you
wrote I assume you don't want to get into data modeling or building an
entity relationship diagram. But just in case there are many data modeling
methodologies. The one that is recommended for use by facilitators is
documented in detail in the booklet "Data Modeling Made Easy" by M. G.
Basically I ask participants to identify the "things" (persons, places,
things, or events) about which they keep information. The criteria for a
thing is that it must have more than one piece of information describing
it and that it not be an example or type of another "thing". Customer is
a thing (entity). Customer name is not it is an element--a piece of
information that is kept about an entity. There is usually not that many
entities. After the entities are identified, list all the information
that is needs to be kept for each entity. This is your data and this is
what you define. The type of information that needs to be included with
each data element definition can vary by the amount of attribute detail
desired by the client. Generally for each element you want to include
its type, format, length
its source of input (forms, interfaces, calculations)
the method of input (data entry, machine-generated)
validation information (is there an associated validation or
examples of input
*Identify interface requirements -- you may feel the context diagram is
sufficient but just in case . . .
Interface requirements address the people, organizations, and systems who
will provide input to or receive output from the system as identified in
the context diagram. The process identifies the information that will be
entered into the system and how it will be entered. And, the information
that will be
generated and passed by the system and how it will be passed (output).
Output from this process will be used as input to screen or report design.
The participant input that is collected should include the following:
Interface or report name (identifier)
For input: the source and where and when it is received and how
it is entered
For output: the purpose, audience, and frequency of the report
Data elements it must contain (the data element lists will be needed
for this process)
Note: Previously undefined data elements can show up during this process.
If this happens, fill out a data element definition form for it. At the
end of this process return to the data model and integrate the additional
elements into it.
*Now close out by developing an implementation strategy: develop a
(transition) schedule and assign roles and responsibilities
*Address issues and wrap-up setting a date for a validation meeting
-Hold a validation meeting to validate the document as correcting reflecting
what was decided during the workshop. This is not a time to redefine or
change the design. Participants should be given about a week to review the
draft document so your documenter needs to be consulted as to when they
will have the draft ready.
From John Walker ..... e-mail: email@example.com
I'm now getting a chance to sit down with, and go over your JAD notes
in detail. They really are a great help. Generally, they correspond close-
ly with the processes that I've been through, and your notes have helped
fill in a few details that I'd overlooked. I really appreciate the effort
that has gone into this, and I'm trying to pull it together--with your
permission--into a generalized document for use with clients.
It is interesting that in spite of the similarities, the process you
describe has a slightly different focus from the one that I'm used to. I
can see that yours is the true "JAD"--the design process resulting in a
design document. And yet the CIO that I worked for had had experience with
JAD in a banking environment, and she, and the consultants we hired to
facilitate were equally adamant about involving the high-level people from
Based on the success we had, and my subsequent thinking, I'd like to
suggest a broader definition of the JAD process than the one suggested
by your statement:
>This is not necessarily the VPs or managers. In fact it usually isn't. I
>always want to have the "real" users of the system present. The VP
>and manager types I usually involve prior to the workshop(s) by holding
>a scoping meeting which I will describe below.
This is not to say that your definition of a JAD is not accurate, but I'd
like to convince you of the benefits of an upwardly extended process
where it is feasible and possible.
The first JAD we ran included the President and four VPs! Also attending
were a few technical people, however, these people were there primarily
(at this point) in an advisory capacity, to provide the VP's with reality
checks, where needed. I was Project Leader, Director of IS, and there only
to observe and provide input where needed. Generally the VPs went at it.
It was an eye-opening experience for everyone. I don't think that the VP's
had really understood what the operation as a whole looked like up until
that point, in spite of the fact that they met and talked about it every
week! Of course, nobody else did either but those of us below the VP level
had neither the responsibility or the pretension to do so, whereas each VP
had been interfering on a regular basis with decisions, without a real
appreciation for what other groups (including IS) were up against. They
also began, for the first time perhaps, to appreciate the complexity of IS
projects where all departments were involved (this was an accounting system).
As a result of this session, the interference that we had been experiencing
from VP's began to diminish. They had slogged it out toe to toe during the
session and it made them realize that there was far more going on, and more
complexity to each other's operations than they had realized.
What we didn't do (the budget was a problem) was have the kind of
follow-up session with the next level down, to piece the details together.
I can't remember why exactly this didn't take place. I left the organization
not long after that first session, so only heard about it through the gv.
[I had been working for a non-govt regulator that the government grabbed
and we became govt employees. I didn't like the idea of that so I just stayed
for the transition year, and then moved on into my present career.]
However, that session should have had exactly the format that you
are advocating, with the detail people putting together the final spec.
I think that they had a heck of a time doing so simply because they
didn't run the second JAD.
Having fought this through, I'm more inclined now to see this as a
kind of intelligence gathering continuum. Here's the sketch.
BACKGROUND TO THE JAD
1. Strategic Plan
This is an essential first base to identify, and have as a familiar
orientation point, the Mission of the organization, and the purposes
served toward that end by individual groups.
2. Business Processes
Each department within the organization should now serve one
or more purposes. What are the business processes that best
serve each of these ends?
2. The Information Plan
This describes the information needed to serve the mission and
purposes described above. This should include formal and
informal needs. The data that serve these needs are then
identified, as well as the sources from which they are obtained
and the channels along which they flow.
THE JAD PROCESS
This is for the specific design of a specific system.
There are really two steps.
1. Ensure that the steps above have been completed
and provide solid information. If not, then embark on a
first, high level JAD of the kind that I have described.
In a large and up-to-date organization, this discussion
will have been carried out ahead of the system acquisition,
with the result that the org can go straight into the second
2. Having described the scope of the system and the
underlying purpose and objectives, a second "design"
JAD of the kind that you are describing is essential.
And it should follow all the caveats and processes
that you have advised to the letter. You've provided an
exact and most helpful description.
However, there are dangers in assuming that the first step
can be routinely covered in the scoping session.
1. Paving the Cowpath
A computer system brings formalization and therefore a certain
amount of rigidity to the present system. Furthermore, the system
will change the business processes, and open up new options. If
this isn't anticipated, the new system will often be found to be the
wrong one for the new processes created! This is like aiming at
a duck in flight (and me a vegetarian and birdwatcher!), instead
of where the duck will be.
A number of people who responded cautioned against this
"paving the cowpath"--as one person put it. Several people
emphasized the need for a review of the business processes
themselves before even my definition of a JAD! You have
mentioned it, but describe it as an option. This is a tough call in
an organization that is not undertaking CPI, because it expands
the scope of the project too far, and may exasperate the sponsor.
For systems like accounting systems, the VPs must be involved.
There is still a tendency for accountants to see these systems as
primarily a bookkeeping problem, with the executives getting
whatever the accountants can give them. The accounting system
is THE key control system in an organization; its outputs in terms
of executive and management control need to be defined first and
THEN the bookkeeping problems can be solved.
2. Outdated views of IT
There is another difficulty with a failure to involve VPs, and that
is their failure to understand the role of IT in supporting every level
of the organization's information processes. This identifies the
organization as being still stuck in the second generation thinking:
of MIS being the highest level of information strategy that the
While executives remain "above" IT, they cannot possibly make
quality strategic decisions about IT. They see middle management
as the source of their information and are neither learning the tools
of the modern era, or understanding its future contribution. They
cannot be primed for the creep of EFT, EDI, electronic mail
and a myriad other developments.
This is not to take the gee-whiz view that IT will replace everyone
and everything. But the opposite extreme is no more enlightened.
So. Where it is possible to do so, the organization seldom loses out
of taking the chance to return to basics, and review--and where
possible, revamp--the business processes on which the system
will be based, as the system is being designed. I believe in many
instances that--certainly where it is possible, or can be
encouraged--the involvement of higher levels is of great benefit
in the future success of any systems effort.
For all the reasons mentioned, it may be a difficult struggle to
involve these levels; and for small impact systems, it may not be
appropriate. This may well have been the case in the organizations
or systems that you have worked with: the attempt to involve
the VP's may have hurt your credibility rather than helped it, or
it may not have been appropriate anyway.
Later posts explaining RAD vs JAD from Carol J. Nuebler
>In article <firstname.lastname@example.org>, Mary Ann Kmetyk
>> I need information on the Rapid Application Design RAD and Joint
>>Application Design JAD process used for Information Systems projects.
I'd like to know if there's a specific format used to conduct meetings
with users and in
RAD is a development methodology that uses itterative prototyping,
timeboxing and user participation during the development cycle.
Essentially your users, tell you what they want, use
the various prototypes and give you feedback along the way.
JAD is a technique that can be used during the RAD lifecycle to do
project planning, requirements gathering, feedback sessions. The use
of a facilitator is often helpful in working with the RAD teams to
enhance communication. I usually didn't change the format of my
sessions when working with teams that did RAD development versus
traditional development, since they still need the same types of
information. The improvements I saw came from increased user
commitment and the tight timeframe that the team had to build the
From Edward S. (Ned) Ruete
JAD was invented by IBM. It is basically the welding of facilitated meeting
techniques with user-centered information systems requirement modeling
techniques. (I attended a course on "JAD-like workshops" hoping to sharpen
my skills in the modeling techniques: unfortunately, I overlooked the word
"like" and found out it was a course on facilitation techniques.)
When JAD originated, the modeling techniques used were primarily DeMarco's
structured analysis with Data Flow Diagrams and relational database design
with Entity/Relationship Models. While each of those is far easier for the
end user to understand than the old monolithic Gothic novel text-based
specification of the 60s, they are still a stretch. I have seen some
excellent facilitators explain the modeling approaches and bring a JAD team
through the process with excellent results. However, it requires an
extremely rare blend of technical knowledge, business knowledge, and
There are other modeling techniques that can be used for JAD that may not be
"classical JAD" but certainly fit the spirit: IDEF modeling and
object-oriented modeling are two that come to mind; also naturual-language
information analysis method (NIAM) modeling works pretty well with groups.
The key to use of any of them is to ask questions about the objects that they
deal with and then, in front of their eyes, translate their answers into the
components of the model being used and explain how the model reflects what
they just said. Object oriented has the advantage that the translation is
more direct and understandable than for most of the other techniques.
RAD is an outgrowth of prototyping. Even the best JAD techniques leave the
participants wondering if things could really work the way they envisioned
them in the design session. Prototyping said that the best way to overcome
that is to provide a skeleton system that they could try out and see how they
liked working with the system they described. But a working prototype is
missing a lot of capacity and security and backup and arhiving and other
infrastructure type things. In pure prototyping, the prototype is done in a
quick-and-dirty environment, then thrown away and the real system done in a
production environment. In rapid application development (RAD), the
prototype is done in an environment that combines quick-and-dirty application
development capabilities with infrastructure capabilities, so that the
prototype is rolled into the final system rather than discarded. The aim of
RAD is to shorten the time between prototype and production system, to
achieve several aims:
Not have the requirements change before the system gets out
Get something out when people need it, not two years later
Keep momentum and enthusiasm up
Put out frequent system updates, adding and changing functionality
every several (nominally 6) months to keep up with needs
Reduce the sunk cost of a monolithic system, adding small and
inexpensive increments, keeping some that are good and throwing away others
that don't work when they're rolled out.
Just like facilitation, each of these (RAD and JAD) can be reduced by
fundamentalists to a single, one-size-fits-all step-by-step method.
Conversely they can be seen as a goal that requires understanding and
learning and practice and innovation at many levels to achieve.
And in response to Edward's post (above),
NOTE: I apologize for having lost the authors name.
RAD is an outgrowth of prototyping. Actually, RAD evolved out of the
attempt to deliver s/w quicker, origianlly using a code generator in
the VAX environment, thinking that it would save lots of time. it only
saved a fraction. the orginator of RAD was Scott Schultz at DuPont who
called it RIPP rapid iterative production prototyping...James Martin's
wife, Carma McClure attended a conference in which Scott described his
technique and, to make a long story short, Jim came to DuPont, picked
Scott's brain, and whola: the book "RAD" came out and many credit it to
RAD definately makes use of prototypes, in an EVOLUTIONARY (not throw
away) fashion. it is more than that, tho. it is also a SMALL team,
highly skilled,great tools, customers on the team, timeboxing as you
say and delivering interations. oh yeah, a dirty secret: must have the
technical infrastructure in place FIRST before the timebox door is
opened! (p.s. i was pleased to really get the real story as a result
of some research into it because I started working with a client to
facilitate in what they were called a RAD project (it was not).
subsequently, I wrote an article about the real history of RAD in Appl.
Development Trends, August 95 issues. I have since faciliated on a RAD
project, using Use Cases (didn't call it that). it is truly a timeboxed
project also making use of "heavyweight" team, very hot in manufactoring
today ala a HBR series that ran several years ago.
All your comments re: RAD are very true and perceptive. RAD is more of
a methodology/peopleware/tool/controlled scope creep thingie..very
difficult for management to TRULY grasp...
RAD also always makes use of facilitated sessions, because they are so good
at accelerating the whole risk assessment, analysis, design/prototype process