1. Oct. 31
IJASCSE Vol 1, Issue 3, 2012
BARRIERS SURROUNDING KNOWLEDGE TRANSFER IN NON-COLLOCATED
SOFTWARE ARCHITECTURE DEVELOPMENT
Marzanah, A.J., Salfarina, A., Abdul Azim, A. G., AND Rusli, A.
Faculty of Computer Science and Information Technology,
University Putra Malaysia
Abstract—Abundance of efforts have I. INTRODUCTION
been endeavored to investigate the Today, the development of software has
barriers of knowledge transfer (KT) that evolved tremendously from being
exist in various level within organizations. concentrated at a single site to being
The structure of non-collocated team geographically dispersed. The distance
amplifies the complication of the KT. between the different teams can vary from a
Despite efforts put forth, not much is few meters (when the teams work in adjacent
known about KT in software architecture buildings) to different continents (Prikladnicki,
development, a setting that is very much 2003). Such distributed environment allows
knowledge intensive. KT is crucially team members to be located in various
essential as for making design decisions remote sites during the software lifecycle,
in developing software architecture, many thus making up a network of distant sub-
factors and inputs need to be carefully teams (Jimenez et al. 2009). In some cases,
considered and accounted. The purpose these teams may be members of the same
of this paper is to discuss and outline our organization; in other cases, collaboration or
perspectives regarding the barriers outsourcing involving different organizations
towards effective KT in this particular may exist. The primary influence to this
environment. We believe that the outcome phenomenon stems from huge savings or
sound business reasons that include
will deposit valuable contribution
reduction in workspace costs, increased in
particularly in the study of KT in non-
productivity, labor cost, better access to
collocated software architecture global markets and environmental benefits.
development and enrich the knowledge Notwithstanding these benefits, such
management literature in general. environment is fraught with challenges.
Software architecture is about making
Keywords-Keywords: Knowledge transfer
design decisions based from the user
(KT), non-collocated software requirements. Typically these design
architecture, barriers. decisions are not well explicitly documented
but remains to reside in the mind of the
software architects or software designers (van
der Ven et al. 2006). This has caused lost of
www.ijascse.in Page 1

2. Oct. 31
IJASCSE Vol 1, Issue 3, 2012
the important knowledge underlying the II. KNOWLEDGE TRANSFER (KT)
decisions (the architectural artifact), including KT is the dissemination of knowledge from
the evaluated alternatives, trade-offs and one individual or group to another within the
rationale about the decision made. Amplified organization. It may be purposely transferred,
by the distance between teams, the or it may occur as an unintended outcome of
interdependencies between them are other activities (Joshi et al., 2006). As
challenged by the decreased of opportunities asserted by Appelbaum and Steed (2005),
for face-to-face interaction while relying “…knowledge are best learned through
heavily on the documentation. The challenge exposure to and experience…”. This is further
continues in terms of limited utilization of the supported by Newell (2005) where according
knowledge areas used and exchanged due to to her, KT implies that each individual or
the arising difficulties in establishing an group or organizational unit need not learn
effective medium for KT between non- from scratch but can rather learn from the
collocated teams to connect with each other. experiences of others. Therefore in this
Additionally, the intensification of these paper, we adopted the definition of KT as the
challenges is increased by the differences in process through which one unit learns from
capabilities and work experiences that exist the experiences of others (Argote &
between the teams. Moreover, the importance Todorova, 2007; Darr & Kurtzberg, 2000).
of software architecture development is From our perspective, KT is about the
acknowledged for it is where the integration of integration of knowledge and experience
knowledge mostly happens. It does not only between people from various backgrounds
provide the blue print of the whole system or and expertise. This is in line with the
software to be developed, but it can knowledge intensive perseverance in
determine the success or failure of the software architecture development, which
development itself. In this paper, our interest demands such integration. These people
is geared into understanding the barriers need not only sharing but also learning from
surrounding effective KT in non-collocated each others’ experience to ensure that they
software architecture development. It is our can accomplish their tasks. It is also believed
belief that in order to achieve effective KT that the definition of KT must cover the use of
particularly between non-collocated teams, it knowledge on the part of the receiver
is crucial that these obstacles must first be (Devanport & Prusak, 2000; Darr & Kurtzberg,
understood so that new perspectives and 2000) and not simply by sharing of the
solutions either to overcome or increase knowledge between units. This is particularly
those impacts on KT can be provided. important to distinct the overlapping terms
In the next sections, the current body of between KT and just knowledge sharing, and
literature reviewed in this study is explained, also makes it easier to verify that KT has
and followed by the discussion on barriers to occurred by investigating those cases
effective KT in non-collocated software involving use, which can be observed and
architecture development. The paper then measured (Darr & Kurtzberg, 2000). Given all
ends with conclusion section. these definitions, we can foresee that the role
KT plays is critical to ensure the continuity of
www.ijascse.in Page 2

