1. INTRODUCTION - Multidisciplinary Design Group

2 downloads 5428 Views 266KB Size Report
normally belong to key personnel of the enterprise hosting the collaboration process. Experts are knowledge and com- petence carriers throughout the whole ...
Collaboration Life Cycle Hilda Tellio˘glu Multidisciplinary Design Group Institute of Design and Assessment of Technology Vienna University of Technology Vienna, AUSTRIA, 1040 [email protected] ABSTRACT This paper is about presenting a new conceptual and methodological framework to collaboration: the Collaboration Life Cycle (CLC). It is based on CSCW concepts, participation principles and predefined processes in certain work environments. It describes how collaboration can occur and tries to help people to create and run a collaborative environment. Through this, it systemises collaboration processes in coordinated work environments. Its four phases – initiation, formation, operation and decomposition – are interlinked to each other and contain several tasks and subtasks. To carry out these tasks specific roles are defined. Depending on the nature of the collaboration process there are workflow- and artefact-based CLC. On the one hand, CLC can be used to study and analyse an existing collaboration project to identify problems, inefficiencies and attention points for improvement. This paper shows an example of such an analysis. On the other hand, experiences and future plans resulted by the deployment of an earlier version of CLC are described before concluding the paper.

KEYWORDS: Frameworks and methodologies for collaboration; coordination and cooperation mechanisms; distributed team management and issues.

1. INTRODUCTION “Collaboration is a structured, recursive process where two or more people work together toward a common goal”1 . Sharing knowledge, learning and building consensus enable collaboration. Sometimes it is necessary to have leadership in a collaboration, sometimes it is better without any. Investigating and analysing collaborative work arrangements have been the focus of several disciplines. Organisation theories have tried to analyse different organisational structures 1 http://en.wikipedia.org/wiki/Collaboration

like budgeting processes, organisational power or resource dependencies by investigating the ways of process modeling, strategic planning, management by objectives, methods of grouping people into units etc. [6]. Furthermore there are suggestions how to manage work dependencies, e.g. by standardisation (predetermined rules of control), direct supervision (one actor manages interdependecies on a caseby-case basis) or mutual adjustment (each actor makes ongoing adjustments to manage interdependencies). Processes of complex systems need to be coordinated. Some studies provide theories to coordination in parallel and distributed computer systems, some others to coordination in human systems and a lot to coordination in complex systems that include both humans and computers. In computer science, the coordination theory is studied in two main research areas: in the field of Computer Supported Cooperative Work (CSCW) and in coordination programming. CSCW is an attempt to understand cooperative work arrangements “with the objective of designing computerbased technologies for such arrangements” [8]. CSCW can be seen from different perspectives: “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” [1]. Collaboration among people with a common goal is the subject of this paper. Although there are several concepts, theories and experience reports in the current related research literature, it is still not clear how to setup a collaborative work environment by considering organisational, technical, economic and strategic circumstances of an enterprise. A guideline to collaboration design is necessary to support collaboration initiators or project managers. On the other hand, if collaboration environments have been accomplished, a collaboration framework can help to study such an environment for further improvements. This paper tries to answer these questions: 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? First of all, the approach of Collaboration Life Cycle is defined to guide initiation, formation, operation and decomposition processes of a sustainable collaboration (Section 2). Section 3 differentiates between workflow- and artefact-based coordinated work environments. In section 4 we illustrate first how an existing collaborative work environment can be studied and analysed, especially how CLC can help in doing so. Second, we show some lessons learned by a first evaluation of this approach. We finally conclude the paper with a short summary and an outlook on future work (Section 5).

2. CLC – COLLABORATION LIFE CYCLE Collaboration Life Cycle (CLC) is an approach for systemising a collaboration process in a coordinated work environment. It consists of the initiation, formation, operation and decomposition of a collaboration process (Figure 1). A first version of CLC is created together with Till Sch¨ummer in the FP6 project MAPPER.2 The approach presented in this paper is a modified and revised version of the original methodology called “Formation and Operation of Sustainable Collaboration”.

