Information stored in distributed team-based student project work

56501 Research Studies

Research Paper

Alastair Bennett
200514155 5th Year MEng Product Design Engineering

Supervisor: Umit Bititci

16th March 2010

A. Bennett
Statement of academic honesty I declare that this submission is entirely my own original work. I declare that, except where fully referenced direct quotations have been included, no aspect of this submission has been copied from any other source. I declare that all other works cited in this submission have been appropriately referenced.

I understand that any act of Academic Dishonesty such as plagiarism or collusion may result in the nonaward of my degree.

Signed ....

Dated ..

A. Bennett
Acknowledgements

It would not have been possible to complete this study without the help of a number of individuals. Special thanks go to my supervisor, Mr Umit Bititci, for all his help and guidance over the course of the study. Thanks also go to Mrs Hilary Grierson for her insights into the subject area, and to Dr Andrew Lynn for his insights into the systems studied. Finally, thanks go to all who gave up time to participate in this study, without whom the study could not have been carried out. March 2010

A. Bennett
Justification of journal choice

This study has been written to conform to the guidelines for publication within the academic journal Computers and Education. This was chosen as it deals with studies relating to primary, secondary and tertiary education, and looks at issues relating to cognition, education and training within these settings. Two of the particular areas from which the journal publishes papers are advanced technology information systems and virtual reality systems in an educational context. The area of this paper, looking at systems used to share information within an educational setting, fits well with the aims of this journal. This paper has been written in line with Computers and Educations Guide for authors, which is available at www.elsevier.com/wps/find/journaldescription.authors/347/authorinstructions online.

A. Bennett
Abstract Alastair Bennett, Department of Design, Manufacture and Engineering Management, Strathclyde University, Glasgow alastairjbennett@gmail.com

In industry it is becoming increasingly common for distributed projects to be carried out, and therefore the same trend is occurring in educational establishments, both to prepare students for working in industry, and to broaden their experiences and expertise. In order for distributed projects to be successful, it is imperative that knowledge and information can be shared between individuals. The most common method for allowing this is the use of online digital repositories that act as digital memories. These allow team members to upload information for others to access, and to access work carried out by others. There are a number of different systems available for use by students to share information during projects, and many studies have looked at developing new systems with more features. However, these studies have not looked into what information is being stored and shared on systems, when information is being stored, and what systems or other methods are most commonly used to share files. This study looks at two areas. Firstly it examines students thoughts and opinions on various systems in order to find out why they like or dislike using them, and what they feel could be improved. Secondly it looks in detail at the files stored in a number of projects, and analyses them in a number of ways, including file sizes, file types, and the different stages of projects they fit into. Finally, a number of recommendations are made relating to improvements that could be to teaching relating to using information sharing systems, improvements that could be made to one specific system examined during the study, and general improvements that could be applied to all information sharing systems to improve their usability.

Key words: information sharing, distributed projects, education Word count: 14,998 words

A. Bennett
Contents Statement of academic honesty Acknowledgements Justification of journal choice Abstract Contents 1. Introduction 2. Literature review 2.1. Distributed teams 2.2. Distributed student projects 2.3. Knowledge 2.4. Technology 2.5. Collaboration 2.6. Communication 2.7. Literature findings 3. Research objectives 4. Methodology 4.1. General approach 4.2. Research design 4.3. Validation 5. Data collection 5.1. Project 1 5.2. Project 2 5.3. Project 3 5.4. Project 4 5.5. Project 5 5.6. File systems 5.6.1. Laulima 5.6.2. Google Groups 5.6.3. Server access and file storage 6. Analysis 6.1. Interviews 6.1.1. Conclusions 6.2. File inspection 6.2.1. Project 1 6.2.2. Project 2 6.2.3. Project 3 6.2.4. Project 4 1 2 3 4 5 7 8 8 9 10 11 12 13 14 15 16 16 17 18 19 19 19 20 20 21 21 21 22 22 23 23 25 25 25 26 27 28

A. Bennett
6.2.5. Comparative analysis 6.2.6. Conclusions 6.3. In depth file analysis 6.3.1. Conclusions 7. Discussion and conclusions 7.1. Discussion 7.2. Contribution to knowledge 7.3. Practical implications and recommendations 7.4. Future research 7.5. Personal reflection References Bibliography Appendix A Semi-structured interview questions Appendix B Files uploaded by each team member Appendix C Number of files uploaded per stage Appendix D Number of files uploaded per file type Appendix E File distribution between stages Appendix F Numbers of files within project stages Appendix G Percentages of total uploads Appendix H Numbers of files uploaded Appendix I Sizes of files uploaded Appendix J Uploads within project timelines Tables Table 1 Research Design Options Table 2 File type information Table 3 Project stage information Table 4 Percentage of total uploads in each period Table 5 Percentage through project of periods of uploading Figures Figure 1 General Research Methodology Figure 2 Project 1 File Types and Amounts Figure 3 Project 2 File Types by Stage Figure 4 Project 3 File Types and Amounts Figure 5 Project 4 File Amounts by Stage Figure 6 Project 4 File Types by Stage Figure 7 Project Timelines Showing Uploading Periods for Each Stage Figure 8 Categories of Information Contained in Project 4 Files 16 26 27 28 29 29 33 35 18 30 31 32 32 30 33 34 35 36 36 37 38 39 39 40 43 i v vi vii viii x xii xiii xiv xv

A. Bennett
1. Introduction

As in industry, distributed team-based projects are becoming more common within an educational setting, with students being distributed within different establishments or having to work at different times and from different locations within one establishment. As with traditional projects, it is essential that information can be shared amongst teams in order to allow all participants to have access to the same knowledge, and to allow the best possible outcome to be produced. In order to allow information to be shared, online repositories are often used. These act as a collective memory for the group. They allow team members to upload files and notes to a system, from where they can then be downloaded and either used or edited by other team members. There are many different systems available to facilitate this sharing, with each providing different features and functionality depending on the project being carried out. Within many institutions there has also been a move towards using these systems to carry out assessment for many modules, with assessors and tutors being able to access the repository in order to examine what has been uploaded and shared, and final deliverables that can be uploaded. As well as allowing projects to be carried out in different ways, it is important to introduce students to these systems because of their use within industry. Due to the globalisation of many companies, and the distribution of expertise throughout different locations, the same types of system are being used more and more within an industrial setting, meaning students need to be prepared to use these once they have jobs. In spite of growth in the use of these systems within education, little is known about how students actually make use of them. There are many different systems with many different features, but in order to provide something that fits the needs of the students, it is important to know how they are using the system, what problems they think exist, and what they would like to see as part of future developments.

A. Bennett
2. Literature review

The literature review in this paper looked at a wide range of areas related to distributed teams, both in general and in an educational context. The boundary of information examined was to look at systems and other information-sharing methods used by distributed teams, with a particular focus on design and new product development teams. Firstly, distributed teams in general were examined, looking at what makes them distributed, performance levels, and levels of virtuality within these teams, with student teams then looked at separately. Following this, areas crucial to distributed teams were examined, including knowledge, technology, collaboration and communication.

2.1. Distributed Teams Within the literature, there are a number of different terms used to describe the same thing. Conversely, different authors use the same terms but with different implied meanings, which can lead to confusion. The term virtual team is often used, and the meaning that is often implied is the same as that as a distributed team. It is important to define early on exactly what a distributed team is, and the different ways in which it can be classed as distributed. Based on a review of previous literature, one definition of distributed teams is: Teams whose members use technology to varying degrees in working across locational, temporal, and relational boundaries in order to accomplish an interdependent task. (Martins et al, 2004) This definition was based on the findings of previous research work by a wide range of authors, and sought to consolidate their views as much as possible. Whether or not the previous authors would accept this, it covers the two key areas of distributed teams: the use of technology and the inclusion of an issue that requires the use of technology. This definition can be expanded slightly by saying that on top of there being a boundary that is being crossed, those involved can either be located within or outwith the same organisation (Leenders et al, 2003). Another important point is to understand why distributed and virtual teams are used, as this helps to reveal how they should ideally work. Leinonen and Bluemink (2007) note that due to advances in technology, it is possible for individuals located all around the world to easily and quickly communicate. When combined with the fact that the expertise and skills required to develop new products are often spread throughout an organisation (Leenders et al, 2003), this leads to the need for distributed teams, since it is far easier to bring the team together virtually. It should also be noted that it is very rare for a team to be entirely distributed (Leenders et al, 2003), with it being far more likely that there will be pockets of team members, and some on their own. The degree to which technology is used within distributed teams is another point of contention between authors. Some authors used to claim that for a team to be classed as virtual, all their communication should be through electronic means (Bouas and Arrow, 1996), but more recent authors said that some face-to-face communication was allowed (Jarvenpaa and Leidner, 1999). Even more recent work has suggested that distributed teams should no longer be contrasted with traditional teams, instead stating that all teams are virtual to a certain extent (Griffith and Neale, 2001). The second part of the previous distributed team definition looks at boundaries between team members. Various authors often discuss one or two types of boundary that cause teams to be distributed, but together there are more. Zoubi and Tavcar (2004) say that team members in the studies they looked at were dispersed due to geographic or organisational dispersion, while Leenders et

A. Bennett

al (2003) say that distributed teams are either geographically or temporally distributed and can be in the same organisation. In their review of previous work, Martins et al (2004) noted that the three most commonly mentioned boundaries are temporal, geographic and organisational boundaries. They also noted that the first two of these are mentioned in almost every definition. Other noted boundaries and barriers that can occur include language and cultural boundaries (Kamel and Davison, 1998) and relational boundaries (Griffith et al, 2003). It should be noted a team could easily be faced with more than one of these boundaries. One way of taking advantage of the temporal boundary is to spread teams geographically in a tactical manner in order to allow work to be carried out 24 hours a day (Gupta et al, 2009). This means that the total number of days from start to end of a project can seemingly be reduced, although this does bring with it a number of other issues. Several authors have looked at the performance of distributed teams in relation to their face-to-face counterparts and commented on the differences. Group size has always been seen as an important factor in team performance (Steiner, 1972). Unlike in face-to-face teams, it was found that during idea-generation exercises the number of ideas generated actually increased (Gallupe et al, 1992). However, Riopelle et al (2003) found that increased team size made it difficult for team members to interact effectively. Martins et al (2004) conclude that the effect of team size is very much dependent on the nature of the task being completed and the technology being used. Some authors have also commented that timeframes for distributed teams are often longer than those for traditional teams. This can be due to electronic chat groups taking longer to reach decisions (Graetz et al, 1998) or because some electronic communication requires longer timeframes (Weisband, 1992). In relation to the outcome of projects, authors seem split on whether distributed or face-to-face teams produce better results. Some authors claim that tests revealed no difference in performance between the two types of team (Cappel and Windsor, 2000), while there are large numbers that claim each type produces better results. As with other areas, performance seems to be task-dependent. Leenders et al (2003) conclude that for complex projects, it is less desirable to have highly distributed, virtual teams, while Gupta et al (2009) state that for other projects there seemed to be no detrimental effects on the efficiency of the team, or the final outcomes. A possible conclusion that could be drawn from this literature is that it is not necessarily whether the team is distributed that affects performance, but how the project is controlled and managed, and how well team members interact. Other main characteristics of distributed groups that are mentioned in literature, contribute to the working of groups fairly substantially, include that distributed team unlikely to work together again after a project (Zoubi and Tavcar, 2004), that they have a membership than traditional teams (Alge et al 2003), and that they seem to have a lifecycle (Jarvenpaa and Leidner, 1999). and seem to members are far more fluid much shorter

