ARTICLES (Part One)

Facilitated Information Gathering Sessions:
An Information Engineering Technique

Copyright © Walter E. Moeller

 Part 1

 Part 2

 Introduction 

 back to top
This article provides a practitioner's view of a technique used for gathering information from a group of Subject Area Experts (Business Partners and Technical Partners). A variety of different objectives are achieved using this technique. These could include development of an Enterprise Data Model, Logical Data Model, or a Physical Data Base Design. It also works well to identify Function and Process requirements. It has been used successfully for Total Quality Improvement analysis projects. This article will provide an overview of the Facilitation Process. I recommend that you call Mr. Gary Rush, M. G. Rush Systems, Inc., Barrington, IL. (312) 304-1464, if you are interested in obtaining formal training in Facilitated information Gathering.

I will discuss how this technique fits into an Information Engineering Approach to Business Systems Development. I will discuss how ICASE tools can assist in the recording of the findings of a Facilitated Information Gathering Session.

I will discuss the benefits, objectives, Critical Success Factors, roles and responsibilities as well as the potential risks of using Facilitated Information Gathering Sessions.

I will illustrate my preferred room layout and discuss the important factors to consider when you conduct a Facilitated Information Gathering Session.

This article discusses the pre-session planning, the execution of the session and the post-session requirements.

I would like to discuss with you a practitioner's view of a technique called Facilitated Information Gathering and discuss how this technique can be used within an Information Engineering environment. This is the generic name for organized meetings with a predetermined objective. You may have heard these referred to by IBM as Joint Application Design (JAD) sessions, or any one of several other TLA's.

In any discussion I believe that it is important to have a common understanding of the terms being used. Therefore, I would like to begin by providing the definitions for a set of terms that you probably see a lot these days. I will be using these terms within this discussion so I want to provide my view of the definition of them, because I view them as inseparable parts of the Facilitated Information Gathering Technique:

  • Facilitated Information Gathering Session,
  • CASE,
  • ICASE,
  • Information Engineering, and of course, the ever popular,
  • TLA.

 Definition of Facilitated Information Gathering Session 

 back to top
A Facilitated Information Gathering Session is the process of using a structured meeting format with a group of Business Partners and/or Technical Partners to define and record business requirements. These sessions follow a predetermined agenda developed to obtain a designated deliverable. Facilitated Information Gathering Session can be used to achieve different objectives within the Information Engineering approach to business systems development. These objectives may consist of the development of an Information Strategy Plan, the identification and documentation of the data or process requirements for a business area, or even the very detailed objectives like the development of screen and report formats, or the recording of process specifications.

 Definition of CASE and ICASE 

 back to top