Figure 1: Collaboration Life Cycle.

Tasks included in each phase are interlinked to each other. They can occur in parallel or even in different order, they can invoke each other if necessary, they can be skipped if not needed depending on the collaboration setting (Figure 2). In the Collaboration Life Cycle there are different roles taken by different people or sometimes by the same person: First of all, there are members of the group working together, discussing and exchanging their (intermediary) results with each other. The central founder and organiser of 2 Model-based Adaptive Product and Process Engineering: FP6-IST016527-MAPPER.

the group is the initiator. Then, there are experts which normally belong to key personnel of the enterprise hosting the collaboration process. Experts are knowledge and competence carriers throughout the whole work process. For coordination work – not only during meetings but also between the meetings – a moderator is needed who organises the group and belongs usually also to the key personnel of the company. A sponsor has to have hierarchy competences promoting the group creation. He or she interests in the results of the group. If there are several groups cooperating, a boundary spanner can organise exchange between different groups [13]. In the next four subsections, each phase of CLC will be described in detail. Table 1 shows an overview of its phases, tasks and subtasks.

2.1. Initiation In this phase the following processes take place: determine the need for collaboration and build a workgroup. Determine the Need for Collaboration. The initiator or multiple initiators determine whether it is necessary to collaborate to solve a concrete problem. There are some parameters that can be considered during this process: How complex is the work to be carried out? How long can it take? What competencies and skills are needed? Can the work be carried out by one person, or is there a need to build a group of people? Are there similar projects done before? Are there some experiences with respect to the need of collaboration? etc. It must be decided whether a collaboration is necessary to reach a common goal. This can be done in a meeting jointly with involved people or individually by a project manager or the initiator. Build a Workgroup. If the decision of the previous process is that a collaboration is needed to carry out the work, the initiator starts to build a workgroup. This happens in three steps: • Build an idea to create a workgroup. First, an idea needs to be created to start the grouping process. Without any idea there is no need for work and of course no need for cooperation. The idea must be specified and described briefly before starting to think about the workgroup. After describing the idea in simple terms that a non-expert can understand and describing the work that has led to this finding, its impact onto people or organisations must be considered. By questioning the idea from different perspectives, its relevance and importance can be evaluated before investing work and time on its realisation. For instance, if the idea is to

Figure 2: The Detailed View of the Collaboration Life Cycle.

design and produce a new product, it must be clarified what that product will replace. Why would this be bought rather than somebody else’s? What is the competitive advantage? Is there research carried out to what competing products exist? What is the size of the market, who will buy the product? And so forth. • Identify (potential) members. Second, the initiator identifies potential members of the group which can be experts or enterprises. Thereby, people with expertise are necessary to solve certain problems, also people to cover specific areas of problem occurrence, problem analysis and problem solving. The selection of suitable partners is based on their competences. To identify and find partners, awareness of the competences of potential and available partners as well as structured competence representations are essential. For this purpose the concept of ontology can be used. An ontology is a suitable mean to formalise individual and enterprise competences [7]. It is well suited for formalisation of competence models because it allows capturing of the rich semantics of competences. Each competence item can be represented with a concept, competence measurement or description with a property and competence subitems with relations to other concepts. Ontologies have also been successfully applied in modeling competences of enterprises and individuals. After developing domain, enterprise and individual ontologies in parallel candidates based on matching between in-

dividual/enterprise and domain/application ontologies can be identified. Ontologies can also be used to find possible collaboration partners by matching of the enterprise or individual ontology to the application ontology, in order to see what parts of the collaboration task or process a specific enterprise or individual can provide, according to its ontology. By looking at the matches, suitable partners (enterprises or individuals), i.e. those that have the best match for what is needed to be done, can be selected. • Invite members. Finally, appropriate people – not only members, project managers but also non-members or experts – are invited by the initiator. This can be done formally or informally. The result is a final list of project members.