2.2. Distributed student projects With industry tending more towards the use of distributed teams, it is important for students to be properly prepared and appropriately trained in how to work in this way (Zoubi and Tavcar, 2004). By looking at industrial psychology, it was discovered that students need skills that extend beyond their chosen discipline (Sheppard et al, 2004). Elpass and Hollinger (2004) also noted that allowing students to work in this way helps them to practically apply what they have been taught.

A. Bennett

10

Within student-based distributed projects, some disadvantages were discovered compared with those in industry. One of these was that on top of the other boundaries and barriers applied to such teams, issues arose with the timings for terms beginning and ending within different institutions. This had a knock-on effect, with the result that projects often cannot not run for long enough to be successful (Zoubi and Tavcar, 2004). As well as preparing students for industry, these projects also allow distributed teams to be monitored under incredibly controlled circumstances. This allows greater lessons to be learned from projects, the outcomes of which can then be applied in industry to improve the results of distributed team projects.

2.3. Knowledge Looking into the area of knowledge, it is important to distinguish between knowledge and information. For the purposes of this study, a general difference will be taken as information being the basis of knowledge, with the transfer of information being integral to the transfer of knowledge. Knowledge is the core product of product design (Leenders et al, 2003), and sharing knowledge effectively is key for teams, whether they are co-located or distributed (Gupta et al, 2009). Leenders et al (2003) also suggest that the productivity of product development teams depends not only on their ability to discover information but also to effectively communicate and share it amongst team members. It is also vital to ensure that information being shared is appropriately protected (Zoubi and Tavcar, 2004). Within distributed teams, it is especially important to ensure that information is shared well, due to the distribution of team members. Ardichvil et al (2003) found that information flowed far better when it was viewed as something that belonged to the whole company, rather than something that an individual had discovered or produced. When knowledge is being shared, it is important to know exactly what needs to be shared and when (Leinonen and Bleumink, 2007). There are a number of ways that this can be carried out depending on the nature of the project being completed. As well as knowing what should be shared, information that is of greater importance should be identified clearly for other team members to see (Cramton and Orvis, 2003). It is also important to ensure that the information that is being shared is unambiguous (Hinds and Weisband, 2003), due to the distribution of team members. Digital libraries are areas in which information can be stored during projects, and then searched by users for information that they need. Information can also be shared from other projects. Elpass and Hollinger (2004) suggest that these will become more and more common, and become the backbone of future education. Leinonen and Bluemink (2007) carried out case studies and talked to the participants in order to discover what information and knowledge they assumed to be shared during projects. Their findings showed that as well as information such as research findings and designs, it was important for more personal information to be shared. They also discovered that team members presumed that ideas about goals and processes would be shared. There are, however, a number of barriers to people sharing information within a distributed team setting, just as with a traditional team. Perhaps the biggest barrier is the tendency not to contribute in case someone is criticised or in case they mislead someone (Ardchvil et al, 2003).

A. Bennett
2.4. Technology

11

Technology plays an absolutely vital role in the work of distributed teams. Distributed teams use technology in a very different way from traditional teams, with it playing a vital role in communication and sharing, as well as for individuals carrying out work. A lot of research has been carried out both in industry and in an educational context as to the role technology plays, how it can and should be used, and what issues there are with it. One common theme that has been discovered by authors is that any technology must be easy to use (Hinds and Weisband, 2003), in order that it continues to work as a support tool and does not become something that takes large amounts of time to work with and keep up to date. Students within team projects at Strathclyde University who were using a wiki-based online system commented that it took far too long just to keep their part of the system up to date, as well as taking a long time to upload new data (Grierson et al, 2006). Lecturers involved with the European Global Product Realisation (E-GPR) course commented that as well as the systems being reliable, students need to be able to master technologies quickly, preferably before the project has started, in order for them to make the best use of these (Zoubi and Tavcar, 2004). In the same paper, Zoubi and Tavcar (2004) talk about the language barriers often present in distributed team projects. Kamel and Davison (1998) looked into this area too, proposing that the development of technology means that language barriers could be removed through the development and use of translation software for such projects. As well as looking at how distributed teams use technology, a large number of authors have put forward frameworks and guidelines for new systems that they think solve the problems faced during distributed projects. Huang et al (2006) proposed an agent-based workflow management system and looked at tackling the issue of interoperability. Anumba et al (2001) looked at developing a multi-agent system within the construction industry to bring together those working across the many different areas involved in such a project. Zhan et al (2003) look at dispersed manufacturing systems, and present a system that allows access to a companys servers from a standard web browser, but also allows the user to customise the system. Their system included the remote use of applications without having to install them on the machine being used and discussed the benefits this brought. Frank and Mitschang (2002) also looked at developing a customised system, but with more of a focus on allowing different users to co-operate on work at the same time. Finally, Fan et al (2008) looked at developing a system that was peer-to-peer, rather than client/server based. This worked by connecting groups of computers to a server, and then linking the servers together. This was aimed at improving the speed of data transfer, since files were accessed on the local server. As well as developing and proposing new systems, authors have also looked at current technologybased systems, examining how useful they are and what differences they can make to projects. Wodehouse et al (2007) found that the Laulima system used at Strathclyde University helped teams to focus, as well as helping to raise overall confidence levels. Grierson et al (2006) found that the same system became more than just a place to store information for students, also becoming a place to share and reflect. Turner and Turner (2007) looked at a number of systems but concentrated on WebCT. They found that a number of issues that had been present from the 1990s were still around, which was not that surprising. More interestingly, they found that there was a critical mass of users needed in order to make use of such technologies worthwhile and successful.

A. Bennett

12

As well as looking at the advantages of using technology during distributed projects, authors have discovered some of the issues both with technology in general, and with specific systems. One of the issues discovered by Zoubi and Tavcar (2004) is the speed of connection needed in order to enable the successful use of technologies. Linked to this, they found that both the systems and connection being used need to be able to cope with the transmission and storage of very large files.

2.5. Collaboration One of the great advantages of distributed teams is that people with different skill sets who would not usually be able to work together can (Leenders et al, 2003). Monplaisir (1999) stated that collaboration is key to effective development, and it is therefore no surprise that almost every author refers to collaboration when talking about distributed projects. One of the areas in which the biggest advantages of collaboration in distributed teams can be seen is in the concept development stage, specifically brainstorming. Connolly et al (1990) found that collaboration at this stage helped bring about slight criticism from team members, which ultimately helped to produce more original solutions. Combs (1993) looked at exploiting the advantages of collaboration during the early stages of design projects by developing co-operative research between multiple companies. The idea behind this was that all the companies would benefit from this, since the ideas created would be better than those created by any of them on their own. However, there were issues with getting companies to see that this would benefit them, rather than just help other companies to make money. For collaboration to be as successful as possible, it is of great importance that multiple individuals can access information at the same time. Unfortunately, synchronous data access is often conflict prone (Frank and Mitschlang, 2002), and instead of aiding collaboration, this actually limits who can look at certain items at a certain time. Riopelle et al (2003) note that different technologies allow different amounts of synchronous access and collaboration, although ideally all systems should have this as a central feature. In order to aid collaboration further, Zoubi and Tavcar (2004) noted that systems supporting distributed design should be available for use at all stages of projects, since collaboration is important at all stages. The obvious area that lacks this support is during the concept development stage if team members are not co-located, since it is useful to be able to see other members ideas during this stage, not just after it. Unlike in traditional teams, it can be harder in distributed teams to ensure that all team members are contributing. Ardichvil et al (2003) propose that some group members shy away from contributing in case they are criticised, while Kamel and Davison (1998) say that the higher level of anonymity within distributed teams can actually help to increase confidence, meaning people contribute more. In order to check up on member contributions, more recent technological systems can be used to look at which team members have added or shared what data, and when, thereby making it a lot easier to ensure equal contributions (Martins et al, 2004). The two biggest barriers to collaboration with distributed projects are very closely linked; compatibility and versions. Cramton and Orvis (2003) noted that one of the biggest barriers to information being shared between team members was issues relating to file compatibility. In their design platform, Zhan et al (2003) saw this as a major issue, and built in an entire part just to help deal with it.

A. Bennett

13

There are a number of issues relating to different versions of files within design teams. Frank and Mitschang (2002) state that when it comes to CAD files, most teams rely only on the version numbers of files to keep up to date, but this does not solve the problem of multiple people working on a file at once in separate locations, and work then being lost. Possible solutions to this problem include synchronous access to files on shared software, or locking other users out while changes are being made. Zhang et al (2004) note that CAD software developers such as PTC and Autodesk are now recognising collaborative work, and producing web-based versions of their software to help with this.

2.6. Communication As in all projects, communication is key for distributed teams. Due to the different types of separation experienced by these teams, their methods of communication need to be flexible, and are markedly different from traditional teams. A number of authors have looked at the issue of communication in distributed teams, both in industry and in an educational context. The research carried out has looked at both methods used to communicate, and common issues. The most obvious communication tools to make use of are e-mail and chat facilities, which Herder and Sjoer (2003) found to be the most common. However, Martins et al (2004) found that the use of less formal chat facilities tended to contribute to higher levels of frustration within teams, while Graetz et al (1998) found that teams using chat tools took longer to reach decisions. Depending on location of team members, tools such as video and telephone conferencing can be utilised, with video conferences in particular being found to contribute to a better quality of decision being reached (Baker, 2002). The issues of synchronous communication compared to asynchronous communication have been found to be a contributing factor, and one that needs to be considered in distributed projects. Herder and Sjoer (2003) state that it is key to have synchronous communication channels, but this may not always be possible, and is partly based around the type of communication channels being used, since not all allow truly synchronous use (Riopelle et al, 2003). Zoubi and Tavcar (2004) found that one of the many issues with asynchronous communication was the uncertainty of whether messages had been received and read, while others found that, as expected, using only asynchronous communication can result in the time to reach a decision or complete a process being far greater than with synchronous communication (Weisband, 1992). As well as the type of communication, the amount of communication that takes place in distributed teams was found to be a factor. Saphiere (1996) found that teams that communicated more often in informal and social ways were more productive than those that did not, while Zoubi and Tavcar (2004) found that higher levels of communication between team members helped the group to bond more, and to produce better results. As with other areas, there are a number of issues that have been found in relation to communication within distributed teams. Herder and Sjoer (2003) found that due to the importance of visual cues and geographical synchronicity, those located together as part of a distributed team will always work better together than with the team members in other locations. Zoubi and Tavcar (2004) found that the lack of visual cues present in most communication methods was a big drawback, and had a reasonable effect on productivity, while Gupta et al (2009) found that without face-to-face communication, it became difficult to transfer tacit information between individuals. Baker (2002) found that the use of video-based communication produced significant improvements, but was not always possible depending on team members distribution.

A. Bennett
2.7. Literature findings

14

One of the main findings through the literature review was that many different groups have attempted to produce new systems to improve information sharing and collaboration practices. However, many of these cases seem to be based on what the particular individuals feel that systems should be able to do, rather than basing them on the particular issues and problems being encountered by teams. The most common theme throughout literature was the importance of information being shared in a useful way within teams, as this was the basis of the team being able to achieve its goals properly. Despite the repeated references to the importance of information sharing, and development of new systems, no authors carried out in-depth studies into what information was actually being shared between team members in different projects. There was also a lack of research into when team members shared information with each other, and whether there were any regular patterns across different types of project. Although some research was carried out looking at specific systems and how they were used both in industry and in educational contexts, the research did not look into the preferred methods used by individuals to share information with each other, or why they used these methods.

