Improving Work Process Information Flows:

A Case Study
Rebecca Wheeler
Systems and Software Division
Jet Propulsion Laboratory
Pasadena, CA USA
Rebecca.wheeler@jpl.nasa.gov
Melody Chang
Enterprise Engineer Division
Jet Propulsion Laboratory
Pasadena, CA USA
Melody.Chang@jpl.nasa.gov
Susan Volk
Enterprise Engineer Division
Jet Propulsion Laboratory
Pasadena, CA USA
Susan.Volk@jpl.nasa.gov

Abstract - The lessons learned from a grass roots effort
involving information systems developers and engineers
in the design and development of a customized work
process support system, named Fredrik, are discussed.
The information system developed is a dynamic, web-
based work process system to support the end-to-end
scheduling, planning, design and documentation activities
of an “extreme collaboration”design team. The system is
used to help schedule and manage multiple pre-design
session meetings, to track and store information gathered
and generated before, during and after a real time design
session, and to facilitate document and design
information retrieval for later re-use. While the close
partnering between the users and developers solved some
long standing trust issues, and resulted in a system more
optimized to the engineering team’s needs, the
participatory design process inadvertenly produced a
less stable and sexy system potentially affecting future
sources of funding for upgrading the system.
Keywords: concurrent engineering, rapid prototyping,
user centered design, real time design, work process
support systems, case study.
1 Introduction
What happened when a well established rapid
advanced design team with highly dynamic work
processes and inadequate data collection practices was
partnered with a rapid prototyping software design team?
A heavily utilized customized scheduling and tracking
system tightly locked to the rapid design team process
was the result. This paper presents the lessons learned
from involving the users in the design and development
of a customized work process support system named
Fredrik.
The basic requirement satisfied by Fredrik was to
collect, organize and retrieve information generated
during the life cycle of a rapid design team process. The
system is used to help manage the status of multiple
simultaneous meetings between different members of the
rapid design team and their multiple customer teams, to
track information gathered before and generated during a
real time design session, and finally to facilitate the
storage of all related design documentation and metadata
so it could be subsequently accessed by the design team
and their customers for the study.
Fredrik was developed for use by Team X. Team X
is a rapid design team utilized at the Jet Propulsion
Laboratory (JPL) to rapidly complete designs in support
of space mission proposals. Team X employs an
“extreme collaboration” design paradigm (1), which
involves the co-location of a team of about 20
multidisciplinary engineers, and their customers, for a
short period of time in a technologically intensive
physical environment to complete a mission design in real
time.
2 Team X Work Process Structure
Team X achieves “extreme collaboration” during
three half-day concurrent design sessions, that take place
over the course of a week. During these sessions, all of
the team members are co-located in a design center that
contains networked workstations and the supporting data
management infrastructure, large interactive graphic
displays, computer modeling and simulation tools, and a
mature shared generic project model that the design team
populates in real time. The team members are fully
committed to completing the design work during the
concurrent design period (2). While the concurrent
design activity is the most innovative part of the Team X
design process, a typical design actually requires at least
three weeks from start to finish. Pre design session
activities include design session scoping, planning and
pre analysis. Post design session activities include design
analysis wrap up and documentation. The pre and post
session activities typically take place “offline” using more
traditional asynchronous team product development
methods.
Most Team X members simultaneously work on
multiple studies. During any given week, a given team
member’s activities could include pre-session planning
and design meetings for multiple studies, participation in
concurrent design sessions, and completion of several
study reports from previously completed design sessions.
Meanwhile, new and existing customers continue to
request new design sessions or changes to their already
scheduled planning and design session schedules. With
the exception of the Team lead and an administrator, none
of the team members work full time as Team X members.
Furthermore, their work load involves almost daily
changes in the studies that they might participate in for as
few as three weeks. Therefore a big concern is how to
keep the Team and the customers “on the same page” in
such a dynamic environment.
3 Fredrik: A Work Process Support
System for Team X
From the perspective of time and cost reduction,
Team X has been extremely successful. Well over 600
early-phase project designs have been completed over the
course of nearly ten years. These studies were completed
in less than one-tenth the time of the previous process at
JPL, and for less than one third of the cost (3). However,
prior to the development of Fredrik, Team X had no
systematic information system to manage its work flow.
Scheduling was ad hoc—handled through phone calls,
emails and multiple, internally inconsistent, methods of
posting schedules. All the information generated from
meetings with the customer, from customer presentations,
from the team design parameters and from product
iterations were stored under one customer file maintained
on a server. When the server became “full”, the files
were moved to compact disks (CDs). If the customer
wished to retrieve a copy of a previously completed
report or the Team wished to “re-use” previously
completed study data, a team member would have to sort
through some 300 CDs that contained the study results.
Further, with no metadata or systematic file storage and
close-out procedures, she would often have to “guess”
which were the final products and assess whether stored
data products had been made internally consistent. Thus,
while Team X was meeting the original goal of rapid
design at greatly lowered costs, some of the “hidden
costs” of that process as implemented were
inconsistencies in the scheduling process, customer data
collection process, team briefing process, and product
production, storage and retrieval processes. These
inconsistencies were an “expense” imposed on team
members, who spent their limited design time retrieving
information from previous study sessions that lacked
adequate metadata which should have been added at the
time the information was generated.
Team X leaders recognized that the "hidden costs"
of inadequate information management was growing as
the number of studies and customers increased. It was
harder to find and re-use data than to "reinvent" the data.
The rapid prototype software design team was asked to
assess the current Team X processes and recommend an
information system approach that would address these
"hidden costs".
The software design team performed a search and
evaluation of COTS scheduling and data management
software. There were many products available that
addressed scheduling but lacked the data management
capabilities needed by Team X. Conversely, there were
many products available that addressed data management
but lacked the scheduling capabilities needed. The option
of integrating and/or modifying COTS software was
considered. However, the cost savings associated with
the use of COTS software can be lost if the software is
not implemented "as is", the software was not designed
for "re-use" or more than 45% of the software needs to be
modified (4). Also, the Team X functional requirements
for scheduling and data management were not well
defined at the time.
Given the lack of a "perfect match" COTS tool and
the vague system requirements, the software team
decided to develop a system through rapid prototyping
for the Team X scheduling and metadata management
capabilities and use the JPL institutional COTS software
for the file management. By using rapid prototyping, the
software design team could interact with Team X to
provide an information system quickly, as well as help
with defining the Team X functional requirements. Thus
Fredrik was conceived
Fredrik is a dynamic, web-based work process system
to support the Team X end-to-end design process. Its
essential elements are a series of standardized on-line data
collection forms integrated with a relational database that
supports detailed scheduling, group lists, automated email
notification, collection of design status and standardized
metadata information, as well as a commercial document
storage system. Fredrik enables tracking of a study
design from the time a customer requests a study until the
time the final report is stored in an on-line library, along
with all the metadata collected over the “lifetime” of the
study process. While the scheduler can be viewed by
anyone with access to internal networks, users must
otherwise log in via a secure web interface to access any
of the other information in the system. Users are
authenticated and provided role based authorization to
access different resources of the system.
From Team X’s perspective, the heart of the Fredrik
system is an on-line calendar/scheduler that provides
scheduling and displays all scheduled pre-sessions,
design sessions, product due dates, and personnel
availability (Figure 1). Clicking on any particular design
session from the calendar brings up scheduling event and
personnel assignment forms (Figure 2), customer study study close-out checklist form (Figure 4).
request form (Figure 3) documentation status forms and