2.2. Formation After the invitation to the group this phase begins. Here – in close interplay – the processes of group formation take place: the determination or negotiation of common goals (substantiate the idea), the forming or emergence of roles and structures, the opening and creation of a shared physical or virtual space. The group formulates the problem and the common goal cooperatively. Define the Common Goal of the Collaboration. Defining the common goal is crucial and needs to be done by

Collaboration Life Cycle Initiation

Formation

Tasks

Table 1: An Overview of the Phases, Tasks and Subtasks of CLC. Subtasks

Determine the need for collaboration Build a workgroup

Build an idea to create a workgroup Identify (potential) members Invite members Determine common goals Negotiate common goals Refine common goals Determine roles for the current project Negotiate roles Assign roles to members Inquire the collaboration context Define the collaboration environment Assign persons to tasks Negotiate task assignments Assign deadlines to tasks Specify the IT infrastructure Setup the specified IT infrastructure

Define the common goal of the collaboration

Define roles for collaborating members

Setup a coordinated work environment

Operation

Work within the coordinated work environment Preserve results Manage change processes Decomposition Publish results Hold contact Decompose the coordinated work environment Decompose the workgroup

determining, negotiating and refining the goal and the subgoals within the group. • Determine common goals. First of all, a list of possible common goals needs to be created in the group. This can be done by a brainstorming or a moderated discussion session. For some of the group members it is not always obvious that there are differences in interests of individuals and of the group as such. These differences can be articulated from the beginning of a collaborative work project if the group takes the time for identifying and communicating the individual and common goals in the group. • Negotiate common goals. In a participative work approach, there must be space for negotiation and revision. Before deciding which concrete goals are set for the collaborative work, they need to be negotiated with project members and experts who are more or less related to their achievement. If there are new goals defined during the negotiations then these must be included to the current list of goals. If there are modifications needed to the defined goals than necessary

revisions must be made. All modified or newly added goals need to be negotiated in the group again until there is no doubt about their relevance and importance for the project-in-plan. • Refine common goals. Based on negotiations with project members and experts common goals must be refined if necessary, whereas the refined goals are again discussed in the workgroup. Define Roles for Collaborating Members. After revising the common goals, roles can be defined and assigned to members within the workgroup. • Determine roles for the current project. First, it must be clear which roles are necessary in the current project. Whether a role can be taken by one person or many, or a person can have more than one role in the project must be investigated. Then, a list of possible roles must be created. • Negotiate roles. The list of the possible roles needs to be negotiated within the workgroup. Everyone in the

group must understand why certain roles are needed in the project, and how the assignment of certain roles are planned. The negotiation can result in new roles, which must be added to the current list of roles. If there are modifications needed to the defined roles than these can be revised and prepared for a new iteration of negotiations. • Assign roles to members. Finally, roles can be assigned to project members. The decision can be made either by one person or a small group of persons, who are knowledgeable about the competencies and interests of project members. Another way of deciding who is going to take which role in the project is to make it participatory within the whole project group. This is a more bottom-up approach, supports the interests of all involved, but can take longer than the centralised way of decision making. Setup a Coordinated Work Environment. For collaboration a coordinated work environment is needed. This is an assemblage of several organisation units with specific goals and structure, populated by actors (as project members), work practices and artefacts [10] [11]. Actors’ work practices are both local within their own organisation unit and linked to others’ practices by means of interactions. To setup a coordinated work environment the collaboration context and environment must be defined. This follows assignment of persons and deadlines to tasks. Finally, a useful infrastructure can be chosen and setup to support the collaboration within the (distributed) group. • Inquire the collaboration context. This is about finding out how collaborating actors perform their work, what task dependencies, relations between activities, temporal and logical orders in carrying out work activities are. The work environment which is the collaboration context must be described in terms of: Work practices carried out individually and collaborative by considering the temporal and logical interdependencies, coordination work carried out explicitly or implicitly, artefacts created, modified and exchanged between project members, constraints defined between work activities and in use of (common) artefacts. • Define the collaboration environment. Depending on the type of the organisational structure and management strategy of the enterprise a collaboration environment must be defined. This environment is used to populate the collaboration setting with objects like tasks or artefacts. The type of work – whether it is defined in a straight forward manner and has to fulfill certain constraints, or whether it is innovative, selforganising, participative and actor-driven – determines