A. Bennett
3. Research objectives

15

Based on the original research question that had been set and the outcomes the literature review, a number of specific research questions were set. These were initially set to look at where and when information was stored during distributed team-based projects. Based on these areas, the following specific research objectives were set: Objective One: To discover what systems are used to store information during distributed group design projects, and what other methods students use. Objective Two: To discover the limitations, problems and issues with commonly used systems, based both on user interaction and file storing capabilities. Objective Three: To discover when information is uploaded during projects, both in terms of whether it is uploaded when half finished or complete, and in relation to the project timeline. Objective Four: To discover the different types and amounts of information being uploaded and shared at different stages of a project. The literature review also revealed that no real research had been carried out into the details of what information was being stored during these projects, and therefore the following objective was also set: Objective Five: To discover what types of information are stored and shared throughout the course of distributed team-based projects.

A. Bennett
4. Methodology

16

There were three research methodologies that could be used for the project; positivism, relativism, and interpretivism (sometimes also referred to as social constructivism). Positivist approaches are often based on experimental research, and what is being observed is independent of the observer. The relativist approach also involves looks at a reality independent of the observer, but looks at the experiences of larger groups of people. The interpretivist approach looks at much smaller numbers of cases, and is based upon conversations and the opinions of individuals. The interpretivist methodology was chosen for use in the study in order to coincide with the inductive approach that would be used. It was also the best methodology to use in this situation due to the information already having been created, and the importance of talking to a smaller number of individuals and gaining more detailed, in-depth thoughts and opinions from them.

4.1.General approach The general approach used can be seen in Figure 1. From the initial research question, a literature review was carried out in this area, and a number of research objectives were set as a result of the findings. Data was then collected both through semi-structured interviews and by examining file systems, with this then being analysed and interpreted. A structure to allow teaching and development of systems was then developed, and conclusions were drawn. The literature review focused on information-sharing practices both in industry and in an educational context, and looked at systems that had been created, and other studies into issues with and uses of information storage and sharing systems.

General Research Question

Literature Review Research Questions Collect Data

Interviews and Observations

Data Interpretation Develop Structure Draw Conclusions

Figure 1 General Research Methodology

A. Bennett

17

Data was collected from four projects through semi-structured interviews and by examining the file systems and uploads associated with each project. These were then analysed separately to gain an understanding of uploading habits, and peoples opinions and thoughts on the systems. In order to try to ensure the information relating to each project was accurate, multiple team members from each project were interviewed, although due to some individuals having graduated, not all team members could be interviewed. Information pertaining to uploading habits was collected and analysed in terms of when it was uploaded, the sizes and types of files, and what parts of the project they fitted into. Peoples thoughts and opinions were noted and compared in order to see what points individuals agreed and disagreed on, and what general opinions started to emerge. Taxonomies or analysis of recordings of interviews could have been used to analyse the data collected, but due to the differing natures of the two sets of data, it was decided to analyse both in tabular form. This allowed the data to be manipulated and examined in detail with ease, and various patterns and trends to emerge. From the findings, a structure was developed containing recommendations both for teaching relating to distributed team design projects, and the development of systems, with a view to improving the issues that had been discovered through this study.

4.2. Research design There were four main areas to consider when designing the research for this study: the type of research, the research paradigm, the research strategy, and the research design itself. A roundup of the different options available is shown in Table 1. This project was based on inductive research rather than deductive research, since it started with specific observations and thoughts and used these to create more general theories and recommendations. Due to the research area, this was far more likely to bring useful results than using a deductive method, which would result in far more specific outcomes that could not be applied as generally as the results from this study. Since this study is based around collecting more general information and thoughts rather than figures, it used qualitative methods of data collection and analysis. These fitted especially well with the thoughts and opinions gathered during the study. The numerical data collected during the project was also analysed qualitatively, as no complex numerical analysis was carried out. Of the three research strategies available for use, an exploratory strategy was chosen. Unlike explanatory or descriptive strategies, which explain why something is happening or are used to identify particular characteristics within a certain area, the exploratory strategy fitted well with the aims of this study. Focused on gaining insights into particular happenings, this can be used to explore problems with no clear solution, and to search for patterns and hypotheses within data sets, rather than setting out to prove or disprove previously formulated theories. Of the five main research designs that could be used, only one fitted well with the aims of this project. Due to the inductive nature of the research, the setting within an educational context and the desire to develop recommendations for improvements based on current practices, case study research was the best choice. The observations and data collected from case studies were incredibly important in this study, due to the need to understand current practices first in order to be able to make recommendations.

A. Bennett

18

Table 1 Research Design Options

Research Type Inductive Research Starting with observations and data collection, and working back to general theories. Deductive Research Starting with the creation of theories and hypotheses, then confirming or disproving them with experiments.

Research Paradigm Qualitative Based on thoughts, opinions and more personal data, and generally involving personal accounts and unstructured interviews. Quantitative Analysing mostly numerical data using often complex statistical methods.

Descriptive Based on exploring and describing what is taking place in an organisation or area.

Research Strategy Explanatory Understanding and explaining relationships and how something happens.

Exploratory Looking at identifying patterns within data, and creating rather than confirming hypotheses.

Pure Research Applied Research Action Research Constructive Research Case Study Research

Research Design The most academic form of research, conducted to improve understanding and develop theory. Tackling problems within organisations with a view tocreating solutions, usually within a specific setting. Research that seeks understanding through attempting to change the situation being investigated. Looking at providing a rich picture of life and behaviour within organisations. Collecting data through studying cases, then interpreting and analysing data to draw conclusions.

4.3. Validation In order to ensure that the information gathered was accurate and reliable, multiple members of each team were be interviewed in order to ensure that there was a general consensus regarding thoughts and opinions. For the file data collected, reliability was ensured by collecting several sets of data in order to be able to back up the findings from a particular project. Due to the use of case studies in the research, it was important to look at how the accuracy and reliability of these could be measure. Three criteria were set to measure the success and validity of the case studies once completed: 1) Is there consistency in the views and data collected? 2) Are there enough samples, and are they varied enough? 3) Are there clear patterns and trends that emerge from the data without complex data manipulation being carried out?

A. Bennett
5. Data collection

19

In total, eight individuals were interviewed about five different projects. Seven of these students study within the Department of Design, Manufacture and Engineering Management (DMEM) at Strathclyde University, and one is an Architecture graduate from Aberdeen University. The Strathclyde students were interviewed about four different projects, which were used as the basis of the file system analysis, and the Aberdeen student was asked about one project. There was some crossover within the Strathclyde projects, with two of the students being interviewed about two different projects that made use of different systems in order to learn how the systems compared, as well as learning about how they worked on their own. Across the five projects, three different systems were used. This meant that as well as looking at how different systems compared, the use made of the same system by different teams could also be examined. In relation to the research objectives set, the interview sessions with individuals were designed to focus mostly on where and when information was stored. The analysis of the file systems looked in far more detail at when information was stored, and also looked at what information was being stored in general, and at specific times.

5.1. Project 1 The first project chosen for the study was part of the Product Development Project (PDP) module at Strathclyde, which is a compulsory module for all 4th and 5th year and Post-Graduate DMEM students. The module involves groups of students working with different external clients to solve an initial design problem, and meet various objectives. This project was for a group of four, and looked at developing a sequential memory unit intended to help improve the physical and neurological fitness of children. The project involved research, specification development, conceptual and detail design, prototyping, and some business recommendations, with some previous research having been carried out. The project ran from 29th October 2008 until 13th May 2009, and included two milestone deadlines on 17th December 2008 and 25th February 2009. Three members of the team were 4th year Product Design Engineering students, while one studied Product Design Engineering with a Diploma in Management, and was also in 4th year. Two members of the team were available to be interviewed for this study, with the other members no longer being present. The team was required to attend a weekly class, when their advisors would meet them to check on progress. Other than this, they would work on the project as and when they could, meaning team members were often carrying out work from different locations and at different times. The Laulima system described below was specified for use as part of this module. Due to the way the system works, only files uploaded by the two remaining team members could be examined for this study. Both team members were interviewed, and file names, types, sizes, and dates uploaded were recorded for all files they uploaded.

5.2. Project 2 The second project was also part of the PDP module. This allowed comparisons to be drawn between how different teams worked and made use of the same system for slightly different projects. The team for this project also consisted of four individuals and looked at the design of protective packaging for glass vials, focusing on creating an environmentally friendly solution and developing a design that could be used both internally and externally by the client company. Research, specification generation,

A. Bennett

20

conceptual and detail design, prototyping, and manufacturing and material recommendations were all included in the scope of the project. This projects timeline was the same as Project 1. Three members of this team were 4th year Product Design Engineering students, and one was a 4th year student studying Product Design Engineering with a Diploma in Entrepreneurship, with three members of the team available to take part in this study. As with Project 1, team members were required to attend a weekly class, but then would also be able to work as they wanted, meaning that they were also working at different times and from different locations. As above, the Laulima system had to be used as part of this class. All three remaining team members were interviewed, but only two file galleries were examined since one team member had never managed to upload any files successfully. The same details concerning files were recorded as in Project 1.

5.3. Project 3 The third project examined was part of the Global Design class within DMEM. This is an elective class taken mostly by 5th year and Post-Graduate students, and looks at educating students in best practices in relation to working in global teams. The team studied was composed of six individuals distributed between Strathclyde University and Swinburne University in Melbourne, Australia, with three team members in each location. One of the Strathclyde team members was also part of Project 1 of this study. The project brief was to design a coffee cup holder that could carry multiple cups at once, with both teams starting work, the Australian part of the team carrying out detail design and the Scottish part of the team carrying out prototyping. This was the shortest project included in the study, running from 5 th to 26th October 2009. The system specified for use in this project was Google Documents, but the team actually used Google Groups as it fitted their needs far better. It was also specified that this was to be the only communication method used. Due to how this system works, all files and details relating to the project could be recorded for inclusion in this study. Two members of the Strathclyde part of the team were also interviewed to gain their opinions on the project and the system used.

5.4. Project 4 This project was carried out as part of the Advanced Product Design Engineering class within DMEM at Strathclyde, a compulsory class for 4th year MEng students, and an elective class for other 4th year and PostGraduate students. The brief for this project was to design and prototype a smart electric wheelchair, with a team of 15 people split down into three sub-teams to work on the frame, drive and control systems. Between the three sub-teams all stages of a design project were covered, from an initial brief to prototyping, detailed design, and manufacturing recommendations. The project ran from 6th October 2008 to 30th March 2009, with an interim deadline on the 8th December 2008. Unlike the other projects examined, no specific storage system was specified for use during this project, but the group decided that a Google Group should be used to store and share files. As with Project 3, the Google Group system allowed examination of all files that had been uploaded, not just those uploaded by the team members interviewed. As well as this examination, two members of the frame team were interviewed for the study, one of whom was also part of Project 2. The sub-teams and individuals were mostly distributed in terms of location rather than time in this project, with different people working in different places depending on what they were prototyping or designing.

A. Bennett

21

