Embed Size (px)
Citation preview
Collaboration in Embedded System
Development
University of Oulu
Department of Information Processing Science
Vesa Mettovaara
Master's thesis
02.06.2005
2
Abstract
Today, when outsourcing and other inter-organizational collaboration is increasing it is important to
study these relationships in order to make collaboration more efficient and to get more out of it. The
purpose of this thesis was to map and reveal both the problems and the success factors in regard to
technical inter-organizational collaboration in the embedded system industry. The study was
implemented by interviewing experts in two target companies. Both companies develop embedded
systems by means of collaboration. Before conducting the interviews, a literature analysis of
different collaboration modes was carried out in order to get a better understanding of inter-
organizational collaboration. The findings reveal that communication, unclear agreements and
security policy questions are the most problematic issues with regard to inter-organizational
collaboration. Success factors, such as logical architecture, effective communication and careful
preparation, can lead to successful results. When software teams are dispersed, the distance makes
communication more challenging because of lack of rich interaction. Technology offers solutions
that can, to some extent, exploit long-distance communication successfully. Communication also
has an impact in team coordination, which is also often found problematic in collaborative projects.
Unclear agreements cause problems because of the competitive nature of customer-supplier
collaboration, for example. Technical details should be included in the agreements. Security policy
issues become a problem when there is a fear of losing competence. The problem is accentuated
when the organization has no specific strategy on what can be told to outsiders. When a product has
a logical architecture and the dependencies within each module are known, the development in
separate sites is easier. Before starting the actual work, preparations should be conducted with care.
The more detailed the plans are, the better. This concerns especially the requirements specifications.
Overall, the specifications should be so clear that there would only be a minimal margin of
misunderstanding. The objective of this thesis was attained, but in order to achieve a better
understanding of the subject further research should be carried out.
3
Acknowledgements
This work has been accomplished at the Department of Information Processing Science at the
University of Oulu. I would like to express my gratitude to my supervisor Dr. Mikko Siponen for
supporting me to carry out this Master of Science thesis. I would also like to thank Dr. Pasi Kuvaja
for making it possible to work in the MERLIN project. I also would like to thank the MERLIN
project, especially researchers Jarkko Hyysalo, Tapio Kuivalainen and Pasi Alatalo for their help.
Furthermore, I would like to express my gratitude to all the interviewees of this study whose names
cannot be mentioned here. For language consulting I would like to thank Maija Myllylä.
Key words: global software development, inter-organizational software development, collaboration
4
1 Introduction..................................................................................................................................6
1.1 Structure ...........................................................................................................................8 2 Collaboration modes ....................................................................................................................9
2.1 Vertical and horizontal integration ................................................................................10 2.2 Equity investments.........................................................................................................10 2.3 Joint ventures .................................................................................................................11 2.4 Technology exchange ....................................................................................................11 2.5 Joint development/R&D agreements .............................................................................12 2.6 Licensing........................................................................................................................12 2.7 Research consortia .........................................................................................................12 2.8 Technology partnerships ................................................................................................13 2.9 Customer-supplier collaboration....................................................................................13
3 Research methods and research settings ....................................................................................17 3.1 Research methods ..........................................................................................................17 3.2 Data collection ...............................................................................................................19
4 Results........................................................................................................................................21 4.1 Problems in collaboration ..............................................................................................21 4.1.1 Communication..........................................................................................................22 4.1.2 Unclear agreements....................................................................................................25 4.1.3 Security policy issues.................................................................................................26 4.1.4 Inflexibility for changes .............................................................................................27 4.1.5 Adaptation to the environment...................................................................................27 4.1.6 Team coordination .....................................................................................................27 4.1.7 Different views...........................................................................................................28 4.1.8 Availability of human resources ................................................................................28 4.1.9 Monitoring the work ..................................................................................................29 4.1.10 Commitment ..............................................................................................................29 4.2 Perceived success factors ...............................................................................................30 4.2.1 Effective communication ...........................................................................................31 4.2.2 Careful preparation ....................................................................................................32 4.2.3 Understanding the cultural differences ......................................................................34 4.2.4 Clear specifications ....................................................................................................35 4.2.5 Logical architecture....................................................................................................35 4.2.6 Effective informing ....................................................................................................36 4.2.7 Competence................................................................................................................36 4.2.8 Other success factors..................................................................................................37
5 Discussion ..................................................................................................................................38 5.1 Problems regarding collaboration ......................................................................................38
5.1.1 Communication..........................................................................................................38 5.1.2 Unclear agreements....................................................................................................39 5.1.3 Security policy issues.................................................................................................39 5.1.4 Inflexibility for changes ............................................................................................40 5.1.5 Adaptation problems..................................................................................................40 5.1.6 Team coordination .....................................................................................................41 5.1.7 Different views...........................................................................................................42 5.1.8 Availability of human resources ................................................................................42 5.1.9 Monitoring the work ..................................................................................................42 5.1.10 Commitment ..............................................................................................................43
5.2 Success factors ...................................................................................................................43
5
5.2.1 Effective communication ...........................................................................................43 5.2.2 Careful preparations...................................................................................................44 5.2.3 Understanding the cultural differences ......................................................................45 5.2.4 Clear specifications ....................................................................................................46 5.2.5 Logical architecture....................................................................................................46 5.2.6 Efficient informing between parties...........................................................................47 5.2.7 Competence................................................................................................................48
6 Conclusions................................................................................................................................49 7 References..................................................................................................................................50 8 Appendixes.................................................................................................................................54
6
1 Introduction
There are three major differences between global software teams and “traditional” local software
teams. These are distance, time zone and national culture. Distance means that developers are
dispersed from each other on different sites. National culture includes language, national traditions,
customs and norms of behaviour. (Carmel 1999, xiii).
Global inter-organizational1 software development has become increasingly common (Heeks, &
Krishna, Nicholson & Sahay 2001, Herbsleb & Moitra 2001, Steinbock 2004). Economic forces are
turning national markets into global markets emerging new forms of competition and cooperation
that reach beyond national boundaries. Besides marketing and distribution this affects on the way
products are conceived, designed, constructed, tested and delivered to customers (Herbsleb &
Moitra 2001). Although inter-organization collaboration and multisite development are becoming
more and more common, they are not entirely new ways of working. For example, for several years
IBM has developed in geographically dispersed mode (Carmel 1999, 17).
Today, strategies guide industry developments, which industry leaders have expanded
and leveraged worldwide. Vendors and operators are no longer the sole agents of
change. The bargaining power of new players in the value chain—contractors, platform
coalitions, software and chip players, content aggregators, and service houses—is on the
rise. In the past, vendors and operators competed through gradual globalization; today,
many players are forced to globalize in order to compete. Concurrently, the power of the
two central players – (primarily European) vendors and operators – over the value
system is steadily eroding as a result of increasing specialization, industry outsourcing of
manufacturing capabilities to highly cost-efficient (primarily Asian) players, and the
entry of the (primarily United States-based) IT leaders.
(Steinbock 2004, 69).
1 Technological inter-organizational collaboration can be defined as “formalized link between two or more independent organizations that brings along a substantial amount of joint technological activity, in which the independence of the original co-operating organizations is preserved.” (Faems 2003, 5).
7
Carmel (1999, 4-16) lists 15 reasons why companies develop software in global teams. The reasons
are catalyst factors (specialized talent, acquisitions, reduction in development cost, globalized
presence, reduction in time-to-market, proximity to the customer), sustaining factors (development
rigor, internal freshness, distance from distractions, professional cadre of software globalist,
experience), size factors (scale, evolving synergies of scale) and “vision” factors (location
transparency, the virtual organization and the virtual team).
According to Weck (2003), inter-organizational collaboration has become one of the key topics in
the 1990s among strategic management research. She states that inter-organizational cooperation
research has mainly focused on examining bilateral or network relationships. The relation between
inter-firm cooperation and the evolution of the whole industry has been examined quite little.
(Weck 2003). Although there are numerous studies about inter-organizational collaboration
research which strictly aims at finding problems of collaboration is difficult to find. There are
studies, for example about coordination and architecture (Herbsleb & Grinter 1999),
communication and distance (Herbsleb & Mockus 2003, Herbsleb, Mockus, Finholt, Grinter 2000),
relationships (Beulen, & Ribbers 2002), trust (Sabherwal 1999), collaboration practices (Paasivaara
& Lassenius 2004) and teams (Carmel 1999). However, I have not found any studies which
concentrate purely on problems in collaborative projects or on the factors and issues that make
collaboration successful.
The research problem is stated as the following research questions:
1. What are the perceived problems regarding collaboration?
2. What are the perceived key factors that lead to a successful collaboration project?
This study focuses on technical inter-organizational collaboration of embedded systems. Companies
can collaborate with each others in many ways. Different collaboration modes are hence examined
in order to get a better view of the nature of inter-organizational collaboration.
This research is important, since it is a known fact that dispersed projects are more challenging than
traditional localized projects (e.g., Carmel 1999, xiii). It is important to study the approved ways to
carry out collaborative projects successfully as well as the problems related to the business
especially now when inter-organizational collaboration is increasing all the time. These are the main
reasons for carrying out this study.
8
This study does not cover the aspects of marketing, production or research agreements. These
agreements are shortly mentioned in chapter 2 but the focus is on technology agreements and
relationships. Nor does this study compare embedded system to non-embedded system.
1.1 Structure
This study is constructed as follows. Chapter 2 covers the results of literature review. In the review
different collaboration modes are presented and examined. Chapter 3 reveals the research settings
and used methods. Chapter 4 lists and examines the results of the interviews. The results are
discussed in the light of literature in chapter 5. Finally, the study ends in chapter 6 where the
conclusions are presented.
9
2 Collaboration modes
Cooperative agreements can take numerous forms from marketing, production and research
agreements to technology partnering. Technological collaboration can be defined as those forms of
cooperation in which a combined innovative activity or interchange of technology is at least part of
the agreement. (Duysters & Hagedoorn 2000, Hagedoorn 1993).
According to Thomson (2001), collaboration can generally be approached in four different ways.
(1) Hierarchical collaboration: individuals perform the tasks assigned to them in isolation of each
other. In a hierarchical model the authority is usually singular. (2) Swap meet collaboration (also
division of labour): individuals perform tasks in isolation but come back together to review or
revise. (3) Asymmetrical collaboration: collaborators cannot be viewed as equal (e.g., teacher-
student collaboration). (4) Dialogic collaboration (also integrative, integrated team or symphony
model): tasks are performed together by all members of the group.
According to Lindström (2003), there are nine different modes of inter-organizational collaboration
modes. She divides the modes in two categories depending on equity sharing. Table 1 below lists
different collaboration modes which are then examined one by one. Because most of the data
discussed in this study comes from experiences from customer-supplier collaboration it is examined
at more length than the other modes.
Table 1. Inter-organizational collaboration modes.
Equity sharing cooperation:
1. Vertical and horizontal integration, including virtual integration (non-equity)
2. Equity investments
3. Joint ventures
Non-equity, contractual alliances:
4. Technology exchange
5. Joint development/R&D agreements
6. Licensing
7. Research consortia
8. Technology partnerships
9. Customer-supplier collaboration
10
2.1 Vertical and horizontal integration
Vertical integration is the merging into a single company of several companies involved in all
aspects of a product's manufacture from raw materials to distribution. Horizontal integration is the
merging into a single firm of several firms involved in the same level of production and sharing
resources at that level. (TheFreeDictionary.com). Vertical collaboration occurs throughout the chain
of productions from the acquiring of raw materials to distribution and after-sales servicing.
Horizontal collaboration occurs between competitors operating at the same level of the production
process, who extend their expertise by sharing knowledge, skills and human resources. Vertical
integration means that the company produces the required input internally and maintains control
over both the sourcing unit and the buying unit. Vertical and horizontal integration can add value if
a company can lower the transaction costs by internalisation or if key suppliers are controlled or
owned by competitors (Lindström 2003).
There are views pointing out that vertical integration should happen only when or if it is critical for
product differentiation. Integration vertically backward can take place to gain necessary inputs and
forward to gain access to cut down distribution channels in order to reduce competition and to allow
a firm to have more control over its prices. Vertical or horizontal integration can be used to gain
bargaining power and to avoid opportunistic strategic behaviour by suppliers or other additional
innovators. Virtual integration can be used instead of vertical integration. Virtual integration means
that original equipment manufacturer’s (OEM) and the suppliers are considered as if they were
inside the company. Unlike vertical and horizontal integration virtual integration is non-equity
agreement. (Lindström 2003).
2.2 Equity investments
Equity investment like minority investment can be seen as a form of cooperation that can eventually
affect the technological performance of at least one partner. Many times it is coupled with
technology exchange agreements. In these equity investments a large company can achieve some
control over smaller company and also it allows them to explore new fields of technology without
full investment. A cross-holding relation between two companies could be of a more equal
11
character. It can be the first step towards integration or closer cooperation between companies
involved. (Hagedoorn 1990).
2.3 Joint ventures
A joint venture occurs when two or more companies pool a portion of their resources within a
common legal organization. A joint venture is a selection among alternative modes by which two or
more company can transact. Joint ventures and research corporations are defined as a combination
of the economic interest of at least two companies in a ‘distinct company’ where profits and losses
are shared according to equity investment. Joint ventures are companies that have shared R&D as a
specific company objective in addition to production, marketing, sales etc. (Kogut 1988).
The potential advantages of joint ventures are associated with the spreading of risks, sharing of
fixed cost, capturing economies of scale, access to the new markets, competitive positioning and
sharing of research efforts. The main reasons for the failures of joint ventures are found in the
different views of the participating companies on strategy and lack of advance agreement on how to
run the company. Problems from economic point of view are reduction of actual competition,
possibility of foreclosure of particular markets and ability reduce potential competition. (Hagedoorn
1990).
2.4 Technology exchange
Technology exchange is the loosest form of technology collaboration. It is not usually defined as a
long-term undertaking. The purpose of technology exchange is to “learn from other organizations,
cost economizing and exchanging strategies to increase the certainty of the technology roadmaps of
the firm.” (Lindström 2003, 63). Hagedoorn (1990) defines technology exchange as technology-
sharing agreements, cross licensing and mutual second sourcing. Technology sharing agreements
can take number of organizational and legal forms. Firms discuss the allocation of established
knowledge or artefacts generated by either by one partner or through collective efforts. Cross
licensing and mutual second sourcing are agreements that have been developed from single-source
technology transfer mechanism. (Hagedoorn 1990).
12
2.5 Joint development/R&D agreements
R&D partnerships refer to standard research and development activity committed to raise scientific
or technical knowledge and the application of that knowledge to the creation of new and better
products and processes. They are specific sets of different modes of inter-organizational
collaboration where two or more organizations share some of their R&D activities. Joint
development refers equity-based joint ventures and R&D agreements usually mean contractual
partnerships, such as joint R&D pacts and joint development agreements. (Hagedoorn 2001). Joint
development agreements can be established between two or more firms, either competitors or
supply chain companies, or with for example governmental programs or university projects
(Lindström 2003). Previously joint R&D partnerships have been considered the least expected form
of inter-organizational collaboration. Recent years have surprisingly indicated that they are
becoming more and more popular (Hagedoorn 2001).
2.6 Licensing
Licensing means, that a company purchases the rights to use another company’s patents or
technology for a single payment and/or royalties of the sales (Lindström 2003). "In licensing
agreements a company is granted the right to use a specific patented technology in return for a
payment. Licensing is a relatively cheap and fast way to acquire a technology. Licensing may be
used when capital is scarce, when important restrictions forbid any other means of entry, when
country is sensitive to foreign ownership, or when it is necessary to protect patents and trademarks."
(Duysters & Hagedoorn 2000, 8). Lindström (2003) counts five types of licensing: traditional
licensing, cross-licensing, sub-licensing, have-made-rights and royalty-free licensing. The sixth
type, a single licensing concerns usually somewhat older technologies and products.
2.7 Research consortia
Research corporations are joint ventures with distinctive research programmes. Both forms are
associated with strong ties between companies (Hagedoorn 1990). Lindström (2003) points that the
key reasons for forming research consortia are to minimize the risk of an individual company in
new technology research, to share costs between number of companies and standardization.
Typically research programs focus on the development of significant new product or process
13
technologies. Business-university activities can be generally categorized as research consortia.
(Lindström 2003).
2.8 Technology partnerships
Technology partnerships are a popular way to cooperate because of their flexibility. “Companies
can enter into technology partnerships with an existing key supplier, a potential supplier, customers,
potential customers and even competitors making partnerships in some cases even three-to four
party partnerships” (Lindström 2003, 66). Hagedoorn (1990) defines technology exchange as a form
of technology partnership.
2.9 Customer-supplier collaboration
Customer buys services from the supplier. Collaboration takes place in teams consisting of
members of both organizations. Teams are embedded into the “bureaucratic arrangements within
the customer and the supplier organizations. The constituting level can hence be understood as a
dynamic relationship that balances the intention and need to collaborate with inherent competing
interests.” (Bjerknes & Mathiassen 2000, 3). Figure 1 shows the relationship between the customer
and the supplier which is enacted on three different levels.
14
Figure 1. Three levels customer-supplier relationship (Bjerknes & Mathiassen, 2000).
People on the constituting level (interactions over time and across different projects) usually include
middle management of the customer organizations and sales and marketing persons from the
supplier organization. Also top management on both sides can be involved. A contract is usually
negotiated by marketing and sales people in collaboration with a project leader from supplier and
middle management and project owner on the customer side. The customer may hire a consultant to
do this task. When the project is running the contract tracking and maintenance is done by a steering
committee with the help of the project leaders or managers on both sides. On development level
actual work take place. The project is carried out by teams on both sides. A project typically lasts
longer for the customer than for the supplier. (Bjerknes & Mathiassen 2000). Figure 2 shows the
important milestones from both contractual and development levels.
Supplier
Contractual level
Development level
Project
Constituting level
Customer
15
Figure 2. Project structure & important milestones (Bjerknes & Mathiassen, 2000).
On constitutional level the customer-supplier relationship can be viewed as a dynamic network of
exchanges that are governed by three types of contractual agreements. These types are teams with
close collaboration, bureaucratic organizational forms and market relationships. In customer-
supplier collaboration companies are dependent on each other, they have their own interest, and
they need to form a coalition of divergent interests” (Bjerknes & Mathiassen 2000, 3). Competition
and divergence is embedded into the economic and structural foundation of the relationship where
collaboration is a short-term and vulnerable dimension that is embedded into the culture of the
relationship. “It is necessary to build and maintain a collaborative environment and culture in which
the underlying competitive nature of the relationship is explicitly addressed and dealt with.”
(Bjerknes & Mathiassen 2000, 3).
There are two kinds of contracts in collaborative projects. A formal, written contract offers
mechanism for structural control and is the results of negotiation process. A psychological contract
is built on trust and consists of a set of unwritten and often unspoken congruent expectations. Trust
is embedded into teams and structural control is an expression of the bureaucratic and market
dimensions of the relationship. Both structural control and trust are needed to deal with unexpected
problems. Projects must continuously seek to balance the two to stay on track. (Bjerknes &
Mathiassen 2000).
The development level of the relationship is where the actual work gets done. “Technical system is
developed or adapted to the customer organization, involving a number of software engineering
Contractual level
Development level
contract signed system accepted end of guarantee
initiation development implementation
problem acknowledged
requirements specified
system accepted
system in use
16
activities. A strong focus on engineering is both natural and needed. But when it is combined with a
neglect of the problems and challenges related to the organization implementation of the new
system it becomes highly problematic” (Bjerknes & Mathiassen 2000, 4). When a new IT system is
introduced to an organization it needs to be done with the practise of hospitality. It needs to be open
and friendly towards new users. Hospitality is necessary due to the ambiguous nature of the system.
Being hospitable means that the new system is taken care of on three different levels: perception,
circumspection and understanding.
Perception means the care that we show to anticipate the new systems. Project teams from both
sides develop shared visions of the new system. Expectations to the new systems are adjusted. An
acceptance test is properly planned. These are all examples of perception. The second level,
circumspection, is a kind of caring that aims at making the use of the new system easier. It can
include user training, ad hoc error correction or workable help desk function. The last level,
understanding is reached when the new system is fully integrated as a part of the customer
organization. (Bjerknes & Mathiassen 2000).
Customer-supplier relation can be divided in three forms which are co-production, co-makership
relations and research contracts. In co-production contracts companies consummate the agreement
to produce a commodity. The ‘leading’ company usually supplies the technology and critical
components whereas the other companies manufacture less critical components and pull together
final products. Co-makership agreements establish long-term contracts between users and suppliers.
Users outsource a part of their production process. Cooperation is found in close contacts on quality
control and planning of supply according to standards. Research contracts regulate R&D
cooperation in which one partner contracts another company to carry out particular research project.
The customer company is usually larger than the supplier one. (Hagedoorn 1990, 24-25).
17
3 Research methods and research settings
This chapter explains the research methods used and exposes the research settings2 of this research.
3.1 Research methods
The research approach is case study in general, and grounded theory in particular. Case study can be
defined as “an empirical inquiry that investigates a contemporary phenomenon within its real life
context, especially when the boundaries between phenomenon and context are not clearly evident”
(Yin 2003, 13). “The case study research strategy comprises an all-encompassing method –
covering the logic of design, data collection techniques, and specific approaches to data
analysis…[it is] a comprehensive research strategy” (Yin 2003, 14).
Data collection is carried out by semi-structured interviews in target companies. Semi-structured
interview (also known as thematic interview) is in between open interview and structured interview
methods. In semi-structured interview the topics of the interview are written down but their specific
form and order is unknown. The respondent can quite freely tell about his experience and opinions.
The interviewer can direct or define the conversation in order to get all the subjects covered
(Hirsjärvi & Hurme 1988, 35-36). “Interviewer’s job is to listen for what the customer is leaving
out and to ask questions that fill the holes” (Beyer & Holtzblatt 1998, 49).
Grounded theory was used for analyzing the data. The theory was developed by Glaser and Strauss
in the 1960s (Järvinen 2001, 65). “The intent of grounded theory is to generate or discover a theory
– an abstract analytical schema of a philosophy that relates to a particular situation. This situation
could be one in which individuals interact, take actions, or engage in a process in response to a
phenomenon.” (Creswell 1998, 55-56). “Classic grounded theory is simply a set of integrated
conceptual hypotheses systematically generated to produce an inductive theory about a substantive
area. Classic grounded theory is a highly structured but eminently flexible methodology. Its data
2 This study was carried out in at University of Oulu within the MERLIN project. MERLIN
project is a collaboration project between several partners in Finland and the Netherlands. It
aims to improve competitiveness and products’ quality in European electronics industry.
18
collection and analysis procedures are explicit and the pacing of these procedures is, at once,
simultaneous, sequential, subsequent, scheduled and serendipitous, forming an integrated
methodological “whole” that enables the emergence of conceptual theory as distinct from the
thematic analysis characteristic of qualitative data analysis research.” (Glaser 2004, 2). Because the
grounded theory is quite complicated to implement and because it usually aims at building up a new
theory it is used in this study only when applicable. In this study where only five interviews were
made it is impossible to come up with any new theories. The purpose was to solve the research
questions and grounded theory was useful for that. In grounded theory there are several steps to
follow. These steps are: (1) open coding: the researcher forms initial categories of information
about phenomenon being studied by segmenting information. Within each category, the investigator
finds several properties or subcategories, and looks for data to dimensionalize, or show the extreme
possibilities on a continuum of, the property. (2) Axial coding: the investigator assembles the data
in new ways after open coding. This is presented using coding paradigm or logic diagram in which
researcher identifies a central phenomenon (i.e., a central category about the phenomenon), explores
causal conditions (i.e., categories of conditions that influence the phenomenon), specifies strategies
(i.e., the actions or interactions that result from the central phenomenon), identifies the context and
intervening conditions (i.e., the narrow and broad conditions that influence the strategies), and
delineates the consequences (i.e., the outcomes of the strategies) for this phenomenon. (3) Selective
coding, the researcher identifies a “story line” and writes a story that integrates the categories in the
axial coding model. In this phase, conditional propositions (or hypothesis) are typically presented.
(Creswell 1998, 57).
The result of this process is a theory, close to a specific problem and taken to further testing
(Creswell 1998, 57-58). In this study where no theory was developed grounded theory was applied
in the following way. First, extensive and specific notes were written from the tapes. From the notes
different categories were written inside the margin of the notes (categories e.g., communication &
data security). After identifying the categories their properties were listed and attached below them.
Among all the categories the main phenomenon was explored. Then all the categories and main
phenomenon were assembled together in bulletin board. After that the connections between
phenomenon and categories were explored. Finally the “story line” was identified from the
description of bulletin board.
19
In the results I will validate my findings by quoting the interviewees and expressing exactly what
the interviewees told about the topic. The quotes help to understand the respondents’ views and
opinions. I will use both “short eye-catching” quotes and longer quotations.
3.2 Data collection
When choosing the target company the criteria stressed the experience in collaboration. In the
beginning the purpose was to interview several companies, but due to the time schedule it was
decided to reduce the number of target companies. After the interviews in the first company were
implemented it was realized that the there were enough data to carry on without more target
companies. Later on, there became an opportunity to interview another company so the number of
target companies aroused to two. The selected companies are large and well-known in Europe. They
have experience with embedded systems and subcontracting from many years. The interviews were
based on the overall experience of collaboration, not on any particular project or partnership.
The interviews were implemented in January and February of 2005. There were five interviews in
two companies with three interviewers.
Table 2. The interviews.
Interviewee Position in organization Experience from collaboration Interviewers
A1 Senior Software Engineer Over ten years experience of
subcontracting and internal multisite
software development
Int1 & Int2
(telephone
interview)
A2 Head of Department Over five years experience of
subcontracting and multisite
development
Int1 & Int2
(face to face)
A3 Project Manager Over ten years experience including
joint ventures, subcontracting and
multisite development
Int1 & Int2
(face to face)
A4 Testing Engineer Four years experience of multisite
projects mainly in testing.
Int1 & Int2
(face to face)
B1 Consultant Experience from subcontracting and
multisite software development
Int3
(face to face)
20
In company A, all the interviewees were currently working within the same project, but in different
positions or geographical location. They also had experience from collaborative work in previous
projects. The interviews lasted from 45 minutes to 80 minutes and were all recorded. Then accurate
notes were taken from the tapes for analyzing the data. The tapes were also partly transcribed, but
due to the tight time schedule there was no time to transcribe everything. Later, when analyzing the
data, if something interesting came up from the notes it was transcribed completely to get an exact
idea about the issue.
The companies and the interviewees are named with letters and numbers. There is “Company A”
and “Company B”. Interviewees in “Company A” are presented as “Interviewee A1”, “Interviewee
A2” etc. From “Company B” there was only interviewee who is named “Interviewee B1”.
Most of the experiences that the interviewees had were in customer-supplier collaboration (from the
customer’s side) and in multisite software development. At least one interviewee also had
experience in joint ventures.
21
4 Results
Communication, unclear agreements and security policy issues seem to be the biggest problems in
collaborative projects. The success factors found were good communication, careful preparations,
understanding each other, clear specifications and logical architecture among others. The problems
and success factors found are first listed in table in the beginning of the sections and then examined
later on.
4.1 Problems in collaboration
This chapter lists and examines problems found in the data. According to interviews, the biggest
problems were communication, unclear agreements and security policy issues. The problems are
first listed in Table 3. Examination of each problem follows later.
Table 3. Perceived problems regarding collaboration.
Problem: Main points:
1. Communication - Distance
- Miscommunication
- Becoming friends takes time (trust)
2. Unclear agreements - Contracts are made without
technical people
3. Security policy issues - Fear of losing competence
- Uncertainty of what can be said
4. Inflexibility for changes - “Who is going to pay for this”
5. Adaptation problems - Adapting to the customer’s
environment can be a problem to the
supplier
6. Team coordination - Distance
- Organizational barriers
- Poor communication across sites
7. Different views - “Views can be very wide-ranging”
8. Availability of human resources - The risk that people change during
22
the project is higher in collaborative
project
- Booking resources is more difficult
9. Monitoring the work - Difficult if the work is done on the
other side of world
10. Commitment - When every party is not fully
committed to the target there is less
chance of success
4.1.1 Communication
According to the interviews, communication seemed to be the most critical issue in collaboration. It
was among the most discussed issues during the interviews. Also, communication has mediation on
other issues e.g., team coordination. This does not necessarily mean that communication would be a
problem if it is well taken care of. All interviewees agreed that in order to achieve a successful
result, communication must work properly. One interviewee refused to call communication a
problem; it just has to be carried out well. In this chapter the problems with communication are
listed. In chapter 5 interviewee’s experience of how to improve communication are listed.
According to the respondents, experience to learning to communicate with each other takes time.
When you learn to know somebody then the communication gets easier. If you do not have
opportunity to meet face to face with all the team members working together is harder.
The weak point is say, when software engineering and software development gets in. How
do we work together? (…) There has been a management team that defined this “perfect
solution”, there are purchasers and legal people from both parties who know each other.
They have been talking, chatting, dealing, making a contract. And then it takes months
before the technical people start to know each other, become friendly (…) you start to call
each other, then you come to the conclusion that there are integration problems, interface
problems and then you start to fly over and then you meet the technical guys and then it
appears that they are not that bad guys at all. They also try to do the job. Because of not
being well prepared you lose months there.
Interviewee B1
23
[In the project] there appeared to be deep, deep troubles. The teams did not know each other
[and] because the interface was not clear people did not know who to complain to. All kinds
of things. (…) because the software didn’t integrate so people needed to fly over and over
and then they found out that they were good guys after all and worked together very well.
[In] the second generation [of the product] all the people who knew each other stayed in so
that worked fine. There was one new party going in, of course they [the other parties] forgot
to inform them and have a kick-off session with them and explain (…) when the real work
was on, all the problems came again. And we could have avoided them by a proper start.
Interviewee B1
When the team is working in the same building communication seems to be much easier. You see
the people all the time and you can chat with them constantly. “Interviewee A1” told about
managing the requirements and architectures in collaborative projects:
If the people work in the same building you can handle things pretty easily just by chatting
to each other when you see them. These off-the-record conversations can be very effective.
You cannot do that when people are dispersed and you do not know them so it really helps
when you can work on the same site.
Interviewee A1
Because of long distances meeting face to face is not always possible or useful. Interviewee’s in
“Company A” told that they use phones, e-mail and NetMeeting3 for distance communication. They
said that e-mail is really good because you can read it whenever you want. With e-mail you can also
reach many people with the same amount of effort. However e-mail seems not be a sufficient
communication tool by itself. Sometimes there is a need to solve a problem with the help of other
communication tools.
3 NetMeeting is a product that enables users to teleconference using the Internet. NetMeeting supports voice, chat sessions, a whiteboard, and application sharing. It is a developed by Microsoft and built into Microsoft's Internet Explorer Web browser. (The Engineering Education Centre).
24
When problems occur you send an e-mail about it. Then the e-mail goes from one person to
another and it is sent back to you. If the problem is not solved and you again send an e-mail
about it to someone else with no results, then you must pick up a phone and start dealing
with the problem. Usually it helps.
Interviewee A3
E-mail has also other kind of problems. Interviewees said that when writing an e-mail you have to
be careful how you present things. People can easily misunderstand or feel offended if they do not
understand your message correctly. When writing to a person who is from another culture this
becomes very important. The third problem related to e-mail is that you cannot be sure that it
reaches its destination.
In my previous project for instance, I tried to hang on so that I always had less than 100
unread messages in my mailbox. I tried to keep it below a hundred but then it all somehow
collapsed. There were something like 120 unread messages in the mailbox. Then I started to
check who had sent the e-mails and just opened the ones that I thought might be important.
I said to myself that okay, maybe the other ones will phone me if they have something
important to say.
Interviewee A3
Telephone is used in personal communication and in conference meetings aside with NetMeeting
programs. Possible problems with telephones are weak lines and the fact that communication is not
that efficient without actually seeing another. Because you cannot use gestures and you cannot see
the impact of your talk there is higher possibility for misunderstanding. Two respondents told that
they have had problems when speaking with foreign partners. When the line is poor and the person
you are calling has a very strong accent it is difficult to understand one another.
Our partners have strong accents and the telephone line is also poor. So when they speak
there can be words missing because of the weak line. You have to concentrate fully to be
able to understand what they say. When we start working with new project and we do not
know all the details yet, it is extremely difficult to communicate with people from a different
culture and with a different language. I was in telephone conference with our partners
25
recently. After thirty minutes I started to sweat and after two hours I became completely
exhausted. I could compare it to a 10 kilometre run. The brains have a challenging job
processing meaning from foreign language spoken with strange accents through a poor and
trembling phone line. It is very exhausting.
Interviewee A1
According to the interviews, NetMeeting is quite suitable for collaboration. It was in regular use in
“Company A” and none of the interviewees from the company criticized it. Although, “Interviewee
A3” told that people do not necessary pay attention when something is presented via NetMeeting or
PowerPoint show but instead they read their e-mails etc. at the same time. When you are using a
traditional flip chart everybody in the room is focusing on that. Of course these flip charts cannot be
used in distance communication. There were also cases where the installation of NetMeeting
software did not succeed so it could not be used. “Interviewee A3” also said that after a certain
stage in development has been reached, sharing the documents on computer monitor is no longer
very efficient. Conference phone linked with Web camera is not very useful according to the
interviewees. The quality of the picture is usually so low that it does not bring any additional value
to the meeting. Other communication channels were the project webpage and some collaborative
tools for sharing files. According to the interviews these tools worked more or less without
problems.
4.1.2 Unclear agreements
Interviewee from “Company B” said that unclear agreements are among the biggest problems in
customer-supplier collaboration. In figure 2, there are the three levels of customer-supplier
relationship. According to “Interviewee B1”, the agreements are made on a high management level
with the legal people (contractual level) and the development level is usually left out from the
negotiations. After the agreement is made the technical experts are invited to come along. At that
point it is usually too late to include any important details in the contract.
(…) and later on they [technical people] come on board [and the management level say:]
‘you are going to be software integrator and that is your supplier’. Then they [technical
people and supplier] start to talk, start to make a plan – that’s too late (…) [Supplier says
that] ‘we supply the software – we did not made any agreement about how we should test it,
26
how we should accept it, what kind of a the documentation we should provide, what kind of
plans we should provide – that was no part of the deal’. So they don’t feel committed to it.
Interviewee B1
According to “Interviewee B1”, high management level hardly realizes these problems because the
people change quite often and it can almost be described as “virtual organization”.
Some manager or management team at some moment in time defines the new product and
how it should be composed with the parties and two months later they do not exists
anymore. Somebody has taken their seats and there you are forced to work each other with
only badly prepared plans and badly prepared context. So there is no real learning. It is
getting better (…) because of [new systems that] monitors let’s say the performance of all
those projects [and] generate ‘lesson learned’ out of all those practices and feed them back
to managers. So, its starting to get better (…) [but] we still make mistakes.
Interviewee B1
4.1.3 Security policy issues
Risks may occur from acquisitions or when your partners do business also with your rival(s). In
security policy issues opinion divided in two sections. Two interviewees in “Company A” saw
security policy issues are a major question in collaboration. They felt they restrained them to
operate with full arsenal for the project. The other two said that in their work all the necessary
information is shared and the contracts protect the security issues.
(…) it would require a clear strategic vision from the company to show what kind of a
information you can share, and how you can tell it…in the current case it would have been
easier if someone would have told what information you definitely can’t share and what you
can. It would made things to go faster in the beginning of the project.
Interviewee A1
27
Our strategy is that everything that relates to the project is told and the partner cannot tell
anything to anyone outside the project. (…) In risk situations these things are analyzed and
action points are listed. In case of an acquisition NDA’s4 are still valid and if the risk
becomes true we usually have a clause the stop the collaboration with the subcontractor.
Interviewee A2
4.1.4 Inflexibility for changes
Usually when changes occur it costs money. “Interviewee A3” said that when changes appear the
first question is: “who is going to pay for this?”
4.1.5 Adaptation to the environment
According to “Interviewee A3” subcontractors have sometimes difficulties to adapt to the customer
environment. It makes collaboration more difficult.
[It is problematic] if the supplier-organisation is not mature enough to adapt itself to the
environment in which they operate. And it is not that they would not want to but the fact that
it is so expensive for them. They cannot assimilate themselves with the customer-
organisation. It is only about the lack of processes, responsibilities and these kinds of things,
things that the CMM-model tries to increase. It is too expensive for the supplier.
Interviewee A3
4.1.6 Team coordination
“Interviewee B1” said that team coordination is an extremely important issue in order to get people
working effectively with each other. When you are working with other companies, which can be
very hierarchical, coordination can be difficult. “Interviewee B1” said that team members at
4 Non-disclosure agreement.
28
development level should meet each other as soon as possible. They also should take part in
preparing the agreement in order to make it more specific from a technical point of view.
4.1.7 Different views
Understanding the documents properly seems to be a serious problem in collaborative projects.
Every interviewee mentioned this at least once during the interviews.
Views can be very wide-ranging if we do not spend enough time making everything clear
for everyone. And when we do not share equal views of the application, the project or the
purpose of whole thing the project can fail purely on that.
Interviewee A2
“Interviewee A2” told that when the collaborative partner (subcontractor) joins the project the
specifications could be written with the subcontractor even if it is already written among own
people. So the specifications could be written twice just to develop a shared view. “Interviewee A4”
said that you must talk constantly (e.g. once a week) about the specification to clarify the “picture”.
4.1.8 Availability of human resources
When people from several companies work on a project the risk that people change during the
project becomes higher. An interviewee’s opinion was that when the same people stay in the project
working is much easier. In case of body shopping when some person is booked up for a particular
period of time and the customer’s time scheduling does not count then the customer must pay for
the work contribution that did not exist.
It must be said that in some cases there can be advantages in buying services from another
company. You do not necessary have to worry about the missing human resources:
When working with our own employees and for example somebody that you need from
another unit is on vacation there is not much that you can do. You just have to wait a month
29
for him to return back to work. But in collaborative projects when a supplier says something
like that you can just ask why he is telling me about this, it is not my problem.
Interviewee A3
4.1.9 Monitoring the work
Problem related to monitoring the work might occur especially in customer-supplier collaboration.
If there are no practices on how the progress should be reported, monitoring may be almost
impossible. How can you make sure that the work is progressing as you have agreed with the
partner? Is the project proceeding in the time schedule?
We have had problems monitoring the progress of the work. In the beginning we did not
make regulations of how the code, output and documentation should be maintained so that
we could instantly see what have been done so we could monitor the work online.
Sometimes when I was busy doing other things and did not have time to supervise the work
I just had to believe that everything was going okay. I just had to trust that everything is
going to be like it had been discussed. When you are in the same building it is so much
easier, you can chat to people when you see them but now all of this must be taken care of
and you must pay more attention to it.
Interviewee A1
4.1.10 Commitment
“Interviewee A2” said that lack of commitment can be a big problem in a collaborative project.
When every party is not fully committed to the project the chances of success decline dramatically.
“Interviewee A4” said that in the beginning the parties try to create a win-win situation to assure
everybody’s motivation in the venture. When a project is a win-win situation for all the partners the
motivation is usually high and chances of success are better. One of these kinds of win-win
situation that came up during the interviews was a case where a supplier after having developed the
software exploited it in its own product. At the same time the price for the customer was lower.
30
4.2 Perceived success factors
During the interviews people were asked about the factors that have major impact for the success of
the collaborative projects. Many of these factors are related to each other. According to interviews
knowing a partner from the past helps when working together. Communication is easier and you
already know each others way of working. Found key factors are presented below.
Table 4. Perceived success factors regarding collaboration.
Perceived success factors: Main points:
1. Effective communication - Meeting face to face in the beginning
- Constant meetings (e.g. once a week)
2. Careful preparations - Development level together with
management and legal experts
- Attention to requirements specification
3. Understanding the cultural
differences
- Understanding partners culture
- Understanding partners goals and way of
working
4. Clear specifications - Unambiguity and clarity
- All details included
5. Logical architecture - Every piece must work with each other
- Team work
6. Efficient informing between parties - Everybody must stay updated on latest
events on the project
7. Competence - Talented people can lead to success
- Buy competence when you need it and
invest only in your core business
8. Other factors - Interface management
- Software configuration management
- Requirement specifications
- Good interface
31
4.2.1 Effective communication
According the interviews, communication in collaborative projects is more important than in local,
traditional projects. All interviewees agreed that in the beginning of a project is important to meet
the team members. “If you really want to develop something new it is the only way to make it
work,” said one of the interviewees. Seeing face to face helps to produce a mutual vision of the final
outcome. Kick-off session should be arranged early enough in order to get the best out of it.
“Interviewee A3” said that nowadays meeting face to face is not so usual than it was before.
Previously you could fly to two-hour meetings regularly, but now the meetings are virtual. It is also
difficult to arrange any joint events (a dinner parties etc.), where all the partners could participate.
Communication gets easier if there is chance to meet the people face to face. One time is
usually enough. And if you get to know somebody you do not have to think how you speak
with him. When you can tell jokes or talk freely communication gets so much easier.
Interviewee A1
In the early stages you should get together in a hotel or a camping or whatever to start to
understand each other, each other’s way of working and achieve a mutual understanding of
what exactly is expected from [the project].
Interviewee B1
Every interviewee thought that constant meetings (e.g. once a week) are good, even when there are
no urgent issues to discuss. On the other hand these weekly meeting should have a compact time
limit (strictly 1-2 hours or less) in order to keep them efficient. External partners should also be
invited to these meetings in order to keep up the good spirit among the project team.
Once a week we have a two-hour meeting. Some people invite external partners to the
meetings only if it is needed. In order to maintain the team spirit I always invited everybody.
I have been thinking that we have a mutual target in the project. If there is a case that in the
meetings there are people who should not be there then some serious errors have been made
in the beginning of the project. In my meetings people used to bring their personal SWOT-
32
analyses. In a SWOT-analysis every member of the team tells what they have been doing
during the past week, what they are going to do the following week and point out possible
problems related to his work. We try to solve these problems immediately in the meeting or
at least to suggest how it can be solved later.
Interviwee A3
In case of a virtual meeting where people participate from different geographical sites a good phone
line and file sharing in a computer pane are sufficient. There is no need for any videoconference,
“Interviewee A3” said. Overall, NetMeeting is workable but in case problems come up, meeting
face to face usually gives the best result. Sometimes a problem can be solved with a simple insight
like in the next example.
(…) recently I tried one way of communication successfully. I explained about this
complicated issue to my colleagues here and at the same time I drew picture of it on a flip
chart. Then I took a picture of the drawing and sent it to our partners at the other site. They
responded that they now understood it. Before sending the picture they [partners] had
problems to understand the issue.
Interviewee A1
Informing is strongly related to communication. Interviewees also pointed out that informing must
be well organized and effective. “Interviewee A2” said that they are moving from e-mail based
informing towards intranet based informing practices.
4.2.2 Careful preparation
Here are presented the interviewee’s visions on how to provide a good start for a project. Every
interviewee thought that the preparations for collaborative project should be made more carefully
than in traditional projects. Interviewee from “Company A” thought that it is better to start the work
by own people and prepare it with time and the interviewee from “Company B” said that the
communication with the other party should start as soon as possible. The main thing is that the
preparations get enough attention.
33
According to “Interviewee B1” it is important to go get the right people together as soon as possible
before signing the contract.
What should be done is at the moment that the decision is taken that you say [to the
supplier] ‘okay, that is the software integrator party from the [customer organization] of the
project, take him or more to open discussions and prepare together with him all the steps so
that his input is there and the contract is made.’ And a good way would be that you make
the legal contract which points to technical documentation and which points to the real plan
so that is a part of the deal. And [many times] that is done too late.
Interviewee B1
According the interviews the first thing that you should do is to learn to know each other. When you
collaborate with people that you already know you save time and effort. According to one of the
interviewees, the companies should have a policy that helps to learn to know the new partners. It
could be very useful to set up a workshop for a few days before actually starting the project and
before the kick off session. Like “Interviewee B1”’s quotation shows above, people in the
development level should meet before making the agreement and they should participate when
negotiate about the contract. But even before you choose a partner to a project you should spent
enough time in preparations. This includes making the requirements in the level that partner
candidates can understand it as clearly as possible. Also the goals and resources have to be analyzed
well before starting the project.
In collaborative projects the requirements should be made more accurate than in internal and
local projects. For instance, we could here by our own draw something on a packet of
cigarettes and somebody would start working with that and the specifications would be
developed along the way. If the project is outsourced in a way that we can have realistic and
comparable offers the requirements should be done carefully. Usually the requirements go
quite deep so that we here argue about some minor details, e.g., the name of some text field
in some tool. The other fringe is that requirements state that a car is needed. You have to
start specifying whether the car should be a bus, a truck or just a passenger car. It is difficult
also to the supplier if you say that you need a car so give me an offer. (…) The goals and
resources must be realistic if you contract out some project. And there is also a risk if you
34
put out suppliers to tender and you compete the price too low. The project fails and the
damage is usually much bigger than if you had paid a little more for it.
Interviewee A3
4.2.3 Understanding the cultural differences
This topic includes several aspects which seem to be important. The more you know about your
partner and his way of working the better. First, there are cultural aspects. Every nation has its own
culture and you have to know it in order to make collaboration work.
Indian people never say ‘no’. You tell them to do something and if they don’t know how,
they stop. You have to understand that, that’s their culture. They have to understand that
reviewing something is not punishing something. That is something you need to teach them.
Interviewee B1
You have to be careful when you communicate in order to avoid misunderstanding. In Far
East there are these loss of face issues so you have to be careful. If you take the traditional
Finnish approach and just talk about the project and criticize without thinking it might cause
troublesome situations.
Interviewee A1
The cultural aspect works the other way round too. If the collaborative partner does not know your
culture it might become a problem. Sometimes the situation is really concrete. “Interviewee B1”
told an example where his company invited the subcontractors to visit in his country to learn about
televisions, the end-product where the software would be developed.
[X] years ago we started to develop software for [common electronic device] in India. Well
educated, very intelligent software engineers. They did not even know what [this device]
was! Those guys make software for [the device] – what do you do? What do you need to
do? You need take them here [to my country] to see what it is, open the box get them trough
a course [of what the device is and how does it work] (…) and then they start to understand
35
what is done to hardware and what is done to software to understand what is expected from
it.
Interviewee B1
The key to understanding the partner’s goals and the way of working is communication. Then it is
easier to develop a mutual vision of a project and create a win-win situation. When there is a win-
win situation the motivation is usually high and changes to success gets better.
4.2.4 Clear specifications
In order to avoid misunderstanding and create a mutual vision of the project, specifications should
be unambiguous and clear. According to the interviewees disorganised specifications cause often
problems situations. It seems to be difficult to avoid misunderstanding that rises from insufficient
communication and unclear or incomplete specifications.
In practice when you are writing requirements on a flip chart, you group them and link them
together and it all seems clear as a day. But when you really start applying the requirements
and thinking about them it is not that simple anymore. At the worst, you can end up fighting
with each other about the system and it can get complicated. You should have a separate
competence for gathering the requirements, some kind of competent facilitator for gathering
the requirements.
Interviewee A3
4.2.5 Logical architecture
One of the interviewees said that logical architecture is the most critical factor in collaborative
projects. When the architecture is connected with other areas like requirements, interfaces, software
configuration management and interface management it must be well designed in multisite projects,
“Interviewee A1” said. He also thought that these issues are quite project-specific. Sometimes
everything goes smoothly and sometimes the architecture is very problematic.
36
If we have a clear and logical project plan, logical system architecture and we can link these
things to other sectors geographical dispersion of the work does not do so much harm. But if
we do the parts separately not thinking about the software architecture and how it all works
together we may face problems afterwards.
Interviewee A1
Architecture issues came up also when interviewing employee from “Company B”.
You think you understand the interface, you make the software components yourself you
test it yourself, you integrate and then you come to the conclusion that there is different
implementation in the interface. The funny thing is when the technical people sit together
[they say:] “Oh, you meant that by it I thought you meant that.” And that could have been
avoided at such an early stage. It is mainly in integration. The first steps of integration take
enormously long [time] because the software does not clue together at all. So that is where
you see it. And then you start to analyze and you come to the conclusion that often here, in
managing requirements and architectures, that is where the mistakes are made.
Interviewee B1
4.2.6 Effective informing
Effective informing between all the members of the team is also a very important issue in
collaboration. Everybody must stay updated on latest news in the project. This is strongly related to
communication. “Interviewee A3” said that they are moving towards webpage based informing that
every member can access.
4.2.7 Competence
According to the interviews competence seems to be one of the reasons why companies collaborate
with each other. When you get talented people in your project you can get successful results.
However sometimes these competence issues are left to secondary values. For example if you get
cheaper programmers somewhere you choose them even if you know there is going to be more bugs
in the code. Or if you have to get the product e.g. to Christmas markets you get the resources where
they are available and do not to pay so much attention to quality issues. Overall it can be said that
37
competence is a very significant reason for collaboration. The companies do not have to keep so
many professionals on their payroll. They can focus more on their core business and buy certain
competencies when needed.
4.2.8 Other success factors
“Interviewee A1” stressed that the interface management, software configuration management and
requirement specification should be done well and links between them should be discovered. In
software projects the interface should be implemented well so that you can easily understand how
the system works. This means that there are good monitoring and debugging features built-in.
“Interviewee B1” summarizes his views of what should be done in collaborative projects:
Basically we know what to do: make very clear agreements, understand others goals as well
as way of working, put the people together and communicate communicate, communicate.
(…) You can almost compare to it to, let’s say good review technique. Review itself it’s not
such a difficult job from the point of view of complexity but the discipline of it is
complicated. What was the input for this piece? What were the requirements? How have
they been translated to design? What will be the output of the design? (…) that is reviewing.
Who does that with such discipline? Almost nobody (…) you should do it that way and if
you do it that way it’s not that difficult. It requires a certain concentration and a certain
discipline. If you do that you are a good reviewer. So you don’t need any special methods or
special techniques to do that. It is a matter of explaining that this is how you should review
the document or piece of code. Same also for culture… its mainly matter of listening to each
other. How do you do that? Ask the right questions, understand each other?
Interviewee B1
In this chapter the success factors of the collaboration were listed and examined. Effective
communication, careful preparations, clear specifications, logical architecture and understanding the
partner’s culture were the most critical factors according to the findings.
38
5 Discussion
In this chapter the results are compared to other research. The chapter reveals that similar results
can be found from previous studies. Communication is considered as one of the main issues in
collaborative projects. Also, the importance of architecture and team coordination is granted in
several studies.
5.1 Problems regarding collaboration
This section compares the findings to previous research. Problem points are discussed in the same
order as listed in Table 3.
5.1.1 Communication
Herbsleb and Grinter (1999), state that geographically dispersed teams face “extraordinary
communication and coordination problems” (Herbsleb & Grinter 1999, 63). According to Carmel
(1999) loss of rich communication is one of the main aspects that pull the global software team
apart and harm its performance (Carmel 1999, xi). According to Herbsleb and Moitra (2001),
informal hallway conversation is very effective and developers not located on the same site have
low chances to practise informal, spontaneous conversations. The same issue came up in the
interviews.
In their study Paasivaara and Lassenius (2003), reported kick-off meetings where external partners
were not invited. In this study one of the interviewee’s told about the company policy that external
people are not invited to social events if the company is going to pay for it. His opinion was that
these mutual social events would help the relationships building and communication.
According to Herbsleb and Grinter (1999), conversations in a foreign language often become
emotional and require both time and energy. In chapter 4.1.1 “Interviewee A1” compared two hour
length telephone conversations to 10 kilometre run.
39
When discussing collaborative tools Carmel’s study (Carmel 1999, 96) points that e-mail is the
most important collaborative tool. In the results of this study e-mail and telephone were treated as
equals and they were the most important tools in collaborative projects. In the market there are
many different tools which Carmel examines (Carmel 1999, 91-118). Paasivaara and Lassenius
(2003) reported of Internet chat which was used in communication at least in two of their target
companies. Herbsleb, Mockus, Finholt and Grinter (2000) also mention instant messaging as a new
technology of communication. In this study besides e-mail and telephone only groupware
application Notes and NetMeeting programs were used regularly. Kobitzsch, Rombach & Felmann
(2001) considered videoconference as a necessity where Paasivaara and Lassenius (2004) and
Hebsleb and Grinter (1999) reported that videoconference does not bring any added value to
communication and is not used in any of their target projects. This came up also in this study.
Actually, one of the interviews was made in a big videoconference room because it was the only
negotiation room available. No one wanted to use it.
5.1.2 Unclear agreements
In customer-supplier relationships based article Bjerknes and Mathiassen (2000) points the
problematic issues related to the beginning of the relationships: “From a customer point of view,
projects do not start with explicit contractual arrangements. They are the result of unstructured,
problematic situations in which different actors have different conceptions of both problems and
solutions.” (Bjerknes & Mathiassen 2000, 1). Beulen & Ribbers (2002) state that contracts are the
key “in managing complex IT-outsourcing partnerships. But contracts do not replace trust between
the outsourcing company and the IT-suppliers.” (Beulen & Ribbers 2002, 2). According to Beulen
& Ribbers contracts need to be flexible due to the decreased time to market and the fast
technological developments but it is not easy to add that flexibility into the contracts. “Flexibility
will be the key in future IT-outsourcing partnership contracts” (Beulen & Ribbers 2002, 8).
5.1.3 Security policy issues
According to Herbsleb & Moitra (2001), in the outsourcing agreements the fear of loosing
“intellectual property or other proprietary information about products or schedules leads to
restricted or filtered communication” and weakens the communication between the parties
(Herbsleb & Moitra 2001, 18). In their study Herbsleb & Grinter (1999) report lack of trust between
40
sites. According to them it leads to reluctance to share information and to situation where sites do
not consider themselves as partners. These issues came up also in the findings of this study (see
section 4.3.1.).
5.1.4 Inflexibility for changes
According to Beulen and Ribbers (2002), a supplier is not usually rewarded for any extra output or
for improving the levels of its services. Therefore it is not at least in the long-term willing to make
any extra effort. “Interviewee A3” said that the issue is always related to money and if you can pay
for changes there is no problem. Bjerknes and Mathiassen (2000) state that in good relationship
between customer and supplier, the customer has the right to make reasonable requirements changes
and know their price. Overall the underlying competitive nature should be addressed and dealt with
in order to maintain a good relationship.
5.1.5 Adaptation problems
“Interviewee A3” told about problems which occur with some suppliers. Sometimes supplier
organization is incapable of adapting itself to the customer environment. According to a case
discussed by Beulen and Ribbers (2002), supplier can be in difficult situation when working with
multiple organizations. Beulen and Ribbers (2002) report a case where an IT supplier produces
services in three different sites. The local IT supplier uses its parent company’s global processes as
well as its own local processes. The service director explains: “In Asia we deliver services to three
different plants. One is completely serviced by us, on the basis of long-term outsourcing contract.
The second is partly serviced by us, on the basis of project and secondment contracts. And the third
plant is serviced entirely by the client’s own IT departments. Implementing all our global processes
would lead to conflicts with these departments, which is why we mix processes from both our
organizations. The result is smoother, harmonized by co-operation.” (Beulen & Ribbers 2002, 8).
Bjerkens and Mathiassen (2000) guide both customers and supplier to improve the process. The
customer can show real commitment through the project and established the project culture. The
supplier can offer a course in being a customer, it can be a facilitator in the process and offer
customer to take part in milestone evaluating. Mutually they can evaluate and discuss the process.
(Bjerknes & Mathiassen 2000).
41
5.1.6 Team coordination
Carmel states that building relationships means meetings in many forms e.g. working together
“shoulder to shoulder,” arrange kick-off meeting and social meetings etc. He also points that
building trust takes time (Carmel 1999, 146). If the team members do not from time to time meet
face to face the trust between them begins to fall under the sufficient level to work together
effectively (Carmel 1999, 146). In this study “Company A” told that they have perceived that
people from different sites should meet around every third month.
It came up several times in the interviews that it is useful to work with the partners that you have
been working before. According to Carmel dispersed teams have difficulties to integrate themselves
into a coherent team. In classic stage model of team development there is three stages that must be
passed before teams become effective. These are forming, storming, norming before performing.
Carmel writes that “a global software team will not even reach the “performing” stage of the model
in only one product development cycle. Not until the second or even third release will the team
reach the higher levels of trust and psychosocial maturity.” (Carmel 1999, 52-54). This might be
one reason why it is companies prefer to work with the same partners. Carmel writes that good
teams develop their own culture. “Team culture emerges from bonding through common work
experiences; through disasters and successes; from a few cliquish jokes; via team symbol or icon;
and through favourite ways to let off steam together.” (Carmel 1999, 61).
According to Paasivaara and Lassenius (2003), companies rarely plan any problem-solving
practices beforehand and this leads delays at the project level. When problems (that usually are
both difficult and expensive to solve) occurs members of the project spent time and effort when
looking somebody to help them. Article provides three practices related to problem solving:
solution provider (a link person tries to solve occurred problems), bulletin boards with e-mail list
and problem e-mail box. In the target “Company A” problems were solved in the weekly meetings
where everyone presents personal SWOT-analysis. Then the problem is solved immediately or a
plan to solve it is provided. Then it is listed to action point list with person(s) responsible of it and is
discussed later. In some projects members from both customer and supplier organizations
participate to weekly meetings regularly and in some projects mutual meetings are held only when
the situation demands it.
42
“Interviewee A1” talked about the meaning of hallway conversations. Herbsleb and Grinter (1999)
point out that, developers in single location rely heavily on ad hoc communication. People have
often difficulties seeing its critical meaning to team coordination because the ad hoc communication
is “invisible” (Herbsleb & Grinter 1999, 64).
5.1.7 Different views
Keil, Cule, Lyytinen & Schmidt (1998), report results of top-11 risks in software projects. Results
are based on panel discussions in Hong Kong, Finland and USA. Misunderstanding the
requirements is listed as third biggest risk. One of the panellists said that “requirements drive the
entire project” (Keil, Cule, Lyytinen & Schmidt 1998, 79). If the risk of misunderstand the goals is
so high in software development generally it is easy to understand the concern in multisite or
collaborative development.
5.1.8 Availability of human resources
Herbsleb & Grinter (1999) mention the problem related to the use of resources. People change and
it causes problems because the new employees do not know the project so well. Herbsleb & Grinter
(1999), state that people must agree how the product will be developed. The project plan must
include plans when milestones must be completed and who will do the work. “Interviewee A3”
complained about the difficulty in booking human resources when timetables do not count or are
difficult to calculate. In their study of complex IT outsourcing Beulen and Ribbers (2002), among
other issues discuss about the human resources. How many employees can be changed during the
project without harming the relationship of customer and supplier? What to do with employees who
are transferred from customer organization to supplier organization? How to retain to most talented
people? “Company A” had experience of transferred employees with supplier organization but this
issue was not further discussed.
5.1.9 Monitoring the work
Paasivaara & Lassenius (2004), report that in their case study there were also difficulties to monitor
how the subcontractors work was progressing. They said that there were many people in the project
43
who wanted to know what the project’s status was. Also the subcontractor needs to know what the
current situation is. They continue that customers often forgot to inform subcontractors if changes
are made to the documents. In this study only customers were interviewed so we have only the other
party’s opinion about the subject. “Interviewee A1” told that because there were any preparations or
guidance on how the outputs should store it became difficult to follow the progress of the project.
5.1.10 Commitment
In their article of risks in software project Keil, Cule, Lyytinen & Schmidt (1998) list lack of top
management commitment as the biggest risk for the project. Study was based of panel meetings in
Hong Gong, Finland and USA. The panellists saw “the lack of top management as a risk that
overshadowed all others” (Keil, Cule, Lyytinen & Schmidt 1998, 79). Failure of gaining user
commitment was rated as second biggest risk before misunderstanding the requirements. The panel
discussions were not based on collaborative project but generally in software projects. “Interviewee
A2” told in the interviews that if one of the parties is not fully committed to the project it can fail
purely on that.
5.2 Success factors
This section compares the findings to previous research. Success factor points are discussed in the
same order as listed in Table 4.
5.2.1 Effective communication
Battin, Crocker, Kreidler and Subramanian (2001), state that communication is the key to team-
based success. They bring up solutions to improve communication richness in geographically
dispersed projects. These are e.g., using liaisons, which in their case were engineers who travelled
to the target site for period of time and helped building bridges between sites. In order to keep up
continuous communication they suggest using intranet publication, conference calls and travelling.
In the results of this study all these factors except using liaisons came up. “Company A” used to
have intranet publication, conference calls and travelling between sites time to time. “Company B”
was not asked about the subject but during the interview at least travelling was mentioned a lot.
44
Carmel (1999) stresses the importance of face to face meetings especially when the situation needs
it e.g., requirements gathering and prototyping (Carmel 1999, 48). Herbsleb & Moitra (2001) also
stresses the meaning of communication especially in the early stages. Herbsleb & Mockus (2003),
states that communication has major influence on the speed of the project.
Paasivaara & Lassenius (2003) state the meaning of relationship building practices (face to face
meetings), problem-solving practices which should be arrange beforehand (see Section 4.2.1) and
informing and monitoring practices.
In their article Bjerknes & Mathiassen (2000) point out the importance of workshops before (and
after) signing the contract. Herbsleb & Grinter (1999), states the significance of bringing people
together early enough. The value of workshops also came up in the interviews and interviewees
pointed that technical people from both parties should participate to these workshops and work with
each others. Also technical details should be included to contract (how the software is tested, how it
is delivered, who decides its acceptance etc.).
5.2.2 Careful preparations
Careful preparations include several different aspects in order to enable a bright start for the mutual
project. There are e.g., contractual issues, relationship issues and issues related to the understanding
the requirements which all should be taken care of before starting collaborative project.
In the interviews “Interviewee A2” told that they can write the requirements two times. First it is
written with own people then with the subcontractor. In this way they make sure that the
subcontractor understands the requirements. In the study of software project risks Keil, Cule,
Lyytinen & Schmidt (1998), report that misunderstanding of the requirements was the third biggest
risk in software projects. Bjerkes & Mathiassen (2000), suggest several proposals for improving the
customer-supplier relationship. For contextual issues in the beginning of the collaboration customer
should make flexible funding procedure, inform supplier about the IT strategy, and specify the
development strategy make the goals visible. Supplier should make its process visible and discuss
about own strategy. Both should e.g., become aware of each others strong and weak sides. For
mutual understanding supplier should get familiar with the customer’s world. Customer can e.g.,
45
offer a course on being customer etc. Workshops are also very good chances to get to know each
others and workshops should hold both before and after signing the contract (Bjerknes &
Mathiassen 2000). A kick-off meeting is very important in order to gain trust between partners
(Carmel 1999, 144-147).
Kobitzsch, Rombach & Feldmann (2001), report results from a case study of a German company’s
multisite software development in India. When discussing about planning issues they explain: “The
German and Indian teams exchanged project-planning issues to reach a common knowledge on
what is planned, which releases to use, and how to reach the delivery dates. They addressed and
solved important considerations such as dependencies on each other’s development results.
Meetings always take place in Germany because the necessary marketing and project-planning
resources are there.” (Kobitzsch, Rombach & Feldmann 2001: 84).
Beulen and Ribbers (2002) predict that flexibility will be the key in future of IT-outsourcing
contracts. “Interviewee B1” stated the meaning of bringing technical people together and letting
them to participate contract signing. “Interviewee B3” pointed out the risk of pushing competitive
bidding too tight. If the cost is too low there is a change that the project fails. According to him the
damage is then bigger than if the customer would have paid a little more in the beginning. Khan,
Currie, Weerakkody & Desai (2003) states the same when discussing about unexpected costs.
5.2.3 Understanding the cultural differences
Krishna, Sahay &Walsham (2004) have studied cultural issues of global software outsourcing.
Their primary conclusion is that collaborating across cultures is not trouble-free process. Problems
occur from different ways of working or issues related to cultural adaptation when working with
foreign teams. Authors give an example where “British managers in an outsourcing relationship
with a particular Indian software supplier found that Indian programmers, in deference to authority,
would not voice criticism in face-to-face meetings but would sometimes send their opinions in
email messages after the meetings had disbanded. The British managers, used to intense interaction
and the development of ideas through meetings, felt frustrated at this “polite” behaviour.” (Krishna,
Sahay & Walsham 2004, 65). “Interviewer B1” told about similar experiences. Herbsleb & Grinter
(1999), report of different communication style between Germans and British. Germans are
accustomed to speaking immediately of the subject when the British expect more greetings and
46
politeness before actually getting in specific detail. Krishna, Sahay &Walsham (2004), suggest that
companies use training and staffing for improving the cross-cultural relationship. Training should
be seen as a two-way learning process (involving both sides) where language, cultural practices,
norms and values are acquired. Staffing means placing employees to the other site who then bridge
these different cultures operating as ‘cultural bridging’ staff. (Krishna, Sahay &Walsham 2004, 65).
Carmel (1999) point out several aspects relating to subject and states that there is no “grand theory
of culture” which would be easily learnt (Carmel 1999, 57).
5.2.4 Clear specifications
The interviewees from “Company A” told that specifications should be made in a way that
everybody would understand them. “Interviewee A3” told about a recent situation where a month
earlier people were gathering requirements but when they returned to the subject there were
difficulties to understand them anymore. Clear specifications means that all the documents and
specifications should be written in a way that everybody can understand them and cannot
misunderstand them. Of course these specifications must be discussed with people regularly. But it
should be written so clearly that there are minimum changes to misread them. “Interviewee A3”
suggested that there would be a facilitator which would collect all the requirements take care of
them. Paasivaara & Lassenius (2004), report of “solution provider”, a person who deals with
different problems (Paasivaara & Lassenius 2004, 191-192). When a problem arrives everybody
knows whom to contact. Maybe this kind of provider could handle also requirements and other
specifications. If somebody does not know some detail in specifications he could directly ask about
it from this person whom likely knows the answer for it.
5.2.5 Logical architecture
According to Carmel (1999), forces that can keep the team together are: telecomm infrastructure,
product architecture, team building, development methodology, managerial techniques and
collaborative technology. (Carmel 1999, xi). Also these issues receive support from the results of
this study. Especially product architecture seems to be important.
47
Carmel states that experienced global managers know the importance of product architecture in
globally dispersed teams. “Product architecture determines whether dispersed sites can work
harmoniously with each other without stepping on each other toes. Proper product architecture is
based in part on the principle of modularity: designing software components that are self-contained
and have few interdependencies with other modules.” Product architecture is linked with task
allocation which can be divided in three strategies. First there is module-based allocation which
means assigning task (or modules) of each sites. Then there is phase-based allocation where the
“work is passed site to site at the end of a major phase in the development process.” Finally there is
integrated allocation strategy (also known as follow-the-sun) where “tasks are tightly integrated
between sites and work is passed, as often as daily, between sites.” (Carmel 1999, 127). In practise
it is useful to use hybrids of module and phase strategies (Carmel 1999, 134). He stresses that “the
key success factor for most dispersed global teams is the clean allocation of tasks: ensuring that
each sites has a significant task that relies as little as possible on other sites” (Carmel 1999, 128).
“Interviewee A1” pointed out the same opinion.
5.2.6 Efficient informing between parties
Paasivaara & Lassenius (2003), point out that informing practices should be designed in the
beginning of the collaboration. They identified three useful practices which are weekly meetings,
progress reports and a travelling steering group. In a large project every site can have its own
weekly meeting and the team leaders have video- or teleconferences afterwards. For monitoring
purposes the customer needs practices for progress reporting. It can be problematic because the
number of code lines or hours used does not necessary inform much. There can be detailed progress
reports for every month including accomplished tasks, open questions, problems and future
estimations about task and problem-solving schedules. Travelling steering group could consist of
members of every site and partners. Meeting location changes and every site is visited at least once.
(Paasivaara & Lassenius 2003). Weekly meetings, progress reports were also familiar to both
companies in this study as well as travelling steering groups. Progress reports practice lacked at
least in one project managed by “Interviewee A1”. He told that he just had to believe that
everything is going just as is agreed and discussed. “Interviewee A3” told that he required personal
SWOT analysis from every member of the project. SWOT analyses included same issues as
progress reports but only as one employee’s point of view.
48
5.2.7 Competence
Carmel (1999), lists specialized talent one of the main reasons why companies practise global
software development (Carmel, 1999: 4). Sometimes there is no other way than “mold together
disparate site” because the people who have the know-how cannot be found anywhere else, he
writes. Kobitzsch, Rombach & Feldmann (2001), states that today in most companies, human
resources and competencies are bigger reasons for distributing the development than just cutting the
labour costs. In this study interviewees from both companies mentioned both competencies and
cost efficiency as reasons for collaboration.
49
6 Conclusions
This study has gathered together both the perceived problems and the perceived success factors with
regard to inter-organizational collaboration in embedded system industry. The study which consists
of two case studies was conducted using case study and grounded theory methods with a semi-
structured interview technique. The target companies were chosen with an emphasis on experience
in inter-organizational product development. Both companies are well known and they have years
of experience of collaborative projects.
The findings contain ten perceived problems in collaboration. Communication, unclear agreements
and security policy issues were found to be the most critical ones. As to the success factors, twelve
of those factors were found, including logical architecture, efficient communication, careful
preparation and an understanding of different cultures.
The objective of this thesis was to answer the research questions presented in Chapter 1. This
objective was attained. Although the study was successful, further research would be needed to state
any universal facts. Many issues would need more investigation, including adaptation problems and
agreements issues. In the future further interviews in different companies could bring additional
information on the subject. Quantitative research methods could also be useful in this area.
Research concentrating on a single problem (e.g., communication) or on only one success factor
could bring valuable information. This time, when mapping all the problems and all the success
factors in the same study, a deep analysis on the individual points had to be left without sufficient
attention. Altogether, previous research supported most of the findings, so we may well be on the
right track.
50
7 References
Battin, R.D., Crocker, R., Kreidler, J. & Subramanian, K. 2001. Leveraging resources in global
software development Software, IEEE, Vol. 18, No 2, 70-77.
Beulen, E. & Ribbers, P. 2002. Managing complex IT outsourcing-partnerships. HICSS.
Proceedings of the 35th Annual Hawaii International Conference on 7-10 Jan. 2002.
Beyer, H., & Holtzblatt, K. 1998. Contextual design: Defining customer-centered systems. San
Francisco, California: Morgan Kaufmann Publishers.
Bjerknes, G. & Mathiassen, L. 2000. Improving Customer-Supplier Relation in IT Development.
IEEE. Proceedings of the 33rd Hawaii International Conference on System Sciences.
Carmel E. 1999. Global Software Teams – Collaborating Across Borders and Time Zones. Upper
Saddle River, New Jersey: Prentice Hall.
Creswell, J.W. 1998. Quality Inquiry and Research Design. Choosing Among Five Traditions.
Thousand Oaks, California: Saga Publication, Inc.
Duysters, G. & Hagedoorn, J. 2000. A note on organizational modes of strategic technology
partnering. Journal of Scientific & Industrial Research. Vol 58, 640-649.
Dyer, J.H. 2000. Collaborative Advantage: Winning through Extended Enterprise Supplier
Networks. Oxford, University Press.
Faems, D. 2003. Linking technological innovation and inter-organizational collaboration: an
overview of major findings. Working Paper Steunpunt OOI: March 2003.
Glaser, B.G.2004. Remodeling Grounded Theory. The Grounded Theory Review: An international
journal. Vol. 4, No. 1, 1-22.
51
Hagedoorn, J. 1990. Organizational Modes of Inter-firm Cooperation and Technology Transfer.
Technovation, Vol. 10, 17-30.
Hagedoorn, J. 1993. Understanding the Rationale of Strategic Technology Partnering:
Interorganizational Modes of Cooperation and Sectoral Differences. Strategic Management Journal.
Vol.14, 371-385.
Hagedoorn, J. 2001. Inter-Firm R&D Partnerships – An Overview of major trends and patterns
since 1960. Eindhoven Centre for Innovation Studies. Conference “The Future of Innovation
Studies” Eindhoven University of Technology, the Netherlands 20-23 September 2001.
Heeks, R., Krishna, S., Nicholson, B. & Sahay, S. 2001. Synching or Sinking: Global Software
Outsourcing Relationships. IEEE Software. Vol. 18, No. 2, 54-60.
Herbsleb, J.D. & Grinter, R.E. 1999. Architectures, coordination, and distance: Conway's law and
beyond. IEEE Software. Vol. 16, No. 5, 63-70.
Herbsleb, J.D. & Mockus, A. 2003. An empirical study of speed and communication in globally
distributed software development. Software Engineering, IEEE Transactions. Vol. 29, No. 6, 481 -
494.
Herbsleb, J.D. & Moitra, D. Global software development. 2001. IEEE Software. Vol.18, No. 2, 16-
20.
Herbsleb, J.D., Mockus, A., Finholt, T.A. & Grinter, R.E. 2001. An empirical study of global
software development: distance and speed. IEEE Software Engineering. ICSE 2001. Proceedings of
the 23rd International Conference.
Herbsleb, J.D., Mockus, A., Finholt, T.A., Grinter R.E. 2000. Distance, dependencies, and delay in
a global collaboration. Proceedings of the 2000 ACM conference on Computer supported
cooperative work.
Hirsjärvi, S. & Hurme, H.1988. Teemahaastattelu. 4. painos. Helsinki: Yliopistopaino.
52
Järvinen, P. 2001. On Research Methods. Opinpajan kirja, Tampere.
Keil, M., Cule, P.E., Lyytinen, K., Schmidt R.C. 1998. A framework for identifying software
project risks. Communications of the ACM, Vol. 41 No. 11
Khan, N., Currie, W.L., Weerakkody, V. & Desai, B. 2003. Evaluating offshore IT outsourcing in
India: supplier and customer. IEEE CNF. System Sciences. Proceedings of the 36th Annual Hawaii
International Conference.
Kobitzsch, W., Rombach D., & Felmann R.L. 2001. Outsourcing in India. IEEE Software. Vol. 18,
No. 2, 78 – 86.
Kogut, B. 1988. Joint Ventures: Theoretical and Empirical Perspectives. The Wharton School,
University of Pennsylvania. Strategic Management Journal, Vol 9, 319-332.
Krishna, S., Sahay S. & Walsham G. 2004: Managing Cross-Cultural Issues In Global Software
Outsourcing. Communications of the ACM. Vol. 47. No.4, 62-66.
Lindström, M. 2003. Ensuring Availability and Access to New and Existing Technologies in
Cellular Terminal Business. Dissertation. Helsinki University of Technology.
Paasivaara, M. & Lassenius, C. 2004. Collaboration Practices in Global Inter-organizational
Software Development Projects. Software Process Improvement and Practice. No. 8, 183-199.
Sabherwal, R. 1999. The role of trust in outsourced IS development projects. Communications of
the ACM. Vol. 42, No. 2, 80-86.
Steensma, H.K. 1997. Internalizing External Technology: A Model of Governance Mode Choice
Working paper. Indiana University Blooomington, Indiana.
The Engineering Education Centre, Loughborough University [Web-site]. Available: http://eec.lboro.ac.uk/learningtech/jtor.htm. [Referenced 10.04.2005].
53
TheFreeDictionary.com, 2005. [Web-site]. Available: http://encyclopedia.thefreedictionary.com.
[Referenced 10.02.2005].
Thompson, I. 2001. Collaboration in Technical Communication: A Qualitative Content Analysis of
Journal Articles, 1990-1999. IEEE Transactions On Professional Communication, Vol. 44 No. 3,
161 - 173.
Weck, M. 2003. Inter-Firm Cooperation and Industry Evolution. Helsinki University of
Technology. [Web-document]. Available:
http://www.tuta.hut.fi/studies/postgraduates/Doctoral_studies/conferences/paper_weck.pdf.
[Referenced 23.02.2005].
Yin, R.K. 2003. Case Study Research. Design and Methods. 3rd ed. Thousand Oaks, California:
Saga Publications, Inc.
54
8 Appendixes
Framework for the interviews Questions:
1. Name.
2. Position in organization.
3. General background from both working environment and collaborative projects.
4. Interviewee’s role in collaborative projects (Project Manager, etc.).
5. How many years of experience in collaborative projects.
6. What kinds of projects (multisite, subcontracting, joint ventures, etc.).
7. Personal opinion about collaboration in general.
8. How is collaboration culture developed over the years (has it increased/decreased, become
more organized, etc.).
9. Usual duration of collaboration project. Does time matter in the result.
10. What are the reasons for collaboration? Advantages/disadvantages.
11. Special characteristics when planning strategy for collaboration.
12. Preparations.
13. Team coordination issues.
14. Progress of the project. Does it take longer for task to be completed in dispersed project?
15. Communication
a. How often? In what way? Where? (Weekly meetings, progress reporting,
inspections, etc.).
b. Face to face meetings (how often?).
c. Effort (arrangements, support, etc.). Cultural differences. Communication tools.
d. Getting to know each other. How?
16. Problem solving practices? Tools, etc.
17. Choosing the partner.
18. The matter of trust. How to increase trust?
55
19. Development processes (using mutual process or separate one? synchronizing?)
20. Maintaining the quality in collaborative project.
21. Requirements and architecture management.
22. Integration.
23. Configuration management.
24. Managing risks. Risk analysis.
25. Documentation.
26. Success factors.
27. Best things in collaboration are (choose five factors).
28. Most problematic issues in collaboration are (choose five factors).