3. Oct. 31
IJASCSE Vol 1, Issue 3, 2012
success to the organization, and also to the and problems. Secondly, it captures early
capability development of those involved in design decisions. In software architecture, the
KT. global structure of the system has been
decided upon, through the explicit assignment
A. Software Architecture of functionality to components of the
architecture. These early design decisions are
The definition of software architecture
important since their ramifications are felt in
includes all the usual technical activities
all subsequent phases. It is therefore
associated with design: understanding
paramount to assess the quality at the earliest
requirements and qualities; extracting
possible moment. Thirdly, architecture is the
architecturally significant requirements;
primary carrier of a software system's quality
making choices; synthesizing a solution;
attributes such as performance or reliability.
exploring alternatives and validating them
The right architecture is the linchpin for
(Uphorn & Dittrich, 2010). In software
software project accomplishment whereby the
development process, software architecture is
wrong one is a recipe for guaranteed disaster.
generally a part of preliminary design in the
design phase. It includes negotiating and B. The Importance of KT in Software
balancing of functional and quality
requirements on one hand, and possible Architecture Development
solutions on the other hand. This means
requirements development and software It is agreed that both analysts and software
architecture are not subsequent phases that architects play important roles in the
are more or less strictly separated, but successful software architecture, and that the
instead they are heavily intertwined. There transfer of knowledge is important in the
are many reasons describing the importance software architecture development. However,
of software architecture phase in software not much is known about KT between
development process. Firstly, it is a vehicle for analysts and software architects a setting that
communication among stakeholders. is very much knowledge intensive. Initially,
Software architecture is a global, often the analyst primarily possesses business
graphic, description that can be knowledge, whereas the software architect
communicated to the customers, end users, primarily possesses technical (including
designers and so on. By developing scenarios architectural) knowledge (Rus and Lindvall,
of anticipated use, relevant quality aspects 2002). KT between these two teams invites
can be analyzed and discussed with various an intriguing intention for discovery of the flow
stakeholders. The software architecture also and nature of the transfer considering the lack
supports communication during development. of its descriptions in the literature. The
This is consistent with the empirical evidence integration of initial knowledge possessed by
by Unphon & Dittrich (2010), where the these teams is seen as a must. More
architecture almost always exists as importantly, there are other elements
knowledge of people applied and surrounding this process (of KT) alongside
communicated answering situated questions the constraints of the environment that need
to be taken into consideration.
www.ijascse.in Page 3

4. Oct. 31
IJASCSE Vol 1, Issue 3, 2012
Software architecture development is outcome of integration of knowledge
where knowledge integration mostly occurs particularly between the analysts and
compared to other phases in software software architects. Through KT, both teams
development life cycles. It is the encounter of can communicate with each other and
two most highlighted roles for developing complete their tasks even when they are
software architecture – the analyst and remotely located. Without KT, the
software architect teams. Both teams are development of software architecture might
specialized in different types of knowledge, be imprecise and does not provide adequate
background and capabilities. Although they information to proceed to the next phase of
are assigned with different job responsibility, development.
they are highly dependent on each other. Making decision is never an easy task.
Software architect needs input from the Software architect is held accountable for
analyst and vice versa to complete each making early design decisions during
other’s objective. But certainly the software architecture development. These
dependency that exists between them is not decisions are partly made based on the input
only limited to the need for delivering their and requirements provided by the analysts.
tasks to develop software architecture. KT is crucially essential as for making these
Instead, at the same time it initiates the design decisions, many factors and inputs
urgency to learn about each other’s expertise, need to be carefully considered and
knowledge and experience, thus creating the accounted. Both teams must provide as much
opportunity for KT. As a result, they create information as possible to ensure that they
new knowledge and increase their own can come out with the best decision for
knowledge possession. Through this software design and at the same time
communication, the software engineer who ensuring that the user requirements are
shares his knowledge also updates his fulfilled.
knowledge (Unphon & Dittrich, 2010). Now
that they are well aware on how and where to C. The Context of Non-Collocated Teams in
locate and access expertise, they are well Software Architecture Development
understood about each other’s accountability,
Sundstrom et al. (1990) define teams as
the process of developing the software
small groups of interdependent individuals
architecture will eventually become much
smoother, faster and less problematic. who share responsibility for outcomes for their
It seems rightly emphasized to rationalize organization. This shared responsibility by
team members implies an agreement as to
the importance of KT since software
the individuals contributing. In many
architecture development acts as a vehicle for
communication among those who are organizations, the team now serves as the
involved. As a blue print that describes the basic unit for transferring and preserving
knowledge (Wu et al. 2006). Studies in
whole software/system, it is a necessity for it
geographically dispersed teams on the other
to be effectively delivered and communicated.
KT determines this by ensuring that the hand, define non collocated teams as a group
software architecture produced is the of geographically distributed and
www.ijascse.in Page 4