Computer Aided Systems Engineering is what I mean by the acronym of CASE. Computer Aided means the use of automated tools for the business systems development process. This incorporates much more than the traditional processes used within Management Information Systems organizations to develop computer application software to support specific business requirements. That concept is quite often referred to as Computer Aided Software Engineering. This tends to focus only on the lower CASE (design and construction) phases of the business application software development life cycle. I refer to this lower CASE approach as the WISC Methodology (WHY ISN'T SOMEONE CODING, AKA WATA - Where are the Applications).

My definition of CASE also includes: the development of an Information Systems Plan to identify where Information Systems can be used to support business goals and objectives, and the identification and prioritization of Business Areas that should be analyzed to determine what data is needed to support this business area This will also allow the organization to decide what processes should be performed on that required data. It is possible to find a wide array of tool vendors that propose to sell you their CASE tools to do any thing from etch-a-sketch drawings to sophisticated rigorous full systems development life cycle development diagrams that feed into application code generators.

Some vendors (such as KnowledgeWare) and practitioners have now begun to discuss this later set of tools as ICASE tools. This stands for Integrated CASE. This new variation implies that several tools work together, with seamless interfaces, throughout the systems development life cycle, through integration into a common repository or encyclopedia. The information identified and recorded in the early phases of the business systems development life cycle is made available and used as appropriate in later phases of the life cycle, or during the life cycle phases of another project. This proposes to increase productivity by using work that is already completed and stored within the ICASE tools.

A word of caution here: I believe the primary benefit of CASE or ICASE is not initially higher productivity, it is the development of more functionally complete systems. Productivity gains will occur after you have completed the first couple of projects and when you attempt to enhance or make maintenance changes to systems that were developed using the Information Engineering Approach. All of the factors involved in becoming a proficient ICASE practitioner will actually cause your initial projects to take longer than if you used the traditional WISC Methodology approach. As you work your way up the learning curve, and begin populating the ICASE repository, you will begin to achieve the productivity enhancements that some people propose as the first benefit of ICASE.

I believe there are several components that must exist and be used together to make the culture of the Information Systems Development utilizing CASE or ICASE the worthwhile process that it can become. These include:

  • Methodology,
  • Techniques, and
  • Tools.

In order to use ICASE to change your business systems development culture to be more effective, you must establish a layer of skilled practitioners around the ICASE components. These skilled practitioners must be supported by experienced Project Managers, which is in turn are supported by a well educated and informed executive management team.

Last and far from least, all of this is wrapped within a nearly impregnable layer of the business' culture. The development of Information Systems is by comparison an easily attained task, compared to the challenges of modifying an organization's culture.

Do you have any illusions as to why it is such a challenge to implement ICASE within your organization when you look at it from the framework of all of the interrelated components?

The components of ICASE work together best when supported by significant doses of education and training. If you have any confusion understanding why I propose these as separate considerations, think about this in light of a story related to me several years age. I have three teenage children, so this story definitely struck home for me. Would you prefer that your children participate in school classes for sex education, or sex training (there may be value, or need for both, but what is your objective?). I find it very important to provide education to management about the process and benefits of Facilitated Information Gathering Sessions, and it is necessary to provide training on how to perform the tasks of the sessions to the practitioners that will be involved in ICASE projects using Facilitated Information Gathering Sessions.

 Definition of Information Engineering 

 back to top
Information Engineering has many formal definitions provided by successful people like James Martin and Clive Finklestein, but I prefer a less formal definition as an Information Engineering practitioner. I like to think of Information Engineering as a set of methods, tools and techniques for getting the right information to the right people at the right time within a specific business or culture . If we could achieve that on a consistent basis I think we could declare ourselves successful, as an Information Services Industry.

Information Engineering is not business as usual, it is a revolutionary way to achieve strategic advantages for our organizations through the use of Information Systems. It is based upon the following Information Engineering Principles:

Educate the project team to use data centered requirements definition, from an Enterprise wide perspective. This principle is a strategic objective that will require major culture change in many organizations in which people or organizational units think that they own their data. Data is an Enterprise resource and must be defined, recorded and maintained as an Enterprise asset that is not duplicated, but is available to all who need access to it.

Data Requirements should be defined and recorded as the first step of an Information Engineering project. These requirements will assist in the documentation of the boundary and scope of the project. They will also provide a solid foundation for the development of a non-redundant shared data architecture for future business systems.

Encouraging the formation of a partnership between the Business Partners (previously referred to as "those Users") and the Technical Partners (previously referred to as "those #*?#!* programmers") within an organization to achieve a mutually advantageous strategic advantage through the application of Information Technology in support of a business objective.

Establishment of significant participation of key business partners to provide the business requirements for new business systems. This does not mean you provide the people who are available. It means you provide the people that you can not possibly do without for a minute. These people are defining how you will compete within your marketplace for the next few years! Who would you prefer to have making these decisions and defining those requirements?

Establishment of Project Management by the Business Partner to ensure the attainment of their business requirements, not just computer systems requirements. This also implies sharing the responsibility for the success or failure of the project. If the project succeeds the technical partners and the business partners both win, but if the project fails, both partners must be held accountable.

Establishment of a culture that requires (or allows) participation of the Technical Partners to provide only the methodology, technique, tool and technology expertise. These people are Information Systems technicians. They should decide what technology to use to achieve your business requirements. They should not be the ones to decide what your business requirements are for this new business system. I have been told by some business partners that they think the development of Information Systems takes too long, and they just want the Information Systems people to throw something together and then implement it. If it does not quite meet all of the business requirements, then we will modify it until it is satisfactory. I believe that this is one of the factors that has caused us to end up with the poor quality systems that we have in some businesses today. Business Partners should be responsible for the identification of the business functional requirements, and the Technical Partners should be responsible for determining how to achieve the designated requirements using available technology. This concept becomes one of the most significant culture change issues in some of the Facilitated Information Gathering Sessions I have participated in.

Provide for the use of computer graphics to document business requirements. Many techniques, such as entity Relationship Diagramming and Data Flow Diagramming, that have existed for years can now be effectively supported with these computer graphics tools. These computer based (ICASE) tools contain Artificial Intelligence or Expert Systems with rules about the use of techniques. The enforcement of these rules will assist your project team in the development of more rigorously correct models using techniques such as Data Analysis (Data Modeling) and/or Structured Analysis (Process Modeling).

Provide for the use a common repository to store and share information recorded in other phases of the systems development life cycle. Information recorded within the repository during previous projects can provide a productivity boost for future projects and maintenance of existing Information Systems. This is one of the major principles if ICASE, and one reason it promises productivity over and above the traditional CASE approach to systems development.

 Definition of TLA 

 back to top
TLA is my three letter acronym for a three letter acronym (or a two letter acronym, if you prefer) used to refer to commonly used business terms. I find most businesses and many industries have commonly used TLA's. One of my objectives during Facilitated Sessions is to document the name and definition of these TLA's. I continue to be surprised how often the use of TLA's actually end up referring to inconsistent names and definitions, even though everyone presumes that they are communicating effectively when they use their TLA's.

Now that I have provided my view of the definitions within the environment in which we conduct the Facilitated Information Gathering Sessions, I would like to discuss the significant aspects of a session.

 Benefits of Facilitated Information Gathering Sessions 

 back to top
The major benefit of a Facilitated Information Gathering Session is that you can obtain and validate business requirements in a shorter time frame by involving all participants (or at least a representative set of participants) who have a stake in the outcome of the session.

This approach is far more productive than the traditional serial interview process because it provides a structure for focusing on issues and resolving them. This is more effective than presuming that you can continue the development process and resolve the issues after the system is developed and implemented.

A significant benefit of Facilitated Sessions is the enhanced communication that occurs among the participants of the session. I have Facilitated Sessions in which participants have stated after the session that this was the first time that they really understood the business issues and the implication of the various choices. They were also pleased that they now had a better understanding of what their associates were trying to accomplish in their job and how their own work influenced other's tasks.

An additional dimension of the improved communication benefit is the enhanced education that occurs for people who attend the sessions and simply observe the process. This is a very effective technique for people who are newly assigned to a business position. They can quite often get more insight about their job during a series of Facilitated Sessions than they could in many weeks on the job.

Facilitated Sessions allow rapid accumulation of requirements or development of the desired deliverables. The sessions can be used to record high level business requirements or technology specific requirements. The group of participants working together not only define requirements more quickly, they also have the forum and the knowledge to resolve issues if conflicts or disagreements arise during the sessions. Facilitated Sessions allow you to eliminate the tedious cycle of serial interview that tend to cause a geometric expansion of complexity as you interview more and more individuals who provide slight variations in each others views.

This approach to requirements gathering provides an education for participants by exposing them to the views and opinions of the other participant. This education is enhanced because the sessions are conducted in a formal but flexible manner to enhance each participant's involvement, but limit the 'blue sky' tendency encountered in less focused group sessions.

This technique supports the Information Engineering approach to Systems Development. It can use other I.E. techniques such as Data Modeling and Process Modeling to enhance the effectiveness of the session by recording the findings in a combination of diagrams supported by textual information. The ability to record the findings of the group into an ICASE tool adds to the efficiency of the session by allowing quick turn around of the groups requirements, providing a standard format for requirement recording and providing for efficient update and refinement of the material recorded during the Facilitated Sessions.

Objectives of a Facilitated Information Gathering Session

The primary objective of most sessions is to define and record requirements for a predetermined segment of the enterprise. This is most often accomplished by gaining the participation of all significant personnel within the scope of the session you are conducting.

A secondary objective is to identify and document issues that are beyond the scope of the session, but that potentially will have an impact on the findings of the session.

 Critical Success Factors of a Facilitated Information Gathering Session 

 back to top
There are a series of things that must be accomplished in order to successfully conduct a Facilitated Information Gathering Session. These include:
  • The Facilitator must be experienced in group session leadership. They need to work with the Project Manager to keep the session on track and keep the discussions focused on the designated objectives.

  • Objectives of the sessions must be clearly defined and understood in advance. This is probably the single most common issue raised by participants that come out of session without having achieved their objectives. They were not clear about the session objectives, or the situation in which other participants did not know or understand their objectives.

  • Deliverables must be clearly defined in advance. This critical success factor is related to understanding the objectives. The form and content of the designated deliverables must be clearly documented before the session and explained and illustrated at the beginning of the session.

  • Participants must be carefully chosen to provide relevant expertise. You want to use the people who know the most about the topics to be discussed, and/or the requirements to be documented. Most sessions are involved in defining requirements that will become the basis of an automated business system. Can you afford to staff the sessions with people who are available simply because they have nothing else to do at the time?

  • Participant's roles and responsibilities for the session must be well defined in advance. Each person deserves to know what they are expected to contribute, as well as knowing what other participants in the session are expected to contribute.

  • The session agenda must be defined in advance. I am amazed at the number of meetings I have been invited to that have not provided an agenda. The old adage "If you don't have a target, you are guaranteed not to hit it" applies here. Make sure that all participants understand what the session intends to accomplish, and what they intend to produce as a result of your session.

  • The scope of the session must be controlled during the session. Do not allow "scope creep" or "design drift" during your sessions or you may not have time to fulfill your objectives. I work with the Project Manager who set up the session to test periodically to make certain that we are still on track and continuing to be productive.

  • Facilitated Information Gathering Sessions work best as an iterative process - don't try for perfection in every session. I heard a comment a short while ago, "that perfection is the enemy of good." Striving for perfection can consume an incredible amount of time. I use two principles here:

    • First, try to get 80% of the benefit by investing the first 20% of your time. I find you can invest an enormous amount of time trying to get every aspect developed perfectly. I encourage participants to get their initial ideas recorded and then review the entire scope, rather than trying to get every detail developed for some aspect of the session. Often this aspect may not even exist in the final view of the requirements.

    • Second, I understand that group sessions strive for consensus among the participants, however, I find very few companies that can afford the time to allow the group to arrive at consensus on all of the issues that come up during the various discussions. I have coined a phrase that I refer to as, "Violent Agreement." I want the group to work through the various issues until they reach a point of "Violent Agreement," which means, they each have satisfied their minimum requirements even though they may not have achieved every single aspect of every objective they have. While facilitating sessions I will occasionally test the situation when two or more participants get into really heated discussion that does not seem to be making any headway by asking if they have achieved "Violent Agreement" yet. This provides a bit of comic relief, but it also give each participant an opportunity to sit back and quickly access their position. Often we are able to move on to more productive activities at that point.

 Roles and Responsibilities of Facilitated Information Gathering Sessions 

 back to top

A Facilitated Session can take many forms or have one of many objectives, however, the attendee's roles generally consist of:
  • Executive Sponsor
  • Project Manager
  • Participants
  • Recorders
  • Facilitator, and
  • Observers
I will list the key responsibilities for each of these roles to be fulfilled during a session. See this chart here for the Roles and responsibilities list.

Continue to Part 2



   PRINCIPLE PARTNERS, INC. - 1355 Corte Loma Walnut Creek, California 94598 - Phone: 925/930-8875