So where has this classical systems development life cycle gotten us? Let's review some
industry statistics:
- 60% of large systems projects have significant cost overruns,
- 75% of completed systems are in need of constant maintenance,
- 60% to 80% of errors originate in the user requirements and functional specifications.
A survey conducted by the Index Group of Cambridge Massachusetts in early 1990
concluded that "Systems developers are operating amid turf battles, historical
bickering, low credibility and the difficulty in pinning down ever-changing systems
requirements." Their survey of 95 systems development directors found that:
- 64% say that they cannot get users in different departments to cooperate in
cross-functional systems projects,
- 78% say that coordinating efforts between end user developers and professional systems
developers is a major challenge even though the number of end users developing their own
systems is on the rise,
- less than 29% say they have any long-range plans for retiring obsolete systems.
These statistics reflect the "state of the art" in software systems
development in large organizations today. We might be tempted to say that it's different
in small organizations. Yes, it probably is different, but likely no better. The
information needs of large organization have hit smaller companies as well. For example:
- We've all got a need to develop strategic systems that support users in multiple
functions.
- The need for cross-functional strategic applications makes it more difficult to get
users to agree to and sign-off on system specifications.
- At the same time, tools are maturing that can help us develop and implement applications
faster than ever before.
In "real life" systems development, time and effort are heavily skewed
towards coding. We feel the need to get started writing the code so we can get it done in
time to allow us to debug the system before we implement it.
This often results in poor planning feeding inadequate design that does not meet
business needs and requires major revisions and difficult maintenance over the life of the
system. To complicate matters, we've got application systems that have been in production,
in some cases, for over 15 years. Each year those creaky old systems get harder and harder
to maintain and modify.
Today's Environment
Computer-Aided Software Engineering (CASE) tools are available today to help us develop
applications very quickly. Along with the tools, the industry has evolved new views of the
traditional systems development life cycle.
The Information Engineering proponents have re-defined and simplified the life cycle to
4 phases: Planning, Analysis, Design, and Construction. Other methodologies have defined
similar phases.
The one thing all of today's development methodologies agree upon is that we need to
improve the quality of the input - the user requirements. Requirements must be defined and
specified in a consistent, repeatable, and structured way.
Consequently, the heart of the IS business has moved up the life cycle. Today we must
focus more on analysis and design and less on the traditional "nuts and bolts",
the coding and the implementation tools.
That means to develop effective information systems today we must take the time to
integrate the technical aspects of information technology and the social aspects of the
organization.
To determine user requirements today, we must adopt more effective techniques that
recognize both the differences in communications styles of our colleagues in the company
and the differences in application requirements of the business functions that we serve.
One such technique is Joint Application Design (JAD).
What is JAD?
Joint Application Design is a management process - a people process - which allows IS to
work more effectively with users in a shorter time frame. Since the late seventies, JAD
has proven to be an effective technique for building user commitment to the success of
application systems through their active participation in the analysis of requirements and
the specification of the system design.
The facilitated JAD workshop brings key users (stakeholders) and systems professionals
together to resolve their differences in a neutral, non-hostile atmosphere. Key to the
workshop is a specially trained, unbiased facilitator who is not a member of the project
team and therefore has no political stake in the outcome of the workshop. The workshop
will build a team that will stay together, psychologically at least, for the life of the
project.
The power of JAD is in the integration of behavioral and group dynamics techniques
within the structure of a soundly engineered methodology. What does that mean? It means
that a JAD workshop is not just a nice meeting.
The workshop has a highly structured agenda with clear objectives including a mechanism
for resolving open issues that often bog down the design process. The deliverables are
clearly defined during the pre-workshop activities so that there can be a smooth and
successful transition to the next phase in the life cycle - application design or
acquisition.
Workshops are effective at all levels: enterprise, business area, application, and
implementation project management. Facilitated workshops can be used whenever a group of
diverse individuals needs to reach a workable consensus. Today, workshops are commonly
used for strategic business planning, strategic IS plans, IS architecture definition,
re-engineering business processes, detailed system design, process and data modeling, and
project management.
This positive, team-building environment gives people a chance to learn from each other
and to understand each other's needs and concerns. The participants will develop a common
view of the project and a common language to discuss the project issues.
A Common Language
We need a common language so that we can understand each other's concerns - not the broad
issues that are obvious to everyone, but the subtleties that give individual business
functions that extra edge.
Users know what they want but they don't have a way to articulate the subtleties of
their business needs so that IS can understand them and build working systems to support
them effectively.
Different functional units have different ways of operating, of making decisions, and
of analyzing what's going on around them. Finance and accounting people, for instance,
tend to be very "cut and dried" or mechanistic in the way they analyze a problem
and judge the merits of a proposed solution. For an accountant, 2 plus 2 is always 4. A
lot of systems people think like accountants. We like to work towards that one right
answer.
Marketing people, on the other hand, are more willing to work with abstractions and
uncertainties. Consequently, they can be more frustrating for IS to deal with. They tend
to see many shades of gray. What's 2 plus 2 in the marketing department? "Well, it
depends, are we buying or are we selling."
Today we need applications that cross functional boundaries and provide high-level
management information and decision support to all of our top executives, to help them
respond to the changing business environment.
However, as we move up the corporate ladder, there is a greater tendency towards a more
open, organic, and adaptive view. That means that there may not be one right answer.
Instead, we may need to choose among a group of not wrong answers to find the one
that best fits the organizations culture, business, and marketplace. That means it's
harder to get upper management to express their needs in terms that systems people can
understand.
The common language developed in the facilitated JAD workshop helps all the
participants com- municate and understand each other's needs so that IS can build systems
that more effectively support the company's higher-level information needs.
Pre-Workshop Activities
Good preparation is key to success. There is between one and three weeks of work required
to prepare for a workshop. That preparation is required to:
1) Identify project objectives and limitations
It is vital to have clear objectives for the workshop and for the project as a whole. The
pre-workshop activities, the planning and scoping, set the expectations of the workshop
sponsors and participants.
Scoping identifies the business functions that are within the scope of the project. It
also tries to assess both the project design and implementation complexity.
The political sensitivity of the project should be assessed. Has this been tried in the
past? How many false starts were there? How many implementation failures were there?
Sizing is important. For best results, systems projects should be sized so that a complete
design - right down to screens and menus - can be designed in 8 to 10 workshop days.
2) Identify critical success factors.
It is important to identify the critical success factors for both the development project
and the business function being studied. How will we know that the planned changes have
been effective? How will success be measured? Planning for outcomes assessment helps us
judge the effectiveness and the quality of the implemented system over its entire
operational life.
3) Define project deliverables
In general, the deliverables from a workshop are documentation and a design. It is
important to define the form and level of detail of the workshop documentation. What types
of diagrams will be provided? What type or form of narrative will be supplied?
It is a good idea to start using a CASE tool for diagraming support right from the start.
Most of the available tools have good to great diagraming capabilities but their narrative
support is generally weak. The narrative is best produced with your standard word
processing software.
4) Define the schedule of workshop activities
Workshops vary in length from one to five days. The initial workshop for a project should
not be less than three days. It takes the participants most of the first day to get
comfortable with their roles, with each other, and with the environment. The second day is
spent learning to understand each other and developing a common language with which to
communicate issues and concerns. By the third day, everyone is working together on the
problem and real productivity is achieved.
After the initial workshop, the team-building has been done. Shorter workshops can be
scheduled for subsequent phases of the project, for instance, to verify a prototype.
However, it will take the participants from one to three hours to re-establish the team
psychology of the initial workshop.
5) Select the participants
These are the business users, the IS professionals, and the outside experts that will be
needed for a successful workshop.
6) Prepare the workshop material
Before the workshop, the project manager and the facilitator perform an analysis and build
a preliminary design or straw man to focus the workshop. The workshop material
consists of documentation, worksheets, diagrams, and even props that will help the
participants understand the business function under investigation.
7) Organize workshop activities and exercises.
The facilitator must design workshop exercises and activities to provide interim
deliverables that build towards the final output of the workshop. The pre-workshop
activities help design those workshop exercises. For example, for a Business Area
Analysis, what's in it? A decomposition diagram? A high-level entity-relationship diagram?
A normalized data model? A state transition diagram? A dependency diagram? All of the
above? None of the above? It is important to define the level of technical diagraming that
is appropriate to the environment. The most important thing about a diagram is that it
must be understood by the users.
Once the diagram choice is made, the facilitator designs exercises into the workshop
agenda to get the group to develop those diagrams.
A workshop combines exercises that are serially oriented to build on one another, and
parallel exercises, with each sub-team working on a piece of the problem or working on the
same thing for a different functional area.
High-intensity exercises led by the facilitator energize the group and direct it towards a
specific goal. Low-intensity exercises allow for detailed discussions before decisions.
The discussions can involve the total group or teams can work out the issues and present a
limited number of suggestions for the whole group to consider.
To integrate the participants, the facilitator can match people with similar expertise
from different departments. To help participants learn from each other, he can mix the
expertise. It's up to the facilitator to mix and match the sub-team members to accomplish
the organizational, cultural, and political objectives of the workshop.
A workshop operates on both the technical level and the political level. It is the
facilitator's job to build consensus and communications, to force issues out early in the
process. There is no need to worry about the technical implementation of a system if the
underlying business issues cannot be resolved.
8) Prepare, inform, educate the workshop participants
All of the participants in the workshop must be made aware of the objectives and
limitations of the project and the expected deliverables of the workshop.
Briefing of participants should take place 1 to 5 days before the workshop. This briefing
may be teleconferenced if participants are widely dispersed.
The briefing document might be called the Familiarization Guide, Briefing Guide, Project
Scope Definition, or the Management Definition Guide - or anything else that seems
appropriate. It is a document of eight to twelve pages, and it provides a clear definition
of the scope of the project for the participants.
The briefing itself lasts two to four hours. It provides the psychological preparation
everyone needs to move forward into the workshop.
9) Coordinate workshop logistics
Workshops should be held off-site to avoid interruptions. Projectors, screens, PCS,
tables, markers, masking tape, Post-It notes, and lots of other props should be prepared.
What specific facilities and props are needed is up to the facilitator. They can vary from
simple flip charts to electronic white boards. In any case, the layout of the room must
promote the communication and interaction of the participants.
The Key Players
1) The Facilitator
The facilitator is in charge of the workshop - the guardian of the process. It is the
facilitator's responsibility to ensure that the expected workshop deliverables are
produced and the expected consensus is achieved. The facilitator is an unbiased leader who
has no ties to the project. He can come from some other department or from outside the
company. Some companies are training facilitators who work out of a facilitation center
attached to the human resources department.
The ideal facilitator is an individual who is excited by working with people. That would
include only between 10% and 15% of senior systems analysts. Good facilitators often come
from non-computer science fields such as teaching or sales. In addition to an aptitude for
working with people, the facilitator must have the skills required to achieve the level of
analysis detail expected from the workshop. That means training in the following areas:
the methodology (such as Information Engineering) that will be used in development, group
dynamics, basic selling skills, issue recognition, and listening skills.
Good facilitators listen, recognize issues as they arise, and provide the leadership and
direction to help people come together.
The facilitator is responsible for ensuring that each person is heard and has an equal
opportunity to influence the decision. The facilitator is also responsible for ensuring
that the participants in the workshop construct a solution that everyone can live with.
2) Documentation Expert
This individual has to document the decisions and the issues in the workshop - to act as a
scribe.
3) The Executive Sponsor
This is the executive who charters the project - the system owner. The sponsor must be
high enough in the organization to be able to clear the calenders of the people required
in the workshop. The sponsor provides motivation for commitment through a short speech at
the opening of the workshop and has to be available for strategic direction and scoping
information during the pre-workshop phase. During the workshop, the executive sponsor must
be available for policy decisions appropriate for his level of authority.
Without the executive sponsor's commitment, people do not show up for workshops on time or
sometimes at all. Schedules change and projects are delayed. In short, without an
executive sponsor, there is no project!
4) The Project Manager
This is the person responsible for the project who will work closely with the facilitator.
The project manager, as the client of the workshop process, receives the deliverables.
5) Business Users
These are the intended users of the system being designed. They are in the workshop
because of their business expertise. Business users fall into 2 categories: real end
users - the people who are actually going the have to use the screens and reports to
do their jobs; and representative end users - the people who think they know what's
going on in the field. They are responsible for standards and methodology for the business
functions they represent.
It is important to get both types of users into the workshop. If the workshop consists of
only representative users, then we get good theoretical model - how things should be - but
the theories may not work in practice. If we have only real end users, then we get a good
system for today but it might not work next year or two years down the road.
6) Systems Experts
The workshop is trying to establish rapport and communications among stakeholders -
including IS. Systems people need to be there to know the constraints so they can advise
the business people regarding hardware and software under discussion. A good rule of thumb
is one systems person for every four users.
7) Outside Experts
Outside experts are business consultants or technology consultants who can provide the
expertise that may not be available in-house. For example, the workshop may need support
from outside consultants for manufacturing, distribution, marketing, prototyping,
organizational dynamics, and change management.
8) Observers
Observers are not allowed to participate in the workshop in any way. They may observe to
gain some insight into the business area under investigation or to become familiar with
the workshop process.
Post-Workshop Activities
After the workshop, it is important to address and resolve the open issues generated by
the workshop. A three-day workshop typically generates about 20 open issues, most of which
are business issues. It is critical to get these issues out on the table for discussion
and resolution before any code gets written.
The facilitator and the documentation expert work together to finalize the workshop
documentation. The project manager is the client who receives the deliverables.
The documentation moves forward through the organization to continue to enroll support
and approvals for the development project if necessary.
The design moves forward either for inclusion in a request for proposal for application
software acquisition or towards a prototype or a code generation phase. It may contain
details such as screen layouts and menus. The data model will contain volumes and
capacities. The process model will specify transaction volumes.
If the design is taken into a prototype, there should be a series of 1/2-day or one-day
workshops to evaluate and validate the prototype.
Workshop Benefits
1) Builds consensus and ownership The workshop approach will quickly achieve
consensus and commitment among users - the customers of the IS function.
2) Improves design quality
The workshop improves the quality of the deliverable of the design phase because it forces
a definition of that deliverable in advance. During the workshop the participants are all
focused on a common goal. Users in the workshop will have a better understanding of the
business issues, the systems issues, and the volume of work to be done.
3) Project teams get focused and stay focused
In the workshop, the participants will build a common view of the project and a common
language to discuss the issues. These elements will stay with the team for the life of the
project.
4) A natural partnership with modern development tools JAD helps realize the
full potential of today's powerful development tools by providing high-quality input
requirements quickly.
5) 20% reduction in overall life cycle costs
In 1989, computer industry productivity expert, Capers Jones, studied 60 development
projects and found:
- Without JAD, 35% of the functionality was missed and that had an impact on at least 50%
of the code - core functionality was missed.
- With JAD, less than 10% of the functionality was missed and that had a minimal impact on
the code - indicating that the core functionality was good but refinement was going on.
JAD doesn't stop refinement - it helps manage it better. Those projects that used JAD
combined with prototyping, did even better!
Conclusion
The information needs of our top executives are not well defined. The business climate is
uncertain and changing. There is no single right answer, there is no single right system.
Progressive systems departments are taking advantage of new tools and new techniques to
re-engineer the way they build systems. There are new development tools, new methodologies
and supporting techniques such as Joint Application Design for developing the requirements
specifications for the systems our users need.
To develop effective information systems today we must take the time to integrate the
technical aspects of information technology and the social aspects of the organization.
That's what facilitated workshop requirements analysis is all about!
Recommended Reading
- Programming Productivity
by Capers Jones; McGraw Hill.
- Systems Analysis and Design
by James C. Wetherbe; West Publishing, 1988.
- Exploring Requirements: Quality Before Design
by Donald C. Gause and Gerald M. Weinberg; Dorset House Publishing, 1989.
- The Fifth Discipline: The Art & Practice of The Learning Organization
by Peter M. Senge; Doubleday/Currency, 1990
- Information Engineering:
Book 1: Introduction
Book 2: Planning & Analysis
Book 3: Design & Construction
by James Martin; Prentice Hall, 1990.
- Up and Running: Integrating Information Technology and the Organization
by Richard E. Walton; Harvard Business School, 1989.
Adapted by the author from his article in UNISPHERE, Nov 1990
P.O. Box 740908, Dallas, TX 75374-0908
(214) 669-9000
Reprinted with permission. All rights reserved.
Free subscription information available upon request.
