Lessons Learnt in the Use of a Collaborative Design ...

Proceedings of the 33rd Hawaii International Conference on System Sciences - 2000

Lessons Learnt in the Use of a Collaborative Design Environment Jari A. Lehto, Pentti Marttiin Nokia Research Center P.O.Box 407, FIN-00045 NOKIA GROUP E-mail: {jari.a.lehto / pentti.marttiin}@nokia.com

Abstract This paper discusses collaboration problems in large organizations where systems development takes place in distributed projects. We describe an in-house collaborative design environment, which has been used in several units in the NOKIA corporation. This environment called Timbuktu is evaluated based on our understanding after several years’ consultation and interviews of knowledge sharing in distributed projects. We use two theories to introduce and analyze the subject: collaboration support as a social action theory, and theory of knowledge creation. Both of these theories are discussed in the context of collaborative design environments. The lessons learnt are aimed to guide developing collaboration environments for the next years.

1. Introduction Many high-tech organizations are faced with the phenomena of globalization. NOKIA is one such fast growing corporation, which has recently established several new sites all over the world. Both Nokia Mobile Phones and Nokia Networks have sites in several countries. Manifold reasons for globalization have been introduced. These include interest in deploying talented people, expansion through acquisitions, reduction in development costs, global presence, staying close to customers, and reduction in time-to-market [3]. These driving forces are common for international high-tech organizations, and, thus we can recognize them in NOKIA globalization. Globalization leads to a situation where software engineering takes place in distributed projects. One of the main questions is how to produce high-quality products for customers with people of various cultures, backgrounds and expertise. Although globalization supports internal variety of ideas due to cultural and educational differences and ability to focus broad experience based on viewpoints [3] dispersion problems will be present in various levels of organizational work. Next we discuss dispersion effects on project management, collaboration, information management, and processes.

First, at the project level, the problem of getting resources and experience for specific tasks leads to distributed projects. How to break such projects into effective teams and how to share information and experience inside and between groups, projects, and sites is the main question here. The fact is that it is easier to manage local groups than dispersed ones. The other drawbacks of dispersion pointed out by Carmel [3] include ‘loss’ of team spirit, difficulties in building trust and commitment, and the team size getting larger and ‘out of hand’. Local teams are regarded as more cohesive and productive than distributed ones [1]. 1 Second, collaboration and communication exist in all human actions except for the simplest tasks [16]. Empirical studies in large-scale software engineering projects [4] have shown that communication bottlenecks and breakdowns are very common. When developing complex systems, engineers frequently need to collaborate not only with their immediate peers, but also with those located in other sites and across country boundaries. When project size, complexity and dispersion increase, difficulties in collaboration become more apparent and global system development harder to manage. Globalization affects the costs and possibilities for organizing face-to-face meetings and maintaining such contacts. Collaboration technologies – based on telecommunications and information technologies – have made it possible for geographically dispersed co-workers to work together, as if they were located close to each other. This is called location transparency. Although several technologies are in use in NOKIA, face-to-face meetings are still considered the most important way to collaborate. Important questions to be answered here include how collaboration technologies can substitute social relationships, achieving trust and commitment to the common goals in distributed or even virtual teams [8] and how can experts or local groups share their tacit knowledge with projects and sites concerned with the same problems [10]. 1

Collaboration in a broad sense means working together to achieve a shared goal. It can be seen as a social communication process, the purpose of which is information (or knowledge and experiences) sharing and integration, and co-working [11].

0-7695-0493-0/00 $10.00 (c) 2000 IEEE

1

Proceedings of the 33rd Hawaii International Conference on System Sciences - 2000