5. Oct. 31
IJASCSE Vol 1, Issue 3, 2012
organizationally dispersed workers performing non-collocated software architecture
one or more tasks that are supported by development.
information and communication technology
(Hertel, Konradt, & Orlikowski, 2004). Wilson IV. BARRIERS TO EFFECTIVE KT IN NON-
(2011) defines distributed team as one whose COLLOCATED SOFTWARE ARCHITECTURE
members are separated by distance, such as DEVELOPMENT
when team members are in different To date, research in KT has received
countries. The distribution is either in (a) time, enormous attention especially in investigating
(b) distance, (c) culture, or some combination the barriers or impediments to effective KT
of these aspects. Advances in technology (Ko et al., 2005; Wu et al., 2006; Anna et al.,
have made it easier to organize and manage 2009; Paulin & Suneson, 2012). This
dispersed groups of people. And competitive phenomenon is not surprising since the best
pressures and the needs of today’s global strategy to implement effective KT is by
market workforce have made virtual or identifying and overcoming these
distributed teams a necessity for some impediments. Our study takes slightly
organizations. As the business environment different approach in that we are not only
becomes more global and businesses are determining what the barriers are, but most
increasingly in search of more creative ways importantly, we are looking at them from more
to reduce operating costs, the concept of positive perspectives. We believe that
virtual teams is of paramount importance underneath some of the barriers, lays the
(Foley, 2000). Software development hidden potential contribution on teams’
organizations are no exception. In the context capability. Therefore, we decide to use
of our research, non-collocated software “external conditions surrounding” KT instead
architecture development simply describes of barriers. The following table 1.0
the development of software architecture by summarizes the findings for surrounding
non-collocated teams, which in this case the conditions of KT.
teams involve the analysts and software
architects. TABLE 1. RESULT FOR EXTERNAL CONDITIONS
SURROUNDING KT
III. METHODOLOGY Percentage
External Conditions Frequency
We conducted semi-structured interviews (%)
with 30 industrial experts ranging from the Physical distance 28 93.3
Functional, experience,
analysts, software architects to project and capability 23 76.7
managers from selected MSC (Multimedia differences
Super Corridor) organizations in Malaysia. Lacking of time 20 66.7
Lacking of trust 18 60.0
Using a list of barriers identified from the Reluctance to share
literature, we constructed appropriate knowledge
13 43.3
questions for the purpose of the interviews. Lacking of motivation 7 23.3
The primary intention was to determine their Low awareness of the
value and benefit of
agreement in regards to the list we conjecture possessed knowledge
5 16.7
as the most likely to inhibit effective KT in to others
www.ijascse.in Page 5

