Embed Size (px)
Citation preview
Collaboration Life Cycle
H. TellioğluVienna University of Technology, Austria
Multidisciplinary Design Group
CTS 2008The 2008 International Symposium on Collaborative Technologies and Systems
May 19-23, 2008Irvine, 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]
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 re-
coordinated‣ “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 CLC1. to set up a collaboration project between distributed
groups2. 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ğluVienna University of Technology
Institute of Design & Assessment of TechnologyMultimedia Design Group
[email protected]://media.tuwien.ac.at/h.tellioglu