Third, information management problems will arise when information is accumulating locally, and there exist global needs to find and access that information. Engineers are faced with difficulties in finding the right information from broadcasting applications such as Intranet and Lotus Notes. In order to find or get critical design information, one needs to contact experts or other people from the area. In many cases, personal networks are valuable to get things running. How to find contacts and how to build networks are among the first problems newcomers are facing in large distributed organizations such as NOKIA. Communication in local teams is informal, and thus, all processed information is not available in explicit form. In distributed projects, the role of documentation is more important than in local ones. However, documents require efforts for creating (author) and recreating (reader) context for understanding explicit information [2, 7]. Fourth, at the process level, one difficulty is how to introduce company level process models, methods, and rules into sites that are based on different working cultures and practices. In this paper we present an anarchistic way of working, which tries to avoid the problem of unsuitability for local situations. We have given flexible means for users to collaborate and to manage information. This paper presents the Timbuktu platform, which is a groupware with visual information management and design capabilities. In other words, it is a ‘writable web’ application supporting both asynchronous and synchronous ways of collaborating through design material. The usage of such environment is related to the ability to build applications easily and to modify them locally and individually, i.e., to provide support for an anarchistic way of working. We believe our environment is based on principles, which can provide a partial answer to the problems discussed above. This paper is organized as follows. Section 2 describes collaboration using two theories: social action theory applied for collaboration support and theory of knowledge creation. These theories are used to point out some important issues that groupware should tackle when used in distributed projects. Section 3 describes a collaborative design environment [12], which has been used in several units in the NOKIA corporation. In Section 4 we discuss our experiences and in Section 5 state the requirements for a future collaborative design environment, which should be adaptable to a variety of needs in vague and dynamic situations. In Section 6 we summarize our findings.

2. Collaboration support for software engineering projects This section presents two theories to focus our approach and to crystallize our claims for the support needed in distributed projects.

2.1. Collaboration as a social action When anchoring collaboration to take place in projects and groups we can use groupwork as a synonym for collaboration. Lyytinen and Ngwenyama [9] define groupwork from the social action perspective using the concept ‘action’: groupwork is defined to be a network of various, co-ordinated social actions, performed by the participants to achieve a joint outcome. Groupwork is shaped by
the organizational context, norms and values that regulate the interactions, role responsibilities and expectations of the participants
need to negotiate participants' position in the group, role responsibilities, group norms and interaction protocols
institutions for sanctioning and legitimizing group behavior, and
the organizational motivation, reward, and incentive schemes [9]. Collaboration presupposes a common medium of communication, culture, shared values, norms, and social relations, and a shared understanding of the organizational context. From this basis Lyytinen and Ngwenyama [9] present a framework that categorizes social actions from instrumental, communicative, discursive and strategic points of view. These are regarded as ideal actions, which are used to point out the orientation of groupware platforms. Instrumental groupware focuses on the control, manipulation and transformation of physical artifacts, and it supports synchronous work and provides shared working areas. Examples of instrumental groupware platforms include collaborative CASE environments, Concurrent Engineering Systems, Group Editors, and Co-authoring systems. Communicative groupware assumes communicative actions as the focal point of collaboration. Here we are not working directly with artifacts, but distributing them (e.g., as a form of an e-mail attachment). Elementary communicative means include phone calls, conference calls, videoconferencing, e-mail, voice mail, chat, letter fax, news, and bulletin boards. Discursive groupware provides a means and arena for open and critical problem solving, exploration, and decision-making. Such groupware include GDSS (Group Decision Support Systems), MSS (Meeting support systems), and IBIS (Issue Based Information Systems). Strategic groupware supports negotiation and bargaining processes, which are characterized by goal conflict, deception, unequal distribution of information and power. NSS (Negotiation Support Systems) represents a strategic groupware. Our view to such an action categorization is that all kinds of actions are taken place in groupwork, but what

0-7695-0493-0/00 $10.00 (c) 2000 IEEE

2

Proceedings of the 33rd Hawaii International Conference on System Sciences - 2000

actions are purposeful to support with computers is an interesting question. Mandviwalla and Olfman [10] have presented generic groupware requirements: groupware should support multiple group tasks, work methods (e.g., voting for choosing tasks), and the development of the group (e.g., roles and responsibilities). Furthermore, groupware should provide interchangeable interaction methods, sustain multiple behavioral characteristics, accommodate permeable group boundaries, and be adjustable to the group’s context [10]. Building a groupware for supporting discursive and strategic actions is a very difficult or even an unrealistic task. We have focused on the use of instrumental groupware facilitated by communicative means. dependent of a collaborative session. The discursive and strategic actions (decision making, idea generation, and problem solving as examples) are not supported; rather they are left to be done by the individuals themselves. Our claim is that projects are not ready and capable of creating rules for these manifold and changing processes in a design context. Human actions just happen, and the means provided by such groupware are too rationalistic or specified too narrowly to a certain way of collaborating. Examples described in Section 3.4 shows that we are able to negotiate, but only using flexible instrumental and communicative means for discursive and strategic purposes.