6. Oct. 31
IJASCSE Vol 1, Issue 3, 2012
conditions surrounding KT. A typical nature of
As predicted, physical distance was the software project teams (including software
most frequently chosen by the participants as architecture development) does not only
an external condition surrounding KT. This confined into achieving specified purpose but
result is in agreement with Gregory et al. also to work within constraints of time. Time
(2009) and Anna et al. (2009) who highlight restrictions have become the possible reason
the physical distance as one of the main that drives the teams to hoard their
impediments for effective KT. The fact that knowledge rather than transfer and share with
two interdependent teams working distantly others. Participants also highlighted the lack
from one another has definitely reducing the of time to engage in KT as a result for being
ease for KT. The problem with KT becomes too occupied with the assigned task and
even more acute as more and more issues reaching the dateline. This comment is
arose, particularly when the chances for direct consistent with Michailova and Husted (2003),
face-to-face meeting or social communication, in which according to them, people naturally
becomes less and less impractical. The fact focus on those tasks that are more beneficial
that software architecture development is a to them. There was one participant who also
knowledge integration activity, to bridge the commented that due to physical distance,
physical gap is very important. This explains they rarely have the time to identify
the previous findings of mediums used for KT, colleagues in need of specific knowledge.
in which various types of communication By far, lacking of trust has been
technologies have been employed to cater nominated by the literature as one of the most
the communication problems between the common impediments to effective KT
non-collocated teams. (Naftanaila, 2010; Falconer, 2006; Lucas,
The findings are continued by the selection 2006; Reige, 2005; Hildreth & Kimble, 2004).
of functional, experience and capability According to findings in Reige (2005), there
differences as second most frequently chosen are two terms concerning this issue. Firstly,
external conditions surrounding KT. Software there is a lack of trust in people because they
architecture development witnesses the may misuse knowledge or take unjust credit
integration of team members from diverse for it and secondly there is a lack of trust in
backgrounds, experiences, and capabilities. accuracy and credibility of knowledge due to
In addition, being assigned with different roles the source, which the latter was studied by
and functions has consequently increased the Sarker et al. (2002), in their research that
gap between teams. Sarker et al. (2002), in investigate KT among information system
their study found that difference in individual development (ISD) team members.
capabilities undermines KT. Reige (2005) Naftanaila (2010) asserts that most people
also mentions the difference in experience in are unlikely to share their knowledge and
his study regarding barriers in sharing of experience without a feeling of trust. This is
knowledge. particularly true when according to some
The numbers are closely entailed by participants, lack of trust is mainly due to lack
lacking of time (Roux et al. 2006; Reige, of social communication between teams,
2005; Ramirez, 2007) as one of the external since they are not physically collocated.
www.ijascse.in Page 6

7. Oct. 31
IJASCSE Vol 1, Issue 3, 2012
Social communication often realized through perceived by the participants is lack of
informal networks, which is very limited motivation. There is an indication that it is the
considering the nature of non-collocated primary trigger for KT (Ajmal & Koskinen,
teams. Additionally, “…the nature of inter 2008; Frey & Osterloh, 2000;). Many studies
community social relation…where people have been conducted to investigate the extent
have limited sense of shared identity, makes of effect the lack of motivation has, upon KT
the existence of trust less likely…” (Hildreth & (Mclaughlin et al., 2008; Disterer, 2001; Frey
Kimble, 2004). & Osterloh, 2000). Lack of motivation,
particularly extrinsic motivation has been
Reluctance to share knowledge can be raised by many as closely related with
possibly caused by the specialized nature of managerial or organizational issues. This type
the knowledge both analyst and software of motivation is about expected organizational
architect teams possessed. The specialist rewards and reciprocal benefits. On the other
nature of their knowledge, combined with the hand, intrinsic motivation refers to knowledge
extensive lack of interaction which had been self-efficacy and enjoyment in helping others
typical, meant that they had very poor and is very important to help perform complex
understanding of how other functions worked, or creative tasks such as developing
or what their constraints or requirements were architecture. In neither ways, both team
(Hildreth & Kimble, 2004). When asked leader and project manager plays a significant
further about the extent of their agreement role in cultivating the sense of motivation
concerning this as a reason why there is a among team members. In order to fulfill their
reluctance to share knowledge with others, tasks during software architecture
there were seemed to be no deniable. development, KT between teams should be of
However, there were few participants who importance despite of physical distance. An
added personal gain and power (job security) observation reported by one participant
as the causes to become reluctant to share regarding this is that KT has always been
knowledge. This finding is in line with seen as laborious especially in terms of time
Paghaleh et al. (2011). Another finding and effort. The tendency to fully concentrate
perceived from the participants concerning in one’s work in order to catch the dateline
the cause for this reluctance is the inability to explains why KT is seen in such a way. It is
absorb new knowledge due to incompetence important to note, as is mentioned by Milne
or limitation in their existing stock of (2007), that individuals are often motivated to
knowledge: keep their tacit knowledge for themselves
“Sometimes, we feel hesitant to share rather than share it. In software architecture
because we are not so sure we can correctly development, both analyst and software
convey to others what we really want to tell architect teams need to be able to exploit
them …it is better to keep that to ourselves these tacit knowledge.
than giving them the wrong ideas” The participants also chose low awareness
of the value and benefit as one of the external
Another external condition surrounding KT conditions surrounding KT, during software
during software architecture development as architecture development. One possible
www.ijascse.in Page 7

