• Keine Ergebnisse gefunden

Considering the possible complexity of a collaboration process and the influence of facilitation on the outcome and the process itself, the successful configuration and use of groupware functionalities is fundamental to design predictable and efficient collab-oration. Briggs et al. [Briggs et al., 2003] assume that the expertise needed for design and execution of collaboration can be reduced by packing and transferring knowledge about collaboration. They introduced Collaboration Engineering as a facilitation, de-sign and training approach for recurring high-value tasks that provides the benefit of professional facilitation to groups without access to professional facilitators [Briggs et al., 2003].

2.4.1 A collaboration pattern approach

Based on the concept of pattern by Alexander et al. [Alexander et al., 1977], Collabo-ration Engineering classifies the collaboCollabo-ration process into six patterns of collaboCollabo-ration (state of 2006 [Briggs et al., 2006]):

Generate To move from having fewer to having more concepts in the pool of concepts shared by the group. The pattern includes collaboration activities for knowledge creation and knowl-edge sharing such as the collection of known concepts from the group; the creation of new concepts that were not pre-viously known to all group members; or the improvement of already shared concepts by adding new details.

Reduce To move from having many concepts to a focus on fewer con-cepts that the group seems worthy of further attention. The pattern includes collaboration activities for selecting a sub-set of shared knowledge by deriving more-general concepts from specific instances in the existing set or by capturing the essence of the shared concepts without eliminating unique concepts.

Clarify To move from having less to having more shared understand-ing of concepts and of the words and phrases used to express them. The pattern includes collaboration activities for im-proving understanding of shared knowledge by proposing al-ternative explanations and formulations of existing concepts.

Organize To move from less to more understanding of the relationships among concepts the group is considering. The pattern in-cludes collaboration activities for improving understanding of shared knowledge by arranging existing concepts into la-beled clusters or by structuring existing concepts according to their conceptual relationships.

Evaluate To move from less to more understanding of the relative value of the concepts under consideration. The pattern includes collaboration activities for knowledge creation by collect-ing the group opinion with respect to the shared concepts or by identifying an order of preference among the shared concepts.

Build Consensus To move from having fewer to having more group members who are willing to commit to a proposal. The pattern in-cludes collaboration activities for identifying and overcom-ing the underlyovercom-ing causes of a lack of consensus.

Briggs et al. used this classification to form a pattern language for collaboration by introducing a design pattern for best facilitation practice called thinkLet [Briggs et al., 2003]. They define thinkLets as named, scripted, reusable, and transferable collabo-rative activities for creating specific known variations of the six patterns of collabora-tion among people working together toward a goal [Briggs et al., 2006]. The initial conceptualisation of the design pattern thinkLet involved the three components Tool, Configuration and Script [Briggs et al., 2001a] which provide information for the tech-nical and process functions of a facilitator [Clawson et al., 1993]. The components Tool and Configuration support the technical dimension of facilitation by defining a specific technology used and its appropriate preparation and use to create a pattern of collaboration. A process dimension is given by the component Script which concerns everything a facilitator would have to do or say to handle negative group behaviours and support group performance in a collaboration process using the specified technol-ogy.

Research shows that the provided facilitation knowledge of a thinkLet can help groups to predictably and repeatably create the pattern of collaboration the thinkLet is intended for, even without any facilitation expertise [de Vreede and Briggs, 2005]. However, the initial conceptualisation of a thinkLet ties a thinkLet closely to a specific technology in a specific configuration [Kolfschoten et al., 2006]. The use of other technologies requires changes in the three components by an expert, because small changes to a thinkLet script can create significant differences in group interactions [Shepherd et al., 1995].

Kolfschoten et al. [Kolfschoten et al., 2006] introduce with the thinkLet Class Dia-gram a formal specification of a thinkLet as a technology-independent logical design element. This specification uses the Unified Modelling Language notation to illustrate and define the key concepts and relations of a thinkLet script. An essential compo-nent is the concept Rule, whose instances define the Script of a thinkLet. Rules define the actions a participant must take individually in a given role, the constraints under which the actions must be executed and the capabilities that will be required to en-gender a pattern of collaboration [Briggs et al., 2006]. Intended actions of a partici-pant can be classified into categories like Add, Edit, Relate, Read, Discuss and Judge [Kolfschoten et al., 2004, 2006]. In conclusion, the formal specification of a thinkLet reduce the complexity of given collected thinkLets to fundamental concepts, which al-low researchers to understand the effects of facilitation interventions and collaboration process design.

2.4.2 An approach for collaboration process design

Collaboration Engineering uses thinkLets to form a pattern language for the design of collaboration processes. The design approach of Collaboration Engineering distin-guishes between the roles of a Collaboration Engineer, a Practitioner and a Participant [Kolfschoten et al., 2011, Briggs et al., 2006]. The role of a Collaboration Engineer is defined as a specialist in collaboration process design, who has expertise in the design and documentation of collaborative work practices using thinkLets. A Practitioner is a task specialist in a specific domain, who has no professional expertise with ration process design or facilitation but can learn specific skills for guiding a collabo-ration process using thinkLets. A Participant is a member of a group, that executes a collaboration process by creating a sequence of different patterns of collaboration. To reach a pattern of collaboration, each participant follows the instructions defined by the thinkLet script.

Figure 2.1: Process Design Approach for Collaboration Engineering adapted from [Kolfschoten and de Vreede, 2009]

According to the design approach of a collaboration process [Kolfschoten and de Vreede, 2009] (shown in Figure 2.1), the Collaboration Engineer analyses the collaborative task and the group characteristics to define requirements for the design of a collaboration process. In a second step the collaborative task will be decomposed into patterns of collaboration, which are used to select collaboration techniques (e.g. thinkLets or idea generation techniques) for a logical process model; a template of a collaboration pro-cess that contains a general description of collaborative activities for a collaborative task. The logical process model will be validated against the defined requirements in an iterative process and will be documented as a paper-based handbook.

A Practitioner configures the logical process model given by the paper-based handbook to a physical process design; a specific collaborative process that contains detailed de-scriptions of collaborative activities for a specific group and content constellation. A transition approach is used to transfer tacit knowledge and skills that are needed for this adaptation to practitioners with less expertise [Kolfschoten et al., 2011]. This approach combines lectures about the key concepts of Collaboration Engineering and challenges of a collaboration process with trainings to offer practice and feedback on the adapta-tion and use of a logical process design.

In conclusion, the given design approach represents and interesting an suitable ap-proach for designing collaboration processes that can make use of technological sup-port in a face-to-face environment. However, the thesis sees an unused benefit of this design approach for collaborative ideation processes that uses technological support in a virtual environment.