2.2. Theory of knowledge creation In systems development we are interested in target systems, their specifications, the process of building these systems, and creating all specifications related to the system. Before a specification is ready for review and acceptance, the required information has to be gathered and transformed into knowledge. The responsibility of creating the required knowledge is in individual developers. Written information does not always help much, and we need to meet, brainstorm, argue, discuss, explain etc. about systems and their behavior. All kinds of social actions discussed in Section 2.1. are present in this process. Thus, we need another theory to illustrate the 2 process of knowledge creation . Nonaka and Takeuchi [12, 13] build their well-known theory of knowledge creation on the need for both tacit and explicit knowledge. Knowledge is created through conversation between tacit and explicit knowledge. This assumption allows the postulation of four different modes of knowledge conversion. They are
from tacit knowledge to tacit knowledge (socialization),

2 By knowledge we mean a justified true belief. Information is a necessary medium for eliciting and constructing knowledge.




from explicit knowledge to explicit knowledge (combination),
from tacit knowledge to explicit knowledge (externalization), and
from explicit knowledge to tacit knowledge (internalization). Nonaka and Takeuchi [12, 13] present a knowledge creation process, where each of the four modes takes place in a circular way. In this process, individual knowledge will be shared with group, project, organizational, and inter-organizational knowledge. Instrumental groupware provides means for externalizing and combining explicit information. We have already pointed out the difficulties in the use of documents taken out of their context. We claim that by a common information space including linking capabilities we can better facilitate the combination process. Another issue is the role of tacit knowledge when using an instrumental groupware. Instrumental groupware itself does not much facilitate the utilization of tacit knowledge. Examples of such means to facilitate the utilization of tacit knowledge are pointing out objects, and storing memorable objects from sessions (e.g., flipboard pictures). This means that we should concentrate on situations to use the tool with the help of various communicative means. Therefore, groupware use should not be restricted to specific situations, and it should not be dependent on time or place. To be able to utilize tacit knowledge we may require working in synchronous sessions, but – according to the anarchistic approach – it is not necessary if contextual information is available. The contextual information can only partially include tacit knowledge, and, thus it is only a partial solution.

3. A collaborative design tool: Timbuktu We have built a tool platform Timbuktu (former name TDE [14, 15]) that supports basic synchronous collaborative actions and where collaborative services can be offered. The metaphor of the platform is an electronic shared desk. It offers connection and communication means for starting and maintaining collaborative work. The desk visualizes, through icons and bars on the screen, all artifacts and co-workers on-line. The desk reflects immediately changes made by any member of the collaborative team and all other users that can see the screen. The deficiencies in current software engineering environments and tools have led us to adopt certain key principles in the development of the Timbuktu system. The most important principles are summarized below.
Focus on design rather than programming. Rather than focusing on programming-oriented features such as automatic code generation, integrated compiling and debugging facilities,

0-7695-0493-0/00 $10.00 (c) 2000 IEEE

3

Proceedings of the 33rd Hawaii International Conference on System Sciences - 2000

syntax-oriented editing, and simulation capabilities, the main emphasis in Timbuktu is on facilitating communication among designers and supporting collaborative work.
Focus on representation and communication rather than formalization. A key goal for Timbuktu is to serve as a collaborative medium that allows the designers to effortlessly and clearly express what they really mean, regardless of whether the information is formal, semi-formal or informal.
Supporting location-transparent teamwork and informal collaboration. In large organizations dispersion is a problem. Information should be spread to sites, and, for example, expert networks have been built. We regard communication support as being one of the most important goals for tools to promote production of large software systems. There are other important goals for tools to support the process, but in this paper we focus on the communication support.

