Transferring Collaboration Process Designs to Practitioners: Requirements from a Cognitive Load Perspective

Transferring Collaboration Process Designs to Practitioners: Requirements from a Cognitive Load Perspective

Gwendolyn L. Kolfschoten (Delft University of Technology, The Netherlands), Sandra van der Hulst (Delft University of Technology, The Netherlands), Mariëlle den Hengst-Bruggeling (Delft University of Technology and Politieacademie, The Netherlands) and Gert-Jan de Vreede (Delft University of Technology, The Netherlands and University of Nebraska at Omaha, USA)
Copyright: © 2012 |Pages: 20
DOI: 10.4018/jec.2012070103
OnDemand PDF Download:
$30.00
List Price: $37.50

Abstract

Collaboration Engineering (CE) is an approach to design and implement sustained collaboration support for collaborative work practices. A collaboration engineer designs a collaboration process and trains a practitioner to execute it on a recurring basis, without further support from professional facilitators. The CE design should be predictable and transferable for successful reuse by the practitioner. The documentation requirements for a CE design are addressed so it can be effectively transferred to practitioners. This documentation or script should contain precise instructions and interventions that the practitioner should make to guide the group in achieving their goals. To detail the requirements for this design document, the authors analyzed the tasks of a facilitator as a basis to derive the tasks of a practitioner. Cognitive Load Theory was used to derive documentation requirements with respect to the CE process design. The authors validated these requirements in an expert validation session and through two case studies.
Article Preview

Introduction

Facilitators support groups to help them achieve their goals. Facilitators traditionally offer process guidance and help groups in using appropriate tools and methods to accomplish their collaborative goals. Yet, due to resource constraints facilitation support might not be available to all groups who could benefit from such support. Furthermore, organizations tend to see collaboration as singular instances rather than something that should be supported over time and they lack mechanisms for transferring best practices in collaboration (Kristensen & Kijl, 2010). Research suggests that groups can benefit from having explicit routines for recurring tasks (Sari, Loeh, & Katzy, 2010). For recurring group processes, a solution to this challenge is proposed by the Collaboration Engineering (CE) approach (Briggs, Kolfschoten, de Vreede, & Dean, 2006; Briggs, de Vreede, & Nunamaker, 2003; de Vreede & Briggs, 2005; de Vreede, Briggs, & Kolfschoten, 2006; de Vreede, Briggs, & Massey, 2009).

In the CE approach an expert facilitator, called a collaboration engineer, designs a collaboration process and transfers this process to a practitioner in the organization. A practitioner is a domain expert in the organization who, as part of his duties, executes this process on a recurring basis. Compared to an all-round facilitator, who often designs and facilitates one-off processes, a practitioner is trained to support only one specific recurring collaboration process, based on a design made by a collaboration engineer (Kolfschoten, Niederman, de Vreede, & Briggs, 2008).

This approach thus offers reusable collaboration support for a recurring process that requires a relatively small investment in the training of the practitioner and limits the use of external expertise to the one-time creation and transition of a collaboration process design. When applied to a high value recurring process, such as project planning, requirements negotiation (Boehm, Gruenbacher, & Briggs, 2001), risk assessment (de Vreede & Briggs, 2005) or progress evaluations, the recurring benefits are argued to exceed the training investment (Briggs, et al., 2003; Kolfschoten, Niederman, de Vreede & Briggs, 2006; de Vreede & Briggs, 2005).

However, the CE approach also presents a challenge. The skill and expertise required to execute this single process needs to be transferred to practitioners in an efficient and effective manner. Yet, facilitation skills and knowledge cannot just be learned from a book (Ackermann, 1996; Clawson & Bostrom, 1996; Post, 1993; Yoong, 1995). Facilitation is typically learned through apprenticeships and experience. However, a practitioner does not need to master all facilitation skills and knowledge like professional facilitators. A practitioner only needs to have command of the skills and techniques required for the execution of one specific, repeatable process. Therefore, these skills and techniques should be captured such that they can be transferred to a practitioner. In other words, practitioners have to be provided with sufficient information to enable them to achieve results of sufficient quality through means of an effective, efficient, and satisfying collaboration process. We call the document in which this transition information is captured a CE process design document. The CE process design document should contain all information that needs to be transferred and addressed in the training of the practitioner.

The aim of this paper is to gain insight into the requirements of the CE process design document or ‘script’ to enable the transfer of a collaboration process and to support the practitioner in executing this particular process. The design document can be the basis for a short practitioner training, and is structured in such a way that practitioners can easily recognize similarities between designs, in case multiple designs are transferred. We followed an iterative exploratory approach to determine these requirements, drawing from the literature, facilitators’ reflections, and case studies.

Complete Article List

Search this Journal:
Reset
Open Access Articles: Forthcoming
Volume 13: 4 Issues (2017): 2 Released, 2 Forthcoming
Volume 12: 4 Issues (2016)
Volume 11: 4 Issues (2015)
Volume 10: 4 Issues (2014)
Volume 9: 4 Issues (2013)
Volume 8: 4 Issues (2012)
Volume 7: 4 Issues (2011)
Volume 6: 4 Issues (2010)
Volume 5: 4 Issues (2009)
Volume 4: 4 Issues (2008)
Volume 3: 4 Issues (2007)
Volume 2: 4 Issues (2006)
Volume 1: 4 Issues (2005)
View Complete Journal Contents Listing