Joint Application Development

From the Electronic Discussion on Group Facilitation

www.albany.edu/cpr/gf/

 

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: john_walker@mindlink.bc.ca

 

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

responses.

 

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]

   PROCESSES

   INPUTS

   OUTPUTS

SUMMARIZE

 

--------------------------------  SELECTIONS ----------------------

OVERALL COMMENTS

From: Bill Lawless bill.lawless@icsbbs.org

-----------------------------------------------

 

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.

 

<snip>

 

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

system problems.

 

From  Peter H. Jones <phjones@smtpgate.read.tasc.com>

-------------------------------------------------------------------

...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

OBJECTIVES

 

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:

 

Then #4:

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

for flaws.

 

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<rachel@hanwell.demon.co.uk>

------------------------------------------------------------

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

desirable links?

 

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.

 

OTHER ISSUES

 

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

that.

 

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 <fearless@roadrunner.com> 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

house.

 

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

documented)

 

*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

 

-Workshop(s) Preparation

*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

*Logistics preparation

*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

they arise.

 

*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

definition.

 

       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

       both

 

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.

Rush Systems.

 

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

       authorities table)

       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)

       Processing requirements

 

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: john_walker@mindlink.bc.ca

 

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

the first.

 

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

      step...

 

  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

organization needs.

 

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 <960128091117_208448786@mail04.mail.aol.com>, Mary Ann Kmetyk

><CMARE@aol.com> wrote:

 

>> 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