3.1. Timbuktu concepts and features Timbuktu is a result of a several year project, which aims to produce future tools for NOKIA’s software developers. The main goals of the project are to produce tools to support the use of visual information instead of 3 textual, to support team (also virtual team ) communication and co-operative work, and to support global information management. We describe these goals as dimensions in our tool: CASE dimension. Timbuktu provides graphical design tools for supporting systems development using UML and workflow notations. Notations are helpful in designing and communicating about software systems, and software processes. Collaboration dimension. Timbuktu serves as a virtual whiteboard system that allows designers to share the same working space location-transparently, and to work on the same graphical designs even simultaneously if necessary. Information management dimension. Timbuktu allows direct, interactive, visual management of documents and other design information in a shared, versioned, and graphical working space. The main differences between Timbuktu, Lotus Notes and Intranet are described in Table 1. Although Timbuktu does not provide new solutions for separate dimensions, its uniqueness comes from the combination of the dimensions. The combination is focused on supporting virtual team communication in a

location-transparent manner and natural structuring of 4 design data . Table 1. Information management differences between Intranet, Lotus Notes, and Timbuktu. Tool

Intranet

Lotus Notes

Timbuktu

Information construct

Network of pages

Lists of documents

Network of workbooks

Granularity information elements

Fine grained: Words, figures

Large grained: documents

Fine grained: Objects Object views

Hyperlinks (1-dir)

Document views Document links, View links, Anchors

Reader

Author

Asynchr.

Asynchr.

HTML files in web servers

Replicated databases

Information reuse Linking of elements

Emphasized user roles Mode of collaboration Physical storage

Workbook hierarchy Hyperlinks (2-dir.) Shortcuts (1-dir.) Author Synchr./ Asynchr. OO repository

3.2. The collaboration dimension From the technical viewpoint, Timbuktu supports virtual co-operations – also referred as synchronous collaboration – with notification mechanism, a collaboration cursor facility, and collaboration status information. The notification mechanism is a high-speed service that keeps the user views synchronized and enables users’ location transparency. The collaboration facility lets users see each other’s cursors on their screens (Figure 1). In contrast to the pure phone call, where one has to use proper names, we can point to objects in Timbuktu without using their proper names. This facility speeds up the communication process and supports it in a natural human-oriented way. Section 3.4. presents examples of using tacit knowledge in collaborative tasks.

4

3

Timbuktu supports building of temporary teams to work with a common task, e.g., a review. Collaboration can also take place between persons having no preplanned contracts of co-working. Noticing the presence of another users may trigger a collaboration session.

By the natural structuring of design data we mean that the information space of the tool evolves according to how the author creates and initiates objects and relations. There is no predefined frame of schema for the user. The author also creates data structures, which are used as the storing schema.

0-7695-0493-0/00 $10.00 (c) 2000 IEEE

4

Proceedings of the 33rd Hawaii International Conference on System Sciences - 2000

transmission requirements more than what it would be if we used transactions between the server and the lightweight client.

Figure 1. Timbuktu screen layout: three workbooks with collaboration bars (one contains text of ‘wikman, kanykane, ajarileh, marttiin’), two collaboration cursors (icons of a hand pointing upwards), and a visit card (icon of a face with the text ‘Jari A. Lehto’). Timbuktu offers some status information about the collaboration situation. We show in the collaboration bar the names of the users working on the pane. The goal is to encourage users to feel they are collaborating. We also provide a visit card, which represents someone, that can be contacted via e-mail. A visit card can also be used as a link to the owner’s homepage. Our next technical goals are integrating conference calls and video connection support with Timbuktu.

3.3. Technical highlights Unlike most other information management systems, Timbuktu avoids locking and exclusive access as much as possible and allows multiple designers to access the same visual diagrams, even simultaneously providing notification services for keeping multiple designers' work up to date. Timbuktu can be seen as a ‘writable and collaborative web’ that provides many of the World Wide Web (WWW) services. In contrast to the WWW, Timbuktu is always fully interactive, it supports shared direct manipulation, and it enables online collaboration with other people using the system. From the technical point of view Timbuktu is based on an extended client-server approach and object-oriented database technology [15] (see Figure 2). Extended clientserver approach is composed of three types of computers, where the first is a conventional database server, and the second is a transaction client located on the server machine. Together they compose an object server for the lightweight object client, which is the third one. This architecture provides us with the means to diminish data