8. Oct. 31
IJASCSE Vol 1, Issue 3, 2012
reason that drives this issue is that they do based organisations. In McCaffer, Ron (Ed.)
not believe these benefits from transferring Proceedings of the 2009 International Conference
knowledge. Even worst, they did not actually on Global Innovation in Construction Proceedings,
Loughborough University UK, Holywell Park,
experience KT although they make claim that Loughborough University, 220-230.
they have. As displayed in typical scenario of 3. Appelbaum SH, Steed, AJ (2005) The critical
general software development teams, they success factors in the client-consulting
often create island of knowledge due to low relationship. Journal of Management Development
awareness that the knowledge possessed by 24(1), 68-93.
the other teams is valuable and useful, which 4. Argote L and Todorova G (2007) Organizational
can help accelerate the completion of their learning: Review and future directions. G. P.
Hodgkinson, J. K. Ford, eds. International Review
tasks. Parallel to this, the intention to transfer of Industrial and Organizational Psychology.
knowledge is refrained by the thought that Wiley, New York, 193–234.
they already possessed a certain level of 5. Darr ED and Kurtzberg TR (2000) An Investigation
knowledge, and thus KT is not much in need. of Partner Similarity Dimensions on Knowledge
When asked their opinion regarding this, the Transfer. Organizational Behavior and Human
participants were unanimously agreed to have Decision Processes, 82(1), 28-44.
been in such state of condition. A few added 6. Davenport TH and Prusak L (2000) Working
Knowledge: How Organizations Manage What
by stressing their uncertainty of the presence They Know. Harvard Business School Press,
of KT, due to lack of understanding of the Boston, USA.
process involved. 7. Disterer G (2001) Individual and Social Barriers to
Knowledge Transfer. Conference Proceedings
IV. CONCLUSIONS 34th Annual Hawaii International Conference on
The main contribution of this paper lies in System Sciences, Los Alamitos, CA:IEEE Press.
the understanding of the barriers or external 8. Falconer L (2006) Organizational learning, tacit
information, and e-learning: a review. The
conditions surrounding KT particularly in non-
Learning Organization, 13(2), 140-151.
collocated software architecture development. 9. Foley SP (2000) The Boundless Team: Virtual
It alarms the presence of these external Teaming. Seminar in Industrial and Engineering
conditions so that those involved may prepare Systems, Master of Science in Technology (MST)
better strategy to facilitate effective KT in the Graduate Program, Northern Kentucky University.
future that can benefit each one of them. It 10. Gregory R, Beck R and Prifling M (2009)
also serves as a useful base for prospective Breaching the knowledge transfer blockade in it
researchers to expand future research in offshore outsourcing projects: A case from the
financial services industry‘. Proceedings of the
barriers of KT. 42nd Hawaii International Conference on System
Sciences. Wikoloa, Big Island, Hawaii.
REFERENCES 11. Hertel G, Konradt U, and Orlikowski B (2004)
Managing Distance by Interdependence: Goal
1. Ajmal MM and Koskinen KU (2008) Knowledge Setting, Task Interdependence and Team-based
transfer in project-based organizations: an Rewards in Virtual Teams. European Journal of
organizational culture perspective. Project Work and Organizational Psychology, 13(1), 1-28.
Management Journal, 39(1), 7-15. 12. Hildreth P, Kimble C (2004) Knowledge Networks:
2. Anna W, Bambang T, Glen MD, Chen L (2009) Innovation through Communities of Practice. IGI
Barriers to effective knowledge transfer in project- Global.
www.ijascse.in Page 8