5.5. Project 5 This project was the only one examined that was based entirely outwith Strathclyde University. It was part of a 3rd year Integrated Studies module taken as part of an Architecture degree at Aberdeen University. This was a three-week project in inter-disciplinary design, looking at designing a gallery space at Castle Fraser in Scotland, and involved conceptual design, client presentations, and costing. The team consisted of 15 individuals in total, split between architecture, project management and quantity surveying degrees. No specific file storage system was used as part of this project, with the university instead providing space on its server to store files so that others could access them. However, this could only be accessed while on campus, and not from any internet connection. Due to the person interviewed having graduated, the file system could not be accessed and analysed for this project, so this project could only provide details on the subjects thoughts on the system in general, and no specifics on how the team as a whole made use of it. The team for this project was distributed both in terms of time and location, with individuals working from various locations and timetables meaning that the whole team could often not meet together.

5.6. File systems The two main file systems that were used in the projects that were examined were Laulima and Google Groups. These are different in many ways, both in terms of the interfaces they use, and the methods of uploading and sharing files. The system used by Aberdeen University was different again, and is also described below.

5.6.1. Laulima The Laulima system is stored on and accessed through Strathclyde University servers. It is based on the TikiWiki system, an open-source content management and groupware web application. It was developed to allow project teams to access and customise their own space within the system, to share files with other team members, and to allow project assessment by tutors. According to the developer of the system, it was never expected to be used as it is, with teams spending a large amount of time working on the design of pages, rather than just using it for file storage and sharing. The back end of the system is based around an SQL database, with teams pages being programmed using one of three options: wiki syntax, HTML coding, or a what-you-see-is-what-you-get editor. The various options available mean the system is incredibly flexible and can be personalised in almost any way. Uploading can be carried out using a file gallery or a Drag and Drop uploader. There are no restrictions placed on the sizes of individual pages within teams areas, or on the number of files that can be linked to. As standard, each user is limited to 200MB of storage at any one time, but this can be increased by the system administrator if necessary. There are no restrictions placed on file types that can be stored, with even files that could pose a security risk (such as .exe and .html) allowed. However, these are modified when uploaded so that they cannot be executed on the server, but can be downloaded and used by others. There are no restrictions on the size of file that can be uploaded, but the system is set to cancel any upload once it reaches a certain amount of time, meaning that video files in particular may not upload successfully.

A. Bennett

22

5.6.2. Google Groups Google Groups is a free tool available from Google that allows members of teams and groups to share files and ideas in an online environment. The system is designed to work across all browsers, with help and support being provided if any issues arise. There are two options available to users in relation to accounts. Those with a Google account, such as for Gmail, can use it to log in, gain full access to pages, and create their own groups. Those without Google accounts can gain access with another e-mail address, but do not have access to all features; they cannot upload files, and cannot create their own groups, but can read posts and download files. Within each group, there are a number of areas that can be changed in relation to the design and different sections that are included. The design changes that can be made are far more restricted than in Laulima, but also far easier to make; a number of options are presented to the user in terms of layout, colour schemes and border types, with some areas such as the colour then being customisable. In terms of file storage, each Group is restricted to a maximum of 100MB of files being stored on the system at any one time, and a maximum file size of 10MB. Although this is the maximum allowable file size, some users have noted that on a slow web connection, an upload can time out and fail without the 10MB maximum being reached. There are no obvious restrictions to the type of file that can be uploaded, with the exception of files such as .exe or .html due to security issues.

5.6.3. Server access and file storage Allowing files to be stored on a particular area of a server is similar to how many file-sharing systems that are commonly used work, but with some major differences. Firstly, you can just drag and drop files on to the server as if it is another folder on your computer, as long as you are connected to the network correctly. An advantage of this system is that unlike the two already mentioned, files can be opened from where they are, either to preview or work on them, meaning that they do not always have to be copied to another computer first. However, this is the extent of this type of systems flexibility, apart from creating subfolders. There are no methods for looking at what revision of a file you are looking at unless it is included in the name, there can be no customisation of the interface, and there are no facilities for talking to or interacting with other team members. Other downsides include that the speed of accessing files in this type of system can be slow depending on who else is accessing the server, and that there can often be no external access, which for Project 5 of this study meant no files could be shared or accessed from anywhere other than the universitys network connections.

A. Bennett

23

6. Analysis The information gathered for this study was broken down and analysed in three ways. Firstly the interviews with each individual were analysed and compared to look for common or contrasting comments, and any general themes. Secondly the file lists and details were analysed for four of the projects to look for identifiable patterns and problems within them. Finally, the file list for Project 4 was studied in more detail to look at exactly what kind of information was stored in the files stored during the project.

6.1. Interviews Semi-structured interviews were carried out with all eight individuals in order to gain feedback on their opinions on the systems they had used and what improvements they thought could be made. A copy of the questions used in each interview can be found in appendix XXXXXXXXXXXXX, and below are summaries of the answers given, with interesting and common points pulled out. When asked where they stored data during these projects, all but one individual noted that they stored information on the specified system, while six participants also kept copies of all their files on USB pen drives. These individuals noted that having copies on a pen drive made it easy to share files with others if they were in the same location, especially for large files. A number of people also shared files by e-mailing them to each other during the projects. When asked whether they always uploaded files or waited until someone else asked for the information, most answered that they would always upload the files, while some participants stated that they would upload most files, especially those that seemed important, but keep some others on their computers until someone asked for them. Everyone interviewed answered that they waited until work was completed before uploading it, as opposed to uploading half-complete files. A member of the Project 2 team commented that this was even true with the teams product design specification (PDS), while a member of Project 3 commented that their PDS was one exception to this, and that they uploaded it at multiple stages. One person commented that they would upload some work when half complete if they wanted feedback or advice from other team members. When asked if people uploaded single files or batches, the most common answer was that it depended very much on what there was at any given time. One person responded that they uploaded in batches to save the pain of having to try to upload more often. The differences between the uploading experiences of the users of Laulima and Google Groups were huge. Those using Google Groups reported absolutely no issues with uploading files, other than reaching their maximum designated space limit at one point. Conversely, those who used Laulima reported a whole series of problems. The most common issues reported concerned stability and speed. A number of participants reported that uploads would often fail, and sometimes even crash their browser. Many also reported that one of the upload methods would sometimes work while the other would not. One of the users stated that uploads failing and crashing at random was par for the course with Laulima, while another stated that they never managed to upload anything successfully, and always had to e-mail files to other group members to upload. The issue of the speed of uploading was also commonly reported, especially with large files. However, in response to being told that many people had reported uploading as being, the system developer stated that it was not the system and server being slow, but issues with too many people trying to upload from the same wireless access point that were likely to be causing these issues. The other common issues reported centred around finding a file again if it had been uploaded using the Drag and Drop facility, and issues with naming files and pages.

A. Bennett

24

The only complaints about using a shared server space were that some larger documents took a long time to store, but all smaller documents were fine. When asked if they generally uploaded files at a specific time of day, most people responded that they usually uploaded whenever they were working on the projects, which varied hugely. The members of the Global Design team noted that they would always upload in time for the start of the Australian working day, in order to allow work to progress. Concerning ease of use, Google Groups once again came out as being far superior to Laulima in many areas. The biggest issue with Laulima compared with Google Groups was that of the programming that was needed in order to create and customise pages, and the lack of guidance and teaching that was given on this. The fact that Google Groups is graphical and generally easier to use seemed to count in its favour. The shared server space was incredibly easy to use, due to the standard file interface of an operating system and lack of other features to cause problems. Many of the Laulima users reported that, looking back, the system was far easier to use towards the end of projects, once they were more familiar with how it worked, but that there was a very steep learning curve at the beginning. This was due in part to being thrown in to using the system with no real teaching on how to carry out the necessary programming and coding to achieve what they were being asked to do. In relation to accessing shared files, the biggest issue with Laulima was in relation to setting permissions correctly, partly due to these being set differently as default depending on which upload method was used. The only issue with Google Groups was finding the correct files due to all being displayed in one list, and there were no issues with the shared server space. There were no complaints in relation to the speed of navigating about the various Google Groups pages from any of the users. The only real complaint from the Laulima users was that at peak times of use, the system could be very slow when attempting to do anything, with it sometimes just stopping and not loading pages. There were once again no issues with using a shared server space, since there were no pages to navigate, only folders. Looking at the flexibility of the systems, Laulima users agreed that the system could be incredibly flexible, but only if you knew what you were doing, and how to program it. Other than the main navigation menu situated at the top of each page and the Shoutbox located at the side, which were both fixed for all users, all other details of teams pages could be changed as desired, as long as they knew the correct code. The Google Groups pages were not nearly as flexible in terms of appearance or layout, but any changes to be made were carried out using a graphical user interface, meaning that no specialist knowledge was needed and the changes could be completed almost instantly. Using the shared server space, there was no flexibility since files were displayed in folders within the users operating system. On Laulima and Google Groups, only image files could be viewed online, with all others having to be downloaded. On Laulima, many teams worked around this by embedding text from word processing documents in to a page, rather than uploading the document. With Google Groups, it was expected that crossover with Google Docs could be used to view and edit other files online, but this was not the case. Using the shared server space, all files could be opened from where they were stored, but this could be slow depending on the server load. A number of suggestions were made in relation to improving the systems. The main improvements suggested for Laulima were based on standard page templates being available, the user interface for editing being greatly improved and the permissions system being simplified. For Google Groups, the main suggestions were to incorporate some sort of file hierarchy, and to integrate other Google services to allow online editing and collaboration. For using a shared server space, access to files outwith an institutions network was suggested as a major improvement.

A. Bennett

25

6.1.1. Conclusions One of the main conclusions from the interviews was that many people are not aware of what can actually be achieved using the various systems. Another fact that came out was that users far preferred systems that were based on graphical interfaces for making changes to pages as opposed to pages that needed programmed, despite losing some flexibility. Almost all individuals stated that they would often share files by e-mailing them to other group members rather than uploading them to the system they were using, and that they would often transfer files using USB drives when in the same location, as this saved time and was better for larger files. Looking at when files were uploaded, people answered almost unanimously that they would wait until files were finished before uploading them. There were no conclusive results relating to when in the day people would upload files, or whether they would upload single files or batches. For both of these areas, it very much depended on when they were working on the project, and how many files were being generated. Finally, the Laulima and Google Groups systems both presented issues in relation to uploading and sharing files. With Google Groups, the main issue was finding files once uploaded due to the organisational issues, while Laulima presented issues in relation to getting files on to the system, as well as having to set the permissions correctly. This was one area where using a shared space on a server to share files came out on top, due to the simplicity of this method, and the ability to organise files quickly and easily.

6.2. File inspection For Projects 1 and 2, details were collected from two individuals, while for Projects 3 and 4 details were collected of all the files that had been uploaded to the systems used, as long as they had not been deleted again. The files for all four were sorted to display the file name, file type, who had uploaded them, their size, the date uploaded, and, where possible, the stage of the project they related to. Once initially organised, the file details were examined in a number of other ways: 1) By who uploaded: How many files each person had uploaded, both in total and of each file type. 2) By file type: The numbers of each file type uploaded, the maximum, minimum, total and mean average sizes of file type, and what percentage of all files they made up. 3) By project stage: The numbers of each file type in each stage, the total size of files in each stage, the percentage of all files in each stage, and the earliest and latest dates files were uploaded relating to each stage. As well as carrying out analysis on each project individually, file details were also organised and compared across all four projects. This was done based on when files were uploaded, what types of files were uploaded and what stages files were uploaded for, with the latter two being broken down into numbers of files, file sizes, and percentages of total files.