Figure 1: Team X Calendar

Figure 2: Scheduling Event and Personnel Assignment

Form

Figure 3: Customer Study Request Form

 Figure 4: Study Status Checklist

While the schedule can be viewed by anyone with
access to the JPL network, only authorized Team
members are allowed to schedule sessions and other
events by logging in via a secure web interface.
When a session is scheduled, an email is
automatically sent to affected team members and the
customer notifying them of the pre-session and study
session dates (Figure 5). The email notification thus acts
as a trigger during the process flow, facilitating
communication between Team X members and their
customer. Any schedule changes can result in additional
emails which, though not automatically sent, can be
easily initiated by the push of a button by the
administrator.

Figure 5: Email Notification Form

All the data that customers enter, including the
email log information, is also stored in a relational
database. This not only helps the Team X customers
keep track of the study status, but it also helps the Team
X members to retrieve and re-use the data. All metadata
collected over the lifetime of the study utilizing the
tracking forms is stored along with a link to the final
product which is located in a secure commercial on-line
library system that accommodates role based access to
different studies. All of the studies generated in the last
nine years and their associated metadata have been added
to the commercial document management system so that
they can be instantly retrieved by the customer (if
authorized) or by team members for re-use (Figure 6).
 Figure 6: Studies and Study Progress List