Figure 2. Timbuktu.

Three

component

architecture

of

We performed exhaustive tests with our earlier version – TDE – based on a traditional client-server architecture. 50 concurrent users were located in two sites with a distance of 100 miles and connected through a 10 Mb LAN to one server using one database. Performance slowed down after having 45 active users: the server was running throughout the test, but slowly at the end. The server machine used one of four available processors. Our experiences were based on real-life like circumstances. The test result showed that TDE did not suffer in performance. However, we noticed that data transmission speed under 2 Mb was too slow. We are currently working with lower transmission speeds with Timbuktu architecture presented in Figure 2.

3.4. Experiences circumstances

in

collaborative

working

This section presents three collaborative cases. The first describes our personal effects and awareness of becoming and being a participant in a collaborative session, the second describes our experiences in method development teamwork, and finally we describe a design review. Awareness of other users is a heavy experience in this kind of database application environment. The visibility

0-7695-0493-0/00 $10.00 (c) 2000 IEEE

5

Proceedings of the 33rd Hawaii International Conference on System Sciences - 2000

and movements of other users give one a feeling of not being alone with this information. When seeing others working in the same area, one immediately becomes aware of their presence and a kind of respect for others occurs. For example, when starting design work in the morning one is able to notice there are others already at work, their application open, and possible ready for continuing unfinished sessions. This phenomena, at least as we regard it, is an appearance of social dimension, which is mediated through the tool. Method development team collaboration was organized to take place in one classroom. We had a team of six participants. The method development tasks were divided into successive and parallel steps according to the methods under development. Participants worked on separate and heavily interrelated tasks. The collaboration support was used to help two or more participants to communicate about mutual things and interfaces between their tasks. During the process we were able to use both tacit and explicit knowledge. Problems could be solved soon after they were met, and, thus production of explicit material was extremely speedy. Graphical representations were used to visualize things, and we were able to point things out instead of explaining with words. In addition, we noticed a new experience: several concurrent discussion threads were going on at the same time. This helped the others to follow at high level the state and direction of the composed work. Although the classroom was equipped with a data projector it was not used. Timbuktu was regarded as offering better support for the teamwork. We regarded this as a discussion session supported only by instrumental groupware facilities. A design review means here a session between a software engineer producing a feature specification (e.g., a property in a mobile switch under development) and experts from the same area of knowledge. The output a software engineer needs to produce for a review is usually a document. The experts need to familiarize themselves with the document and write down their comments when necessary. The software engineer collects all comments and rewrites the document for the next review done by the same experts. Usually, all comments are gathered and discussed, and the solution suggested in a face-to-face meeting. The problems in such a review process include time consumption, overlapping comments, and dependencies between comments that are not considered. These problems are due to a set of separate asynchronous discussions between the software engineer and each expert. In a review session supported by Timbuktu we are able to use a common information space instead of documents and provide a session where the review can take place in both asynchronous and synchronous way. The presentation of design material is carried out using views offered by Timbuktu, and the synchronous communication session

was supported with a conference phone call. Physically comments were placed close to things in consideration. Comments around design space were accessible by Timbuktu hyper-linking facilities. We noticed that the same comment did not appear more than once. Furthermore, the reviewers were easily able to follow how the rewriting proceeds just by browsing the hyper-links of their comments. The reviews were substantially (in some cases 75 %) shorter than the ones using the legacy procedure. One pitfall of collaborative reviews is cognitive overload of contextual information. Although material is helpful it needs to be well organized. This raises the problem of authoring and reading a hyper-document, where information is natural for the author but unnatural for the reader. In addition, in some cases the final face-toface meeting was skipped. Some ideas and solutions, that may have been discovered face-to-face, could remain unknown. We conclude at technical level that we have confronted the need for a higher level of collaboration support than the current Timbuktu can offer. It seems necessary to support several types of collaboration sessions. There is a requirement for chaired sessions and sessions where all participants are on equal teams like discussion. We regard that awareness is not enough: we should be able to offer means to build-up the feeling of togetherness. The feeling of togetherness is one of the cornerstones in creating virtual collaboration. Furthermore, we have noticed that we should be able to better support the use of ones tacit knowledge by presenting and pointing to visual artifacts and at the same time communicating using a phone or video connection. The aim is to bring face and body gestures into the communication flow, and, thus to allow feedback to the other communicative partners. This is highly needed in a distributed expert organization.