6.2.1. Project 1 The most obvious point from looking at these files was a complete lack of the use of naming conventions. A large percentage of files were images that had either been left with the names allocated by the device used to create them, renamed along the lines of Picture 1, or were untitled and assigned general names by the system when uploaded. Another point that stands out is that the two individuals interviewed only uploaded three different file types; JPEGs, PDFs and GIFs, as can be seen in Figure 2. No word processing documents were uploaded, as these were embedded into pages instead so they could be viewed online, but no CAD files or presentations were uploaded either. There was also a big difference in the number of files uploaded by each person, with one uploading nearly three times as many as the other.

A. Bennett

26

Figure 2 Project 1 File Types and Amounts

Of the files uploaded, nearly all were JPEGs, and nearly all that could be identified fell into the concept or prototyping stages. However, due to the naming that had been used, the stages into which most files fitted could not be identified. The dates of uploading showed that groups of files were often uploaded on a certain day followed by a gap, as opposed to fewer files being uploaded far more regularly. The file lists also revealed a number of instances of double uploading within this project. Although the details collected did not reveal if there had been any changes made to files, there were a number of times when files of the same name, format and size had been uploaded twice on the same date. A possible explanation is that they had been uploaded using the Drag and Drop feature on Laulima, and then could not be found, so were uploaded again. Due to the large number of unidentifiable files, a timeline of when stages started and stopped could not be fully constructed. However, the files that could be identified into certain stages ran in a good order, with no overlaps between different stages.

6.2.2. Project 2 Unlike Project 1, the naming conventions used as part of this project were far clearer, and gave a far better understanding of what was contained within a file. JPEG and PDF files were by far the most commonly uploaded, but there was a wide range of file types used, including other images, word processing documents and presentations, as can be seen in Figure 3. For both the word processing and presentation documents, both Microsoft Office 2003 and Microsoft Office 2007 versions were used at different points, with the file sizes of the different versions varying quite dramatically. There were also very few word processing documents, as the team often saved files as PDFs in order to avoid any compatibility issues.

A. Bennett

27

Figure 3 Project 2 File Types by Stage

In this project, more files were uploaded during the concept and research stages than in others, and there were no files uploaded for any stages after conceptual design. As with Project 1, multiple files were often uploaded at once, although this project showed more instances of single files being uploaded. The numbers of files uploaded by each individual was far closer for this project, with the individual who uploaded slightly fewer files overall actually uploaded more in terms of file sizes. Again, there were a number of instances of files being double-uploaded, but a full explanation for this is once again lacking. In relation to when files were uploaded, neither of the individuals interviewed uploaded anything after the second milestone of the project. The stages of the project were also not as well defined as in Project 1, an example of which is the project plan files being uploaded in the middle of the research files.

6.2.3. Project 3 In this much shorter project a number of differences and similarities can be seen with the other projects. Looking firstly at who uploaded data, the numbers of files uploaded were fairly consistent across the team, with one individual uploading far more files, and one uploading slightly fewer. JPEGs were by far the most common file type, as can be seen in Figure 4, with one or two files of many other types also being uploaded. In total, more JPEGs were uploaded than all other file types combined during the project. Most of the files that were not JPEGs were either word processing documents, spreadsheets or presentations, and were a mixture of Microsoft Office 2003 and 2007 versions. Looking at the different stages of the project, the conceptual design stage contained far more files than any other, accounting for half of all files uploaded. All of these files were either JPEGs or image-based PDFs, with no text-based documents. Other than the research stage, very few files were uploaded, showing either that the system was under-used to share files, or that far fewer files were actually produced than might have been expected. Examining the project timeline and what files were uploaded when revealed a number of things. Firstly, specification files were all uploaded on the same day, meaning that despite there having been some revisions, none were made after the conceptual design stage had started. There was also a lot of crossover between different stages, with research and concept files being uploaded until almost the same date. Overall, far more files were uploaded towards the start of the project than at later stages, with over twothirds of files being uploaded within the first third of the project.

A. Bennett

28

Figure 4 Project 3 File Types and Amounts

Overall, file naming conventions used for this project were quite helpful, and gave a good indication of what each file contained. There were no examples of double-uploading during this project, either as it did not happen due to the simpler uploading system in Google Groups, or because it was easier to notice and delete duplicates.

6.2.4. Project 4 This project contained some of the best and worst examples of file naming. Most of the file names gave a good indication of what stage of the project they fitted into, and sometimes suggested what the file contained. However there were other files such as one named simply g that gave no indication of what they related to. Although there were some examples of files being uploaded with the same name, they were not actually the same file, as had been experienced while examining the other projects; there were in fact no examples of double uploading the same file in this project. In this project single files were often uploaded, meaning that there were far more days when files were actually uploaded. The uploading of meeting minutes as distinct files was unique to this project, since they could not be embedded in the system. Studying the minutes uploaded showed that minutes were taken regularly both by the whole team, and by sub-teams. However after a little more than a quarter of the project, no more minutes were uploaded to the system. The specification stage of this project contained far more files than the other projects studied, and these were uploaded over a relatively long period of time. The concept stage also lasted a long time, with files being uploaded for this from a little over a month after the start of the project up until almost the end. As well as spanning the longest time, the concept stage also contained the most files, although not by as clear a margin as in other projects. As Figure 5 shows, the concepts stage once again contained the most files, although the research stage and minutes were close behind. There was also a wider spread of file types within each stage of the project than in any other project.

A. Bennett

29

Figure 5 Project 4 File Amounts by Stage

Looking at the types of file uploaded, word processing documents were by far the most common, with over twice as many as there were images. There were also far more CAD files shared during this project than in any other, with many of these being shared within ZIP files in order to allow whole assemblies to be uploaded. Many of the file types that were used during the project, such as TXT and GIF files, were only used once, or only in one stage of the project, as shown in Figure 6. Looking at the project timeline, there were far more files uploaded towards the start of the project than towards the end, with large gaps in the middle. Looking at when files were uploaded for different stages shows that the embodiment stage overlapped quite significantly with both the concept and prototyping stages of the project. One likely explanation for this is that the three sub-teams were working on slightly different stages at different points, and therefore uploading information relevant to different stages. Finally, there was a large variance in the numbers of files uploaded by different individuals. Team members took turns keeping minutes, and therefore all uploaded word processing files, while many other file types were only uploaded by one individual. Two of the team uploaded far more files than others, while others contributed minutes and nothing else.

Figure 6 Project 4 File Types by Stage

A. Bennett

30

6.2.5. Comparative analysis Data collected for these four projects was compared in three ways: on the projects overall timelines; on the file types uploaded; and on the stages involved in each projects. In order to compare the timelines of the projects, file uploads were graphed according to date for each project, and then presented alongside each other. For the stages and file types, calculations were carried out to find the numbers of files, sizes of files, and percentages of total size made up from the different stages and file types. This allowed patterns and similarities to be noticed between the four different projects, or to see if there were in fact no patterns. Tables 2 and 3 were created to show this data. Starting by looking at the file types uploaded across the different projects, JPEGs and PDFs were by far the most common file format in terms of number of files uploaded. Word processing documents were numerous for one project, but not for the other three, probably due to the type of project, or text being embedded in the Laulima system. Looking at the total file sizes of different types, JPEGs again came out as generally having the greatest total file size. Unlike the numbers of files, presentations also rate highly in terms of total file sizes within the projects they were uploaded for despite very few individual files being uploaded. When used, ZIP and RAR files also sum to have large total file sizes, due to the types of files included in these. Although word processing documents show as being common in one project, and occurring a few times in others, the total file sizes were very low due to what they contained. When the percentages of the total file sizes for each project were considered, JPEGs, PDFs, ZIPs and presentations generally came out highest. Individual CAD files made up almost none of either the total file sizes or percentages of files, but ZIP or RAR files containing CAD data made up a significant amount when utilised.

Table 2 File types sorted by number of files, total sizes in kB, and percentages of total space
Project PDP1 PDP2 APDE Global Design Project PDP1 PDP2 APDE Global Design Project PDP1 PDP2 APDE Global Design Project PDP1 PDP2 APDE Global Design Project PDP1 PDP2 APDE Global Design Project PDP1 PDP2 APDE Global Design .asm .doc 0.38 5.35 3.69 .prt .docx 0.87 0.036 0.22 .psd 15.75 0.187 18.83 Sizes .asm .doc 447.59 3741.2 1746 .prt .docx 1024 25.1 102 .psd 18616.32 131.1 8908.8 .asm .doc 2 25 4 .prt .docx 1 1 1 .psd 1 1 1 .rar 2 2 1 .txt Numbers of .drw .gif 2 .rar 10444.8 14848 11.5 .txt .drw .gif 10.12 .jpg 30544.16 17670.57 6162.4 30428.1 xlsx .pdf 368.47 29477.97 7508.2 540.9 .zip .ppt 29948.17 5427.2 Other .rar 8.84 21.232 0.016 .txt Percentages .drw .gif 0.03 .jpg 98.78 14.95 8.812 64.32 xlsx .pdf 1.19 24.94 10.736 1.14 .zip .ppt 25.33 11.47 Other

0.218 .pptx 8.96

0.003

0.103 0.02

51.594

1.713 0.3

TOTAL 100 100 100 100

152.2 .pptx 10588.16

2.2

72.2 11.5 .jpg 88 15 7 26 xlsx

36081.5

1197.9 144.1 .ppt 3 1 Other

TOTAL 30923 118218 69934 47309

1 .pptx 1

.pdf 4 12 11 5 .zip

2 1

2 3

TOTAL 94 37 63 42

A. Bennett
Table 3 Project stages sorted by number of files, total sizes in kB, and percentages of total space
File percentages Minutes Planning 0.9 0.92 0.583 Deliverables 0.29 Presentations 21.36 32.806 1.812 0.89 Brief 214.99 3825.15 447.59 407 1990.7 Concept 438.61 17830.84 21676.6 26483.3 Team 1 3 4 Concept 18 10 18 21 Embodiment Prototyping 684.62 1265.5 295.2 Brief 7 2 2 13 Embodiment Prototyping 15 3 2 Deliverables 3 Presentations 4 7 File numbers Minutes Planning 1 4 Deliverables 89.66 Presentations 14259.18 22915.4 File sizes Minutes Planning 278.81 612.19

31

Project PDP1 PDP2 APDE Global Design Project PDP1 PDP2 APDE Global Design Project PDP1 PDP2 APDE Global Design Project PDP1 PDP2 APDE Global Design Project PDP1 PDP2 APDE Global Design Project PDP1 PDP2 APDE Global Design

Team 0.18 29.04 5.98 Concept 1.42 26.72 31.033 79.4 Team 55.95 19384.07

Site 0.69 5.73

Brief 0.67

Embodiment

Prototyping 2.21

Research Specification 0.11 12.95 2.61 7.123 0.932 8.63 5.1 Unknown/Other TOTAL 94.2 100 100 25.712 100 100 Research Specification 33.48 8641.74 1741.48 4975.3 651.1 2873.3 1699.8 Unknown/Other TOTAL 29161.89 30958.01 66742.24 17960.2 69851.1 33342.3 Research Specification 2 9 3 12 5 12 3 Unknown/Other TOTAL 47 94 37 5 63 42

Site

Site