4 Lessons Learned
Fredrik was developed over several years using a
participatory design and rapid prototyping methodology.
Significant improvements were gained in process
consistency, efficiency, and information retrievability, but
the development process required a lot of interaction
between the Team leaders and the information system
developers to articulate and automate the study session
process. However, without that interaction, the
information system would not have been optimized to
resolve Team X’s most pressing problems. Indeed, the
Team had already rejected the adoption of tool several
other efficiency or design support tools developed
without its participation. Today, Team X consistently
uses Fredrik to manage all of its scheduling—pre-
sessions, team assignments, design sessions and product
production status.
The participatory design process required constant
effort on the part of management to maintain because
there was often tension between the development and
engineering teams’ views of needed functionality. In
general, the Fredrik team wanted to “push the envelope”
in terms of process redesign and information system
capability. Team X, generally wanted to simply automate
their existing process. Management’s job was to try to
manage the tension and amicability between the two
teams in order to effect the best compromise. Three
major lessons learned from implementing this relatively
uncomplicated system are discussed below.
Information system users and information system
developers MUST continuously interact during the
information system development process.
Team X has work to do. They don’t have time to
play with what they perceive as “esoteric” tools that don’t
seem to solve their problems or require a lot of effort to
learn. Further, they didn’t have time to “populate” ANY
data collection information systems with far more data
than necessary to do the job they need to get immediately
done, no matter what the greater “need” articulated by the
developers or outside managers. Finally, Team X has
endured a long history of development efforts that had
tried to impose their “improved” process or technology
solutions on the Team without any understanding of their
constraints, processes or needs. As a matter of course,
therefore, Team members understandably resist changes
that they perceive might inhibit their effectiveness, even
if the change might resolve issues they really want
resolved.
The solution to this legitimate resistance was to
establish regular interactive sessions between the Team X
leaders and the Fredrik developers. The Team X process
was captured in a way that could be implemented in
Fredrik. The developers implemented practical solutions
to some long-standing Team X problems. This process
established trust between the two groups.
Rapid Development Prototypers MUST anticipate
and accommodate entire database redesigns.
The good news was that Team X leadership really
wanted support and were willing to standardize and even
evolve their processes to be supportable by enhancements
in Fredrik when the enhancements really solved their
problems. The bad news was that with the new sense of
“trust” between the teams, the Team X leadership started
requesting more and more design changes. Indeed, more
than a year was spent simply adding “new functionality”
to Fredrik. While the development team was delighted
that their product was being adopted by Team X, they
were becoming frustrated that Team X was specifying
“solutions” that were essentially work-arounds to an
increasingly unwieldy prototype database structure.
Instead, the developers requested down time to redesign
the databases. However, the Team X management team
was used to getting at least some of their new
requirements implemented every few weeks and resisted
freezing the current system for a redesign.
Coincidentally, a Team X reorganization occurred, and
the new Team X managers were responsive to
information system developer needs and the existing
Fredrik configuration was “frozen” for a few months
while the redesigned database are restructured. It remains
to be seen, however, whether the original camaraderie
between the mission design team and the information
system design team will be re-established with the new
Team X.
Funding sponsors NEED to recognize that “sexy”
technologies are not necessarily what is needed to
resolve process inefficiencies.
Obtaining, retaining and getting enough funding for
the development of Fredrik—especially before
demonstrating usefulness to Team X members—was a
constant struggle. The system is not particularly exciting
from a technology development perspective—no artificial
intelligence, no optimization algorithms—just forms,
database, a scheduler and code to link all the pieces
together. Therefore, winning external or internal
technology development proposals during the initial
development phases for Fredrik were frequently
unsuccessful. Institutional funding sources favored the
development of better engineering tools, focusing on
further improving concurrent design session
effectiveness, so those funding sources were frequently
unsuccessful as well. The hidden costs to the design team
members inherent in their process inefficiencies was
evident only to a few of Team X customers, technology
developers and, finally, concurrent Team managers, who
after continued lobbying on the part of the original
Fredrik design team, finally banded together and
provided enough seed money to implement the system.
However, without a strong belief in the value of a work
process support system on the part of the original Fredrik
design team, Team X could still be manually scheduling
its meetings and sorting through hundreds of CDs looking
for its data.
5 Conclusions
Not long ago, Team X had to call or email people
to schedule their meetings and hunt through hundreds of
CDs for previous reports. Even though their process was
very inefficient, they had experienced many problems
with previous improvement attempts and hence resisted
using new tools. A close partnering with the Fredrik
developers solved some practical problems and built trust
allowing further development to address inefficiencies.
The rapid proptotyping approach was ideally suited to
articulating Team X requirements and assuring that they
were implemented in a manner useful to Team X. This in
turn resulted in an process management system that was
intensively utilized by them. However the unanticipated
consequences were a less stable and “sexy” system than
might have been developed in the absence of a user based
design. One fallout was difficulties in finding funding
sources for early development of the system and,
potentially affecting future sources of funding for
upgrading the system.
Currently the Fredrik database system is being
modified to accomodate the addition of new rapid design
teams and management structures, which are likely to be
more réceptive to the adoption and funding of Fredrik
than was the case in earlier years. It remains to be seen,
whether the original camaraderie between the new
mission design teams and the Fredrik design team can be
re-established.
References
[1] Mark, G. (2002). Extreme Collaboration.
Communications of the ACM. Vol. 45(6), pp.89-93.
[2] Chachere, J., Kunz, J., and Levitt, R. 2004.1, “Can
You Accelerate Your Project Using Extreme
Collaboration? A Model-Based Analysis” 2004
International Symposium on Collaborative Technologies
and Systems; Also Center for Integrated Facility
Engineering Technical Report T152, Stanford University,
Stanford, CA
[3] Wall, S., Reinventing the Design Process: Teams
and Models," International Astronautical Federation
Specialist Symposium on Novel Concepts for Smaller,
Faster and Better Space Missions, Redondo Beach, CA,
April 1999.
[4] Boehmn, B. Abts, C., Brown, W., Chulani, Sul,
Clerk, B.K., Horowitz, E., Madachy, R., Reifer, D.J. and
Steece, B., Software Cost Estimation with COCOMO II,
Prentice Hall, 2000.
Acknowledgements
The research described in this publication was carried out
at the Jet Propulsion Laboratory, California Institute of
Technology, under a contract with the National
Aeronautics and Space Administration.