Collaboration Life Cycle H. Tellioğlu Vienna University of Technology, Austria Multidisciplinary Design Group CTS 2008 The 2008 International Symposium on Collaborative Technologies and Systems May 19-23, 2008 Irvine, California, USA
Outline Introduction Challenges Collaboration Life Cycle Types of CLC: workflow-based and artefact-based CLC Use of CLC The Case The Scenario The Analysis Evaluation Deficits Improvements Future Work Conclusions
Introduction collaboration is a structured, recursive process where two or more people work together towards a common goal necessary: sharing knowledge, learning and building consensus, (no) leadership research so far investigating and analysing collaborative work arrangements: different organisational structures, process modelling, planning, management... managing work dependencies: by standardisation, direct supervision or mutual adjustment [Malone & Crowston, 1991] theories of coordination in parallel and distributed systems, in human systems, in complex systems in computer science: CSCW and coordination programming
Introduction Computer Supported Cooperative Work (CSCW) attempt to understand cooperative work arrangements with the objective of designing computer-based technologies for such arrangements [Schmidt & Bannon, 1992] as simply a loose agglomeration of cooperating and at times competing communities as a paradigm shift as technological support of cooperative work forms as Participative Design [Bannon, 1993]
Challenges how to setup a collaborative work environment by considering organisational, technical, economic and strategic circumstances of an enterprise a guideline to collaboration design to support collaboration initiators or project managers a collaboration framework to study a collaboration environment for further improvements How can we start a collaboration project? What can be decided before hand and what later during collaboration? What can be used to support the whole process? How can be an existing collaboration environment managed?
Collaboration Life Cycle an approach for systemising a collaboration process in a coordinated work environment
Collaboration Life Cycle roles members initiator experts moderator sponsor boundary spanner [Wenger, 1998]
Collaboration Life Cycle hilda.tellioglu@tuwien.ac.at
Collaboration Life Cycle hilda.tellioglu@tuwien.ac.at
Types of CLC different types of collaboration focus on management and control support participation and sharing top down decision making bottom up organisation... 1. workflow-based CLC 2. artefact-based CLC
Workflow-based CLC order of work activities over time common resources have to be aligned actors routine work has to be coordinated according to a predefined procedural trajectory [Lundberg & Tellioglu 2000] a process-oriented model of work containing a sequence of work steps different settings routed in different predefined trajectories depending on the circumstances no possibility to design work practices for themselves or others or whatever [Bowers et al. 1995] need for workflow systems
Workflow-based CLC formation tasks and subtasks must be defined dependencies between tasks are identified resource sharing dependencies are identified fit dependencies between tasks and subtasks are to be found all these dependencies result in a flow of tasks and subtasks which considers flow, resource sharing and fit interrelations among them operation the group works within the workflow by having someone responsible for the administration and monitoring of the flow of work project members use worklists
Artefact-based CLC the sequence of activities and how coordination is carried out can vary from time to time and from person to person in case of contingencies various artefacts need to be recoordinated often a need for coordination towards a goal, depending upon its contingencies [Lundberg & Tellioglu 2000] coordinative artefacts can be used to coordinate the work in an ad-hoc and improvised manner situated activities are articulated activities and behaviours are not predefined
Artefact-based CLC formation a network of coordinative artefacts [Schmidt & Wagner 2004] can be defined key coordinative artefacts are identified - by naming an artefact, defining a unique identifier for the artefact, identifying its key properties, its relationships with other artefacts and its functions clusters can be build by selecting related artefacts and naming the selection tasks supported by each cluster can be identified and assigned to specified clusters
Artefact-based CLC operation everyone works on individual and common (coordinative) artefacts project members access artefacts, modify them, hand them over to others artefacts change most of the time, get more complete, disappear or new artefacts are added to the current ones the network of artefacts must be monitored and administered by the group or by some of the group
Use of CLC 1. to set up a collaboration project between distributed groups 2. to study and analyse an existing collaboration project to identify problems, inefficiencies and attention points for improvement illustrate how, by focusing on operation phase how teams carry out their work cooperatively how the established IT infrastructure is used whether there are inefficiencies or organisational or technical areas for improvement...
Use of CLC: The Case collaborative design in a technology-based engineering project in MAPPER [IST/NMP Project, 016527, 2006] a small producer of virtual electronic components with two branches (VCP1 & VCP2) VCP1 engineers design electronic components digitally, which are then executed by VCP2 engineers to create digital prototypes the partner ICO accesses the results of VCP2 and implements analogue components based on the digital design delivered use of a common information space enabling definition and run of workflows
The Scenario L. in VCP1 working for the USB project performs a synthesis with support of the remote invocation tool after completion the invocation tool sends the results to the CVS repository, which is also accessible from VCP2, where the engineer can download the file and start FGPA prototyping L. has found a bug, which he needs to correct in the source file L. updates the actual source file locally, uploads the modification to the repository, updates the file in the invocation tool, and starts the synthesis after completion, L. switches to the internal chat forum to inform his colleague that the update has been completed
The Scenario two advantages of common information space the synthesis can be done on one machine (with one single license) if the engineer in VCP2 finds a small error, he can fix it on his computer and invoke the synthesis again remotely workflows are used to automatically update the code to run specified tests and simulations based on the digital design to save the results to commit the changed files onto the repository
The Analysis engineers managed to create a coordinated work environment they have a distribution of work, where all know who is responsible for what type of work the order of coding, running tests, synthesis or simulation, debugging is clear to the project members coordination is done implicitly by means of committed artefacts and explicitly by using chat applications they have an infrastructure consisting of a repository and several tools, which can be invoked remotely by using a specific application all participants can access the central IT infrastructure and access the common artefacts
The Analysis engineers managed to create a coordinated work environment the invocation tool enables VCP1 and VCP2 to work together on small errors in digital design without having to communicate explicitly some error-prone processes, like working with the latest version of an artefact, have been automated the explicit communication is limited to chats between engineers, which are not efficient the invocation tool could offer open communication channels no support for awareness between engineers results are preserved in the CVS repository scripts and test cases are reused
The Analysis relations and exchange between actors VCP1 and VCP2 engineers meet time to times and at least know each other well aware of competencies and availabilities of each other VCP engineers do not meet ICO engineers at all no video or computer conferences on a regular base the only informal exchange established is within the own group Sometimes it is better to chat with a colleague than getting up and going to his workplace to talk with him. in most cases ICO does not modify the digital code when errors occur trust and accountability
Evaluation: Deficits missing support for resource overview and capacity management peoples availability and capacity resolving conflicting demands between projects views for different stakeholders specific types of collaboration the use of collaboration environment capturing decision making accessing the central repository missing access to competences and skill profiles of team members
Evaluation: Improvements use of explicit representations of competencies and skills of personnel and access to the improved allocation mechanism of human and non-human resources by considering the conflicting demands between projects access to common information space and the used collaboration environment by enabling an appropriate view for different stakeholders support for work practices like for specific types of collaboration or for decision making consideration of participation of stakeholders in design and engineering as a key issue in collaboration processes in manufacturing
Evaluation: Future Work improve current CSCW, participatory engineering and modeling approaches not only support for unstructured communication, but also support for emerging knowledge structures, process and product design extensions to current concepts improve model-driven infrastructures based on CSCW concepts to support social, constructive learning methods and more contextualised collaboration decrease information overload
Evaluation: Future Work provide users with information, tools and communication channels that they need to perform their roles explore awareness, accountability and shared understanding further in CLC support for knowledge sharing shared knowledge needs to be understood by people involved by improving sense reading and sense giving through the use of appropriate knowledge representations through the care taking of their social dimensions like interpretation schemes, norms and power relations [Walsham 2004]
Conclusions presented a new conceptual and methodological framework to collaboration: the Collaboration Life Cycle CLC is based on CSCW concepts and participation principles by also considering different types of work environments 4 phases: initiation, formation, operation, decomposition workflow- and artefact-based CLC CLC describes how collaboration can occur and tries to help people to create and run a collaboration environment CLC systemises collaboration processes in coordinated work environments
Conclusions CLC as an instrument to analyse current practices in a collaborative work environment suggest a modified improved (IT) work environment including cooperation and coordination mechanisms CLC is a first step to address project management problems and to offer a systematic solution to these problems need to consider CLC in collaborative systems, by providing a configurable environment for users and offering interfaces for integration with other tools
Thanks for your attention! Hilda Tellioğlu Vienna University of Technology Institute of Design & Assessment of Technology Multimedia Design Group hilda.tellioglu@tuwien.ac.at http://media.tuwien.ac.at/h.tellioglu
Collaboration Life Cycle hilda.tellioglu@tuwien.ac.at