what type of environment is needed to support the collaboration (see Section 3 for the operation phase in such environments). • Assign persons to tasks. By considering competencies and skills of persons involved in the project, persons must be assigned to tasks. Not only the immediate productivity of the people should influence the decision of who is going to do what, but also the interest and wishes of the people in the middle or long term. The latter is necessary for their motivation and identification with the project. • Negotiate task assignments. Task assignments must be communicated with people assigned in order to get their agreement or to discuss their concerns or other wishes before starting with the project work. The negotiation with people can result in modifications of assignments. • Assign deadlines to tasks. Not only the people but also temporal constraints must be assigned to tasks and subtasks. The result of this step is normally a project plan with a time line and assigned persons. This plan can be used during the whole project by keeping it up-to-date. • Specify the IT infrastructure. Having the collaboration defined, people and deadlines assigned to tasks, the next step is to decide for an IT infrastructure and to create its specification. Here, centralisation is a core issue. Depending on the degree of centralisation of the IT infrastructure, there are at least three alternatives: – A central IT infrastructure – All data is saved and managed on a central server to which all members have access. This is also called common information space [2]. – A distributed IT infrastructure – Data is saved where it is created and used mostly. All others can access the distributed data by means of replication mechanisms. – A hybrid IT infrastructure – Data is saved distributed, but copied also regularly on a central server. The distributed data is a working copy of the original data that is on the central server. • Setup the specified IT infrastructure. Depending on the decision taken in the previous step, a central, decentral or hybrid IT infrastructure must be set up. There are several commercial products on the market to use for this purpose. It is crucial that the system chosen as the infrastructure does really support the way of working of the people and not cause additional effort which is not really beneficial for its users.

2.3. Operation After the formation of the group the operation phase starts with its interdependent processes: In this phase the real collaboration and interaction take place. This includes communication, cooperation and coordination activities. The aim is to fulfill the goals as well as the preservation of the results, as basis for continuing collaboration and as product of the collaboration process. This can be repeated several times. During this process goals, roles, structures etc. can be adjusted or re-negotiated as needed. Work within the Coordinated Work Environment. Actors collaborate in the group and interact with each other. This involves exchanging artefacts and information with others via mailing, face to face meetings, telefon calls or conferences etc. Between the points of cooperation project members work on their individual tasks or cooperate with some of the other project members to achieve an intermediary result. Not only the formal communication and coordination are very important in this phase, but also informal exchange, awareness of others’ work in progress, trust issues between people, willingness and readiness to share knowledge and experiences and so forth are crucial issues for a successful cooperation in a distributed workgroup. Preserve Results. The outcome of the individual and collaborative work must be preserved, on the one hand, to have a project result and, on the other hand, to facilitate the basis for a continuing collaboration. Manage Change Processes. During the whole operation phase, change processes must be managed to adjust or renegotiate goals, roles, temporal or organisational structures etc. before it is too late. Change management is one of the most important but underestimated issues in collaborative work environments.

2.4. Decomposition Are the goals of the collaboration reached or as the case may be that the members have lost interest in the collaboration, the collaboration will tend to be lost and the decomposition phase begins. It consists of several steps: publishing and reuse of results, holding contact, decomposition of the collaboration environment. Publish Results. Results of the groupwork are published, i.e. they have been made available to non-members (to whom it may concern, e.g. the customer, the public etc.), after reaching a certain level of maturity. Results may also be reused by members or non-members. Reuse of results can help to fulfill other goals or tasks within the same project or

