information sharing in distributed team projects

8/3/2019 Information Sharing in Distributed Team Projects

1/61

Information stored in distributedteam-based student project work56501 Research Studies

Research Paper

Alastair Bennett200514155

5th Year MEng Product Design Engineering

Supervisor: Umit Bititci

16th March 2010


2/61

A. Bennett 1

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 thissubmission 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 non-award of my degree.

Signed ....

Dated ..


3/61

A. Bennett 2

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 thestudy. Thanks also go to Mrs Hilary Grierson for her insights into the subject area, and to Dr AndrewLynn for his insights into the systems studied. Finally, thanks go to all who gave up time to participatein this study, without whom the study could not have been carried out.

March 2010


4/61

A. Bennett 3

Justification of journal choice

This study has been written to conform to the guidelines for publication within the academic journalComputers and Education. This was chosen as it deals with studies relating to primary, secondary andtertiary education, and looks at issues relating to cognition, education and training within thesesettings.

Two of the particular areas from which the journal publishes papers are advanced technologyinformation 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 ofthis journal.

This paper has been written in line with Computers and Educations Guide for authors, which isavailable at www.elsevier.com/wps/find/journaldescription.authors/347/authorinstructions online.


5/61

A. Bennett 4

Abstract

Alastair Bennett, Department of Design, Manufacture and Engineering Management, StrathclydeUniversity, Glasgow

[email protected]

In industry it is becoming increasingly common for distributed projects to be carried out, and thereforethe same trend is occurring in educational establishments, both to prepare students for working inindustry, and to broaden their experiences and expertise. In order for distributed projects to besuccessful, it is imperative that knowledge and information can be shared between individuals. Themost common method for allowing this is the use of online digital repositories that act as digitalmemories. These allow team members to upload information for others to access, and to access workcarried out by others.

There are a number of different systems available for use by students to share information duringprojects, and many studies have looked at developing new systems with more features. However, thesestudies have not looked into what information is being stored and shared on systems, wheninformation is being stored, and what systems or other methods are most commonly used to sharefiles.

This study looks at two areas. Firstly it examines students thoughts and opinions on various systemsin 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 ofways, 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 systemexamined during the study, and general improvements that could be applied to all information sharingsystems to improve their usability.

Key words: information sharing, distributed projects, education

Word count: 14,998 words


6/61

A. Bennett 5

Contents

Statement of academic honesty 1

Acknowledgements 2

Justification of journal choice 3

Abstract 4

Contents 5

1. Introduction 7

2. Literature review 8

2.1. Distributed teams 8

2.2. Distributed student projects 9

2.3. Knowledge 10

2.4. Technology 112.5. Collaboration 12

2.6. Communication 13

2.7. Literature findings 14

3. Research objectives 15

4. Methodology 16

4.1. General approach 16

4.2. Research design 17

4.3. Validation 185. Data collection 19

5.1. Project 1 19

5.2. Project 2 19

5.3. Project 3 20

5.4. Project 4 20

5.5. Project 5 21

5.6. File systems 21

5.6.1. Laulima 21

5.6.2. Google Groups 22

5.6.3. Server access and file storage 22

6. Analysis 23

6.1. Interviews 23

6.1.1. Conclusions 25

6.2. File inspection 25

6.2.1. Project 1 25

6.2.2. Project 2 26

6.2.3. Project 3 27

6.2.4. Project 4 28


7/61

A. Bennett 6

6.2.5. Comparative analysis 30


6.3. In depth file analysis 34


7. Discussion and conclusions 36

7.1. Discussion 36

7.2. Contribution to knowledge 37

7.3. Practical implications and recommendations 38

7.4. Future research 39

7.5. Personal reflection 39

References 40

Bibliography 43

Appendix A Semi-structured interview questions iAppendix B Files uploaded by each team member v

Appendix C Number of files uploaded per stage vi

Appendix D Number of files uploaded per file type vii

Appendix E File distribution between stages viii

Appendix F Numbers of files within project stages x

Appendix G Percentages of total uploads xii

Appendix H Numbers of files uploaded xiii

Appendix I Sizes of files uploaded xivAppendix J Uploads within project timelines xv

Tables

Table 1 Research Design Options 18

Table 2 File type information 30

Table 3 Project stage information 31

Table 4 Percentage of total uploads in each period 32

Table 5 Percentage through project of periods of uploading 32

Figures

Figure 1 General Research Methodology 16

Figure 2 Project 1 File Types and Amounts 26

Figure 3 Project 2 File Types by Stage 27

Figure 4 Project 3 File Types and Amounts 28

Figure 5 Project 4 File Amounts by Stage 29

Figure 6 Project 4 File Types by Stage 29

Figure 7 Project Timelines Showing Uploading Periods for Each Stage 33

Figure 8 Categories of Information Contained in Project 4 Files 35


8/61

A. Bennett 7

1. Introduction

As in industry, distributed team-based projects are becoming more common within an educationalsetting, with students being distributed within different establishments or having to work at differenttimes and from different locations within one establishment. As with traditional projects, it is essentialthat information can be shared amongst teams in order to allow all participants to have access to thesame 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 acollective memory for the group. They allow team members to upload files and notes to a system, fromwhere they can then be downloaded and either used or edited by other team members. There aremany different systems available to facilitate this sharing, with each providing different features andfunctionality depending on the project being carried out.