4. Lessons learnt from the adoption and use of a collaborative tool 4.1. Groupware should be generic and dynamic Most systems development tasks are individual, intellectual, uncertain, and dependent on the context. Furthermore, groups change their task definitions in response to outside influences. Thus, there exists a need for very flexible tools, where rules are not embedded into the tool, and the tasks for which the tool is intended are not restricted to a specific context. A groupware system that reflects individual user’s own mental model of work is the one they are willing to use. From this basis we are proposing an anarchistic approach that takes an individual user into account. Fuchs [5] has pointed out that "collaboration requires working in a synchronous and asynchronous mode frequently switching

0-7695-0493-0/00 $10.00 (c) 2000 IEEE

6

Proceedings of the 33rd Hawaii International Conference on System Sciences - 2000

between modes, or even working in both modes at the same time". Therefore, collaboration should not be restricted to a certain place and even restricted to be taking place at a certain time. However, many groupware tools can only be used in very specific circumstances requiring, e.g., a meeting room.

4.2. Groupware adoption is not a technical problem It heavily concerns individuals. According to our experience, utilization of collaborative services is not primarily a technical problem. We have let users proceed at their own speed when starting to use the services of our tool. They are pleased to see other users – or their cursors – roaming over the screen, and a feeling of a kind of social togetherness is commonly experienced. We have followed the principle to let everybody see what is available and not in any way inhibit information browsing. However, we still hear complaints that users’ privacy is compromised because the desk is open to every observer and there are no locking capabilities. This means that we are faced with the dilemma of privacy and awareness. All the available technology and experiments of how to use a collaborative service is extremely small. We have not made any reliable investigations of the reasons for this, but we think that users are so individualistic that they do not see how the tool could be used. We have also identified that obviously suitable means and manners are not yet developed for current users. The use of collaborative services is a much larger problem area than only a technical one. It obviously lies in us, but will take time to become part of our everyday life. Organizations are not ready for collaborative environments. We feel that collaboration will not take its place automatically. We do not know the reason for that, we have offered collaborative support, but it has not started to run. We believe that it might have something to do with our natural way of delegating responsibilities: it is hard to delegate responsibilities to a virtually perceived actor. Another point could be that current tools supporting communication do not acknowledge the need for memory and tracking of the communication event. If we do not get a response to something we have delegated, it is certain that we do not feel confident. Our current management and communication systems are based on the natural enterprise. Our challenge is now to understand how the natural enterprise must be reflected in the virtual enterprise. The cornerstone might not be responsibilities, but as long we can find this kind of correspondences we have possibilities to recover those which are potential.

5. A Vision for a Future Groupware: Virtual Enterprise In this section we outline a future view for a collaborative design environment. It is based on a vision derived from the theories as well as our experiences. In our tool individual knowledge creation is thought to be supported by letting individuals collect pieces of information stored in the tool by drawing, attaching notes and pictures to workspace, linking and commenting on others’ work, and communicating with others in synchronous sessions. It is possible to add features for personal networking although we have not yet built support for it. From this basis we characterize the environment capable of supporting both synchronous and asynchronous sessions. We characterize the overall solution to our problem as creating a virtual enterprise. Virtual means in principle something that is not tangible, but exists and is supposed to behave like its natural paragon or ideal. Enterprise here characterizes those efforts we do in our job to reach objectives set for us. The context for this job as described above means having meetings, teaching, supervising, and consulting with people whose location could be unknown to us. Their background, working circumstances, owned skills etc. could also be unknown to us. To support virtual enterprise we need:
support for synchronous and asynchronous collaboration (already discussed above)
support for real location transparency,
support for personal networking,
support for management of history data and audit trails,
access to distant and shared information,
workplace to cope with the progress of efforts, and
workplace to cope with our learning. This list does not cover everything; we merely list the most important and vital factors for the successful function of virtual enterprises.