9. Oct. 31
IJASCSE Vol 1, Issue 3, 2012
13. Jimenez M, Piattini M, Vizcaino A (2009) 24. Paulin D and Suneson K (2012) Knowledge
Challenges and Improvements in Distributed Transfer, Knowledge Sharing and Knowledge
Software Development: A Systematic Review. Barriers – Three Blurry Terms in KM. The
Advances in Software Engineering. Electronic Journal of Knowledge Management
14. Joshi, KD and Sarker S (2006) Examining the 10(1), 81-91.
Role of Knowledge, Source, Recipient, Relational, 25. Prikladnicki R, Audy JLN and Evaristo JR (2003)
and Situational Context on Knowledge Transfer Distributed software development: toward an
among Face-to-Face ISD Teams. In: HICSS 2006 understanding of the relationship between project
- 39th Hawaii International Conference on team, users and customers. Proceedings of the
Systems Science 4-7 January, 2006, Kauai, HI, 5th International Conference on Enterprise
USA. Information Systems (ICEIS '03), 417–423.
15. Ko DG, Kirsch LJ, and King WR (2005). 26. Ramirez A (2007) To Blog or Not to Blog:
Antecedents of Knowledge Transfer From Understanding and Overcoming the Challenge of
Consultants to Clients in Enterprise System Knowledge Sharing, Journal of Knowledge
Implementations. MIS Quarterly, 29(1), 59-85. Management Practice, 8(1).
16. Lucas LM (2006) The role of culture on knowledge 27. Riege A (2005) Three-dozen knowledge sharing
transfer: the case of the multinational corporation. barriers managers must consider. Journal of
The Learning Organization, 13(3), 257-275. Knowledge Management, 9(3), 18-35.
17. McLaughlin S, Paton RA and Macbeth DK (2008) 28. Roux DJ, Rogers KH, Biggs HC, Ashton PJ and
Barrier impact on organizational learning within Sergeant A (2006) Bridging the science–
complex organizations. Journal of Knowledge management divide: moving from unidirectional
Management 12(2), 107-123. knowledge transfer to knowledge interfacing and
18. Michailova S and Husted K (2003) Knowledge sharing. Ecology and Society 11(1), 4.
sharing in Russian companies with western 29. Rus I and Lindvall M (2002) Knowledge
participation. Management International, 6(2), 19- Management in Software Engineering. IEEE
28. Software, 19(3), 40-59.
19. Milne P (2007) Motivation, incentives and 30. Sarker S, Sarker S, Nicholson D, and Joshi KD
organisational culture. Journal of Knowledge (2002) Knowledge Transfer in Virtual Information
Management, 11, 28-38. Systems Development Teams: An Empirical
20. Naftanaila I (2010) Factors affecting Knowledge Examination of Key Enablers. Proceedings of the
Transfer in Project Environment. Review of Hawaii International Conference on System
International Comparative Management, 11(5), Sciences (HICSS-36), Big Island, Hawaii.
834. 31. Sundstrom E, De Meuse KP and Futrell D (1990)
21. Newell S (2005) Knowledge Transfer and Work teams: applications and effectiveness,
Learning: Problems of Knowledge Transfer American Psychologist, February, 120 – 133.
Associated with Trying to Short-circuit the 32. Uphorn H and Dittrich Y (2010) Software
Learning Cycle. Journal of Information Systems architecture awareness in long term software
and Technology Management. 2(3), 275-290. product evaluation. The Journal of Systems and
22. Osterloh M, Frey BS (2000) Motivation, knowledge Software, 83.
transfer, and organizational form. Organization 33. Van der Ven JS, Jansen GJ, Nijhuis JAG, Bosch J
Science, 11(5), 38-50. (2006) Design Decisions: The Bridge between
23. Paghaleh MJ, Shafizadeh E and Mohammadi M Rationale and Architecture. In Rationale
(2011) Information Technology and its Management in Software Engineering. Allen H.
Deficiencies in Sharing Organizational Knowledge. Dutoit, Raymond McCall, Ivan Mistrik, Barbara
International Journal of Business and Social peach (Eds.), 329-246. Springer Verlag.
Science 2(8). 34. Wu WL, Hsu BF and Yeh RS (2006) Fostering the
determinants of knowledge transfer: a team-level
www.ijascse.in Page 9

10. Oct. 31
IJASCSE Vol 1, Issue 3, 2012
analysis. Journal of Information Science, 33(3)
326–339.
35. Wilson, E. M. (2011). Dimensions of Team
Distribution within a Software Team.
Book Chapter in Distributed Team Collaboration in
Organizations: Emerging Tools and Practices- IGI
Global.
www.ijascse.in Page 10