Within many institutions there has also been a move towards using these systems to carry outassessment for many modules, with assessors and tutors being able to access the repository in order toexamine 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 studentsto these systems because of their use within industry. Due to the globalisation of many companies, andthe distribution of expertise throughout different locations, the same types of system are being usedmore and more within an industrial setting, meaning students need to be prepared to use these oncethey have jobs.

In spite of growth in the use of these systems within education, little is known about how studentsactually make use of them. There are many different systems with many different features, but in orderto provide something that fits the needs of the students, it is important to know how they are using thesystem, what problems they think exist, and what they would like to see as part of futuredevelopments.


9/61

A. Bennett 8

2. Literature review

The literature review in this paper looked at a wide range of areas related to distributed teams, both ingeneral and in an educational context. The boundary of information examined was to look at systemsand other information-sharing methods used by distributed teams, with a particular focus on designand 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 atseparately. 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 leadto confusion. The term virtual team is often used, and the meaning that is often implied is the sameas that as a distributed team. It is important to define early on exactly what a distributed team is, andthe 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 acrosslocational, temporal, and relational boundaries in order to accomplish aninterdependent task. (Martins et al, 2004)

This definition was based on the findings of previous research work by a wide range of authors, andsought 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 ofan issue that requires the use of technology.

This definition can be expanded slightly by saying that on top of there being a boundary that isbeing crossed, those involved can either be located within or outwith the same organisation (Leenderset al, 2003).

Another important point is to understand why distributed and virtual teams are used, as this helpsto reveal how they should ideally work. Leinonen and Bluemink (2007) note that due to advances intechnology, 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 oftenspread 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 contentionbetween authors. Some authors used to claim that for a team to be classed as virtual, all theircommunication should be through electronic means (Bouas and Arrow, 1996), but more recent authorssaid that some face-to-face communication was allowed (Jarvenpaa and Leidner, 1999). Even morerecent work has suggested that distributed teams should no longer be contrasted with traditionalteams, 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 teammembers. 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 thestudies they looked at were dispersed due to geographic or organisational dispersion, while Leenders et


10/61

A. Bennett 9

al (2003) say that distributed teams are either geographically or temporally distributed and can be inthe same organisation.

In their review of previous work, Martins et al (2004) noted that the three most commonlymentioned boundaries are temporal, geographic and organisational boundaries. They also noted thatthe 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 relationalboundaries (Griffith et al, 2003). It should be noted a team could easily be faced with more than oneof these boundaries.

One way of taking advantage of the temporal boundary is to spread teams geographically in atactical manner in order to allow work to be carried out 24 hours a day (Gupta et al, 2009). Thismeans that the total number of days from start to end of a project can seemingly be reduced, althoughthis 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-facecounterparts and commented on the differences. Group size has always been seen as an importantfactor 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 tointeract effectively. Martins et al (2004) conclude that the effect of team size is very much dependenton 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 thanthose 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-faceteams produce better results. Some authors claim that tests revealed no difference in performancebetween 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 detrimentaleffects 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 theteam is distributed that affects performance, but how the project is controlled and managed, and howwell team members interact.

Other main characteristics of distributed groups that are mentioned in literature, and seem tocontribute to the working of groups fairly substantially, include that distributed team members areunlikely to work together again after a project (Zoubi and Tavcar, 2004), that they have a far more fluidmembership than traditional teams (Alge et al 2003), and that they seem to have a much shorterlifecycle (Jarvenpaa and Leidner, 1999).

2.2. Distributed student projects

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


11/61

A. Bennett 10

Within student-based distributed projects, some disadvantages were discovered compared withthose in industry. One of these was that on top of the other boundaries and barriers applied to suchteams, issues arose with the timings for terms beginning and ending within different institutions. Thishad a knock-on effect, with the result that projects often cannot not run for long enough to besuccessful (Zoubi and Tavcar, 2004).

As well as preparing students for industry, these projects also allow distributed teams to bemonitored under incredibly controlled circumstances. This allows greater lessons to be learned fromprojects, the outcomes of which can then be applied in industry to improve the results of distributedteam 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 ofknowledge, 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 knowledgeeffectively is key for teams, whether they are co-located or distributed (Gupta et al, 2009). Leenders etal (2003) also suggest that the productivity of product development teams depends not only on theirability to discover information but also to effectively communicate and share it amongst teammembers. It is also vital to ensure that information being shared is appropriately protected (Zoubi andTavcar, 2004).

