Proceedings of the 42nd Hawaii International Conference on System Sciences - 2009
Modeling Collaborative Behavior:
Foundations for Collaboration Technologies
Steven Poltrock and Mark Handel
Boeing Phantom Works
{steven.poltrock}{mark.j.handel}@boeing.com
Abstract
Can models of collaboration serve as a foundation
for development of collaborative technologies in much
the same way that engineers use models when
developing complex systems? We explore this issue by
investigating how eight approaches to understanding
or modeling collaboration could be used to improve
technologies that support a change management
process. Some approaches are ostensive, defining how
collaboration should be achieved. These approaches
provide ways of documenting, analyzing, simulating,
and automating the process. Other approaches are
performative,
describing
actual
collaboration
behavior. These approaches reveal the variability in
collaboration and deviations from the intended
process. Technologies could benefit from and facilitate
both types of approaches by recording collaborative
events for later analysis. We conclude by considering
ways that modeling collaboration could contribute to
requirements analysis, new collaboration capabilities,
adoption, and maximizing benefit from technologies.
1. Good products are based on good
models
Consider how researchers and developers define
the capabilities of collaboration technologies. They are
largely guided by intuition, introspection, features of
existing products, and, in the case of product
development, their customers’ stated needs.
Collaboration technologies improve primarily through
improvements in infrastructure and through a
Darwinian process of trying new features and retaining
those features that achieve some success. There is no
competitive advantage inherent in this approach,
although developers can achieve some short-term
competitive advantage by executing this approach
more quickly or effectively than others.
Compare this approach with the methods used
when designing a new airplane. Engineers construct
digital models of aircraft and analyze them. The
knowledge acquired through scientific studies strongly
predicts how these models will behave when
instantiated physically. In the early days of aircraft
development, people designed and built aircraft based
on observations of birds. Now designs are based on
knowledge of aerodynamic principles coupled with
tests conducted in wind tunnels and in actual flight. For
collaboration systems, we are still at the bird-model
stage.
The research community has, however, made
progress establishing theories and models that can
guide development of more effective collaboration
systems. The theory of distributed cognition has
provided new insights about the collaboration involved
in navigating naval vessels and operating commercial
aircraft [15, 16, 17]. Grounded theory has provided
insights about the importance of interwoven situational
awareness, dense social networks, and contested
collaboration in battalion-level battlefield management
[26]. Insights gained from using ethnomethodology
about coordination within police swat teams led to a
new method for robots to collaborate [18]. Applied to
airport operations, ethnomethodology suggested more
effective ways to organize work and technology [29].
Models of the adoption of CASE tools described
factors that influenced successful adoption of these and
other technologies [22]. In each example, researchers
studied collaboration in the field, modeled the
observed collaboration in accordance with a theoretical
framework, and identified practical implications in
terms of tools or work organization.
In this paper, we explore how eight ways of
modeling collaboration could be used to improve
collaboration technologies by considering their
application to change management, a complex
collaborative process. We informally evaluated each
approach by investigating the potential improvements
it suggests to technologies that support change
management. These evaluations were based on
observations and participation in the development of
technologies to support change management in a large
978-0-7695-3450-3 2009 U.S. Government Work Not Protected by U.S. Copyright
1
Proceedings of the 42nd Hawaii International Conference on System Sciences - 2009
aerospace program for two years. During our study this
program formalized procedures for managing changes
to budgets, schedules, organizational structure, and
other business attributes. We interviewed many of the
more than 100 people who participated in this process,
and we participated in or observed meetings in which
they planned, carried out, and evaluated the process.
2. Ostensive and performative models
Feldman and Pentland [9] differentiated between
two views of an organizational process: the ostensive
view that describes how collaboration is intended to
work; and the performative view that describes how
collaboration happens in reality. The distinction
between ostensive and performative models of
collaboration is prominent in studies of collaboration
in the workplace. Suchman [27, 28, 29] observed that
actual work practice (the performative model) rarely
follows the formal business process (the ostensive
model). Instead, people engage in complex problem
solving activities in which the business process acts as
an organizing plan and structure for their behavior.
This is a disturbing observation to people responsible
for mission-critical environments that require careful
attention to processes. These results are, however, well
established. Actual work activities depend heavily on
many contextual elements that are not included in
business process models.
Four of the modeling approaches we explored
emphasize ostensive behavior: UML (Universal
Modeling Language) modeling, workflow modeling,
coordination theory models, and GOMS (goals,
objectives, methods and selection) models.
3.1 UML models
The employees of modern industrial corporations
have considerable experience creating and reading
process models in business process instruction
documents and as part of process improvement
activities. Process models are also widely used in
software development to represent the processes that
software is intended to support. These are clearly
ostensive models, describing how collaboration is
expected to be accomplished. Unified Modeling
Language (UML) is a collection of methods and
diagrams for modeling business processes and software
architecture [1]. It is widely used in industry because
such models document and support business processes.
The activity diagram or swimlane model is the UML
representation most frequently used in industry. These
diagrams show the sequence of activities and the roles
responsible for performing each activity.
Figure 1 shows the UML activity diagram created
by the organization responsible for the change process.
A change originator prepares a change request (CR)
and sends it to a change coordinator who checks that it
meets expected standards. The change coordinator
3. Ostensive modeling approaches
[rejected]
Change
Originator
Create a CR
Change
Coordinator
Check quality
Data
Managers
Assess
impact
Team
Reps
Assess
impact
CCB
Prepare for
review
Acknowledge
Authorize change
Plan change
Review/approve
change
Make change
[approved]
Figure 1. A UML model of an engineering change management process
2
Proceedings of the 42nd Hawaii International Conference on System Sciences - 2009
sends it to a review panel consisting (in this case) of
data managers and representatives of various teams.
They assess the impact of the proposed change on their
own work and return the results to the change
coordinator. The proposed change and expected
impacts are presented to a change control board (CCB)
that approves or rejects it. If approved, a plan for
implementing the change is developed, authorized, and
finally implemented.
These models provide an important function as
plans for collaborative work, but they are not complete
or accurate descriptions of the collaboration required
when performing the work. The models generally
describe responsibility for activities and do not show
the communication and collaboration that an individual
initiates in order to carry out the activities. This model,
for example, does not describe what the change
coordinator does if the CR does not meet expected
standards. It also does not describe or capture the
phone calls, meetings, and email messages needed to
coordinate an activity. This model was created as part
of the documentation of the business process used by
participants in the process. Such models are useful as
high-level representations of a process and for
communicating about the process.
3.2 Workflow
Workflow models describe roles, tasks, and task
interdependencies. A workflow management system
automates task handoff from one person/role to another
in accordance with the model. Because workflow
management systems participate in processes, it is
essential that workflow models accurately describe the
processes. Because workflow models describe only the
information needed for process automation, they do not
have to be complete models of collaboration.
Workflow models are ostensive; they define how the
work should be coordinated and control the flow of
work to ensure that it is done in accordance with the
model.
Most popular workflow packages use a graphical
representation of workflow processes. Workflow
models are conceptually similar to UML diagrams, but
they are much more detailed and much harder to
understand because they include extensive errorchecking and exception handling that are essential
elements of process coordination. Here, performative
aspects of collaboration bubble up into an ostensive
model of collaboration. In order to create a usable
workflow, it is necessary to understand what
exceptions are likely and develop the software needed
in those situations. Some of this is simple input
validation (e.g., a field being left empty or
inappropriate responses). Other aspects of error
handling are, however, more subtle, such as what to do
when someone is not available or when a new situation
arises.
A workflow model of the change management
process was clearly useful. It drove a workflow
management system used by about a hundred people to
coordinate changes, and their interactions with that
system provided the raw data for some of the analyses
that follow. This model was not, however, a complete
or accurate description of the actual collaboration.
Participants collaborated in many other ways outside
the scope of the model, such as through meetings,
telephone conversations, and email. The workflow
model only described transitions of task responsibility.
Sometimes one person was assigned a task and
reported its eventual completion, but another person
performed the actual work involved in the task.
3.3 Coordination Theory
Coordination Theory defines coordination as
managing dependencies among activities [21].
Collaboration would be easy if everyone could work
independently toward a shared goal without any need
for interaction. In reality, collaboration requires
managing the dependencies among people, processes,
and objects, and Coordination Theory describes these
dependencies and the mechanisms for managing them.
The theory identifies three basic types of dependencies:
flow, sharing, and fit. Flow dependencies arise when
one activity produces a resource needed by another
activity. For example, an engineering design activity
necessarily precedes a stress analysis of the designed
part. A sharing dependency arises when multiple
activities require the same resource, such as a person, a
machine, or a data object. A fit dependency arises
when multiple activities produce a single resource. All
the parts of that resource must fit together.
In collaboration with Mark Klein from MIT we
constructed a top-down model of the engineering
change management process [23]. Figure 2 shows an
early step in the construction of such a model. First we
identified the “deep structure” of the process, i.e. the
core tasks and key dependencies. The change process
consists of three core tasks (propose changes, authorize
changes, and implement changes) and two key
dependencies (a change request (CR) flows from the
first task to the second, and an authorizing change
notice (CN) flows from the second task to the third).
We elaborated this core model by selecting
coordination mechanisms that address these
dependencies from a Process Handbook containing
these mechanisms and exceptions that they are likely to
encounter [20]. For example, we added the generic
“manage flow” coordination mechanism to handle the
3
Proceedings of the 42nd Hawaii International Conference on System Sciences - 2009
first flow dependency. Managing a flow always
involves managing the timing, usability, and location
of the resource that is flowing. Each of these subtasks
has characteristic exceptions (the manage usability step
has, for example, the exception “flow wrong thing”),
and each of these exceptions has a range of processes
(not shown) for handling them.
Continuing this approach, we developed a detailed
model of this change management process and two
other change management processes used in the same
aerospace program to manage changes to other
attributes of the program. We found that the
differences between these three processes can be
viewed as a consequence of choosing different
coordination mechanisms or different exception
handlers, and we developed a consolidated derivation
tree that shows the origins of these variations in the
processes [23].
Modeling the process using Coordination Theory
provided valuable insights about alternative ways of
managing the process and about the reasons for the
variability in processes that we observed. The models
are clearly ostensive, describing how people should
perform the process. The explicit representation of
exception conditions and handlers for these exceptions
could be used to develop more robust workflow
management systems by anticipating the kinds of
exceptions that might occur or by dynamically
responding to an exception using a handler described
in the Process Handbook.
3.4 GOMS models
GOMS [5] is a formal method for modeling
human-computer interactions that provides a dynamic
description of a single person’s actions when
interacting with a computer. It is generally used to
model highly repetitive skilled activities to predict
performance and determine the impact of changes to a
user interface on total system performance. A GOMS
model includes a detailed definition of its constituents:
the goals, operators, methods, and selection rules
required for a person to perform the activity. Modeling
tools have been developed to support construction and
simulation of GOMS models. Such models are
ostensive in that they describe how the work is
intended to be done, but these models may be tested
against actual work performance.
Change Management
Has part
Has part
Has part
Propose
Flow (CR)
change
Authorize
Implement
Flow (CN)
change
change
ihb
Manage flow
Has part Has part
Has part
Manage
timing
Manage
usability
Manage
location
Has exception
Has exception
Has exception
Flow
wrong
time
Flow
wrong
thing
Flow
wrong
place
Figure 2. The top level of a model based on
Coordination Theory
Kieras and Santoro [19] developed and tested a
GOMS model of a complex team task, operating a
combat information center aboard a navy vessel. They
developed GOMS models that described how each role
or individual on the team would interact alone with the
system. Then they created a team of these models by
adding methods for team interaction. For example, one
role announces orally when a new event is identified,
and another role responds by re-evaluating this event.
Those collaboration activities were added to the
GOMS model. Through simulation tools, they could
predict the performance of the system if human teams
perform according to plan. They discovered, however,
that validating the model was exceptionally difficult in
such a complex task; there were substantial deviations
between the model and actual human performance. It
appeared that people were not collaborating in exactly
the ways described by their subject matter experts.
Different human teams differed substantially in the
ways they interacted and communicated. The GOMS
model described how the tasks were intended to be
done, but actual behavior deviated widely from this
ostensive model.
We considered developing a GOMS model of the
engineering change management process and
concluded that such a model would be inappropriate
for this activity and would not deepen our
understanding of the process or provide an adequate
model of collaboration. This approach bears fruit when
users are continuously engaged in interacting with a
computer system, but the change management process
4
Proceedings of the 42nd Hawaii International Conference on System Sciences - 2009
requires using many different computer systems and
non-computerized resources. Assessing the impact of a
proposed change may require formal analyses or
discussions with other people. This single task may
involve substantial problem solving and is not readily
captured as a set of rules.
4. Performative modeling approaches
Four
modeling
approaches
emphasized
performative behavior: grounded theory, temporal
models, social network models, and Language Action
Perspective models.
4.1 Grounded theory
Grounded theory is an approach or methodology
for developing an understanding about how and why
collaboration occurs within a particular setting.
Grounded theory has a long history, originating in the
work of Glaser and Strauss [12] and evolving through
many subsequent books and papers (e.g., [11]). The
Grounded theory approach is to carefully observe,
record, and analyze collaborative behavior, building an
understanding about the underlying processes and
structures that is grounded in the observations. The
basic steps of this approach are data collection, note
taking, coding, annotating, sorting, and writing.
We observed, interviewed, and collected artifacts
from the people who participated in the engineering
change management process. Analyzing these data, we
constructed codes and relationships between them.
Figure 3 shows part of the model that emerged from
this analysis. In an interview with change coordinator
MC, he said, “Actually, most of our changes these days
have been configuration changes, and TG and I are
doing all those. KC is doing the rest of them.” The
model shows these three change coordinators, two
types of changes, and the relationships between types
of change and change coordinators. Change
coordinator KC complained that “configuration is not
following the process. We find out about them in the
CCB and stick them in the system.” Thus we discover
that there is both a standard process and an exception
process, and configuration changes are following the
exception process. The exception process was not
implemented in the workflow management system
used to coordinate changes, but the change
coordinators had found ways to enter the data in the
system without following the defined workflow
process. We will learn more about this in later sections
of this paper.
Process Types
Standard
Exception
Change Types
Configuration
Other
Change Coordinators
MC
KC
TG
Figure 3. Part of a grounded theory model
We also learned that the change coordinators were
maintaining a spreadsheet with detailed information
about each change, including who had created and
reviewed it, its current state in the process, the decision
of the change control board, and the reasons for any
delays. The existence of this spreadsheet was a surprise
because it duplicated the information that the workflow
management system automatically generated. It
revealed that the change coordinators had relatively
little trust in the change management system. They
undertook the extra work to maintain the same data in
a spreadsheet, despite the inevitable problem that the
spreadsheet did not support collaboration. Only one
person at a time could open and edit the spreadsheet.
The grounded theory approach yielded a
performative view of engineering change management,
and this view contained potentially important details
about this process that were not included in any of the
ostensive views. Indeed, it revealed that the ostensive
models were not consistently followed, and that
participants in the process undertook extra work to
protect themselves from the consequences of a failure
of a system based on ostensive models.
4.2 Temporal models
Collaborative behavior consists of actions and
reactions that occur over a span of time, and the time
course of these actions can provide insights about the
structure and practice of collaboration. Other studies of
temporal properties of collaboration have shown that
humans are creatures of habit, and rhythms of activity
can be tracked and predicted with some reliability [2,
10, 14].
The change management system recorded when
each participant completed a task in the process.
Because this process is repeated many times, we can
explore both daily and weekly patterns of temporal
activity. Figure 4 shows when change coordinators
created the change requests and change activities
(authorizing an approved change) during a three month
period. These data show that they accomplished most
of this work early in the morning or in the early
afternoon, and there was a sharp decline in activity
during lunch hours. In our observations and interviews
we learned that the change coordinators were in
meetings for many hours of each day, and they
reserved the early morning for accomplishing work
done at their desks.
5
Proceedings of the 42nd Hawaii International Conference on System Sciences - 2009
Hourly CRs/CAs
12.00
10.00
8.00
CAs
CRs
6.00
4.00
2.00
0
0
18
:0
0
0
17
:0
16
:0
0
0
15
:0
14
:0
0
0
13
:0
12
:0
0
11
:0
00
9:
10
:0
00
00
7:
8:
6:
5:
00
00
0.00
Hour of Day
Figure 4. Number of change requests and
change activities created per hour
Figure 5 shows the number of change requests and
change activities created per day of the week. Again,
there are obvious patterns in the data, but the patterns
are different for these two types of documents. The
reasons for these patterns and their differences stem
from the meetings that change coordinators attend and
their distribution across the week. Our interviews and
observations revealed that change control boards met
every Monday, Tuesday, and Wednesday, and change
activities were created after these meetings, often early
the next morning. But the Wednesday change control
board considered configuration changes, which we
learned were handled as exceptions. MC and TG
created all new change requests for the week after the
Wednesday meeting. On Fridays the change
coordinators had few meetings and used this time to
catch up on work that had accumulated during the
week.
80
70
60
50
CAs started per day
CRs started per day
40
30
20
10
0
M
T
W
R
F
S
U
Figure 5. Number of change requests and
change activities created per day of the week
Figures 4 and 5 show temporal patterns in the data,
and the data we collected using the grounded theory
approach suggest some of the causes of these patterns.
We have not, however, constructed a detailed model of
the causal relationships resulting in these patterns of
activity. Such a model would provide another
performative view of the process, emerging directly
from their interactions with the system used to
coordinate changes. The ostensive models that guided
development of this system included nothing about the
temporal flow of the activities. Models of temporal
properties could be used to improve such systems. For
example, some workflow management systems can
assign tasks to individual people in a resource pool
depending on the number of tasks in their current
queues, but if they used temporal models they could
also predict their future workloads.
4.3 Social Network Models
Social network models describe the actual
interactions that occur in a workplace. Networks of
information, trust, and energy are critical to the
operation of businesses, and understanding the
interactions that underlie these networks has proven
useful. Often these networks do not mimic the
structures implied by business processes and
organizational charts. Some have argued that work will
proceed more smoothly if both processes and social
networks are adjusted to reflect the realities and goals
of organizations [7].
We constructed a social network model that
represents the flow of task responsibility from one
person to another in the engineering change
management process. When change coordinators
created a change request, they also created a team of
people to perform the tasks required to process the
request. Each time a task was completed (e.g., review a
proposed change), the workflow management system
assigned the next task to whomever had the appropriate
role on that team. We created a relationship matrix in
which the cell at row A and column B contained the
number of times a task completed by person A was
followed by a task assigned to person B.
Figure 6 presents a social network model
constructed from this relationship matrix. Each red
object in the model represents a change coordinator,
each orange object represents a reviewer, and each
green object represents a person who implements an
approved change. A line between these objects
indicates that these people performed successive tasks
in one or more process instances. The lines between
people are shorter when they frequently perform
successive tasks. An arc beginning and ending at the
same object indicates that the represented person
performed successive tasks, and numbers next to the
arcs are the frequencies of the same person performing
successive tasks.
6
Proceedings of the 42nd Hawaii International Conference on System Sciences - 2009
RLS
BLH
HQT
PJB
TJP
10
RME
CBP
MLC
JFT
7
EH
JME
24
2
DAR
TDG
SBK
GGG
AWW
RLB
KC
5
LKB
DCH
WLJ
RJT
MM
MFH
JOM
KK
DQL
MTC
Figure 6. Social network model of the
engineering change management process
We were surprised to discover that change
coordinators, particularly MC and TG, frequently
performed many of the tasks in the process. Instead of
distributing the work to a multidisciplinary team, as
intended, the change coordinators were assigning
themselves to many of the roles on the team. Again,
our interviews and observations were enlightening
about the reasons for this. Changes to configuration
were not following the intended process. The people
involved in analyzing changes to configuration were
unwilling to adopt the system used for all other
changes, and the change coordinators were simply
acting as proxies for the people who were actually
accomplishing the work. The change coordinators put
themselves in many or all of the roles on the team
defined within the system, but they did not actually
have these roles within the team that performed the
work.
This social network model is a performative view
of the collaboration as it was captured by the change
management system. But it is a distorted view, because
some people were not using the system as intended.
We might never have known about this unexpected
way of using the system if we had not investigated the
social networks.
4.4 Language Action Perspective
The Language Action Perspective begins with the
premise that people act through language. The speech
act is the unit of analysis, with speech acts situated
within conversations. An important example is a
conversation for action in which one person asks
another to do something. The second person can
accept, decline, or counter offer. Each response yields
different conversational alternatives for the requestor.
This simple conversational structure was at the heart of
The Coordinator, a system intended to support office
communication [32]. Other commercial products and
virtually all proposed protocols for agent-to-agent
communication [6] and tools for modeling
organizational discourse [24] have been based on this
theoretical approach.
Conversations for action are clearly important in a
business context, but people also engage in other types
of conversations in office environments. These include
conversations for clarification, for possibilities, and for
orientation. The key observation of the Language
Action Perspective is that each type of conversation
has regularity of structure. The types of speech act that
are appropriate at any point in a conversation are
constrained by this regularity. An information system
with knowledge of this regularity may support
communication more effectively (the purpose of The
Coordinator) or participate in conversations as one of
the communicating agents.
The engineering change management process
could be viewed as a collection of negotiation
conversations. In these conversations the requestor
asks for commitment to make a change and the
responder commits, counter offers, or declines. In the
change management process, the change originator
asks for a change to be made. The change coordinator
asks the data managers and team representatives to
review the proposed change. Later the change
coordinator asks the change control board to approve
the change. The recipient of each such request can
make any one of several responses. An instance of the
change management process would consist of dozens
of such conversations, and keeping track of each of
them would seem to be an onerous task, but this is
exactly what people do when engaged in complex
business activities.
The intent of the Language Action Perspective
was to capture the performative properties of work
more effectively by drawing attention to all the actions
available to a person. If we view change management
as a collection of conversations in which each actor in
the process has a limited set of possible responses, then
we are encouraged to explore and define the sets of
responses. This analysis can be based on records of the
actions taken in an existing system, observations of
people at work, and interviews of process participants.
We could create an ostensive model that defines
and constrains the set of available actions at each step
in the process. And we could implement a system
based on such a model that explicitly lists all possible
7
Proceedings of the 42nd Hawaii International Conference on System Sciences - 2009
actions, allowing users to choose among them.
Systems inspired by this approach have been criticized
for being too prescriptive. In some workplaces the
conversational acts available in The Coordinator were
perceived as too explicit; people wanted to be more
subtle [30].
When using the Language Action Perspective to
construct ostensive models of collaboration, we must
remember that in some conversations the participants
do not have adequate information to make
commitments. In a design setting, for example, mutual
understanding often emerges through discussion.
Understanding developed through speech (e.g.
common ground or decision making) is not easily
expressed through the Language Action Perspective..
5. Discussion
In this paper we explored how eight ways of
modeling collaboration could be used to improve
support for an engineering change management
process. Ostensive modeling approaches provided
ways of documenting, analyzing, simulating, and
automating this collaborative process. Performative
modeling approaches provided alternative views of the
actual collaborative behavior of the process
participants and its deviations from the intended
behavior described by the ostensive models. Each
model provided a different view of behavior and
offered different opportunities for improving the
technology or its use. In this section we re-examine
how the eight modeling approaches we investigated
contribute to requirements analysis, choosing or
developing new collaboration capabilities, adoption,
and
maximizing benefit
from technologies.
5.1 Improving requirements
Application requirements are generally defined by
creating an ostensive model of the processes they are
intended to support. Requirements for industrial
applications are developed by experts in the application
domain who know the tasks to be performed very well,
but may not know or be able to express all the
collaboration or cognitive requirements. They also may
not realize that actual work practice is rarely identical
to the work process defined by domain experts [31].
Some organizations have adopted participatory design
practices [25] to avoid breakdowns associated with
traditional development practice, and those practices
were followed in our development of change
management technology, but these practices do not
assure that all critical contextual factors will emerge
[13].
Performative modeling approaches can be used to
obtain a deeper understanding of actual work practice
and its variability. These approaches provide
exceptionally thorough understanding of how
collaborative work is accomplished and the factors that
influence its success. The principal shortcoming of
employing a performative modeling approach is its
cost in terms of time and specially trained personnel.
Of course, in some cases the benefits justify these
costs. Another shortcoming is that their results are
specific to the conditions in which the work was
observed, and those conditions include the specific
people involved in the work. Introduction of a
technology will change those conditions, as will
ongoing changes in job assignments.
According to Coordination Theory, the purpose of
collaboration is to satisfy dependencies, and the
business process is constructed for that purpose. This
approach identifies alternative mechanisms or activities
that might yield an improved process and consequently
a different technology. For example, work that has
been allocated to engineers via a first-in, first-out
queue could instead be allocated through an auction in
which engineers bid on the jobs they want to tackle.
This approach to requirements analysis should yield an
entirely different process and consequently very
different detailed requirements.
5.2 New Collaboration Capabilities
Workflow modeling directly addresses the
creation of new collaboration capabilities. The
workflow model is instantiated in software, and it
supports collaboration among all participants in
accordance with that model. The shortcoming, of
course, is that work practices that deviate from the
model are impaired. In our experience deploying
workflow applications, deviations are often required.
Both temporal and social network models suggest
ways to improve collaboration support. For instance,
rather than setting up teams beforehand, a
collaboration infrastructure might be able to
automatically build teams based on closeness and
availability. Collaboration systems often seem “tonedeaf” to users, not necessarily understanding the details
of day-to-day work or social interactions. Being able to
leverage social networks and temporal models may
make these systems aware of a larger context in which
the work takes place, and to adapt appropriately.
5.3 Improving Adoption
Adoption of collaboration technology poses
unique challenges because everyone involved must
8
Proceedings of the 42nd Hawaii International Conference on System Sciences - 2009
adopt the technology in order for it to be effective. The
ostensive modeling approaches are unlikely to provide
much assistance planning or executing successful
adoption beyond indicating the people/roles that must
adopt the technology. Developing a successful
adoption plan generally requires an understanding of
social and organizational influences on the process,
which are more likely to emerge from a performative
modeling approach. Indeed, performative modeling
approaches have been used to analyze the adoption of
collaborative technologies in research using both the
Technology Acceptance Model (TAM) [8] and
Technology Transition Model (TTM) [3, 4]. Social
network models may be useful when considering
whom to target as early influential adopters and which
groups of people must adopt concurrently to achieve
any benefit of the technology.
probabilities. Extending the GOMS approach by
introducing alternative methods and probabilistic
selection rules offers one way to model variability in
human collaborative behavior. The methods and
selection rules of such a model might be organized in
patterns as in Language Action Perspective models.
They could also take into consideration the temporal
patterns of behavior and the communication patterns
revealed by social network theory. An information
system with such a model could match actual group
behavior to the model in real time and potentially
anticipate future collaborative behaviors or participate
in collaborations in a more human-like manner.
6. REFERENCES
1.
Bahrami, A., Object Oriented Systems Development:
Using the Unified Modeling Language. McGraw Hill
College, New York, 1999.
2.
Begole, J. Tang, J., Hill, R. Rhythm Modeling,
Visualization, and Applications. In Proceedings of the
16th Annual ACM Symposium on User Interface
Software and Technology. Vancouver, 2003, 11-20.
3.
Briggs, R.O., Adkins, M., Mittleman, D., Kruse, J.,
Miller, S. and Nunamaker, J.F. A technology transition
model derived from field investigation of GSS use
aboard the U.S.S. Coronado. Journal of Management
Information Systems, 15, 1998, 151-196.
4.
Briggs, R. O., Nunamaker, J.F. and Tobey, D. The
Technology Transition Model: A Key to Self-Sustaining
and Growing Communities of GSS Users. In
Proceedings of the 34th Hawaii International
Conference on Systems Sciences, 2001.
5.
Card, S.K., Moran, T.P., and Newell, A. The
Psychology of Human-Computer Interaction, Lawrence
Erlbaum Associates, 1983.
6.
Colombetti, M. & Verdicchio M. An analysis of agent
speech acts as institutional actions. In Proceedings of
the First International Conference on Autonomous
Agents and Multiagent Systems, Bologna, Italy, 2002,
1157-1164.
7.
Cross, R., Parker, A. The Hidden Power of Social
Networks: Understanding How Work Really Gets Done
in Organizations. Harvard Business School Press,
Cambridge, 2004.
8.
Davis, F.D. User acceptance of information technology:
system characteristics, user perceptions and behavioral
impacts. International Journal of Man-Machine Studies,
38, 1993, 475-487.
9.
Feldman, M.S.. and Pentland, B.T. Reconceptualizing
organizational routines as a source of flexibility and
change. Administrative Science Quarterly, 48, 2003, 94118.
5.4 Maximizing Benefits
Many collaboration technologies may be viewed
as communication media, a view that is consistent with
the language action perspective. Properly instrumented,
collaboration technologies could provide substantial
information about the collaborations they support and
enable a continuous cycle of performative modeling
and analysis. Models based on these data could be used
to identify or anticipate problems or breakdowns in
collaboration or opportunities for improving
collaboration. For example, social network analysis of
communications could be employed to identify people
who are key nodes in a communication flow and
provide additional support or capabilities to those
individuals. Temporal models could identify nonstandard work habits, and help to provide the
additional support needed (or flag possibly illegitimate
use).
Actual
communication
behavior
derived
automatically from technology use could be compared
with an ostensive model of optimal performance, and
significant deviations could be targeted for special
attention. Suppose, for example, that a GOMS model
existed of optimal team performance in a work context.
Kieras and Santoro [19] noted that actual collaboration
performance deviated substantially from their model of
collaboration in a command and control setting. If such
deviations were automatically collected and analyzed,
some deviations might be evidence of the need for
additional training or team coaching.
None of the modeling methods we explored
described the variability that is well known to exist in
collaboration practice. A more complete model of
collaboration would describe alternative practices, the
conditions under which they were enacted, and their
10. Fisher, D., Dourish, P. Social and Temporal Structures
in Everyday Collaboration. In Proceedings of the
9
Proceedings of the 42nd Hawaii International Conference on System Sciences - 2009
SIGCHI conference on Human factors in computing
systems. Vienna, 2005, 551-558.
11. Glaser, B.G. Doing grounded theory: Issues and
discussions. Sociology Press, Mill Valley, CA, 1998.
12. Glaser, B.G., and Strauss, A.L. The discovery of
grounded theory: Strategies for qualitiative research.
Aldine, Chicago, 1967.
13. Grudin, J. Obstacles to participatory design in large
product development organizations. In D. Schuler & A.
Namioka (Eds.), Participatory Design: Principles and
Practices, Hillsdale, NJ: Erlbaum, 1993, pp. 92-122.
14. Hudson, J, Christensen, J. Kellogg, W., Erickson, T. "I'd
be overwhelmed, but it's just one more thing to do":
Availability and Interruption in Research Management.
In Proceedings of the SIGCHI conference on Human
factors in computing systems. Minneapolis, 2002, 97104.
15. Hutchins, E. Cognition in the Wild. Bradford Books,
Boston, 1995.
16. Hutchins, E., Holder, B.E. and Perez, R.A. Culture and
Flight Deck Operations. Prepared for The Boeing
Company, University of California, 2002.
17. Hutchins, E. and Klausen, T. Distributed cognition in an
airplane cockpit. In Y. Engeström and D. Middleton
(Eds.) Cognition and Communication at Work. New
York: Cambridge University Press. 1996, 15-34.
18. Jones, H. and Hinds, P. Extreme work teams: Using
SWAT teams as a model for coordinating distributed
robots. ACM Conference on Computer Supported
Cooperative Work (CSCW 2002), New Orleans,
November 2002, 372-381.
19. Kieras, D.E. and Santoro, T.P. Computational GOMS
modeling of a complex team task: Lessons learned.
Proceedings of the SIGCHI conference on Human
Factors in Computing Systems (CHI 2004), Vienna,
Austria, 2004, 97-104.
20. Klein, M. and Petti, C. A handbook-based methodology
for redesigning business processes. Knowledge and
Process Management, 13, 2006, 108-119
21. Malone, T, K. Crowston, K. and Herman G. (eds).
Organizing Business Knowledge: The MIT Process
Handbook. MIT Press, Boston, 2003.
22. Orlikowski, W.J. Case tools as organizational change:
Investigating incremental and radical changes in system
development. Management Information Systems
Quarterly, 17, 3, 1993, 309-340.
23. Poltrock, S., Handel, M. and Klein, M. Understanding
process differences: Agreeing upon a single way to skin
a cat. Proceedings of IEEE Conference on Knowledge
Systems for Coalition Operations (KSCO 2007),
Waltham, MA, May, 2007.
24. Schoop, M. An introduction to the language-action
perspective. ACM SIGGROUP Bulletin, 22, 2, 2001, 38.
25. Schuler, D. and Namioka, A. Participatory Design:
Principles and Practices, Hillsdale, NJ: Erlbaum, 1993.
26. Sonnenwald, D.H., and Pierce, L. Information behavior
in dynamic group work contexts: Interwoven situational
awareness, dense social networks, and contested
collaboration in command and control. Information
Processing & Management, 36, 3, 2000, 461-479.
27. Suchman, L.A. Office procedures as practical action:
Models of work and system design. ACM Transactions
on Office Information Systems, 1, 4 (Oct. 1983), 320328.
28. Suchman, L.A. Plans and Situated Actions: The
Problem of Human-Machine Communication,
Cambridge University Press, 1987.
29. Suchman, L. (1993). Technologies of Accountability:
On Lizards and Aeroplanes. In G .Button (ed.)
Technology and the Working Order. Routledge,
London, 113-126.
30. Suchman, L. Do categories have politics? The
Language/Action perspective reconsidered. Computer
Supported Cooperative Work (CSCW), 2, 3, 1994, 177190.
31. Suchman, L.A. and Wynn, E. Procedures and problems
in the office. Office: Technology and People, 2, 1984,
133-154.
32. Winograd, T. A language/action perspective on the
design of cooperative work. In I Greif (Ed.), ComputerSupported Cooperative Work: A Book of Readings,
Morgan-Kaufman, San Mateo, 1988, 623-653.
10