in other projects in the enterprise. Reusability of products is an issue for itself and is not explored in this paper. Hold Contact. For sustainability of collaboration, the network of people created during the project must be preserved. Keeping contact to people involved or related to the project up-to-date makes invoking a new network for further projects easier. Decompose the Coordinated Work Environment. At this stage of a project, the collaboration context consisting of tasks and artefacts, roles, persons, deadlines, tasks and assignments are not relevant anymore. This context and the related IT infrastructure can be decomposed. Decompose the Workgroup. Decomposing the workgroup does not mean to loose the information about project members, their skills and interests. As mentioned before, contact to people related to the project must be kept for further activation. This is the official end of a project that project members are notified.

3. TYPES OF CLC As described in the last section, CLC contains four phases that contain several tasks which are carried out in sequence or parallel and interrelated to each other. What was not mentioned so far is that there are different types of collaboration projects: Some do focus on management and control, some do not. Some support participation and sharing, others do not. In some decisions are made top down, in others project members are involved in decision making and the management of the project is organised rather bottom up. So, two types of collaboration projects can be distinguished: workflow-based CLC and artefact-based CLC. Workflow-based CLC. In some work settings, there is an 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” [5, p.162]. This creates a process-oriented model of work containing a sequence of work steps. Different settings may be routed in different predefined trajectories depending on the circumstances, which have been described in advance. This does not allow project members to “design work practices for themselves or others or whatever” [3, p.51]. This type of task-driven work environments needs workflow systems. What happens in this type of projects in the formation phase? First of all, tasks and subtasks must be defined. Identifying dependencies between tasks facilitates the change of the order of tasks and subtasks in the flow. After

