=Paper=
{{Paper
|id=None
|storemode=property
|title=Towards Effective Collaborative Design and Engineering
|pdfUrl=https://ceur-ws.org/Vol-747/paper7.pdf
|volume=Vol-747
}}
==Towards Effective Collaborative Design and Engineering==
https://ceur-ws.org/Vol-747/paper7.pdf
Towards effective collaborative design and engineering
Stephan Lukosch Gwendolyn Kolfschoten
Delft University of Technology Delft University of Technology
Faculty of Technology, Policy, and Management Faculty of Technology, Policy, and Management
Jaffalaan 5, 2628 BX Delft, The Netherlands Jaffalaan 5, 2628 BX Delft, The Netherlands
s.g.lukosch@tudelft.nl g.l.kolfschoten@tudelft.nl
ABSTRACT Groups might not be able to overcome the challenges of collabo-
Effective collaborative design and engineering has to deal with var- ration by themselves [16]. Even if groups are able to accomplish
ious challenges. It is essential to create a shared understanding and their goals, they can often collaborate more efficiently and effec-
facilitate interaction in such a way that effective collaboration be- tively using collaboration support [6]. Collaboration support can
comes possible. Free riding, group think or hidden agendas need be comprised by tools, processes and services that support groups
to be addressed by rarely available process facilitators. Available in their joint effort. In knowledge oriented organizations, there is
tools are not regularly used, are not intuitive and often are difficult often a need or demand for collaboration support. However, tools
to adapt to the changing group needs. In order to tackle the above and technology for group support exist in a variety of shapes from
issues, we want to enable effective collaborative design and engi- complex computer systems, as e.g. Group Support Systems (GSS),
neering by offering intelligent collaboration support that supports to simple boxes with cards and pencils. Each of these tools can
facilitators of collaboration processes when monitoring collabora- be used by the group to be more successful in sharing ideas and
tion processes and planning process interventions or tool adapta- indicating relations and preferences, but current challenges emerge
tions. from the fact that available tools are not regularly used, are not in-
tuitive and often are difficult to adapt to the changing group needs
[7]. This makes it difficult for organizations to provide their teams
Categories and Subject Descriptors with a suitable and adaptable collaboration support that help them
H.4.1 [Office Automation]: Groupware; H.5.3 [Group and Or- accomplish their goals efficiently and effectively.
ganization Interfaces]: Computer-supported cooperative work;
K.4.3 [Organizational Impacts]: Computer-supported collabora- As discussed in [7], current collaboration support systems focus
tive work adaptations with a limited scope. They are either restricted to spe-
cific domains or to specific aspects of collaborative work, often
General Terms focusing on awareness or knowledge management. Compared to
Design, Human Factors this, we aim to create intelligent collaboration support that creates
a shared understanding, facilitates collaborative actions across vari-
ous geographic, temporal, disciplinary, and cultural boundaries and
Keywords provides intuitive and adaptive tool support. This will allow us to
Collaboration support systems, intelligent collaboration support, offer collaboration support for a variety of collaborative tasks in
facilitation, group support systems a way that groups can use it for themselves without the need for
extensive training or a professional facilitator. In this paper, we
1. INTRODUCTION will as a first step propose a conceptual framework towards intel-
Collaboration has become a critical skill as products and services ligent collaboration support. We modeled collaboration processes
are becoming increasingly complex, no individual has the skills to and identified factors suggesting process changes as well as adap-
design, develop and deliver these alone. Collaboration is however, tations. These factors are the basis for this framework of intelligent
not without challenges. On a group level, it is essential to create a collaboration support, which will offer us a first step in monitoring
shared understanding, define rules for decision-making and facili- groups and predicting the need for facilitation interventions.
tate interaction in such a way that effective collaboration becomes
possible [13]. On a process level, free riding, dominance, group In the next section we will explain in detail how facilitators guide
think, hidden agendas, are but a few phenomena in group work that collaboration processes. This will lead to a conceptual framework
make it a non straight-forward effort [16]. of collaboration support interventions, presented in section 3. Next
we will present how this framework can be used to identify specific
collaboration situations to create intelligent collaboration support.
We will then reflect on this design and end with conclusions and a
research agenda.
2. FACILITATING COLLABORATION
PROCESSES
One of way of supporting groups in achieving their goals more ef-
ficiently and effectively is to support the group by structuring and
guiding their activities. This skill and profession is called facilita- 1. Collaboration process design: Interventions to guide col-
tion. The facilitation task is described extensively in GSS literature laborators in choosing appropriate tools and techniques to
[1, 8, 14]. The task of a facilitator requires both experience and support the collaboration process.
extensive knowledge of group dynamics and facilitation methods.
This tasks involves for instance management of the activities the 2. Collaboration process execution: guidance to move from
group is performing, quality of their deliverables, relations between one activity to a next activity, changing the collaboration sup-
the participants and the use of resources and time [9]. This type of port environment to transfer between activities, while taking
process guidance is often offered by someone external to the group, documents and decisions along to a next phase.
to ensure impartiality and objectivity. 3. Collaboration process guidance: Activities need to be ini-
tiated and guarded to execute the collaborative activity.
In an effort to reduce the need for professional facilitators, re-
searchers have been coding facilitation practices to enable the sepa- 4. Collaborative behavior guidance: guidance in determining
ration of the design task of a facilitator and the execution task [11]. and adjusting improves collaborative effectiveness.
In this way a master facilitator called collaboration engineer, can
design and transfer a collaborative work practice to practitioners to
In a face to face context, facilitators can make adjustment interven-
execute it for them selves based on a short training. This approach
tions based on behavior of group members, including communica-
is called Collaboration Engineering [3]. To ensure the predictabil-
tion with group members, quality of the output of the group, and
ity and transferability of the collaborative work practice, they are
progress versus planned time for the group task. Based on our ex-
designed with design patterns called thinkLets [4].
perience and discussion with expert facilitators, the following list
is a first attempt to identify factors used to determine the need to
To realize an intention by means of intervention, two types of in-
make an intervention:
terventions are required [2]. First, there are static interventions in
which one or more commands are given to initiate the key activi-
ties of a process. We will refer to this kind of communication as an • Group: behavior, emotions, communication, body language,
instruction intervention. Second, there are dynamic interventions address facilitator, gestures
intended to adjust the actions performed by the group to resolve a
discrepancy between the facilitator’s intentions and the groups’ ac- • Task: amount of input, rate of input, quality of input, quality
tions. These interventions depend on emergent conditions. We will of output, shared understanding, fit in relations in output
call these messages adjustment interventions. • Time: progress, time left
The conceptual design of a thinkLet exists of a set of instruction
and adjustment interventions described as rules [4]. These rules Some of these aspects are non-digital and based partially on inter-
are similar to rules mimicking human behavior in avatars [2]. Each pretations. This requires a translation to gain the same insights
rule describes for a role an action that needs to be performed using from the online interaction. For instance facilitators might monitor
a capability under some set of constraints to restrict those actions. de-focus of participants as an indicator that the group is finished
Further, some thinkLets include conditional rules for frequently- with the task. However, this might also be learned from a signifi-
required adjustment interventions because specific discrepancies cant decrease in input rate. However, without technology support
manifest predictably during the execution of an activity based on to monitor input rate, perhaps per participant, this would be diffi-
the thinkLet. cult to detect for a facilitator. Also the interpretation of input rate
requires some experience and understanding of the cognitive impli-
An example of a set of rules are captured in the L EAFHOPPER thin- cations of tools and knowledge sharing. Therefore we need more
kLet [4]: than a thermometer to measure input rate, we need an intelligent
collaboration support system that can monitor these factors, and
use them to reason about the current collaboration process in order
1. Allow participants to add in parallel any number of contribu- to support facilitators in making intervention decisions.
tions to any category.
2. Allow participants to add only contributions that are relevant
4. LEAFHOPPER FACILITATION INTER-
to the categories in which they are placed. VENTIONS
In the textbox below we describe what a facilitator does after initi-
3. Allow participants to add only contributions that match to the ating the L EAFHOPPER thinkLet to brainstorm ideas in categories.
contribution specification. Underlined are those indicators the facilitator uses to make deci-
sions on interventions. Some of these indicators can directly be
4. Let participants shift focus from category to category as in- observed, others are an interpretation of the facilitator.
terest and inspiration dictate.
After initiating the Leafhopper the facilitator needs to maintain sev-
5. Ensure that participants read the contributions of others for
eral rules. The contributions of the group need to meet the quality
inspiration.
intended, they need to meet the contribution specification, the cat-
egory in which they are placed. The contributions need to be made
3. CONCEPTUAL FRAMEWORK in a certain timeframe, and they need to cover a certain scope of
In order to provide intelligent collaboration support, we first need information (completeness). Additionally the facilitator will need
to identify the key goals that guide facilitation interventions. When to maintain a safe and respectful atmosphere to ensure that people
facilitators intervene to initiate activity they can offer these at dif- feel free and encouraged to participate. To ensure that the partic-
ferent levels [15]: ipants can share all relevant contributions, the facilitator can add
Figure 1: Domain model for collaboration in a shared workspace
a category ’other’. This category is monitored by the facilitator. setting (e.g., team structure, roles, tasks). Dey et al. [5]define con-
When a pattern of contributions can be found in this category, the text as any information used to characterize a situation of an entity
facilitator will add a new category to cover this topic. where an entity may be any object, person or place providing in-
formation about the interaction between a user and an application.
The facilitator will monitor the input, mainly to detect if there are With this definition, any information may help characterizing the
small or insufficient quality contributions. Later in the process situation of the interaction’s participants because it is part of the
the facilitator will monitor if the categories each contain a suffi- context itself. For our purposes, we can narrow this definition so
cient number of contributions. Also, the facilitator will monitor that context includes all information which is necessary or helpful
the ’other’ category to see if there is a persistent topic addressed, to adapt a shared workspace to better fit the needs of a collaborat-
and therefore, a need to add a category. The facilitator might inter- ing team. This implies that the context contains information about
vene if some categories are not filled. Such intervention would be the team as well as about the current collaboration situation. This
made before the time for the task is passed, to give participants context information is necessary to recognize situations which de-
time to add ideas in these categories, but not too early, when par- mand a facilitator’s intervention (and thus help minimizing the ef-
ticipants might not yet had a chance to contribute to all categories. fort needed for adaptation).
The facilitator will also observe the group to see if participants get
distracted, or focus on other activities, which indicate that they We use a collaboration domain model for describing collaboration
are (no longer) motivated for the task. The facilitator will also mon- environments and collaboration situations [7]. Figure 1 summa-
itor behavior, communication and body language to see if any of the rizes this domain model and shows the basic classes and their rela-
input causes an emotional reaction, which could indicate conflict tions that can be used to describe collaboration context in a global
or flaming, which would require intervention. Finally the facilitator collaboration space. The domain model intends to capture the basic
will monitor the input rate and the focus of participants to detect concepts of collaborative workspaces. It focuses on the technolog-
when there is no more inspiration and the task can be ended. If the ical support for collaborative interaction and does not distinguish
group is still very active and focused when time is running out, different artifact types or task domains. If applied to a certain col-
the facilitator might encourage the group to speed up or to focus laboration environment, it must be extended with concepts match-
on more important contributions in order to ensure that sufficient ing the specific properties.
progress is made when the task should be finished. In some cases
this can also be a reason to give the group more time for the task. The model in Figure 1 distinguishes different concepts that describe
collaboration in a collaboration environment and relations between
these concepts. We start exploring and explaining the model in Fig-
5. DESIGNING INTELLIGENT COLLAB- ure 1 with the concept of an Actor (see lower part of Figure 1). The
ORATION SUPPORT domain model assumes that Actors are member of a Team and have
In order to create a collaboration support system that can suggest a Role defined by the User Workspace, as Applications are started
facilitators to make interventions, we use an explicit context model from within the User Workspace and thus the workspace can en-
to describe the current collaboration situation. A collaboration situ- sure pre-defined Roles. Each Role allows an Actor to perform spe-
ation can be characterized by the configuration of the collaboration cific Actions. The available Actions are defined by the supported
environment as well as the state of interaction of the users with the Application Functionality of an Application. As an example con-
system (e.g., based on interaction history) and the organizational
sider a chat application which should offer at least two action types: categories and in case again alerts the facilitator can specified as
OpenChat and SendMsg. These two actions would allow users to follows:
communicate with each other by opening a chat tool and send mes- rule "empty categories"
sages to each other. Other forms of collaboration such as within a when
collaborative diagram editor would require to add additional action $category: Category(size == 0)
types in order to specify the application functionality. then
forall $c in $category
As Actors interact with the Application by performing Actions al- openForFacilitator(Alert, "Category "+
$c.name()+" is empty.
lowed by their Roles, Roles define interaction possibilities within Focus the attention of
an application, e.g. in a shared writing application an author might the participants on the
perform all edit actions whereas a reviewer can only comment ex- empty category.")
isting text. The Actions are received by the corresponding Con- end
troller components of the Application. An Application implements
the model-view-controller (MVC) paradigm [12] and consists of
As final example, the following rule checks the focus of the partici-
Views and Controllers components. Views and Controllers use Ser-
pants in order to alert the facilitator when half of the participants do
vices to access the Artifacts. Artifacts use Services to notify Views
not focus on the activity of creating contributions. For that purpose,
and Controllers about changes. Each Application is part of a User
the rule retrieves for focus of each participant by identifying the ac-
Workspace and is created by an Application Factory which spec-
tive View in the User Workspace. Based on the basic collaboration
ifies what Applications are available within a workspace and how
model (cf. Figure 1), this information can be inferred via the User
these can be initialized. Finally, the class Application Functionality
Workspace and the opened Applications within the workspace. The
specifies the functionality an Application offers, e.g. in relation to
following example rule assumes that the participants should focus
communication, shared editing, or awareness.
on a view with the name ’contribution input’ and if they do not do
so alerts the facilitator:
All above classes are useful to model and store the configuration of
a collaboration environment and to capture the current context at rule "participants distracted"
runtime. Based on such context information, a collaboration envi- when
ronment is enabled to recognize situations, which demand a facili- $participants: Participant(focus !=
"contribution input")
tator’s attention and intervention. $threshold: $participants[0].team().
size()/2
The domain model is abstract and not related to a specific applica- eval($participants.size() >= $threshold)
tion domain. When considering our example on the L EAFHOPPER then
thinkLet, we need to extend the model as shown in Figure 2. In openForFacilitator(Alert, "More than 50%
order to incorporate the L EAFHOPPER thinkLet, the Artifact class, of the participants do
not focus on creating
the Action class and the Role class were extended. Based on this contributions.")
extension, we can now distinguish between participants and the fa- end
cilitator as well as identify contributions within a category.
6. DISCUSSION AND CONCLUSION
Based on the extended domain model, we can suggest process in-
Collaboration has become a critical success factor for many orga-
terventions or tool adaptations in order to improve collaborative
nizations, as products and services are becoming increasingly com-
interaction. One process intervention within our L EAFHOPPER ex-
plex and cannot be designed individually. However, collaboration
ample is triggered when the category ’other’ exceeds a specified
has several challenges. It is essential to create a shared understand-
threshold. The following rule consists of a condition and an action
ing and facilitate interaction in such a way that effective collabora-
block. The condition block retrieves all contributions within the
tion becomes possible. Free riding, group think or hidden agendas
context model that belong to the category ’other’ and then evalu-
need to be addressed by rarely available process facilitators. Avail-
ates whether the number of contribution has exceeded a specified
able tools are not regularly used, are not intuitive and often are
threshold. If this is the case, the action block opens an alert view
difficult to adapt to the changing group needs. In order to tackle
for the facilitator. The following pseudo code shows how such a
the above issues, we want to enable effective collaborative design
rule can be specified:
and engineering by offering intelligent collaboration support that
rule "create new category" supports facilitators of collaboration processes when monitoring
when collaboration processes and planning process interventions or tool
$contributions: Contribution(category == adaptations.
’other’)
eval($contributions.size() >= 20)
then
In this article, we identified several factors that are observed by
openForFacilitator(Alert, "Number of professional facilitators before changing and adapting an ongoing
contributions in collaboration process. We further introduced an abstract context
category ’other’ has model which can be used to model collaboration within a shared
exceeded specified workspace. We extended this model to include concepts and classes
limit. Check whether of the L EAFHOPPER thinkLet. Based on the experiences of a pro-
new category is
necessary.")
fessional facilitator, we used this extended context model to define
end rules which can assist a facilitator.
Based on the proposed rules, a context-adaptive and intelligent col-
Another example for a rule that monitors whether there are empty laboration support environment, such as [17], can alert a facilita-
Figure 2: Extended domain model for the L EAFHOPPER thinkLet
tor when an intervention might become necessary and reduce the Information Systems (IJCIS), 19(1-2):71–120, 2010.
facilitator’s overhead. In future work, we will go a step further [8] S. Hayne. The facilitator’s perspective on meetings and
and model entire collaboration processes based on thinkLets [10]. implications for group support systems design. Database,
We then will study factors that determine and influence collabora- 30(3-4):72–91, 1999.
tion performance, e.g. cognitive load or shared understanding, and [9] G. Kolfschoten and G. de Vreede. A design approach for
that inform facilitation interventions. Once identified, we will inte- collaboration processes: A multi-method design science
grate these factors in our context model and think about possibili- study in collaboration engineering. Journal of Management
ties to measure soft factors via additional application functionality Information Systems, 26:225–256, 2009.
and without obstructing or distracting the group work, e.g. by of- [10] G. Kolfschoten, S. Lukosch, and M. Seck. Modeling
fering means for self reporting. We will further identify and specify collaboration processes to understand and predict group
rules that recognize situations that require process interventions by performance. In A. Dix, T. Hussein, S. Lukosch, and
recording facilitation interventions and the performance indicators J. Ziegler, editors, Proceedings of the IUI workshop on
at the point of intervention to gain more fine-grained rules for pro- Semantic Models for Adaptive Interactive Systems (SEMAIS)
cess intervention. 2010, 2010.
[11] G. Kolfschoten, F. Niederman, G. de Vreede, and R. Briggs.
The path to intelligent collaboration support sketched above is long, Roles in collaboration support and the effect on sustained
but small steps might already improve collaborative design and en- collaboration support. In Hawaii International Conference
gineering today. As facilitators need to monitor many factors and on System Science (HICSS-41), 2008.
indicators of progress, basic suggestions for process intervention as
[12] G. E. Krasner and S. T. Pope. A cookbook for using the
outlined above might already reduce some of the cognitive load of
model-view-controller user interface paradigm in
the facilitation task.
Smalltalk-80. Journal of Object-Oriented Programming,
1(3):26–49, Aug. 1988.
7. REFERENCES [13] S.-Y. Lu, W. Elmaraghy, G. Schuh, and R. Wilhelm. A
[1] F. Ackermann. Participants perceptions on the role of scientific foundation of collaborative engineering. CIRP
facilitators using group decision support systems. Group Annals - Manufacturing Technology, 56(2):605 – 634, 2007.
Decision and Negotiation, 5:93–519, 1996. [14] F. Niederman, C. Beise, and P. Beranek. Issues and concerns
[2] N. Badler, R. Bindiganavale, J. Bourne, M. Palmer, J. Shi, about computer-supported meetings: The facilitator’s
and W. Schuler. A parameterized action representation for perspective. Management Information Systems Quarterly,
virtual human agents. In Workshop on Embodied 20(1):1–22, 1996.
Conversational Characters, 1998. [15] F. Niederman, G. de Vreede, R. Briggs, and G. Kolfschoten.
[3] R. Briggs, G. de Vreede, and J. Nunamaker. Collaboration Extending the contextual and organizational elements of
engineering with thinklets to pursue sustained success with adaptive structuration theory in GSS research. Journal of the
group support systems. Journal of Management Information Association for Information Systems, 9(10), 2008.
Systems, 19:31–63, 2003. [16] J. J. Nunamaker, R. Briggs, D. Mittleman, D. Vogel, and
[4] R. Briggs and G.-J. de Vreede. ThinkLets: Building Blocks P. Balthazard. Lessons from a dozen years of group support
for Concerted Collaboration. Delft University of systems research: A discussion of lab and field findings.
Technology, Delft, The Netherlands, 2001. Journal of Management Information Systems, 13:163–207,
[5] A. K. Dey, G. D. Abowd, and D. Salber. A conceptual 1997.
framework and a toolkit for supporting the rapid prototyping [17] D. Veiel, J. M. Haake, and S. Lukosch. Facilitating
of context-aware applications. Human-Computer Interaction, team-based adaptation of shared workspaces. In
16(2, 3, & 4):97–166, 2001. International Symposium on Collaborative Technologies and
[6] J. Fjermestad and S. Hiltz. A descriptive evaluation of group Systems (CTS 2010), pages 275–284. IEEE, 2010.
support systems case and field studies. ournal of
Management Information Systems, 17:115–159, 2001.
[7] J. M. Haake, T. Hussein, B. Joop, S. Lukosch, D. Veiel, and
J. Ziegler. Modeling and exploiting context for adaptive
collaboration. International Journal for Cooperative