Looking at the files uploaded into different stages of the four projects, there were a number of points that stood out. The first of these was that the research and conceptual design stages generally feature the most individual uploads. Also, despite the four projects entailing mostly the same stages, no files were uploaded for many stages in some of the projects. Across the whole of each project, most files seem to be uploaded into the middle stages, picking up at research and starting to drop off after the conceptual design stage. This does not match up exactly with the total sizes of files uploaded at different stages, although the conceptual design stage file sizes are again quite high. Research files take up a reasonable amount of space compared to some other stages, but nowhere near as much as the concept or embodiment design stages. The small number of files uploaded for presentations show as taking up a large amount of space, no doubt due to the inclusion of many high-quality images. For the project that minutes were kept for, these files took up little space, as did those for many other early stages in projects. When looking at the percentages of the total size made up by files in each stage, the conceptual design stage unsurprisingly once again comes out as being highest for three of the four projects. As with the file sizes, the early stages of the project again came out low compared with other stages, and embodiment and presentations once again come out high.

A. Bennett

32

Looking at the whole project timelines revealed some very interesting trends that occurred within the projects. It was visually obvious that in each project there was a point about a third of the way through when there was a big drop off in terms of uploading, and that in some there was a distinct period of uploading around the middle, and then another towards the end of the project. Once these definable periods of uploading had been identified, they were measured to see what percentages of files were uploaded into each period. The results of this can be seen in Table 4. As can be seen, this reveals no patterns, other than the figures for Period 1 of Projects 3 and 4 being relatively close. Since this did not reveal anything, the details were then examined to show at what percentage of the way through each project these different periods started and stopped. These results are shown in Table 5, and show more concrete results. The first interesting point is to note the times at which the first period of uploading concluded. Three of the four projects are within 1.7% of each other, and ran over a time period when a difference of a day would change this result by around 0.55%, meaning the times spent on this first period were almost identical. The result for Project 3 is slightly higher than the other three, but since this was a short project, a difference of one day would change this result by around 4%, meaning the duration of this period was similar. The only other pattern to emerge from this was that period 2 of uploading started around the same time for three of the four projects; that is within 2.8% of each other. The other project did not have a second period of uploading as such, just a single file uploaded in the middle. The only other conclusion that can be drawn from this is that there are large percentages of time in each project when no files are being uploaded and shared. Another area examined across all four projects was whether or not certain project stages consistently fell within certain parts of the timeline; for example, if the concept stage always started between 35 and 40% of the way through the project. To do this, the diagrams in Figure 7 were examined. One of the most immediate issues was that despite starting and finishing with, and including many of the same stages, the files that were uploaded did not relate to some of these stages. The stages that were included in each project were examined anyway, but no similarities were found between them, showing that design projects are generally flexible and fluid, with stages differing in length depending on the particular design task. Despite the previous examination not discovering any repeatable results, it was found that for each stage, there was often a core set of files uploaded at roughly the same time, with some satellite files relating to that stage being uploaded either far earlier or, more commonly, far later.

Table 4 Percentage of total uploads in each period

Project Project 1 Project 2 Project 3 Project 4 Period 1 Uploads 43.6% 64.9% 78.6% 74.6% Period 2 Uploads 43.6% 35.1% 16.7% 1.6% Period 3 Uploads 12.8% N/A 4.7% 23.8%

Table 5 Percentage through project of periods of uploading

Project Project 1 Project 2 Project 3 Project 4 Period 1 Start Period 1 End Period 2 Start Period 2 End Period 3 Start Period 3 End 0% 31% 52.1% 63.4% 99% 100% 0% 30.2% 54.9% 63.4% N/A N/A 0% 36.7% 52.4% 71% 90% 100% 0% 31.9% 76.4% 76.4% 87.5% 100%

A. Bennett

33

Project 1
Start Milestone 1 Milestone 2 End

Team Site Planning Research Concept Prototyping Deliverables Unknown Team Site Planning Research Concept Brief Presentations Specification Start Milestone 1 Milestone 2 End

Project 2

Project 3
Start End

Team Specification Research Concept Prototyping

Project 4
Start Interim Presentation End

Minutes Research Concept Prototyping Embodiment Specification

Figure 7 Project Timelines Showing Uploading Periods for Each Stage

6.2.6. Conclusions The most obvious conclusion from studying the files uploaded for each project was that there were no standard naming conventions used, and that naming practices were awful for most of the files involved. This meant the contents of files and where they fitted in a project could generally not be determined from the file names alone. It also emerged that systems where links to files are displayed on pages rather than the main file gallery itself often seem to include far more instances of files being double uploaded. In terms of file types, images are by far the most commonly uploaded files, especially JPEGs, generally account for the most files, and the biggest total file sizes within projects. In projects using Google Groups, word processing files were reasonably common too, but in projects using Laulima these were very rare, as teams embedded the text on pages rather than uploading the files. Very few CAD files were uploaded in three of the projects, with only Project 4 showing a reasonable number being uploaded. Looking at the different stages of projects showed that the conceptual design stage within each project contained the most files, generally both by numbers and sizes. It also showed that there was often not a clear distinction between stages starting and finishing, with there generally being a core time for files being uploaded, and then satellite files for that stage being uploaded far earlier or later. Finally, regardless of the duration of stages involved, each project examined showed a drop off in uploading roughly a third of the way through the project timeline. Some of the projects also showed a distinct middle period of uploading, but there were no conclusive start or end points for this.

A. Bennett

34

6.3. In depth file analysis One of the main points that was discovered from the file analysis carried out for the four projects was that the naming conventions used were generally not particularly helpful, and the names did not give a description of what the files actually contained. Sometimes the file types could be used to give some indication, but often this still did not fully explain what information was being presented. In order to discover more details about what information was being examined, it was decided to examine the projects in more detail, by looking at the individual files that were uploaded. Ideally, all four projects would have been examined in detail, but due to time and access restrictions, only one could be. Project 4 was chosen for a number of reasons: 1) Since the project made use of Google Groups, all the files could be accessed. 2) Many different file types were uploaded during the project, including CAD files that were not present in other projects. 3) The project included examples of both very good and very bad file naming. 4) The wide range of activities involved in the project meant many different types of information were produced. 5) Access could be gained to download and examine each file individually. Once selected, all the files that had been stored during this project were downloaded from the Google Group and individually studied. The details included within each file were categorised in two ways. The first looked at the information presented in each file in general, whether or not this clearly linked the file to a particular stage in the project, and whether this link was clearer than that initially presented by the file name. The second method looked at classifying the information presented under a number of standard headings that could be applied to the file lists for any project, with the intention that these headings could be specific enough to accurately show what information was included in a file, yet general enough to apply to a wide range of design projects. After examining the files in terms of the project stage they fitted into, little extra information was learned than could be seen in most of the file names, although some, such as the file named g, became clearer once examined. Looking into the types of information being presented in the different files revealed much more than looking at the project stages did. After examining each file, 16 headings were created to classify the types of information being presented: A - Text B - Numerical C - Image D - Visual E - Geometric F - Dimensional G - Functional H - Feature I - Links and References J - CAD Parts K - CAD Assemblies L - CAD Drawings M - Evaluation N - Branding O - Materials P - Manufacturing

Once these classifications had been created, each file was marked according to which of these it contained. The information map that this created can be seen in Figure 8. The 16 different headings are not exclusive, and can be broken down into further groupings. The text, numerical, image and visual headings all group together well, and describe certain aspects of a file. The other obvious groupings are the geometric and dimensional headings, and the three CAD headings.

A. Bennett

35

File Strath logo Meeting minutes week 2 Frame team - market research Drive team - castors Drive team - general research and wheels Control Team Wheelchair research GL Meeting minutes week 3 Control Team Wheelchair Research AB Control Team Wheelchair GPS article AB Drive Team Research Drive Team Choosing a powered wheelchair Drive team - Intellwheels Drive team - research and motor specs Frame team - examples Meeting minutes Week 4 Frame team meeting minutes week 4 Class brainstorm Control team research MB Control team - Design criteria MB Drive team minutes week 4 Meeting minutes week 5 PDS Competitor research AB PDS Version 1.1 Meeting minutes week 6 Frame brainstorming Drive brainstorming PDS Version 1.2 PDS Version 1.3 Meeting minutes week 7 Frame team minutes week 7 Frame week 7 functions Meeting minutes week 8 Frame brain session Drive team brainstorming outcomes AC Drive team brainstorming post its Frame group chosen focus points Meeting minutes Frame group function block diagram Control brainstorm Control function tree Meeting minutes week 9 Frame team minutes week 9 Highlights PDS sections for Frame Drive team function mean tree Pic 012 Final concept sketches - frame group Control function means tree New concept.jpg Assembly Fixed final wheelchair Assembly purged Final assembly PROTO Assembly From Liam and India Sketching 2 Proto g Exploded iso proto assembly Framegroupdraftfolio Wheelchair contest

Figure 8 Categories of Information Contained in Project 4 Files

6.3.1. Conclusions There were three main outcomes from this in-depth examination of the files within this project. Firstly, it is far easier to know what a file contains by seeing which of the 16 headings it relates to than by looking at the file name alone. Secondly, there is a noticeable shift from files containing text to being more imagebased at a certain point in the project; for this project, this was around the detail design stage. Finally, it can be seen that far more files contain information relating to the first eight categories than the last eight.

A. Bennett

36

7. Discussion and conclusions 7.1. Discussion The aim of this research study was to investigate information-sharing practices in distributed team-based student project work, with a specific focus on where and when information is stored and shared, and what that information is. In order to achieve this, five projects were chosen to be studied, four of which were based within Strathclyde University, and one that was based within Aberdeen University. In order to collect data, interviews were carried out with individuals from all five projects, and full or partial file details were collected for four of the projects. Both sets of information were then analysed tabularly in order to look for patterns and trends within the data. A number of different approaches were used as part of the study in order to try and maximise the validity and accuracy of the information gathered and the results produced. Firstly, in order to ensure that the data collected was valid, only individuals that had recently completed projects using information sharing and storage systems were interviewed, meaning they had first hand experience of the research area. In order to ensure the results gained were repeatable, triangulation was used in two ways. Firstly, multiple members of each project team were interviewed in order to ensure the views and opinions being collected were balanced and accurate, and not just the views of one team member that others did not agree with. Secondly, two examples of each file system studied in detail were examined in order to ensure that any patterns or findings from one project could be backed up or proven to be anomalies by another. Finally, reliability of results was maximised both through triangulation as already discussed, and by not carrying out any complex data manipulation, but examining details in their simplest form in an attempt to not create findings from nothing. When the research was being designed, three measures of success were set out for the case studies: 1) Is there consistency in the views and data collected? 2) Are there enough samples, and are they varied enough? 3) Are there clear patterns and trends that emerge from the data without complex data manipulation being carried out? Relating to the thoughts and opinions collected through interviews, there was definitely a high level of consistency within the data collected in relation to each of the systems used. There was also a level of consistency across the data that was collected relating to the file systems for the four projects examined. In terms of the numbers of samples, the numbers of individuals interviewed provided a relatively high number of in-depth samples, but the number of file system examination samples could have done to be higher in order to draw more conclusive results. Relating to the third measure, the patterns and trends that were drawn out of the data were those that were either immediately or relatively obvious, and did not require complex manipulation to discover. Overall, this means that the case studies carried out were mostly successful and valid, but contained some areas that could have been improved upon to produce more concrete results. There were three main limitations within this project. The first of these was that for the projects that made use of the Laulima system, only files uploaded by the students who were interviewed could be examined, meaning the file lists and timelines for two of the projects were not fully accurate or complete, instead only showing files from certain individuals. While this would probably be indicative of the behaviour of the other team members uploading habits, this cannot be verified. The second limitation was the number of projects for which the file systems were studied, and that could be studied in detail as Project 4 was. The final limitation was the number of different file systems that were examined. Examining four projects that all used different systems would have brought a wider variety of results, but the choice was made to instead look at two examples of each system in use to provide more reliable results. Overall, the study was successful in relation to the research objectives that were initially set out. Insights were gained into where and when information is stored, and what information it is that is stored in distributed team-based student projects, allowing suggestions to be made into what could be changed and improved in relation to these areas.

