Search

Thursday, July 24, 2008

Guidelines for Successful JAD

Researchers and practitioners not only recognize a similar list of JAD components, their lists of guidelines for successful JAD sessions have many commonality too. Not all JADs are successful, some are even disastrous.[23] These guidelines are based on research results and personal experiences and are given to avoid failures. They represent the critical success factors and they are to be followed carefully. These guidelines are summarized below:

  • Use experienced and skilled facilitators
  • Get Executive Sponsor’s commitment and support
  • Get the right people to participate, predefine their roles and responsibilities
  • Set clear defined, well understood and obtainable goals or objectives
  • Plan detailed agenda and stick with it
  • Define deliverables clearly in advance
  • Keep Technical Jargon to a Minimum
  • Produce Final Document Quickly
After all, the most important thing for a project is to use a skilled facilitator. The most important thing for a facilitator is to do a good preparation. That’s why in Jane Wood and Denise Silver’s second edition Joint Application Development, three out of five defined phases of JAD sessions are pre-session activities. These five phases are:

  1. JAD project definition
  2. Research on user requirement
  3. Preparation for the JAD session
  4. Conducting and facilitating the JAD session itself, and
  5. Predicting and obtaining approval of the final document that incorporates all decisions made.
If these 5 phrases are all carried out well, the JAD will be successful. Not one of them should be omitted.

http://www.umsl.edu

The JAD session

Despite the different definitions and manes for JAD, there is one thing common among them -- the facilitated session. JAD is either defined as such a session itself, or contains such a session. The basic components of a JAD session is listed below

Executive Sponsor: The executive who charters the project, the system owner. They must be high enough in the organization to be able to make decisions and provide the necessary resources and support for the project. They might attend the opening and closing session.

PROJECT LEADER/manager: Generally the leader of the application development team answers questions about the project regarding scope, time, coordination issues and resources. They may contribute to the sessions as long as they do not inhibit the participants.

FACILITATOR/SESSION LEADER: Chairs the meeting and directs traffic by keeping the group on the meeting agenda. The facilitator is responsible for identifying those issues that can be solved as part of the meeting and those which need to be assigned at the end of the meeting for follow-up investigation and resolution. The facilitator serves the participants and does not contribute information to the meeting.

SCRIBE/MODELER/Recorder/Documentation Expert: Records and publish the proceedings of the meeting and does not contribute information to the meeting.

PARTICIPANTS: Customers in the business area directly or indirectly being affected by this project, who are experts in their field and can make decisions about their work. They are the source of the input to the session.

OBSERVERS: Generally members of the application development team assigned to the project. They are to sit behind the participants and are to silently observe the proceedings.

Besides people listed above, each JAD session has well-defined objectives, detailed agenda and guidelines, visual aids, and a final document containing all the decisions made by the group.

http://www.umsl.edu

Gathering requirements- One on One interview

One on One interviews are the most common methods of interviewing. The technique involves having an interviewee and interviewer, there can be some variations when there is scribe present to document the proceedings. ( normally the business analyst takes down the minutes of the meeting).

The following process will help the interview proceed efficiently and effectively and will help you gather requirements in the shortest time. 

1. Prepare ahead of time: preparation for an interview involves reviewing all prior relevant deliverables, such as project definition and other business planning documents. You should also look into any historical data that is available to see if similar analysis has been performed in the past on a prior project. The interviewer should also take initiative in preparing, scheduling and also reserving the meeting space. Choose an appropriate time to schedule a meeting. Do not schedule meeting at the end of the day. If arranging for a meeting during lunch hours provide lunch, if the meeting goes on for a long time.

2. Conduct the Interview: When the interview begins you should put your questioning and listening skills to good use. Once the interview begins, the interviewer should be flexible to the discussion and lead the discussion where it needs to go. 
   - Answer upfront questions: After the purpose of the project is explained, the interviewee might ask questions about the project, interviewee's role and the purpose of the project, take some time to answer these kinds of questions, and also give the interviewee a chance to ask some questions. 
   - Consider the use of two interviewers: This process might be considered when some one provides large amount of detailed information or this method can be substituted with a tape recorder (prior permission of the interviewee is required to record their interviews).
   - Confirm the time period of the interview:  This helps on focussing on the discussion and helps everyone in providing the requirements in the concise time period.
   - Follow the interviewee's method of sequencing the material
 Ask you questions and listen to their responses, prepare to document the discussion accordingly. 

3. Documentation: After the interview is complete document the discussion and send it back to the interviewee for review. The purpose of the review is to validate that the interviewer has captured the information correctly. 


Communication-Asking questions and listening

The important part of elicitation is the art of communication. Elicitation is dependent upon the successful communication between the client and the analyst. The client must strive to communicate how he or she works today, the changes that need to be made, why the changes are important and the potential consequences associated with the changes made. This information will be turned into requirements by the analyst. The analyst must have strong verbal skills and understand the right questions to ask.  The analyst must also have active listening skills to ensure that he or she understands the intentions of the client. 

Who Is Using the Rational Unified Process?

More than a thousand companies were using the Rational Unified Process at the end of 2000. They use it in various application domains, for both large and small projects. This shows the versatility and wide applicability of the Rational Unified Process. Here are examples of the various industry sectors around the world that use it:

• Telecommunications
• Transportation, aerospace, defense
• Manufacturing
• Financial services
• Systems integrators


More than 50% of these users are either using the Rational Unified Process for e-business or planning to do so in the near future. This is a sign of change in our industry: as the time-to-market pressure increases, as well as the demand for quality, companies are looking at learning from others' experience, and are ready to adopt proven best practices. The way these organizations use the Rational Unified Process also varies greatly: some use it very formally; they have evolved their own company process from the Rational Unified Process, which they follow with great care. Other organizations have a more informal usage, taking the Rational Unified Process as a repository of advice, templates, and guidance that they use as they go along -- as a sort of "electronic coach" on software engineering.

6. Control Changes to Software

Particularly in an iterative development, many work products are often modified. By allowing flexibility in the planning and execution of the development and by allowing the requirements to evolve, iterative development emphasizes the vital issues of keeping track of changes and ensuring that everything and everyone is in sync. Focused closely on the needs of the development organization, change management is a systematic approach to managing changes in requirements, design, and implementation. It also covers the important activities of keeping track of defects, misunderstandings, and project commitments as well as associating these activities with specific artifacts and releases. Change management is tied to configuration management and measurements.

5. Continuously Verify Quality

Often people ask why there is no worker in charge of quality in the Rational Unified Process. The answer is that quality is not added to a product by a few people. Instead, quality is the responsibility of every member of the development organization. In software development, our concern about quality is focused on two areas: product quality and process quality.

• Product quality -- The quality of the principal product being produced (the software or system) and all the elements it comprises (for example, components, subsystems, architecture, and so on).
• Process quality -- The degree to which an acceptable process (including measurements and criteria for quality) was implemented and adhered to during the manufacturing of the product.

Additionally, process quality is concerned with the quality of the artifacts (such as iteration plans, test plans, use-case realizations,design model, and so on) produced in support of the principal product.