that, resource sharing dependencies are identified, i.e. resources to be shared by more than one task or subtask are identified by marking them. Finally, 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. The result can be represented e.g. by means of a model showing the temporal and logical order of tasks and subtasks. In the operation phase, the group works within the workflow by having someone responsible for the administration and monitoring of the flow of work. Project members use worklists, i.e. they access their worklists and carry out their tasks within the given time slot. Artefact-based CLC. In other work settings, “the sequence of activities and how coordination is carried out can vary from time to time and from person to person. When contingencies occur in the way work activities are carried out, the various artefacts need to be re-coordinated. There is often a need for coordination towards a goal, depending upon its contingencies” [5, p.162]. Several artefacts, especially coordinative ones, can be used to coordinate the work in an ad-hoc and improvised manner. This type of work contains “the unfolding usage of artefacts exposed to unanticipated changes articulating the situated activities. It accommodates a wide variety of activities and behaviours that are not predefined, but must instead be viewed as a unique and unfolding in each case” [5, p.162]. If the work environment is an artefact-driven one as described here, a network of coordinative artefacts can be defined in the formation phase [9]. After identifying the key coordinative artefacts (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. Finally, tasks supported by each cluster can be identified and assigned to specified clusters. In the operation phase, everyone works on individual and common (coordinative) artefacts. Artefacts build up the core of the whole process. 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.

4. LESSONS LEARNED CLC can be used twofold: to set up a collaboration project between distributed groups or to study and analyse an existing collaboration project to identify problems, inefficiencies and attention points for improvement. In this section,

we will illustrate how an existing collaborative work environment can be analysed, especially how the framework of CLC can help in doing so. Our analysis will focus on the operation phase of CLC. We want to know, among others, 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. Before finishing this section, we also want to summarise some intermediary results of the introduction of an earlier version of this approach in a manufacturing company in MAPPER.

4.1. Analysis of Existing Collaboration Environments by Using the CLC Framework The case is about collaborative design in a technology-based engineering project in MAPPER. A small producer of virtual electronic components has two branches (VCP1 and VCP2) located in different cities. VCP1 engineers design electronic components digitally, which are then executed by VCP2 engineers to create digital prototypes. The partner ICO located in another country accesses the results of VCP2 and implements analogue components based on the digital design delivered. All participants use a common information space, where they store all artefacts like scripts, design code, synthesis and simulation results, change history of some artefacts (by means of the configuration management tool CVS). All can access the common artefacts remotely and invoke synthesis or simulation processes by using a specific tool, which is accessible centrally and enables the definition of workflows. These workflows are used to automatically update the code, run specified tests and simulations based on the digital design, save the results and commit the changed files onto the repository. The collaboration scenario. L., an engineer in VCP1 working for the USB project performs a synthesis with support of the remote invocation tool. After the synthesis has been completed, 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. One of the advantages is that the synthesis can be done on one machine (with one single license); the other benefit is that if the engineer in VCP2 finds a small error, he can fix it on his computer and invoke the synthesis again remotely. L. has found a bug, which he needs to correct in the source file. He updates the actual source file locally, uploads the modification to the repository, updates the file in the invocation tool, and starts the synthesis. There are log files from the synthesis (where engineers can look for warnings), the result (a binary file in MCS format, which is used for FPGA prototyping, with the software only

being available in VCP2), and the scripts, which are invoked by the invocation tool. The scripts are shared with ICO in the form of a Netlist. When the synthesis has been completed, L. switches to the internal chat forum Gadu-Gadu to inform his colleague that the update has been completed. L. comments: “This is a good thing that everything is automated. There is no possibility to run the wrong script, you are sure that the actual sources are used, you don’t have to think about which file to update, it is simplified now, the invocation tool does the CVS update”. L. has prepared scripts for simulation. This is a series of test cases for testing the VHDL code. Each test case contains simulator files to be used in the VCP verification environment, with each test case verifying a feature of the VCP model. ICO does analogue design and the idea is to provide them with the opportunity to run their own simulation in the case of small errors. ICO checks some behavioural case on their analogue simulator and if they find a problem in the digital part, they can find the test corresponding to this situation and run the test themselves. This scenario is not different from the previous one, except that it involves an external partner, who can use the VCP tools without knowing them. They can influence the digital simulation by changing text files (hence they don’t need a software license). The wave representation of the simulation allows ICO to manually compare the wave forms and in case it is helpful for them to move some signals in time because they have found a problem in their simulation, they can change the stimuli files and regenerate the test case. We can analyse now several issues in this scenario with respect to collaboration based on CLC: The engineers in this case 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, no matter in which group they work. Coordination is done implicitly by means of committed artefacts and, if necessary, 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 – no matter where they are located – can access the central IT infrastructure and access the common artefacts. The invocation tool enables VCP1 and VCP2 to work together on small errors in digital design without having to communicate explicitly. In addition, some error-prone processes, like working with the latest version of an artefact, have been automated. Unfortunately the explicit communication is limited to chats between engineers, which are not efficient e.g. when a piece of code needs to be reviewed, or

complex contents need to be discussed. The invocation tool could offer open communication channels by enabling an integrated communication by means of annotations to the common artefacts or notifications e.g. to inform engineers about the status of tests and simulations. The IT infrastructure used in this case does not enable awareness between engineers. On the one hand, they do not know whether or when a process will finish. On the other hand, they are also not aware of the presence of other engineers especially when they are located somewhere else. The external chat tool is a way to see whether the colleague is online. The results are preserved in the CVS repository. Scripts and test cases are used in more than one project, if necessary with slight adaptations. VCP1 and VCP2 engineers meet time to times and at least know each other well. They are aware of competencies and availabilities of each other. VCP engineers do not meet ICO engineers at all. They have only electronic communication and exchange. Engineers chat if they want to talk to each other, or they skype if it is too complicated to communicate by texting. They do not have video or computer conferences on a regular base. The only informal exchange they have established is within the own group, because the group members are present and sit together in same rooms. This does not mean that they do not use chats within their own team. “Sometimes it is better to chat with a colleague than getting up and going to his workplace to talk with him.” Even if it is possible, in most cases ICO does not modify the digital code when errors occur. They rather notify the VCP1 and ask them to fix the particular bug. This is a trust issue. VCP does not think that ICO is competent enough to make changes to the digital part of the design. Being designers for analogue components ICO is not confident enough to act as digital designers. It is also an issue of accountability: If things get worse or the damage to customer is big, who can be made responsible for that? These are just some examples showing how to use the framework of CLC for the analysis of current work. The concepts included in CLC, structures including tasks, workflows, roles, resources etc. help us to understand the status quo of the collaboration practices in a cooperation work environment.

4.2. Evaluation of CLC in a Manufacturing Company An earlier version of the CLC approach was one of the four submethodologies in MAPPER and it was represented in an

active-knowledge-based model. Users tried to use the models in their real work environments to support their work practices. Several deficits of this approach were identified [4, p.78]: Missing access to competences and skill profiles of team members; missing support for resource overview and capacity management, for peoples’ availability and capacity, for resolving conflicting demands between projects, for views for different stakeholders, for specific types of collaboration, for the use of collaboration environment, for capturing decision making, for accessing the central repository. Based on this list of known deficits, following areas of improvement are identified: • The 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 These deficits are also based on deficits of current CSCW, participatory engineering and modeling approaches: Though existing CSCW and CSCL (Computer Supported Collaborative Learning) approaches support unstructured communication, they do not adequately capture, support or utilise emerging knowledge structures, process and product design that are being updated throughout manufacturing life cycles. Applying the basic CSCW concepts showed that we need extensions to current concepts. Especially we saw that model-driven infrastructures can benefit from CSCW concepts to support social, constructive learning methods and more contextualised collaboration. This would enable utilising modelled process and product contexts to decrease information overload and would provide users with the information, tools and communication channels that they need to perform their roles in their current work practices. Participation of stakeholders in design and engineering must be considered as a key issue in collaboration processes in manufacturing. Awareness, accountability and shared understanding are e.g. some of the important CSCW concepts that need to be further explored in CLC. Knowledge sharing is crucial for sustainable participation in engineering processes and can be established only if knowledge processing is cooperative. Shared knowledge needs to be understood by people involved, by improving sense reading and sense giving, on the one hand through the use of appropriate knowledge representations, and on the other hand through

the care taking of their social dimensions like interpretation schemes, norms and power relations [12].

5. CONCLUSIONS This paper is about presenting a new conceptual and methodological framework to collaboration: the Collaboration Life Cycle. It is based on CSCW concepts and participation principles by also considering different types of work environments like strictly predefined processes versus open environments where users improvise and decide about the flow of work and cooperation. Depending on these differences, there are workflow- and artefact-based CLC. The CLC describes how collaboration can occur and tries to help people like project managers, project initiators, collaboration designers, facilitators or consultants to create and run a collaboration environment. It systemises collaboration processes in coordinated work environments. Its four phases – initiation, formation, operation and decomposition – are interlinked to each other and contain several tasks and subtasks. To carry out these tasks several roles are defined. CLC can be used as an instrument to analyse current practices in a collaborative work environment and then to suggest a modified improved (IT) work environment including cooperation and coordination mechanisms. In section 4, on the one hand, we illustrated an analysis case. On the other hand, we presented some experiences of the deployment of an earlier version of CLC and some plans for its further development. Several project management tools are available to build a team, by assigning persons to tasks, planning the work flow in the project, defining milestones and intermediary results, calculating the cost of human and non-human resources etc. The main goal of these tools is to support the project manager in planning, monitoring and documenting a project. How the collaboration between members is facilitated, supported and monitored, what changes are done to (common) artefacts, who or which subgroups has the token for modifying the (common) artefacts, who must be notified of these modifications later on etc. are issues related to collaboration in a team. Unfortunately project management tools and methods do not deal with these issues. The CLC is a first step to address these problems and to offer a systematic solution to these problems. It is partly supported by tools like a modelling tool for initiation, or by configuration management tools for operation phase. It also make use of communication tools like email applications, chat rooms, electronic blackboards, wiki sites or blogs. The question is still whether it makes sense to develop a (standard, unified) collaboration system based on the CLC integrating different tools. Systems like LotusNotes, BSCW, Groupware etc. try to offer a collaboration environment for projects, but

they only provide the platform to manage artefacts, data exchange, todo lists etc. They do not guide people setting up a collaboration environment, they do not integrate project management activities with production and communication tasks carried out. That means that there is a need to consider CLC in collaborative systems, by providing a configurable environment for users and offering interfaces for integration with other tools. One of the open questions from the CSCW research point of view is how to adapt this approach to current work situations by considering the type of the collaboration project and the skills and interests of available people. Whether patterns can be applied to identify structures or issues in collaboration processes, based on the collaboration patterns which are already available, is an interesting research perspective that we will further investigate. Additionally, CLC will be extended and refined to address details of group work, e.g. to enable participation of stakeholders where appropriate, by sharing artefacts or information systems, but at the same time by considering organisational structures users defined.

REFERENCES [1] Bannon, L., “CSCW: An Initial Exploration”, Scandinavian Journal of Information Systems, Vol. 5, 1993, pp. 3-24. [2] Bannon, L., “Constructing Common Information Spaces”, Proceedings of the Fifth European Conference on Computer Supported Cooperative Work, September 7-11, 1997, pp. 8196. [3] Bowers, J., G. Button, and W. Sharrock, “Workflow From Within and Without: Technology and Cooperative Work on the Print Industry Shopfloor”, Proceedings of the Fourth European Conference on Computer-Supported Cooperative Work ECSCW’95, 1995, pp. 51-66. [4] Carstensen, A., J. Haake, S.G. Johnsen, O. Ohren, P. Penkala, J. Stirna, H. Tellio˘glu, and M. Wessner, DELIVERABLE D7: REQUIREMENTS TO METHODOLOGY DEVELOPMENT, MAPPER, Model-based Adaptive Product and Process Engineering, IST/NMP Project, 016527, 2006. [5] Lundberg, N., and H. Tellio˘glu, “Understanding Complex Coordination Processes in Health Care”, Scandinavian Journal of Information Systems, Vol. 11, No. 2, 2000, pp. 157-181. [6] Malone, T.W., and K.G. Crowston, TOWARD AN INTERDISCIPLINARY THEORY OF COORDINATION, Massachusetts Institute of Technology, Center for Coordination Science, Cambridge, Massachusetts, USA, 1991. [7] Sandkuhl, K., A. Smirnov, and B. Henoch, “Towards Knowledge Logistics in Agile SME Networks – Technological and Organisational Concepts”, in: Dolgui A., J. Soldek, and O.

Zaikin (eds.): SUPPLY CHAIN OPTIMISATION: PRODUCT/PROCESS DESIGN, FACILITY LOCATION AND FLOW CONTROL, Kluwer Academic Publishers, 2004. [8] Schmidt, K., and L. Bannon, “Taking CSCW Seriously. Supporting Articulation Work”, Computer Supported Cooperative Work (CSCW), Vol. 1, 1992, pp. 7-40. [9] Schmidt, K., and I. Wagner, “Ordering Systems. Coordinative practices and artifacts in architectural design and planning”, International Journal of Computer Supported Cooperative Work, 2004. [10] Tellio˘glu, H., “Modeling Coordinated Work: Definition and Application of the Model ’Coordinated Work Environment’”, The Journal of Supercomputing. An International Journal of High-Performance Computer Design, Analysis, and Use, Vol. 24, 2002, pp. 161-171. [11] Tellio˘glu, H., “CoMex – A Mechanism for Coordination of Task Execution in Group Work”, Proceedings of the 1st International Workshop on Computer Supported Activity Coordination, CSAC 2004, in conjunction with ICEIS 2004 (The 6th International Conference on Enterprise Information Systems), Porto, Portugal, 2004, pp. 13-20. [12] Walsham, “Knowledge Management Systems: Action and Representation”, Action in Language, Organisations and Information Systems (ALOIS), Sweden, 2004. [13] Wenger, E., COMMUNITIES OF PRACTICE – LEARNING, MEANING AND IDENTITY, Cambridge University Press, Cambridge, 1998.