Information Technology Reference
In-Depth Information
2006), and results is a set of categorized ideas that
might contain redundant and double ideas.
A collaboration process design mostly consists
of a sequence of thinkLets, which is scripted in a
manual for practitioners (Kolfschoten, Kosterbok,
& Hoekstra, 2008; Vreede & Briggs, 2005). Fur-
thermore, practitioners get a process model and a
set of cue cards to support them during the execu-
tion of the process design (Kolfschoten & Hulst,
2006). The information required for the designer
of a collaboration process, i.e. the Collaboration
Engineer, is different from the information re-
quired by the practitioner. While the Collaboration
Engineer needs information to support the selec-
tion and combination of thinkLets, the practitioner
only needs the information required to understand
and execute the thinkLets in different instance of
the collaborative work practice.
Since the robustness of the collaboration pro-
cess design is of critical importance, there is large
emphasis on the validation of the design before
it is transferred to practitioners in the organiza-
tion. For this purpose, quality dimensions of a
collaboration process design are distinguished, as
described above (efficacious, predictable, trans-
ferable, reusable, acceptable). These dimensions
also offer a framework for the analysis of the
task (efficaciousness), stakeholders (acceptance),
available resources (reusability), and practitioners
(transferability) (Kolfschoten & Rouwette, 2006b;
Kolfschoten, Vreede et al., 2007; Kolfschoten,
Vreede, Chakrapani, & Koneri, 2006). Once the
requirements and constraints to the collaboration
process are known, a first sequence of activities is
determined. Then for each activity a thinkLet is
be selected resulting in a sequence of thinkLets.
Additionally other activities such as breaks,
presentations and introductions are placed in the
sequence. For each activity, additional information
should be specified. For instance in the example
of the LeafHopper thinkLet, the collaboration
engineer should specify the type of contributions,
(e.g. solutions, risks, problems), the categories in
which the group should brainstorm contributions,
the topic of the brainstorm in general and the time
for the thinkLet. Thus, if the LeafHopper were
used to have a group brainstorm requirements
for a new tool, categories could be hardware re-
quirements, software requirements and network
requirements, while the time for the activity could
be one hour.
Once all activities are specified, the col-
laboration process design can be validated based
on a number of criteria. Some characteristics
of thinkLets can be used to determine generic
characteristics of the entire process design such
as its duration, complexity, and the amount of
discussion. These factors influence the acceptance
of the work practice. This validation activity can
be automated, such that an alert is issued when
the collaboration process design does not meet
some or all of the criteria, e.g. too many complex
thinkLets are used, or too little discussion is in-
cluded in the design. Other validation criteria can
be offered as a checklist for consideration. After
validation, a process manual for the practitioner
should be created containing a process model, the
script for each activity, a summary of the analysis,
and cue cards to support execution (Kolfschoten
& Hulst, 2006). Furthermore, the execution of
the collaboration process can be supported with
tools such as Group Support Systems, for which
the information of the activity scripts needs to be
instantiated as well.
Over the past five years, the Collaboration
Engineering research community has developed
a number of 'paper-based' tools to support the
Collaboration Engineering efforts. First, the design
approach as described above, was developed and
evaluated based on feedback from facilitators and
students using the design approach (Kolfschoten,
Hengst, & Vreede, 2007; Kolfschoten & Vreede,
2007). The thinkLet pattern concept has been
introduced by Briggs and de Vreede (Briggs et
al., 2003; Briggs, Vreede, Nunamaker, & David,
2001; Vreede & Briggs, 2001), and was further
developed into its current form (Kolfschoten,
Appelman, Briggs, & Vreede, 2004; Kolfschoten,
Search WWH ::
Custom Search