Within distributed teams, it is especially important to ensure that information is shared well, due tothe distribution of team members. Ardichvil et al (2003) found that information flowed far betterwhen it was viewed as something that belonged to the whole company, rather than something that anindividual 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 onthe nature of the project being completed. As well as knowing what should be shared, informationthat is of greater importance should be identified clearly for other team members to see (Cramton andOrvis, 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 byusers for information that they need. Information can also be shared from other projects. Elpass andHollinger (2004) suggest that these will become more and more common, and become the backboneof future education.

Leinonen and Bluemink (2007) carried out case studies and talked to the participants in order todiscover what information and knowledge they assumed to be shared during projects. Their findingsshowed that as well as information such as research findings and designs, it was important for morepersonal information to be shared. They also discovered that team members presumed that ideasabout goals and processes would be shared.

There are, however, a number of barriers to people sharing information within a distributed teamsetting, just as with a traditional team. Perhaps the biggest barrier is the tendency not to contribute incase someone is criticised or in case they mislead someone (Ardchvil et al, 2003).


12/61

A. Bennett 11

2.4. Technology

Technology plays an absolutely vital role in the work of distributed teams. Distributed teams usetechnology in a very different way from traditional teams, with it playing a vital role in communicationand 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 roletechnology 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 becomesomething that takes large amounts of time to work with and keep up to date. Students within teamprojects at Strathclyde University who were using a wiki-based online system commented that it tookfar too long just to keep their part of the system up to date, as well as taking a long time to uploadnew data (Grierson et al, 2006).

Lecturers involved with the European Global Product Realisation (E-GPR) course commented that aswell as the systems being reliable, students need to be able to master technologies quickly, preferablybefore 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 thedevelopment of technology means that language barriers could be removed through the developmentand use of translation software for such projects.

As well as looking at how distributed teams use technology, a large number of authors have putforward frameworks and guidelines for new systems that they think solve the problems faced duringdistributed projects. Huang et al (2006) proposed an agent-based workflow management system andlooked 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 machinebeing used and discussed the benefits this brought. Frank and Mitschang (2002) also looked atdeveloping a customised system, but with more of a focus on allowing different users to co-operate onwork at the same time.

Finally, Fan et al (2008) looked at developing a system that was peer-to-peer, rather thanclient/server based. This worked by connecting groups of computers to a server, and then linking theservers together. This was aimed at improving the speed of data transfer, since files were accessed onthe local server.

As well as developing and proposing new systems, authors have also looked at current technology-based 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 tofocus, as well as helping to raise overall confidence levels. Grierson et al (2006) found that the samesystem became more than just a place to store information for students, also becoming a place to shareand reflect.

Turner and Turner (2007) looked at a number of systems but concentrated on WebCT. They foundthat a number of issues that had been present from the 1990s were still around, which was not thatsurprising. More interestingly, they found that there was a critical mass of users needed in order tomake use of such technologies worthwhile and successful.


13/61

A. Bennett 12

As well as looking at the advantages of using technology during distributed projects, authors havediscovered some of the issues both with technology in general, and with specific systems. One of theissues discovered by Zoubi and Tavcar (2004) is the speed of connection needed in order to enable thesuccessful use of technologies. Linked to this, they found that both the systems and connection beingused 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 notusually be able to work together can (Leenders et al, 2003). Monplaisir (1999) stated that collaborationis key to effective development, and it is therefore no surprise that almost every author refers tocollaboration when talking about distributed projects.

One of the areas in which the biggest advantages of collaboration in distributed teams can be seenis in the concept development stage, specifically brainstorming. Connolly et al (1990) found thatcollaboration at this stage helped bring about slight criticism from team members, which ultimatelyhelped to produce more original solutions.

Combs (1993) looked at exploiting the advantages of collaboration during the early stages of designprojects by developing co-operative research between multiple companies. The idea behind this wasthat all the companies would benefit from this, since the ideas created would be better than thosecreated by any of them on their own. However, there were issues with getting companies to see thatthis 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 individualscan access information at the same time. Unfortunately, synchronous data access is often conflictprone (Frank and Mitschlang, 2002), and instead of aiding collaboration, this actually limits who canlook 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 havethis as a central feature.

In order to aid collaboration further, Zoubi and Tavcar (2004) noted that systems supportingdistributed design should be available for use at all stages of projects, since collaboration is importantat all stages. The obvious area that lacks this support is during the concept development stage if teammembers 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 membersare contributing. Ardichvil et al (2003) propose that some group members shy away from contributingin case they are criticised, while Kamel and Davison (1998) say that the higher level of anonymity withindistributed 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 whichteam members have added or shared what data, and when, thereby making it a lot easier to ensureequal 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 toinformation being shared between team members was issues relating to file compatibility. In theirdesign platform, Zhan et al (2003) saw this as a major issue, and built in an entire part just to help dealwith it.


14/61

A. Bennett 13

There are a number of issues relating to different versions of files within design teams. Frank andMitschang (2002) state that when it comes to CAD files, most teams rely only on the version numbersof files to keep up to date, but this does not solve the problem of multiple people working on a file atonce in separate locations, and work then being lost. Possible solutions to this problem includesynchronous 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 nowrecognising 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 separationexperienced by these teams, their methods of communication need to be flexible, and are markedlydifferent from traditional teams.

A number of authors have looked at the issue of communication in distributed teams, both inindustry and in an educational context. The research carried out has looked at both methods used tocommunicate, and common issues.

The most obvious communication tools to make use of are e-mail and chat facilities, which Herderand Sjoer (2003) found to be the most common. However, Martins et al (2004) found that the use ofless formal chat facilities tended to contribute to higher levels of frustration within teams, while Graetzet al (1998) found that teams using chat tools took longer to reach decisions. Depending on locationof team members, tools such as video and telephone conferencing can be utilised, with videoconferences 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 beenfound 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 notalways be possible, and is partly based around the type of communication channels being used, sincenot all allow truly synchronous use (Riopelle et al, 2003).

Zoubi and Tavcar (2004) found that one of the many issues with asynchronous communication wasthe 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 aprocess being far greater than with synchronous communication (Weisband, 1992).

As well as the type of communication, the amount of communication that takes place in distributedteams was found to be a factor. Saphiere (1996) found that teams that communicated more often ininformal 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 tocommunication within distributed teams. Herder and Sjoer (2003) found that due to the importance ofvisual cues and geographical synchronicity, those located together as part of a distributed team willalways 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, andhad a reasonable effect on productivity, while Gupta et al (2009) found that without face-to-facecommunication, it became difficult to transfer tacit information between individuals. Baker (2002)found that the use of video-based communication produced significant improvements, but was notalways possible depending on team members distribution.


15/61

A. Bennett 14

2.7. Literature findings

One of the main findings through the literature review was that many different groups have attemptedto produce new systems to improve information sharing and collaboration practices. However, manyof these cases seem to be based on what the particular individuals feel that systems should be able todo, 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 usefulway 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 newsystems, no authors carried out in-depth studies into what information was actually being sharedbetween team members in different projects. There was also a lack of research into when teammembers shared information with each other, and whether there were any regular patterns acrossdifferent types of project.

Although some research was carried out looking at specific systems and how they were used both inindustry and in educational contexts, the research did not look into the preferred methods used byindividuals to share information with each other, or why they used these methods.


16/61

A. Bennett 15

3. Research objectives

Based on the original research question that had been set and the outcomes the literature review, anumber of specific research questions were set. These were initially set to look at where and wheninformation was stored during distributed team-based projects. Based on these areas, the followingspecific research objectives were set:

Objective One: To discover what systems are used to store information during distributedgroup design projects, and what other methods students use.

Objective Two: To discover the limitations, problems and issues with commonly usedsystems, based both on user interaction and file storing capabilities.

Objective Three: To discover when information is uploaded during projects, both in termsof whether it is uploaded when half finished or complete, and in relation to the projecttimeline.

Objective Four: To discover the different types and amounts of information beinguploaded 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 whatinformation 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 throughoutthe course of distributed team-based projects.


17/61

A. Bennett 16

4. Methodology

There were three research methodologies that could be used for the project; positivism, relativism, andinterpretivism (sometimes also referred to as social constructivism). Positivist approaches are oftenbased on experimental research, and what is being observed is independent of the observer. Therelativist approach also involves looks at a reality independent of the observer, but looks at theexperiences of larger groups of people. The interpretivist approach looks at much smaller numbers ofcases, 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 theinductive approach that would be used. It was also the best methodology to use in this situation dueto the information already having been created, and the importance of talking to a smaller number ofindividuals and gaining more detailed, in-depth thoughts and opinions from them.

4.1.General approachThe general approach used can be seen in Figure 1. From the initial research question, a literaturereview was carried out in this area, and a number of research objectives were set as a result of thefindings. Data was then collected both through semi-structured interviews and by examining filesystems, with this then being analysed and interpreted. A structure to allow teaching and developmentof systems was then developed, and conclusions were drawn.

The literature review focused on information-sharing practices both in industry and in an educationalcontext, and looked at systems that had been created, and other studies into issues with and uses ofinformation storage and sharing systems.

Figure 1 General

Research Methodology

Literature Review

Research Questions

General Research Question

Collect DataInterviews and Observations

Data Interpretation

Develop Structure

Draw Conclusions


18/61

A. Bennett 17

Data was collected from four projects through semi-structured interviews and by examining the filesystems and uploads associated with each project. These were then analysed separately to gain anunderstanding of uploading habits, and peoples opinions and thoughts on the systems. In order to tryto ensure the information relating to each project was accurate, multiple team members from eachproject 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 thoughtsand opinions were noted and compared in order to see what points individuals agreed and disagreedon, and what general opinions started to emerge.

Taxonomies or analysis of recordings of interviews could have been used to analyse the datacollected, but due to the differing natures of the two sets of data, it was decided to analyse both intabular form. This allowed the data to be manipulated and examined in detail with ease, and variouspatterns 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 improvingthe 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 differentoptions available is shown in Table 1.

This project was based on inductive research rather than deductive research, since it started withspecific 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 usinga deductive method, which would result in far more specific outcomes that could not be applied asgenerally as the results from this study.

Since this study is based around collecting more general information and thoughts rather thanfigures, it used qualitative methods of data collection and analysis. These fitted especially well with thethoughts and opinions gathered during the study. The numerical data collected during the project wasalso analysed qualitatively, as no complex numerical analysis was carried out.

Of the three research strategies available for use, an exploratory strategy was chosen. Unlikeexplanatory or descriptive strategies, which explain why something is happening or are used to identifyparticular 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 problemswith no clear solution, and to search for patterns and hypotheses within data sets, rather than settingout 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 thisproject. Due to the inductive nature of the research, the setting within an educational context and thedesire to develop recommendations for improvements based on current practices, case study researchwas the best choice. The observations and data collected from case studies were incredibly importantin this study, due to the need to understand current practices first in order to be able to makerecommendations.


19/61

A. Bennett 18

4.3. ValidationIn order to ensure that the information gathered was accurate and reliable, multiple members of eachteam were be interviewed in order to ensure that there was a general consensus regarding thoughtsand opinions. For the file data collected, reliability was ensured by collecting several sets of data inorder 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 andreliability of these could be measure. Three criteria were set to measure the success and validity of thecase 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?

Research Type

Inductive Research Deductive Research

Starting with the creation of theoriesand hypotheses, then confirming ordisproving them with experiments.

Starting with observations and datacollection, and working back to generaltheories.

Research Paradigm

Qualitative Quantitative

Analysing mostly numerical data usingoften complex statistical methods.

Based on thoughts, opinions and morepersonal data, and generally involvingpersonal accounts and unstructuredinterviews.

Research Strategy

Descriptive Explanatory Exploratory

Based on exploring anddescribing what is takingplace in an organisationor area.

Understanding andexplaining relationshipsand how somethinghappens.

Looking at identifyingpatterns within data, andcreating rather thanconfirming hypotheses.

Research Design

PureResearch

The most academic form of research, conducted to improveunderstanding and develop theory.

Applied

Research

Tackling problems within organisations with a view tocreating

solutions, usually within a specific setting.

ActionResearch

Research that seeks understanding through attempting tochange the situation being investigated.

ConstructiveResearch

Looking at providing a rich picture of life and behaviourwithin organisations.

Case StudyResearch

Collecting data through studying cases, then interpreting andanalysing data to draw conclusions.

Table 1 Research Design Options


20/61

A. Bennett 19

5. Data collection

In total, eight individuals were interviewed about five different projects. Seven of these students studywithin the Department of Design, Manufacture and Engineering Management (DMEM) at StrathclydeUniversity, and one is an Architecture graduate from Aberdeen University.

The Strathclyde students were interviewed about four different projects, which were used as the basisof the file system analysis, and the Aberdeen student was asked about one project. There was somecrossover within the Strathclyde projects, with two of the students being interviewed about two differentprojects that made use of different systems in order to learn how the systems compared, as well aslearning 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 systemby different teams could also be examined.

In relation to the research objectives set, the interview sessions with individuals were designed to focusmostly on where and when information was stored. The analysis of the file systems looked in far moredetail 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 atStrathclyde, which is a compulsory module for all 4th and 5th year and Post-Graduate DMEM students. Themodule 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, specificationdevelopment, conceptual and detail design, prototyping, and some business recommendations, with someprevious research having been carried out. The project ran from 29th October 2008 until 13th May 2009,and included two milestone deadlines on 17 th December 2008 and 25th February 2009.

Three members of the team were 4 th year Product Design Engineering students, while one studiedProduct Design Engineering with a Diploma in Management, and was also in 4 th year. Two members of theteam 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 onprogress. Other than this, they would work on the project as and when they could, meaning team memberswere 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 thesystem 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 forall files they uploaded.

5.2. Project 2

The second project was also part of the PDP module. This allowed comparisons to be drawn between howdifferent 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 designthat could be used both internally and externally by the client company. Research, specification generation,


21/61

A. Bennett 20

conceptual and detail design, prototyping, and manufacturing and material recommendations were allincluded 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 4 th yearstudent 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 memberswere interviewed, but only two file galleries were examined since one team member had never managed toupload 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 takenmostly by 5th year and Post-Graduate students, and looks at educating students in best practices in relationto working in global teams.

The team studied was composed of six individuals distributed between Strathclyde University andSwinburne University in Melbourne, Australia, with three team members in each location. One of theStrathclyde 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 bothteams starting work, the Australian part of the team carrying out detail design and the Scottish part of theteam carrying out prototyping. This was the shortest project included in the study, running from 5th to 26thOctober 2009.

The system specified for use in this project was Google Documents, but the team actually used GoogleGroups as it fitted their needs far better. It was also specified that this was to be the only communicationmethod used. Due to how this system works, all files and details relating to the project could be recordedfor inclusion in this study. Two members of the Strathclyde part of the team were also interviewed to gaintheir 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 atStrathclyde, a compulsory class for 4th year MEng students, and an elective class for other 4 th year and Post-

Graduate students. The brief for this project was to design and prototype a smart electric wheelchair, with ateam 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 December2008. Unlike the other projects examined, no specific storage system was specified for use during thisproject, 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 theframe 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 thisproject, with different people working in different places depending on what they were prototyping ordesigning.


22/61

A. Bennett 21

5.5. Project 5

This project was the only one examined that was based entirely outwith Strathclyde University. It was partof a 3rd year Integrated Studies module taken as part of an Architecture degree at Aberdeen University. Thiswas 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 15individuals 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 spaceon its server to store files so that others could access them. However, this could only be accessed while oncampus, and not from any internet connection.

Due to the person interviewed having graduated, the file system could not be accessed and analysed forthis 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 workingfrom 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 GoogleGroups. These are different in many ways, both in terms of the interfaces they use, and the methods ofuploading and sharing files. The system used by Aberdeen University was different again, and is alsodescribed below.

5.6.1. LaulimaThe Laulima system is stored on and accessed through Strathclyde University servers. It is based on theTikiWiki system, an open-source content management and groupware web application. It was developed toallow project teams to access and customise their own space within the system, to share files with otherteam members, and to allow project assessment by tutors. According to the developer of the system, it wasnever expected to be used as it is, with teams spending a large amount of time working on the design ofpages, 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 programmedusing one of three options: wiki syntax, HTML coding, or a what-you-see-is-what-you-get editor. Thevarious 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 offiles that can be linked to. As standard, each user is limited to 200MB of storage at any one time, but thiscan be increased by the system administrator if necessary. There are no restrictions placed on file types thatcan 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 downloadedand used by others. There are no restrictions on the size of file that can be uploaded, but the system is setto cancel any upload once it reaches a certain amount of time, meaning that video files in particular may notupload successfully.


23/61

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 filesand ideas in an online environment. The system is designed to work across all browsers, with help andsupport being provided if any issues arise.

There are two options available to users in relation to accounts. Those with a Google account, such asfor Gmail, can use it to log in, gain full access to pages, and create their own groups. Those without Googleaccounts can gain access with another e-mail address, but do not have access to all features; they cannotupload 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 anddifferent sections that are included. The design changes that can be made are far more restricted than inLaulima, 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 thesystem 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 10MBmaximum being reached. There are no obvious restrictions to the type of file that can be uploaded, with theexception 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 thatare commonly used work, but with some major differences. Firstly, you can just drag and drop files on tothe 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 anothercomputer first.

However, this is the extent of this type of systems flexibility, apart from creating subfolders. There are nomethods for looking at what revision of a file you are looking at unless it is included in the name, there canbe no customisation of the interface, and there are no facilities for talking to or interacting with other teammembers.

Other downsides include that the speed of accessing files in this type of system can be slow dependingon who else is accessing the server, and that there can often be no external access, which for Project 5 ofthis study meant no files could be shared or accessed from anywhere other than the universitys networkconnections.


24/61

A. Bennett 23

6. Analysis

The information gathered for this study was broken down and analysed in three ways. Firstly the interviewswith 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 foridentifiable patterns and problems within them. Finally, the file list for Project 4 was studied in more detailto 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 theiropinions on the systems they had used and what improvements they thought could be made. A copy of thequestions used in each interview can be found in appendix XXXXXXXXXXXXX, and below are summaries ofthe 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 storedinformation on the specified system, while six participants also kept copies of all their files on USB pendrives. These individuals noted that having copies on a pen drive made it easy to share files with others ifthey were in the same location, especially for large files. A number of people also shared files by e-mailingthem 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 wouldupload most files, especially those that seemed important, but keep some others on their computers untilsomeone 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 eventrue with the teams product design specification (PDS), while a member of Project 3 commented that theirPDS was one exception to this, and that they uploaded it at multiple stages. One person commented thatthey would upload some work when half complete if they wanted feedback or advice from other teammembers.

When asked if people uploaded single files or batches, the most common answer was that it dependedvery much on what there was at any given time. One person responded that they uploaded in batches tosave the pain of having to try to upload more often.

The differences between the uploading experiences of the users of Laulima and Google Groups werehuge. 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 wouldsometimes work while the other would not. One of the users stated that uploads failing and crashing atrandom was par for the course with Laulima, while another stated that they never managed to uploadanything 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, inresponse to being told that many people had reported uploading as being, the system developer stated thatit was not the system and server being slow, but issues with too many people trying to upload from thesame 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 withnaming files and pages.


25/61

A. Bennett 24

The only complaints about using a shared server space were that some larger documents took a longtime 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 theyusually 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 manyareas. The biggest issue with Laulima compared with Google Groups was that of the programming thatwas needed in order to create and customise pages, and the lack of guidance and teaching that was givenon 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 systemand 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 endof projects, once they were more familiar with how it worked, but that there was a very steep learning curveat 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 permissionscorrectly, 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, andthere were no issues with the shared server space.

There were no complaints in relation to the speed of navigating about the various Google Groups pagesfrom any of the users. The only real complaint from the Laulima users was that at peak times of use, thesystem could be very slow when attempting to do anything, with it sometimes just stopping and not loadingpages. There were once again no issues with using a shared server space, since there were no pages tonavigate, 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 menusituated 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 changesto be made were carried out using a graphical user interface, meaning that no specialist knowledge wasneeded and the changes could be completed almost instantly. Using the shared server space, there was noflexibility 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 bedownloaded. On Laulima, many teams worked around this by embedding text from word processingdocuments in to a page, rather than uploading the document. With Google Groups, it was expected thatcrossover 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 slowdepending on the server load.

A number of suggestions were made in relation to improving the systems. The main improvementssuggested for Laulima were based on standard page templates being available, the user interface for editingbeing greatly improved and the permissions system being simplified. For Google Groups, the mainsuggestions were to incorporate some sort of file hierarchy, and to integrate other Google services to allowonline editing and collaboration. For using a shared server space, access to files outwith an institutionsnetwork was suggested as a major improvement.


26/61

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 actuallybe achieved using the various systems. Another fact that came out was that users far preferred systems thatwere 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 filesby e-mailing them to other group members rather than uploading them to the system they were using, andthat they would often transfer files using USB drives when in the same location, as this saved time and wasbetter for larger files.

Looking at when files were uploaded, people answered almost unanimously that they would wait untilfiles were finished before uploading them. There were no conclusive results relating to when in the daypeople would upload files, or whether they would upload single files or batches. For both of these areas, itvery 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 andsharing files. With Google Groups, the main issue was finding files once uploaded due to the organisationalissues, 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 outon 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 werecollected of all the files that had been uploaded to the systems used, as long as they had not been deletedagain. The files for all four were sorted to display the file name, file type, who had uploaded them, theirsize, 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 fileswere uploaded relating to each stage.

As well as carrying out analysis on each project individually, file details were also organised and comparedacross all four projects. This was done based on when files were uploaded, what types of files wereuploaded 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. Alarge percentage of files were images that had either been left with the names allocated by the device usedto create them, renamed along the lines of Picture 1, or were untitled and assigned general names by thesystem 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, asthese were embedded into pages instead so they could be viewed online, but no CAD files or presentationswere uploaded either. There was also a big difference in the number of files uploaded by each person, withone uploading nearly three times as many as the other.


27/61

A. Bennett 26

Of the files uploaded, nearly all were JPEGs, and nearly all that could be identified fell into the concept orprototyping stages. However, due to the naming that had been used, the stages into which most files fittedcould not be identified.

The dates of uploading showed that groups of files were often uploaded on a certain day followed by agap, 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 thedetails collected did not reveal if there had been any changes made to files, there were a number of timeswhen files of the same name, format and size had been uploaded twice on the same date. A possibleexplanation is that they had been uploaded using the Drag and Drop feature on Laulima, and then couldnot be found, so were uploaded again.

Due to the large number of unidentifiable files, a timeline of when stages started and stopped could notbe fully constructed. However, the files that could be identified into certain stages ran in a good order, withno 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 betterunderstanding of what was contained within a file. JPEG and PDF files were by far the most commonlyuploaded, but there was a wide range of file types used, including other images, word processingdocuments and presentations, as can be seen in Figure 3.

For both the word processing and presentation documents, both Microsoft Office 2003 and MicrosoftOffice 2007 versions were used at different points, with the file sizes of the different versions varying quitedramatically. There were also very few word processing documents, as the team often saved files as PDFs inorder to avoid any compatibility issues.

Figure 2 Project 1 File Types and Amounts


28/61

A. Bennett 27

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 wereoften 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 whouploaded 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 isonce again lacking.

In relation to when files were uploaded, neither of the individuals interviewed uploaded anything afterthe 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 manyother types also being uploaded. In total, more JPEGs were uploaded than all other file types combinedduring 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 thanany 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 eitherthat the system was under-used to share files, or that far fewer files were actually produced than might havebeen 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 somerevisions, none were made after the conceptual design stage had started. There was also a lot of crossoverbetween 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 two-thirds of files being uploaded within the first third of the project.

Figure 3 Project 2 File Types by Stage


29/61

A. Bennett 28

Overall, file naming conventions used for this project were quite helpful, and gave a good indication ofwhat each file contained. There were no examples of double-uploading during this project, either as it didnot happen due to the simpler uploading system in Google Groups, or because it was easier to notice anddelete 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 agood indication of what stage of the project they fitted into, and sometimes suggested what the filecontained. However there were other files such as one named simply g that gave no indication of whatthey related to. Although there were some examples of files being uploaded with the same name, theywere not actually the same file, as had been experienced while examining the other projects; there were infact 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 theycould not be embedded in the system. Studying the minutes uploaded showed that minutes were takenregularly both by the whole team, and by sub-teams. However after a little more than a quarter of theproject, no more minutes were uploaded to the system.

The specification stage of this project contained far more files than the other projects studied, and thesewere uploaded over a relatively long period of time. The concept stage also lasted a long time, with filesbeing uploaded for this from a little over a month after the start of the project up until almost the end. Aswell as spanning the longest time, the concept stage also contained the most files, although not by as cleara margin as in other projects.

As Figure 5 shows, the concepts stage once again contained the most files, although the research stageand minutes were close behind. There was also a wider spread of file types within each stage of the project

than in any other project.

Figure 4 Project 3 File Types and Amounts


30/61

A. Bennett 29

Looking at the types of file uploaded, word processing documents were by far the most common, withover twice as many as there were images. There were also far more CAD files shared during this projectthan in any other, with many of these being shared within ZIP files in order to allow whole assemblies to beuploaded. Many of the file types that were used during the project, such as TXT and GIF files, were onlyused 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 thantowards the end, with large gaps in the middle. Looking at when files were uploaded for different stagesshows that the embodiment stage overlapped quite significantly with both the concept and prototypingstages of the project. One likely explanation for this is that the three sub-teams were working on slightlydifferent 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. Teammembers took turns keeping minutes, and therefore all uploaded word processing files, while many otherfile types were only uploaded by one individual. Two of the team uploaded far more files than others, whileothers contributed minutes and nothing else.

Figure 5 Project 4 File Amounts by Stage

Figure 6 Project 4 File Types by Stage


31/61

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 thefile types uploaded; and on the stages involved in each projects. In order to compare the timelines of theprojects, 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 andsimilarities 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 farthe most common file format in terms of number of files uploaded. Word processing documents werenumerous for one project, but not for the other three, probably due to the type of project, or text beingembedded in the Laulima system.

Looking at the total file sizes of different types, JPEGs again came out as generally having the greatesttotal file size. Unlike the numbers of files, presentations also rate highly in terms of total file sizes within theprojects 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 wordprocessing documents show as being common in one project, and occurring a few times in others, the totalfile 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 andpresentations generally came out highest. Individual CAD files made up almost none of either the total filesizes or percentages of files, but ZIP or RAR files containing CAD data made up a significant amount whenutilised.

PercentagesProject .asm .doc .docx .drw .gif .jpg .pdf .pptPDP1 0.03 98.78 1.19

PDP2 0.38 0.87 14.95 24.94 25.33

APDE 0.218 5.35 0.036 0.016 8.812 10.736

Global Design 3.69 0.22 64.32 1.14 11.47Project .pptx .prt .psd .rar .txt xlsx .zip Other TOTALPDP1 10 0PDP2 8.96 15.75 8.84 10 0APDE 0.187 21.232 0.003 0.103 51.594 1.713 10 0Global Design 18.83 0.02 0.3 10 0

SizesProject .asm .doc .docx .drw .gif .jpg .pdf .pptPDP1 10.12 30544.16 368.47PDP2 447.59 1024 17670.57 29477.97 29948.17

APDE 152.2 3741.2 25.1 11.5 6162.4 7508.2

Global Design 1746 102 30428.1 540.9 5427.2Project .pptx .prt .psd .rar .txt xlsx .zip Other TOTALPDP1 30923PDP2 10588.16 18616.32 10444.8 118218APDE 131.1 14848 2.2 72.2 36081.5 1197.9 69934Global Design 8908.8 11.5 144.1 47309

Numbers ofProject .asm .doc .docx .drw .gif .jpg .pdf .pptPDP1 2 88 4

PDP2 2 1 15 12 3

APDE 1 25 1 1 7 11

Global Design 4 1 26 5 1Project .pptx .prt .psd .rar .txt xlsx .zip Other TOTALPDP1 94PDP2 1 1 2 37APDE 1 2 1 2 9 2 63Global Design 1 1 3 42

Table 2 File types sorted by number of files, total sizes in kB, and percentages of total space


32/61

A. Bennett 31

Looking at the files uploaded into different stages of the four projects, there were a number of pointsthat stood out. The first of these was that the research and conceptual design stages generally feature themost individual uploads. Also, despite the four projects entailing mostly the same stages, no files wereuploaded for many stages in some of the projects. Across the whole of each project, most files seem to beuploaded into the middle stages, picking up at research and starting to drop off after the conceptual designstage.

This does not match up exactly with the total sizes of files uploaded at different stages, although theconceptual design stage file sizes are again quite high. Research files take up a reasonable amount of spacecompared 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 doubtdue to the inclusion of many high-quality images. For the project that minutes were kept for, these filestook 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 designstage unsurprisingly once again comes out as being highest for three of the four projects. As with the filesizes, the early stages of the project again came out low compared with other stages, and embodiment andpresentations once again come out high.

File percentagesProject Team Site Brief Minutes Planning Research SpecificationPDP1 0.18 0.69 0.9 0.11

PDP2 29.04 5.73 0.67 0.92 12.95 2.61

APDE 0.583 7.123 0.932Global Design 5.98 8.63 5.1Project Concept Embodiment Prototyping Deliverables Presentations Unknown/Other TOTALPDP1 1.42 2.21 0.29 94.2 10 0PDP2 26.72 21.36 10 0APDE 31.033 32.806 1.812 25.712 10 0Global Design 79.4 0.89 10 0

File sizesProject Team Site Brief Minutes Planning Research SpecificationPDP1 55.95 214.99 278.81 33.48

PDP2 19384.07 3825.15 447.59 612.19 8641.74 1741.48

APDE 407 4975.3 651.1

Global Design 1990.7 2873.3 1699.8

Project Concept Embodiment Prototyping Deliverables Presentations Unknown/Other TOTALPDP1 438.61 684.62 89.66 29161.89 30958.01PDP2 17830.84 14259.18 66742.24APDE 21676.6 22915.4 1265.5 17960.2 69851.1Global Design 26483.3 295.2 33342.3

File numbersProject Team Site Brief Minutes Planning Research SpecificationPDP1 1 7 1 2

PDP2 3 2 2 4 9 3

APDE 13 12 5

Global Design 4 12 3Project Concept Embodiment Prototyping Deliverables Presentations Unknown/Other TOTALPDP1 18 15 3 47 94PDP2 10 4 37APDE 18 7 3 5 63Global Design 21 2 42

Table 3 Project stages sorted by number of files, total sizes in kB, and percentages of total space


33/61

A. Bennett 32

Looking at the whole project timelines revealed some very interesting trends that occurred within theprojects. It was visually obvious that in each project there was a point about a third of the way throughwhen there was a big drop off in terms of uploading, and that in some there was a distinct period ofuploading 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 whatpercentages of files were uploaded into each period. The results of this can be seen in Table 4. As can beseen, 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 theway 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 ofuploading concluded. Three of the four projects are within 1.7% of each other, and ran over a time periodwhen a difference of a day would change this result by around 0.55%, meaning the times spent on this firstperiod were almost identical. The result for Project 3 is slightly higher than the other three, but since thiswas a short project, a difference of one day would change this result by around 4%, meaning the durationof this period was similar.

The only other pattern to emerge from this was that period 2 of uploading started around the same timefor three of the four projects; that is within 2.8% of each other. The other project did not have a secondperiod of uploading as such, just a single file uploaded in the middle. The only other conclusion that can bedrawn from this is that there are large percentages of time in each project when no files are being uploadedand shared.

Another area examined across all four projects was whether or not certain project stages consistently fellwithin certain parts of the timeline; for example, if the concept stage always started between 35 and 40% ofthe 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 ofthe 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 thatdesign projects are generally flexible and fluid, with stages differing in length depending on the particulardesign 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 tothat stage being uploaded either far earlier or, more commonly, far later.

Project Period 1 Uploads Period 2 Uploads Period 3 Uploads

Project 1 43.6% 43.6% 12.8%

Project 2 64.9% 35.1% N/A

Project 3 78.6% 16.7% 4.7%

Project 4 74.6% 1.6% 23.8%

Project Period 1 Start Period 1 End Period 2 Start Period 2 End Period 3 Start Period 3 End

Project 1 0% 31% 52.1% 63.4% 99% 100%

Project 2 0% 30.2% 54.9% 63.4% N/A N/A

Project 3 0% 36.7% 52.4% 71% 90% 100%

Project 4 0% 31.9% 76.4% 76.4% 87.5% 100%

Table 4 Percentage of total uploads in each period

Table 5 Percentage through project of periods of uploading


34/61

A. Bennett 33

6.2.6. Conclusions

The most obvious conclusion from studying the files uploaded for each project was