5.1. Location transparency Due to the dispersed enterprise we cannot have all our work mates ‘along the same corridor’, which in the near past guaranteed the best collaboration. We have to be able to work with colleagues who are located all over the globe and we should not spend time wondering where they are located and how difficult it is to have meetings with them. Our colleagues have to be location transparent and so they become – more or less – virtual to us. The objective of location transparency support for collaboration is to transmit all the information and data between locations of participants. This must be controlled by the natural need of participants in this virtual enterprise.

0-7695-0493-0/00 $10.00 (c) 2000 IEEE

7

Proceedings of the 33rd Hawaii International Conference on System Sciences - 2000

Location transparency needs support for high rated data exchange, because it has to satisfy the corresponding natural need of rapid data exchange. For example, one can understand this need by imagining a meeting where we have material made beforehand including overhead foils, notes, whiteboard illustrations, and video images. In addition to that, we have to get a view of participants movements, reactions, countenance, and reflections. The perceivable information controlled by the observer will be huge in amount. However, location transparency is not a solution for collaborating with sleeping people, which still remains as another problem of collaboration across time zones.

efficient to collect references than transmit data to one’s own ‘place’.

5.5. Workplace to cope with the progress of these efforts

Personal networking should be supported. Hattori et al. [6] argued that search engines or directory services for communities can partially help, but more sophisticated systems are needed. Socialware [6] aims to support networking communities which are forthcoming and the borders of which are dynamically changing. Furthermore, communities are not based on strict objectives; rather they support individuals’ diverse objectives. Such an approach is promising for knowledge sharing from the point of view of the personal networking problem.

In general, our normal workplace is a desk. It can be equipped differently for different tasks and working situations. In a virtual enterprise we should have something, which corresponds to our natural workplace. In Timbuktu we have called it an electronic desk. An electronic desk simulates a desk with things on it. While an e-desk is a working place it is also a tool for visualizing work entities. This has some positive affect also to communication and information management such as richer set of mnemonics, and spatial information of relationships with other things. The workplace can also be applied as a memory, which can be structured and enlarged with pseudo dimensions. An example pseudo dimension is the visualization time by reducing the size of objects or setting more closely related artifacts nearer each other than more loosely related ones. It is also possible – if ethically correct – to glance at other peoples desks. Home pages on the Web simulate the idea of a workplace quite well, only suffering the support of WYSIWYG authoring.

5.3. Audit trails and information management

5.6. Cope with our learning in that process

When people are communicating, their brains register things about the phenomena that can be remembered and recalled later. It is natural to demand such memory support from groupware. We sometimes need to go back in history and make sure what has happened. This ability should be easy to use similarly as information management systems. The history should be created without any additional burden to the user. The importance of this support can be seen in the current practice of using e-mail systems, where users save their messages as documents for a long time. However, this information is hard to search and hard to integrate with other sources of data.

If we think of an electronic desk at different points in time we can see that it could reflect in some respect its users learning curve. Users gather things that are currently important to them, and, thus the desk is under continuous modification. This has some similarities with our experiences, which are updated every time we do something, and we never return to a previous organization. This is an important property of learning systems.

5.2. Support for personal networking

5.4. Access to shared distant information People share their thoughts and ideas when having conversations and meetings. Valuable opinions are transmitted from participant to participant. In the context of a virtual enterprise, we also have some of our data in electronic form. As thoughts and ideas it should be accessible to remote workers. A related question is that should we collect data or references to it. It is usually more beneficial to have a reference to the information than having a copy of it. This is simply due to the fact that by copying one cuts the evolution of an artifact. In a virtual enterprise it is more

6. Summary In this paper we have presented our view of a collaborative design tool for the use of distributed projects, where we have limited possibilities to meet face-to-face. Firstly, we have stressed the need for a general platform, which provides support for diversified synchronously or asynchronously managed actions. Secondly, we have pointed out that personal networking is an important means for finding and sharing information, and, thus it should be taken into consideration when building groupware. Personal contacts with colleagues, experts and other stakeholders in systems development are important in the knowledge creation process: sharing of tacit knowledge (socialization) and externalizing it to a lingual form. Based on Timbuktu experiences we have outlined a human-centered vision of groupware (virtual enterprise)