A. Bennett

37

7.2. Contribution to knowledge The literature review that was carried out showed that few authors had looked in detail at where people stored information during distributed team-based projects, and no authors were found that had looked into what information was stored and when. As a result of this lack of previous studies, there were some gaps in knowledge surrounding where information was actually stored during projects, and complete gaps in relation to what was being stored, and when in projects it was being stored. As a result of the knowledge gaps in relation to the specific research objectives, the knowledge that was generated as part of this study all adds to what is already known, as opposed to confirming or extending previous hypotheses. The new knowledge can be split into two main areas: knowledge created from interviews, and knowledge created from file system investigation. The new points of knowledge are: Based on interviews: 1) Most users are not aware of all the features actually available in file-sharing systems. 2) Users will happily sacrifice system flexibility in order to improve ease of use. 3) Team members will often share files via e-mail or USB drives due to the ease of this compared with logging on to a separate system. 4) Users will wait until finishing and revising a document before uploading it as opposed to making it immediately available to others. 5) Permissions issues to access files are the single biggest issue when sharing files between team members. 6) Access to systems outwith educational institutions is vital in order to allow effective work to be carried out. Based on file system investigation: 7) No standard file naming conventions are used within a large percentage of projects. 8) Systems where the file lists are not immediately viewable are prone to double-uploading of files. 9) Full details of the information contained within a file can rarely be determined from the filename alone. 10) Classifying the information contained in a file under a set of standard headings makes it far easier to find the desired file within a project. 11) Image files are the most commonly uploaded and shared during projects, while CAD files are rarely shared online. 12) The conceptual design stage of a project generally accounts for the most files being uploaded. 13) There is often a core group of files uploaded around a certain time for each project stage, with other satellite files being uploaded far earlier or later. 14) There is a distinct drop-off point around a third of the way through projects where files stop being uploaded for a period of time. 15) There are no consistencies in the start and end times of project stages in different projects. These findings are all based on team-based design projects using information-sharing systems within an educational setting, but may also hold relevance within other settings. Points 1-10, 13, 14 and 15 may well be applicable to team-based projects of all kinds that make use of information sharing systems, while points 11 and 12 are specific to design projects. It is quite possible that many of the points are specific to projects being carried out with Strathclyde University, and the Department of Design, Manufacture and Engineering Management specifically, since this was the main area of research. However, it is likely that many of the points, especially those that arose from the interviews, will be applicable as much wider theories.

A. Bennett

38

7.3. Practical implications and recommendations Based on the new knowledge that has been discovered during this study, a number of recommendations have been developed for both teaching in relation to the use of information-sharing systems, and future system development. Many of the system development recommendations relate directly to the Laulima system used within Strathclyde, while others are general to all systems. Teaching recommendations: Providing better training on how to use complex systems, including programming, so that all team members will be able to make changes to the system, rather than just one or two individuals within each team. Introducing and encouraging better file naming practices to aid other team members and assessors in knowing what a file contains, and to generally help find files on a system once uploaded. Encouraging uploading of files rather than e-mailing or other methods, especially if work has to be uploaded for assessment anyway. Stressing that files should be generated and uploaded on an ongoing basis throughout projects, and that there should not be regular drop-offs and periods of time when no new files are added to systems. Including more regular checks from supervisors that files are being uploaded and shared continually throughout projects in order to encourage continual uploading. Providing standard templates to allow students who cannot program pages to still be able to produce useful and attractive sites. Moving from programmable pages to a graphical user interface for making changes. Simplifying the permissions system so that sensitive files are still secure, but easier for whole teams to access. Including a report issue button so that the developer is notified when a problem is discovered. Including a method to identify instances of double-uploading, alerting the user and presenting them with options to keep or remove the files in question. Adding facilities to view, embed and edit more types of file online, either individually or collaboratively, to save files being downloaded, edited and re-uploaded. Including the ability to add tags to a file when uploading to show what stage of a project it relates to and what types of information are contained. These could be based on the 16 areas identified in the in-depth file analysis, allowing other users to easily identify what is within each file more accurately than by the filename itself.

Laulima system development recommendations: -

General system development recommendations:

These recommendations are intended to prepare individuals better for using information-sharing systems both within an educational context and an industrial setting, and to make the systems themselves easier to understand and use for all members of teams.

A. Bennett

39

7.4. Future research Based on the new findings, there are a number of recommendations for future research that could be carried out. Firstly, data could be gathered from a much wider range of projects that make use of different information-sharing systems. This data could be examined to see if it matches the uploading patterns noted in this study, and to verify the other findings relating to files being uploaded. Wider research could also be carried out into the categorisation of the different types of information stored within files for different types of project, in an attempt to refine the list of 16 categories produced in this study. Finally, research could be carried out into developing systems in order to produce a system that would maximise flexibility and adaptability while maintaining a simple graphical user interface that would require little or no expertise to use.

7.5. Personal reflection Overall this study helped to provide a greater insight into the approaches teams take to sharing information in distributed team-based student project work, in terms of when and where information is stored, and what that information is. This has allowed a greater personal understanding of the area, the production of a number of findings that contribute to knowledge in the area, and a number of recommendations that could be used to solve the problems that were discovered during this study.

A. Bennett

40

References Alge, B J., Wiethoff, C. and Klein, H J. (2003) When does the medium matter? Knowledge-building experiences and opportunities in decision-making teams, Organisational Behaviour and Human Decision Processes, vol. 91, pp. 26 - 37 Anumba, C J., Ugwa, O O., Newnhorn, L. and Thorpe, A. (2001) A multi-agent system for distributed collaborative design, Logistics Information Management, vol. 14, no. 5/6, pp. 355 - 366 Ardichvil, A., Page, V. and Wentling, T. (2003) Motivation and barriers to participation in virtual knowledge sharing communities of practice, Journal of Knowledge Management, vol. 7, no. 1, pp. 64 - 77 Baker, G. (2002) The effects of synchronous collaborative technologies on decision making: A study of virtual teams, Information Resources Management Journal, vol. 15, pp. 7993 Bakis, N., Aouad, G. and Kagioglou, M. (2007) Towards distributed product data sharing environments progress so far and future challenges, Automation in Construction 16, pp. 586 - 595 Ball, P D., Grierson, H., Minn, J., Jackman, J K. and Patterson P. (2006) Working on an assignment with people youll never meet, International Journal of Engineering Education Baudin, V. and Villemur, T. (2009) Student centred distance learning experiments over a communication and collaborating platform, Interactive Technology and Smart Education, vol. 6, no. 1, pp. 60 - 75 Benford, S., Bullock, A., Harvey, P., Howidy, H., Shepherd, A. and Smith, H. (1993) GRACE: system to support development and use of CSCW applications, Internet Research, vol. 3, no. 1, pp. 25 35 Bouas, K S. and Arrow, H. (1996) The development of group identity in computer and face-to-face groups with membership change, Computer Supported Cooperative Work, vol. 30, pp. 8 - 28 Cai, J., Lu, S C Y., Grobler, F., Case, M. and Jing, N. (2005) Modelling and managing collaborative processes over the internet, Business Process Management, vol. 11, no. 3, pp. 255 - 274 Cappel, J J. and Windsor, J C. (2000) Ethical decision making: A comparison of computer-supported and face-to-face group, Journal of Business Ethics, vol. 28, pp. 95 - 107 Combs, K L. (1993) The role of information sharing in co-operative research and development, International Journal of Industrial Organization 11, pp. 535 551 Connolly, T., Jessup, L M. and Valacich, J S. (1990) Effects of anonymity and evaluative tone on idea generation in computer-mediated groups, Management Science, vol. 36, pp. 689 - 703 Cramton, C D. and Orvis, K L. (2003) Overcoming barriers to information sharing in virtual teams, In Gibson, C. and Cohen, S., "Creating conditions for effective virtual teams" (pp. 21-36), San Francisco, CA: Jossey-Bass Easterby-Smith, M., Thorpe, R. and Jackson, P R. (2008) Management Research, 3rd Edition, ISBN 978-184787-177-0 Elpass, W J. and Hollinger, C. (2004) Design education via collaboration in an advanced knowledge environment, International Engineering and Product Design Education Conference Fan, L Q., Kumar, A S., Jagdish, B N. and Bok S H. (2008) Development of a distributed collaborative design framework within peer to peer environment, Computer-Aided Design 40, pp. 891 - 904 Frank, A. and Mitschang, B. (2002) A customizable shared information space to support concurrent design, Computers in Industry 48, pp. 45 - 57 Gallupe, R., Dennis, A., Cooper, W., Valacich, J., Bastianutti, L. and Nunamaker, J Jr. (1992) Electronic brainstorming and group size, Academy of Management Journal, vol. 35, pp. 350 - 369 Graetz, K A., Boyle, E., Kimble, C., Thompson, P. and Garloch, J. (1998) Information sharing in face-to-face, teleconferencing and electronic chat groups, Small Group Research, vol. 29, pp. 714 - 743

A. Bennett

41

Grierson, H., Ion, W. and Juster, N. (2006) Project Memories: documentation and much more for global team design, International Engineering and Product Design Education Conference Griffith, T L. and Neale, M A. (2001) Information processing in traditional, hybrid and virtual teams: From nascent knowledge to transactive memory, Research in Organisational Behaviour, vol. 23, pp. 379 - 421 Griffith, T L., Sawter, J E. and Neale, M A. (2003) Virtualness and knowledge in teams: Managing the love triangle of organisations, individuals and information technology, MIS Quarterly, vol. 27, pp. 265 - 287 Gupta, A., Mattarelli, E., Seshasai, S. and Broschak J. (2009) Use of collaborative technologies and knowledge sharing in co-located and distributed teams: towards the 24-h knowledge factory, Journal of Strategic Information Systems 18, pp. 147 - 161 Herder, P M. and Sjoer, E. (2003) Group based learning in internationally distributed teams: an evaluation of a cross-Atlantic experiment, Frontiers in Education Conference Hinds, P J. and Weisband, S P. (2003). "Knowledge sharing and shared understanding in virtual teams", In Gibson, C. and Cohen, S., "Creating conditions for effective virtual teams" (pp. 21-36), San Francisco, CA: Jossey-Bass Hooff, B. and Huysman, M. (2009) Managing knowledge sharing: emergent and engineering approaches, Information and Management 46, pp. 1 - 8 Huang, C J., Trapper, A J C. and Yao, Y H. (2006) Developing an agent-based workflow management system for collaborative product design, Industrial Management and Data Systems, vol. 106, no. 5, pp. 680 - 699 Jarvenpaa, S L. and Leidner, D E. (1999) Communication and trust in global virtual teams, Organisational Science, vol. 10, pp. 791 - 815 Kamel, N N. and Davison, R M. (1998) Applying CSCW technology to overcome traditional barriers in group interactions, Information and Management 34, pp. 209 - 219 Kern, E M. and Kersten, W. (2007) Framework for internet-supported inter-organisational product development collaboration, Journal of Enterprise Information Management, vol. 20, no. 5, pp. 562 - 577 Kim, K Y., Manley, D G. and Yang, H. (2006) Ontology based assembly design and information sharing for collaborative product development, Computer-Aided Design 38, pp. 1233 - 1250 Leenders, R T A J., Engelen, J M L. and Kratzer, J. (2003) Virtuality, communication and new product team creativity: a social network perspective, Journal of Engineering and Technology Management 20, pp. 69 92 Leinonen, P. and Bluemink, J. (2007) The distributed team members explanation of knowledge they assume to be shared, Journal of Workplace Learning, vol. 20, no. 1, pp. 38 - 53 McDonough III, E F., Kahn, K B. and Barczak, G. (2001) Investigation of the use of global, virtual and collocated new product development teams, Journal of Product Innovation Management 18, pp. 110 - 120 Martins, L L., Gilson, L L. and Maynard, M T. (2004) Virtual teams: what do we know, and where do we go from here?, Journal of Management 30, pp. 805 835 Mitschang, B. (2003) Data propagation as an enabling technology for collaboration and cooperative information system, Computers in Industry 52, pp. 59 - 69 Monplaisir, L. (1999) An integrated CSCW architecture for integrated product/process design and development, Robotics and Computer-Integrated Manufacturing 15, pp. 145 - 153 Riopelle, K., Gluesing, J C., Alcordo, T C., Baba, M., Britt, D., McKether, W., Monplaisir, L., Ratner, H H. and Wagner, K H. (2003) Context, task, and the evolution of technology use in global virtual teams, In Gibson, C B. and Cohen, S G. (Eds) Virtual teams that work: Creating conditions for virtual team effectiveness, pp. 239 264, San Francisco: Jossey-Bass Saphiere, D M H. (1996) Productive behaviours of global business teams, International Journal of Intercultural Relations, vol. 20, pp. 227 - 259

A. Bennett

42

Sheppard, K., Dominick, P. and Aranson, Z. (2004) Preparing students for the new business paradigm of international teamwork, International Journal of Engineering Education, vol. 20, no. 3, pp. 475 - 483 Shouqian, S. and Zongkai, L. (2001) Models and techniques of computer supported co-operative conceptual design, Integrated Manufacturing Systems, vol. 14, no. 6, pp. 530 - 536 Steiner, I D. (1972) Group Process and Productivity, New York: Academic Press Stough, S., Earn, S. and Buckenmeyer, J. (2000) Virtual teaming: a strategy for moving your organisation into the new millennium, Industrial Management and Data Systems, vol. 100, no. 8, pp. 370 - 378 Turner, S. and Turner, P. (2007) Familiar problems revisited: co-operative aspects of an e-learning environment, Interactive Technology and Smart Education, vol. 4, no. 2, pp. 91 - 99 Wang, C Y., Yang, H Y. and Chou, S T. (2008) Using peer-to-peer technology for knowledge sharing in community practices, Decision Support Systems 45, pp. 528 - 540 Weisband, S. (1992) Group discussion and first advocacy effects in computer-mediated and face-to-face decision making groups, Organisational Behaviour and Human Decision Processes, vol. 53, pp. 352 - 380 Wodehouse, A., Breslin, C., Eris, O., Grierson, H., Ion, W., Jung, M., Juster, N., Leifer, L., Mabogunje, A. and Sandker N. (2007) A reflective approach to learning in a global design project, International Engineering and Product Design Education Conference Zhan, H F., Lee, W B., Cheung, C F., Kwok S K. and Gu X J. (2003) Web-based collaborative design platform for dispersed network manufacturing, Journal of Materials Processing Technology 138, pp. 600 - 604 Zhang, S., Shen, W. and Ghenniwa, H. (2004) A review of internet-based product information sharing and visualisation, Computers in Industry 54, pp. 1 - 15 Zoubi, R. and Tavcar, J. (2004) Preparing undergraduate students for work in virtual product development teams, Computers and Education 44, pp. 357 - 376

A. Bennett

43

Bibliography Allen, T J. (1968) Organisational aspects of information flow in technology, 42nd Aslib Annual Conference Benford, S., Smith, H., Shepherd, A., Bullock, A. and Howidy, H. (1992) Information sharing approach to CSCW: the GRACE project, Computer Communications, vol. 15, no. 8, pp. 502 - 508 Benson-Armer, R. and Hsieh, T Y. (1997) Teamwork across time and space, The McKinsey Quarterly, no. 4, pp. 19 - 27 Boh, W F. (2007) Mechanisms for sharing knowledge in project based organisations, Information and Organization 17, pp. 27 - 58 Chen, Y J., Chen, Y M., Wang, C B. and Chu, H C. (2007) Design and implementation of a cooperative enterprise selection mechanism for allied concurrent engineering environment, Concurrent Engineering, vol. 15, no. 3, pp. 257 - 274 Chen, Y J., Chen, Y M. and Chu, H C. (2008) Enabling collaborative product design through distributed engineering knowledge management, Computers in Industry 59, pp. 395 - 409 Chung, C C W., Choi, J K., Ramani, K. and Patwardhan, H. (2005) Product node architecture: a systematic approach to provide structured flexibility in distributed product development, Concurrent Engineering, vol. 13, no. 3, pp. 219 - 232 Duarte, D. and Snyder, N. (1997) Facilitating global organisational learning in product development at whirlpool corporation, Journal of Product Innovation Management 14, pp. 48 - 55 Farshchian, B A. (2001) Integrating geographically distributed development teams through increased product awareness, Information Systems 26, pp. 123 - 141 Fowler, S. and Karinthi, R. (1996) Remote access to CAD databases using an information sharing system, Computers in Industry 29, pp. 117 - 122 Griffin, A. (1997) PDMA research on new product development practices: updating trends and benchmarking best practices, Journal of Product Innovation Management 14, pp. 429 458 Gronbaek, K. and Mogensen, P. (1997) Informing general CSCW product development through cooperative design in specific work domains, The Journal of Collaborative Computing 6, pp. 275 - 304 Grudin, J. (1991) Obstacles to user involvement in software product development, with implications for CSCW, International Journal of Man-Machine Studies 34, pp. 435 - 452 He, F. and Han, S. (2006) A method and tool for human human interaction and instant collaboration in CSCW based CAD, Computers in Industry 57, pp. 740 - 751 Krishnan, S. and Uhlmann, J. (2004) The design of an anonymous file sharing system based on group anonymity, Information and Software Technology 46, pp. 273 278 Kydd, C T. and Jones, L H. (1989) Corporate productivity and shared information technology, Information and Management, pp. 277 - 282 Li, J., Sikora, R., Shaw, M J. and Tan, G W. (2006) A strategic analysis of inter-organisational sharing, Decision Support Systems 42, pp. 251 - 266 McAdam, R., OHare, T. and Moffett, S. (2008) Collaborative knowledge sharing in composite new product development: an aerospace study, Technovation 28, pp. 245 - 256 Mervyn, F., Kumar, A S., Bok, S H. and Nee, A Y C. (2004) Developing distributed applications for integrated product and process design, Computer-Aided Design 36, pp. 679 - 689 Nahm, Y E. and Ishikawa, H. (2004) Integrated product and process modelling for collaborative design environment, Concurrent Engineering, vol. 12, no. 1, pp. 5 - 23 Ostergaard, K J. and Summers, J D. (2007) Resistance based modelling of collaborative design, Concurrent Engineering, vol. 15, no. 1, pp. 21 - 32

A. Bennett

44

Penichet, V M R., Marin, I., Gallud, J A., Lozano, M D. and Tesoriero, R. (2007) A classification method for CSCW systems, Electronic Notes in Theoretical Computer Science 168, pp. 237 - 247 Perks, H. (2005) Specifying and synchronising partner activities in the dispersed product development process, Industrial Marketing Management 34, pp. 85 95 Rodden, T. (1991) A survey of CSCW systems, Interacting with Computers, vol. 3, no. 3, pp. 319 - 353 To, C K M., Fung, H K., Harwood, R J. and Ho, K C. (2009), Co-ordinating dispersed product development processes: a contingency perspective of project design and modelling, International Journal of Production Economics 120, pp. 570 - 584 Tuzmen, A. (2002) A distributed process management system for collaborative building design, Engineering, Construction and Architectural Management, vol. 9, no. 3, pp. 209 - 221 Qiu, Y., Ge, P. and Yim, S C. (2007) A risk-based global coordination system in a distributed product development environment for collaborative design, part I, framework, Concurrent Engineering, vol. 15, no. 4, pp. 357 - 368 Zhang, F. and Zue, D. (2001) Optimal concurrent design based upon distributed product development lifecycle modelling, Robotics and Computer Integrated Manufacturing 17, pp. 469 - 486

A. Bennett
Appendix A Semi-structured interview questions

I hereby agree that the information, views and opinions shared herein may be used as part of this research study, and that this interview may be recorded for later review. I understand that the information will not be shared outside of the setting of this research study, and that no personal details will be disclosed. Print: __________________________________ Sign: ___________________________________ Date: ___________________________________

A. Bennett
General details Name: Course: Class project was part of: Group Size: Project title: Project scope: Project start and end dates: Interim deadline dates: How would you generally rate your ability to use technology?

ii

What was stored? What types of file were stored during the project? What stages of the design process were involved in the project?

A. Bennett
Where was information stored? Was a certain information storage and sharing system specified for use during the project? If so, what system was this? If not, what system was used to store and share information? Personally, did you always store information on this system? If not, where did you usually store information? Was all information shared online, or were other methods used? If work was done on paper, was it then taken and stored digitally? Have you ever heard of/used these systems? If so, do you have a preference? GoogleDocs GoogleSites Wetpaint Laulima MindMeister Dropbox 4shared Box.net GoogleGroups Personal Websites Windows Live Skydrive Other Wiki Systems

iii

When was information stored? Did you always upload information, or only when someone asked you to? Did you upload files when they were part done, or always wait until you had completed work on them? Would you upload individual files, or batches? Did you ever experience speed or other issues while uploading files? Was there a specific time of day you generally uploaded files?

A. Bennett
Inspection: What file types did you upload? What sizes of file did you upload? When about in the project were these uploaded? What stage do these files fall into?

iv

Problems and Issues How easy was the system to use in general? How easy was it to upload files? How easy was it to share/access shared files? Did you experience any problems with file formats or sizes? How fast was the system? How flexible/adaptable was the system? Could you view files online, or did they have to be downloaded? What are your general opinions on the system? Did you have any problems with latest file versions?

Recommendations and Improvements What improvements do you think could be made to this system?

A. Bennett

Appendix B - Files uploaded by each team member

Project 1

Project 2

Project 3

Project 4

A. Bennett

vi

Appendix C - Number of files uploaded per stage

Project 1

Project 2

Project 3

Project 4

A. Bennett

vii

Appendix D - Number of files uploaded per file type

Project 1

Project 2

Project 3

Project 4

A. Bennett

viii

Appendix E - File distribution between stages

Project 1

Project 2

Project 3

A. Bennett

Project 4

ix

A. Bennett

Appendix F - Numbers of files within project stages

Project 1

Project 2

Project 3

A. Bennett

Project 4

xi

Appendix G - Percentages of total uploads

File Percentages Per Stage

A. Bennett

File Percentages Per File Type

xii

Appendix H - Numbers of files uploaded

Numbers of File Per Stage

A. Bennett

Numbers of File Per File Type

xiii

Appendix I - Sizes of files uploaded

Total File Sizes Per Stage

A. Bennett

Total File Sizes Per File Type

xiv

A. Bennett

xv

Appendix J - Uploads within project timelines

Project 1

Project 2

Project 3

A. Bennett

Project 4

xvi