0-7695-0493-0/00 $10.00 (c) 2000 IEEE

8

Proceedings of the 33rd Hawaii International Conference on System Sciences - 2000

based on the capability for both asynchronous and synchronous sessions and adaptation to support individuals tasks. We have also discussed the other side of the coin, which makes empirical studies hard: individuals and organizations may not be ready for such virtual tools.

Acknowledgements We would like to thank all developers of Timbuktu, especially Johan Wikman – the chief architect of Timbuktu. Special thanks are given to Mikko Tarkiainen and Riikka Harju for their fruitful comments to this work.

[14] Taivalsaari A., and Vaaraniemi S., "TDE: Supporting Geographically Distributed Software Design with Shared, Collaborative Workspaces", In: A. Olive, J. A. Pastor (Eds.), Advanced Information Systems Engineering, LNCS#1250, Springer-Verlag, 1997, pp. 81-87. [15] Wikman J., "Evolution of a Distributed Repository-based Architecture", In: http://www.ide.hk-r.se/~bosch/NOSA98/, Electronic Proceedings of the First Nordic Software Architecture Workshop, 1998. [16] Winograd T., and Flores F., Understanding computers and cognition, Norwood: Ablex, 1986.

References [1] Allen T., Managing the flow of technology, Cambridge MA: MIT Press, 1977. [2] Bannon L., and Bødker S., "Constructing common information spaces", In: J. Hughes, T. Rodden, W. Prinz and K. th Schmidt (Eds.) Procs. of the 5 ECSCW, Dordrecht: Kluwer Academic Publishers, 1997. [3] Carmel E., Global Software Teams: Collaborating Across Borders and Time Zones, Prentice-Hall, 1999. [4] Curtis B., Kellner M.I., and Over J., "A field study of the software design process for large systems", Communications of the ACM, 31, 11, 1988, pp. 1268-1287. [5] Fuchs L., "AREA: A Cross-Application Notification Service for Groupware", In: S. Bødker M. Kyng, K. Schmidt (Eds.) Procs. of the 6th ECSCW, Dordrecht: Kluwer Academic Publishers, 1999, pp. 61-80. [6] Hattori F., Ohguro T., Yokoo M., Matsubara S., and Yoshida S., "Socialware: Multiagent Systems for Supporting Network Communities", Communications of the ACM, 42, 3, 1999, pp. 55-61. [7] Hertzum M. "Six Roles of Documents in Professionals' Work", In: S. Bødker M. Kyng, K. Schmidt (Eds.) Procs. of the th 6 ECSCW, Dordrecht: Kluwer Academic Publishers, 1999, pp. 41-60. [8] Lipnack J., and Stamps J., Virtual teams: reaching across space, time, and organizations with technology, NY: Wiley & Sons, 1997. [9] Lyytinen K., and Ngwenyama O.K., "Groupware Environments as Action Constitutive Resources: A Social Action Framework For Analyzing Groupware Technologies", Computer Supported Cooperative Work: The Journal of Collaborative Computing, 6, 1, 1997, pp. 1-23. [10] Mandviwalla M., and Olfman L., "What Do Groups Need? A Proposed Set of Generic Groupware Requirements", ACM Transaction on Computer-Human Interaction, 1, 3, 1994, pp. 245-268. [11] Marmolin H., Sundblad Y., and Pehrson B., "An Analysis of Design and Collaboration in a Distributed Environment", In: Bannon, Robinson, Schmidt (Eds.) Procs. of st 1 ECSCW, 1991, pp. 147-162. [12] Nonaka I.A., "Dynamic Theory of Organizational Knowledge Creation", Organization Science 5, 1, 1994, pp. 1437. [13] Nonaka I.A., and Takeuchi H., The Knowledge Creating Firm, How companies Create Dynamics of Innovation, Oxford University Press, 1995.

0-7695-0493-0/00 $10.00 (c) 2000 IEEE

9