COMMUNICATION PATTERNS AND PRACTICES IN SOFTWARE

DEVELOPMENT NETWORKS
Maria Paasivaara, Casper Lassenius and Jarkko Pyysiinen
Helsinki University of Technology
P.O.B 9600
FIN-02015 HUT
Finland
E-mail: maria.paasivaara@hut.fi, casper.lassenius@hut.fi,
jarkko.pyysiainen@hut.fi

ABSTRACT
We present communication needs, patterns and practices found in networked
software development projects. Based on 34 interviews in eight distributed interorganizational projects carried out by large, experienced organizations, we found
no systematic approaches to communication. Instead, practices were invented on a
need basis at the project level. We identified four communication needs, as well as
nine communication practices that addressed those needs. Five of the practices
were found in three or more projects, and therefore classified as patterns. We
propose that systematic collection and dissemination of working communication
patterns for networked product development projects could help managers better
plan and execute such efforts.
INTRODUCTION
Effective and efficient communication is central to systematic success in new
product development (NPD) [1]. Product development projects are increasingly
being distributed across companies and countries, complicating communication in
several ways. Although there is a fairly large literature base on communication in
local NPD, the literature on how to plan and organize for communication in
globally and organizationally distributed NPD is scarce. In this paper we try to
add to existing knowledge by providing a tentative list of communication needs,
successful communication practices and communication patterns found by
studying one specific type of distributed NPD networked software development.
Software development projects are on the one hand easy to distribute since the
product, i.e., source code and documentation, is easy to send electronically
between the sites, and good tools for distributed software configuration
management exist. On the other hand, software is an intangible, invisible product,
making it difficult to understand even locally. Indeed, this invisibility has been
argued to be one of the inherent properties of software development that makes it
so challenging [2]. The addition of geographical and corporate borders certainly
adds to the challenge. We think that these aspects make software projects an
interesting class of NPD projects to study.
As with NPD projects in general, distributed inter-organizational software
development projects, including outsourcing, subcontracting or partnership
relations, are becoming increasingly common [3][4]. Advice for outsourcing and
acquiring large projects or modules with well-defined requirements can be found
in literature [5]. However, many NPD software projects are faced with a lot of
uncertainty, and subcontractors or partners are needed long before these

uncertainties can be resolved and the requirements thoroughly specified. In such

projects parties usually cannot receive clear requirement specifications at the
beginning. Instead, close cooperation and communication between the parties are
required during the whole project, as the project both builds a product and tries to
understand what to build at the same time. In this kinds of projects, problems
often arise, since practices needed for collaborating and communicating across
distances and organizations are neither well understood nor typically established
in practice. In our experience, companies easily underestimate the need for
specific practices when collaborating across distances, and start global interorganizational projects without first planning how to work together. This can lead
to quite problematic situations. Most of the problems are related to
communication difficulties (e.g. [6][7]), which mainly arise due to geographical
distance, which e.g. limits the number of face-to-face meetings [8][4]. Moreover,
cultural differences both when crossing company and country borders make
communication more difficult. In addition to cultural issues, company borders
may also limit communication for several other reasons. For example, you might
not know whom to contact in the other company, there might be differences in
communication technology (e.g. incompatible videoconference facilities), security
issues might complicate the situation (e.g. suppliers are not allowed to enter the
customers database), or there might be lack of trust leading to a situation in which
you just do not want to expose partners to too much information about new
products under development.
Current literature does not provide much help for managers planning distributed
software development projects; only a few articles can be found presenting
practices used in case projects (e.g. [6][9][3]). We believe that finding the most
important communication needs and collecting successful practices, especially to
support communication, could help managers better plan and execute global interorganizational software development projects. This paper presents an idea about
collecting and presenting successful communication practices as communication
patterns.
The rest of this paper is structured in the following way: The next chapter
presents a brief overview of the identification and use of patterns in software
development, and further motivates the work presented in this paper. This is
followed by a description of the research methodology used and the cases studied.
In the results chapter we present the practices and patterns that we found in our
research. Finally, we present a short discussion and our conclusions.
PATTERNS AND PRACTICES IN SOFTWARE DEVELOPMENT
The work on patterns and pattern languages by the famous architect Christopher
Alexander [10][11] has been very influential in the software engineering
community. Alexander described patterns that occur in buildings and towns. A
pattern to Alexander describes a problem which occurs over and over again in
our environment, and then describes the core of the solution to that problem, in
such a way that you can use this solution a million times over, without ever doing
it the same way twice [10]. Alexander shows that although every building is
unique, each may be created by following a collection of general patterns. This
means that a pattern gives a general solution to a common problem, a solution
from which a more specific solution can be derived.
Even though Alexander was talking about architecture related problems and
solutions that occur in buildings and towns, his work have inspired many in the

software development community. Gamma et al. [12] applied Alexanders

thoughts in designing object oriented systems. Their aim was to record designers
experience as design patterns, which name, explain, and evaluate important and
recurring designs in object-oriented systems in a form that people can use them
effectively. The use of patterns has spread even to managing software
development. Coplien [13][14] describes organizational and process patterns,
which he thinks help us both to understand existing software development
organizations and to build new ones. Ambler [15] presents process patterns that
are especially intended for object oriented software development. He defines an
organizational pattern as A pattern that describes a common management
technique or a potential organizational structure and a process pattern as A
pattern that describes a proven, successful approach and/or series of actions for
developing software. Both Coplien and Ambler present patterns that are proven
or at least expected to be successful. However, all commonly occurring patterns
may not be good for the organization. Taking the viewpoint that identifying and
documenting often recurring mistakes can be useful, Brown et al. [16] describe so
called antipatterns, or commonly occurring solutions to a software
development need that generates significantly negative consequences. They also
provide solutions that are applicable when such antipatterns are found.
Some organizational patterns that
Coplien [13][14] presents describe
communication related problems and solutions. One of them is a pattern called
gatekeeper, which is actually very close to Allens [17] findings. In the
gatekeeper pattern the problem is both communication overhead created by the
collaboration with many external collaborators and also introvert engineering
personality types. The solution could be to have a suitable project member in the
role of gatekeeper. This person would disseminate information from outside to
project members and translate it into terms relevant to the project. Copliens
patterns are carefully described: every pattern has a name, describes the problem,
gives the context of the problem, explains the forces or tradeoffs affecting it, gives
solution to the problems, and explains the resulting context and design rationale.
Other communication related patterns, especially meant for distributed use can be
found, e.g., from the Dispersed Agile Software Development web site [18]. These
pages present patterns such as TravellingDevelopers and DailyConferenceCall.
Only a few communication patterns suitable for networked software
development projects are presented in literature. We believe that collecting and
documenting communication related successful solutions from networked projects
can help managers better tackle the communication challenges of networked NPD
projects. In this paper we describe some practices and patterns encountered in
networked software development projects. We use both the terms practice and
pattern. Successful practices we encountered three or more several projects are
called patterns, other successful practices encountered in only one or two of our
case projects we call practices.
RESEARCH METHOD
The research presented in this paper is based on a multiple-case study approach
[19]. Six successful Finnish companies (which we will call Alpha, Beta, Gamma,
Delta, Epsilon and Zeta) that develop software were chosen for the study. Three of
the companies develop software products, one customer specific systems and two
embedded systems. We used purposeful sampling [20] and selected companies
that we knew used software subcontractors and that we expected to be quite

experienced in inter-organizational software development. All companies, except

one, were large and well known in Finland.
We chose all in all eight projects for closer study - from five companies we chose
one and from one large company we chose three organizationally dispersed
projects. Since pure partnership projects were difficult to find, we concentrated on
projects involving subcontractors, and focused on the communication needs, and
communication patterns and practices found between the customer and the
subcontractor(s) in parallel development situations. The projects chosen had also a
global distribution aspect, either inside or between the companies. The focus of
this study is illustrated in Figure 1.
Organisational
distance
2 or
more
companies

Collocated Domestic
network
network
project
project

Traditional
1 company project

Same
location

Distributed
project
Same
country

Global
network
project
Globally
distributed
project
Different
countries

= Focus of
the study

Geographical
distance

Figure 1. Project Types and the Focus of this Study

We purposefully selected projects that demanded constant collaboration and lots
of communication between parties, e.g., due to high degree of uncertainty,
dependencies and changing requirements. All eight projects had sites or partners
in two or three different countries. Four projects were distributed between
continents, two of them between Europe and Asia, and two between Europe and
North America. In three projects all sites were located in Europe. One customer
specific project had developers only in Finland, but the requirements came from
customer sites located all over the world.
We performed 34 semi-structured interviews, each lasting 2-3 hours. We tape
recorded all interviews, transcribed them and used Atlas/TI for grouping and
analysing the results. In each customer company we interviewed, if possible, both
a partnership manager responsible for software subcontracting, and a process
developer involved in subcontracting process development. In some cases the
partnership manager and process developer was the same person. From a chosen
case project we interviewed a project manager and, if possible, also one or more
team members and a representative from the supplier company. The cases and
interviewees are presented in Table 1.

Case
Projects
Alpha 1
Alpha 2
Alpha 3
Beta
Gamma
Delta
Epsilon
Zeta

Interviews
Partnership
Manager
1
2
1
1

Process
Developer
1
1
1
1

Team
Member
1
1
1

Subcontractor
1
2
1
-

All

1
1

Project
Manager
2
1
3
1
2
1

5
4
2
7
3
4
3

Industry

Distribution

Telecom

Europe & NA
Europe
Finland
Europe
Europe
Europe & NA
Europe & Asia

Bespoke SW
Security
Telecom
SW products
to several
industries
Telecom

Europe & Asia

Table 1. Case Project Interviews

In three cases the number of project managers interviewed is more than one,
since also some subproject managers were interviewed. Suppliers were
interviewed only in half of the projects, due to various reasons. In two cases
suppliers were situated across so long distances that we were unable to travel, and
in one case the customer did not want us to interview the supplier. In one case we
found out that the suppliers were not doing intensive concurrent development with
the customer, making us believe that they would not provide much added value to
the study. The number of interviewees differs between cases, depending, e.g., on
the size of the project, and how interesting the project was from the point of view
of communication practices.
In company alpha two of the projects (1 and 2) were normal product
development projects from different organizational units, and project 3 was a
bespoke system that was developed by a supplier. In company Zeta we
interviewed 3 persons from the supplier, since the supplier had interesting internal
distribution.
RESULTS
Our main finding and themost surprising result of this study was that the
companies did not have clear organization-wide practices or patterns that would
have been commonly used in their inter-organizational software development
projects. The practices and patterns we encountered were mainly project specific
and created by trial and error. Most of the practices and patterns found and
presented in this paper might seem quite basic. However, in our experience, they
are often not implemented in real life projects, even though we think that a lot of
problems could be avoided by using them. Next, the communication needs,
patterns and practices we found are presented.
Communication needs
From our case projects we first wanted to identify the most important
communication needs. We believe that knowing the communication needs forms a
basis for planning communication in networked projects. Moreover, recognizing
the often neglected communication needs will, we believe, help managers to pay
more attention to these important needs in the future. Later in this paper we will
also group the recognized communication practices and patterns according to the
needs that they satisfy.

We identified four main types of communication needs: 1) problem solving, 2)

informing, monitoring and feedback, 3) relationship building, and 4) decisionmaking and coordination. This classification is very close to the classification
presented by Stahl et al. [21] on communication in distributed product
development. Their classification included informing, information exchange and
feedback, co-ordination and decision-making, and problem solving. We combine
the first two types since we find it difficult to separate informing from information
exchange. We add monitoring, since creating transparency of project progress and
work done in a network is especially important in networked projects. Moreover,
many things that are informed also create transparency and provide monitoring
information, therefore informing and monitoring are difficult to separate. For
these reasons we call this combined need informing, monitoring and feedback.
The second and third need proposed by Stahl et al. [21], co-ordination and
decision-making, and problem solving, we find relevant. Finally, we added a
fourth need: relationship building. This need includes all kinds of social
communication, which is especially hard and important in a distributed project
and therefore needs to be emphasized. Relationship building type of
communication is often part of almost all communication. However, we want to
separate it since this kind of communication is critically needed in networked
projects to build trust and cooperative relationships between parties. The changes
to Stahl et al.s classification were made when comparing their classification to
needs found from our case projects.
We found all these communication needs in all projects we studied. However,
the importance of each need and the suitable communication practices and
patterns with which to satisfy those needs depended on both the type and the
phase of the project. For example, relationship building communication is needed
especially in the beginning of a project and is the most important in projects where
collaborating parties do not know each other beforehand. Quite often, however,
relationship building was at least partly neglected, which caused problems later
on, when contact persons were not known and trust between parties was lacking.
Other important but often neglected needs were problem solving communication
and providing monitoring information about the current situation in the project to
partners and own distributed sites. An interesting, and important finding was that
communication needed for problem solving was almost totally forgotten when
planning projects. This type of communication was needed especially in projects
involving a lot of uncertainties, since problems demanding communication just
cannot be totally avoided. In the next section, we discuss these identified needs in
more detail.
Problem solving
Problem solving communication is easily forgotten in project planning, even
though it is commonly needed in distributed projects, especially when facing a lot
of uncertainties, e.g., concerning new technologies. If channels for problem
solving communication are not agreed upon at the beginning of the project, it
might take a long time before problems are solved and this delays the whole
project. When no suitable communication practices exist, project members easily
spend a lot of time just trying to find a person who can help them, wasting both
time and energy. In addition, the barrier for the suppliers personnel to contact the
supplier can be high despite having serious problems. This can easily lead to a
situation in which problems are brought up too late, when they are both difficult

and expensive to solve. Problem solving communication need should definitely be

paid attention to when planning distributed projects.
Informing, monitoring and feedback.
The customer normally remembers to monitor how the suppliers work is
progressing, even though it is difficult if only time reports are used. However, the
suppliers personnel and other distant sites would also like to get information
about the progress of the whole project. This information would, besides helping
personnel in distant sites to accomplish their tasks, motivate them, e.g., to adhere
to the schedule, when they know why it is important. For a customer it is also very
easy to forget to inform the supplier about decisions and changes made, or new
documents produced. The informing and monitoring should happen in both
directions from the customer to the supplier and the other way around.
Besides informing, suppliers also expect feedback from their work, e.g., about
the quality of the work. They would like to get comments also when they are
doing something right, not only when things go wrong. This is also a motivating
factor.
Relationship building
It is easier to communicate with a person that you have met at least once.
Therefore, face-to-face meetings are crucial, especially in the beginning of the
project. These meetings facilitate later electronic communication. Moreover, it is
important that distant sites and companies have faces. Otherwise they are easily
forgotten and, e.g., their questions might not be regarded as important and urgent
to answer. Trust between parties would make collaboration in a distributed project
easier. However, trust develops slowly and preferably in face-to-face situations,
which are rare in distributed projects.
Building a good relationship with suppliers requires also that they be treated
more as partners and experts in their field, not like second-class citizens, as we
have sometimes observed. Usually, suppliers want to do high quality work.
Decision making and coordination.
Coordination and decision making is in a networked project concentrated to a
network level steering group, the project mangers and the team level meetings. All
these should take part of the responsibility. Define what kind of decisions each of
them can make and how the whole project is informed about those decisions.
Communication patterns and practices
The communication needs presented in the last chapter form a basis for
communication patterns and practices needed in networked software development
projects. In this chapter communication patterns and practices found in our case
projects are presented and related to each need that they help to satisfy.
The case companies did not agree upon communication practices at the
beginning of their projects, a fact that caused problems later. Even many basic
guides recommend doing a project communication plan first, e.g. the PMBOK
Guide [22], but that just did not seem to be a common practice in our case
projects. Especially the need for problem solving communication was huge in the
case projects. However, agreeing about it was often neglected partly because
anticipating when and who would need it seemed to be difficult. Other important,
but neglected, needs were relationship building and monitoring communication

between distributed team members. These communication gaps limited

transparency and caused, e.g., team members not always knowing whom to
contact and made following the progress of the project difficult. Next,
communication practices related to each four types of communication needs are
presented. We use the same format as Coplien [13] uses, i.e., practice/pattern
name, problem, context, forces, solution, resulting context, and design rationale.
As we mentioned earlier, we call good practices encountered in at least three
projects patterns (e.g. Rising et al. [23] mention this rule of three). Other good
practices, used in only one or two projects, we simply call practices. When
identified in a larger number of projects they could, as well, become patterns.
However, our sample of projects, eight altogether, was so small that additional
practices did not meet the rule-of-three requirement. Altogether, we found five
patterns and four practices. The goodness of a practice or pattern was determined
by subjective opinions of our interviewees who used those patterns and practices
in their projects.
Problem solving
Problem solving communication was noticed to be very problematic inmost
projects. This type of communication was not planned beforehand in many of
the projects it just emerged and then also practices to solve it emerged. However,
in all the projects problems and questions appeared all the time. Problems and
questions are hard to avoid in distributed software development projects, since the
requirements can rarely be specified up-front at the level of detail that would be
demanded. We think that managers planning networked software development
projects should remember this communication need already in the planning phase
of the project. We found three practices, one of which we classified as a pattern,
that seemed to help companies deal with this communication need: Problem
Solving Responsible, Communicating Developers and Discussion Lists. These are
described in Tables 2, 3, and 4 below.
Practice
name
Problem
Context

Forces
Solution

Resulting
context

Design
rationale

Problem Solving Responsible

Whom to ask when the developers in the subcontractors team have questions?
The suppliers developers have a lot of questions during the development,
concerning, e.g., requirements, technical problems, the rest of the system to be
developed elsewhere etc. However, these developers do not know whom to contact in
the customers organization to help answer those questions.
When developers do not know whom to contact in another organization they do not
ask, but try to solve the problem by themselves. This way solving the problem takes
longer, or waiting just aggravates the problem until the developers dare ask.
The customer organization should name a person or two, whose primary
responsibility is to make sure that questions are answered quickly enough. This
person either answers him or herself or finds the answer from elsewhere in the
organizations.
When the suppliers developers know that there is a person whose job is to answer
their question and they know who he or she is, it is much easier to initiate contact.
This solution ensures that questions are answered quickly and work progresses in the
right direction. Answering questions and finding the solutions takes time, therefore
you should ensure that the Problem Solving Responsible does not have too many
other duties. In two of our case projects this kind of person reported that more than
half of his time was spent on answering questions.
In two of our case projects (Beta, Epsilon) this kind of problem solving person did
not exist in the beginning of the project, but after some time developers learned, by
asking around, that this person, in both cases a system architect, knew the answers to
many questions. Finally, most of his time was spend on answering questions. The
media used was most often either email or chat.

many questions. Finally, most of his time was spend on answering questions. The
media used was most often either email or chat.

Table 2. Problem Solving Responsible

Practice name
Problem
Context

Forces

Solution
Resulting
context

Design
rationale

Communicating Developers
Should we allow developers to communicate directly?
Especially in smaller projects, developers from the supplier and the customer,
working on related tasks (e.g., working with the same interface between
modules, or the other testing the module that the other one has developed) need
to communicate with each other.
Developers need to communicate between companies, but on the other hand
too much direct, uncontrolled communication between all developers may lead
to a situation that is very difficult to manage. The project manager may not
know what is going on, and developers may have agreed directly on matters
that affect costs, schedule or other parts of the system. Directing all intercompany communication through project managers may burden project
managers too much and they may restrict the information flow.
Specific developers from the customer and the supplier, working on common
interfaces or problems could be introduced and encouraged to communicate
directly. Internet chat was observed to be an efficient media for this purpose.
Projects managers can concentrate on other things than mediating information,
when part of the information flow takes place directly between developers.
Direct communication is not encouraged with anyone, but between specific
developers from both companies, and regarding specific matters. Decisions
about important matters are still brought to the project managers.
In two case projects (Epsilon, Zeta) developers, working in different companies
and countries, communicated frequently using chat. The chat client made it
easy to see who was present in another company. Several good properties of
chat was mentioned; it is cheap to use compared to the phone, it is possible to
have chat discussions open all the time, several developers can participate in
the conversations, counter questions can be asked right away, foreign language
speakers are easier to understand when the discussion is written, and from a
written conversation it is also easy to copy important paragraphs and, e.g., send
them by email to others.

Table 3. Communicating Developers

Pattern name
Problem
Context
Forces
Solution
Resulting
context
Design
rationale

Discussion Lists
How to find an expert of some specific technology from a large project to
answer a question?
Very large projects with expertise widely distributed.
Experts knowing the answers need to be encouraged to follow the discussion.
Project wide discussion lists (news groups) around certain technological topics.
Expertise can be found inside the own project.
Discussion lists were used successfully in two larger projects (Alpha1 and
Epsilon). In a smaller project (Gamma), project wide mailing lists were used for
the same purpose. In an email or discussion list questions asked need to be
explained very carefully, otherwise readers do not understand the questions and
they have to send several mails asking clarifying questions before the question is
understood correctly and can be answered.

Table 4. Discussion Lists

Informing, monitoring and feedback

In a project team members need to be informed, e.g., about changes to

requirements or schedule. The customers project manager and also the subproject
manager want to monitor the progress in the project. Moreover, team members
like to get information on project progress. Team members also need feedback on
their work. We found that subcontractors rarely were given information on the
current state in the project, and in some cases they did not even receive feedback
on their work. In parallel development situations in which the work of various
sites and partners are strongly interconnected it seems to be important to have
status information flow not only from the subcontractor to the customer, but also
in the other direction. In many projects we studied, this communication need was
disregarded. We found three practices, two of which we classified patterns. These
are listed in Tables 5, 6 and 7: Weekly Meetings, Monitoring Reports and
Frequent Deliveries.
Pattern name
Problem
Context
Forces

Solution
Resulting
context

Design
rationale

Weekly Meetings
How to monitor the project, inform and give feedback?
Weekly meetings, using face-to-face, and/or video- or teleconferencing, are
suitable for all distributed projects.
Physical meetings are difficult to arrange in distributed projects. Also time
differences cause problems. In large projects there are so many participants that
it is difficult for them all to be at work at the same time and on the other hand
they can not all be interested on every detail that happens in the project. On the
other hand all team members, both from customer and supplier, need information
about project progress, next tasks and changes. They need also feedback on their
work.
Short weekly meetings, where the progress of the project, current problems,
changes, and future tasks are discussed. Depending on the number of persons
involved and inter-site distances the arrangements differ.
In a small project all distributed sites can have one common teleconference
meeting. In a larger project smaller meetings can take place in every site or team
and team leaders or project managers can have a common video-/teleconference
afterwards. In a larger project also smaller meetings between collaborative sites
is a possibility.
In three of the case projects (Alpha1, Beta, Epsilon) different kinds of weekly
meetings were used. For example Alpha1 used the practice described above
having first site-specific meetings and then teleconference between team leaders
/ project managers. All projects saw weekly meetings as a useful practice. They
all preferred teleconferences over videoconference as a media used, since they
saw that the picture in videoconference was of low quality and/or equipment
incompatible and therefore did not bring added value.

Table 5. Weekly Meetings

Practice
name
Problem
Context
Forces

Solution

Monitoring Reports
How to monitor the subcontractor?
Monitoring reports are used between customer and subcontractor to convey
information about the project progress mainly from subcontractor to customer.
The customer wants to monitor the progress made in the subcontractors teams, but
doing this is often very difficult since, e.g., the number of code lines, or hours used in
coding do not give very accurate information. Not following the progress at all can
cause negative surprises.
The subcontractor writes weekly or monthly progress reports which include
information, e.g., about tasks accomplished, open questions, problems, and future
estimations about task / problem solving schedules. The customer gives feedback on
every issue in the report.

Resulting
context

Design
rationale

estimations about task / problem solving schedules. The customer gives feedback on
every issue in the report.
The customer knows the situation in the subcontractors teams, can react fast when
the project is not going in the right direction and can also help in resolving
problematic situations. Feedback received from the customer gives the subcontractor
information that it is doing correct things. Getting feedback also motivates team
members.
Two case projects (Alpha1, Zeta) used monitoring reports. In one project they were
delivered every week and in another every month, since in this project weekly
meetings partly compensated reports.

Table 6. Monitoring Reports

Pattern
name
Problem
Context
Forces
Solution
Resulting
context

Design
rationale

Frequent Deliveries
How to monitor the progress in the project and ensure that modules are compatible?
You are designing the process for an inter-organizational distributed project.
Monitoring progress is important, but difficult. Concrete results clearly show how the
project progresses. These concrete results also add trust among developers.
Both customer and supplier use iterative process with frequent deliveries.
Subcontractor delivers functioning code during the development phase regularly, e.g.,
monthly or even weekly. The delivery is integrated into the system and tested.
Frequent deliveries, and integration and testing ensure that subcontractor is doing work
that is compatible and requirements are understood correctly. Also monitoring the real
progress is easier. Integration and testing gives developers instant feedback on their
work, which is very motivating. Moreover, when customer sees that subcontractor is
doing good work, customers personnel starts to trust and respect the subcontractor and
its developers know-how, which makes further collaboration easier.
Half of the projects (Alpha1&2, Beta, Epsilon) used frequent deliveries. An iterative
process model, with frequent deliveries seems to be very suitable for network use. The
iteration cycles varied between projects and also between project phases. In project
Alpha 2 two subcontractors used different iteration cycles, which caused problems. We
also noticed that the customer and supplier must do not need to have a common
process. Instead, both can use their own processes, as long as iteration cycles and
major milestones are synchronized.

Table 7. Frequent Deliveries

Relationship building
Relationship building in a distributed project is important for collaboration to
succeed. Relationship building actually takes place during all collaboration and
communication between parties. Here we want to emphasize the importance of
building a good relationship and trust between parties. Also this aspect should be
remembered when planning communication in a project.
It is best to start building the relationship right in the beginning of a project, e.g.,
a common kick-off meeting for the whole project or a sub-project is often a good
idea. If it is impossible to arrange due to large project size and long distances, you
could arrange other face-to-face meetings for important communication link
persons. For example, project architects or other key persons can go to the
suppliers site to train them, or some suppliers key persons can be invited to the
customers site for training or a short collocated working period. When major
problems arise they are best solved face-to-face. The practice presented earlier,
Frequent Deliveries, is good also from a trust building point, since being able to
produce functioning code in the early phase of the development builds trust

between parties based on their know-how. Here describe two patterns that were
noticed to be especially good for relationship building, but that also satisfy other
communication needs: Give Faces and Organization Chart.
Pattern
name
Problem
Context
Forces
Solution

Resulting
context
Design
rationale

Give Faces
How to avoid negative attitudes and disregard towards distant sites and partners?
Starting a distributed project with several partners and sites that do not know each
other beforehand.
Meeting everybody face-to-face would be an optimal solution, however that is often
not cost efficient. It is a known fact that it is much easier to disregard questions or
deliveries coming from unknown persons.
Arrange that in a networked project with new partners everybody meets at least
somebody from all other sites they will be collaborating with. This gives the sites
faces, they are no longer unknown and easily disregarded partners. These meetings
can take different forms, e.g., kick-off meeting, collocated working period, training
session or project steering group meeting.
A project with every site having a face.
Project Alpha1 Travelling Steering Group was used as a practice to give faces to
every site. In project Epsilon, testers were very reluctant to test the code delivered by
a subcontractor from a distant country. They preferred to test their mates work first.
The situation improved significantly after mutual visits. In project Beta a common
cruising trip was organized in the middle of the project when project was facing
difficulties. Before this trip many of the workers from different sites had never met
each other. After the trip communication and collaboration improved according to the
interviewees.

Table 8. Give Faces

Pattern
name
Problem
Context
Forces
Solution

Resulting
context
Design
rationale

Organization Chart
It is difficult to know whom to contact in a networked organization, when you do not
know anyone.
A large or medium size networked project with partners and/or persons that do not
know each other beforehand.
Same as in the Give Faces practice.
Make an organization chart of all persons contributing to a networked project, put it,
e.g., on the project extranet, where everybody in the project can easily find it. This
chart should include names, roles, contact information and preferably also photos and
some personal information, e.g., about hobbies. Update as necessary.
It is easier to find specialists to contact, e.g., when having problems.
This was regarded important in all larger projects. In project Alpha1 the customer did
not want to give the subcontractor customers organization chart, which caused
difficulties to the subcontractor. The subcontractors project manager tried to solve
the problem by creating an own organization chart of the customer by adding new
persons and their contact information, when he met them. In project Gamma a
website with photos and personal information was regarded as very useful.

Table 9. Organization Chart

Decision making and coordination
Inan inter-organizational project coordination and decision making is
concentrated to an inter-organizational steering group, project managers and

Weekly Meetings, described earlier. All these should take part of the
responsibility. Define what kind of decisions each of them can make and how the
whole project is informed about those decisions. Having a Travelling Steering
Group was an interesting and successful practice we encountered, the description
of which is in Table 10 below.
Practice
name
Problem
Context
Forces
Solution
Resulting
context

Design
rationale

Travelling Steering Group

How to coordinate a project distributed between many sites and companies?
A large project including a lot of distribution and uncertainty.
In a large project high-level decisions are hard to make and coordinating a highly
distributed project with a lot of uncertainties is difficult.
Arrange a project steering group consisting of members coming from all sites and
partners, also from the subcontractor companies. This steering group should meet
often enough, e.g., once a month, and meet in different project sites.
When every site is involved most of the important decisions can be made in the
meetings and none of the partners is forgotten. When subcontractors can participate
also their point of view and worries are accounted. Besides decision making, these
meetings give participants a good overview of the whole project, which they can
convey to their own teams. The fact that the meeting place changes, forces everyone
in the steering group to visit all sites at least once and nobody has to travel every
time. This gives also the team members in every site a possibility to meet
representatives from all sites (compare Give Faces). The frequency of meetings
depends at least on the uncertainties and changes that project has.
This practice was used in project Alpha1. They regarded this as a very good practice.
It had helped them to avoid many problems in a project with lot uncertainties and
constant changes.

Table 10. Travelling Steering Group

DISCUSSION AND CONCLUSIONS
This paper presented communication needs, and communication patterns and
practices collected from one special type of NPD projects - globally distributed
inter-organizational software development projects. The main results of the study
are 1) the state of the practice was found to be very low regarding communication
practices and patterns used in networked software development projects, 2) the
paper presented an idea for collecting and presenting successful interorganizational communication practices from networked NPD projects as
communication patterns.
The most surprising result of this study was the low state of practice regarding
communication patterns and practices in our case companies, all successful in
their field. Actually none of the case companies had clear practices that would
have been commonly used in all inter-organizational projects. The practices
encountered were mainly project specific and created by project level trial and
error. For example, the case companies did not agree upon communication
practices in the beginning of their projects, which later caused problems.
We described five successful patterns and four practices encountered in our case
projects, as examples of communication practices and patterns. The patterns and
practices found and presented in this paper may seem quite basic. However, we
believe that in real life projects a lot of problems could probably be avoided by
their systematic use. Even though these patterns and practices were collected from
one special type of NPD project, i.e. software development projects, we believe
that very similar patterns could be useful also in other types of networked NPD
projects. Here we could describe only a few patterns, as useful examples, because

the limited number of case projects. We believe that even more important than
these patterns described, is the idea of identifying and documenting them. The
idea of collecting and recording experiences from real NPD projects as
communication patterns could bring useful information to managers in a form that
is easy to read and apply in projects. We believe that these kinds of
communication patterns are needed in networked NPD project management.
There are several reasons for this: 1) communication is seen as the main problem
in most of the projects, 2) the current state of the practice is very low, even basic
things are problematic, 3) current practices are project specific and created by trial
and error, 4) good patterns and practices are, so far, not much documented in the
literature.
Besides communication pattern
s and practices, this paper also presented
communication needs found in our case projects. Especially the need for problem
solving communication was recognized to be huge in the case projects, but
agreeing on how to arrange for it was often neglected. Other important, but
neglected, needs were relationship building and project monitoring
communication between distributed team members. These are needs that
managers should pay more attention to when planning networked NPD projects.
Future research
In the future we plan to extend this study on communication patterns and
practices. Our intention is to study more projects and collect successful
communication patterns and practices used in them. We would like to encourage
also other researchers to collect relevant patterns and managers to bring up their
experiences.
REFERENCES
[1] Moenaert, R. K., Caeldries, F., Lievens, A. & Wauters, E. (2000)
Communication Flows in International Product Innovation Teams. Journal of
Product Innovation Management, 17: 360-377.
[2] Brooks, F. P. (1987) No Silver Bullet - Essence and Accidents of Software
Engineering (Reprinted from Information-Processing 86, 1986. Computer 20(4):
10-19.
[3] Heeks, R., Krisna, S., Nicholsen, B., and Sahay, S. (2001) Synching or
sinking: global software outsourcing relationships. IEEE Software, March/April,
pp. 54-60.
[4] Herbsleb, J., Mockus, A., Finholt, T., and Grinter R. (2001) An Empirical
Study of Global Software Development: Distance and Speed. Proceedings of the
23rd International Conference on Software Engineering, ICSE. Pages, 81-90.
[5] IEEE (1994) IEEE Recommended practice for software acquisition, Institute
of Electrical and Electronics Engineers, Inc.
[6] Battin, R.D., Crocker, R., Kreidler, J., and Subramanian, K. (2001)
Leveraging resources in global software development. IEEE Software,
March/April, pp. 70-77.
[7] Mockus, A. and Herbsleb, J. (2001) Challenges of Global Software
Development. Proceedings of the Seventh International Software Metrics
Symposium, METRICS 2001. IEEE. Pages, 182-184.
[8] Carmel, E. and Agarwal, R. (2001) Tactical approaches for alleviating
distance in global software development. IEEE Software, March/April, pp. 22-29.

[9] Ebert, C. and De Neve, P. (2001) Surviving Global Software Development.

IEEE Software, March/April. pp. 62-69.
[10] Alexander, C.A. e t a l . ( 1 9 7 7 ) A Pattern Language:
Towns/Buildings/Construction. Oxford University Press, New York.
[11] Alexander, C.A. (1979) The Timeless Way of Building. Oxford University
Press, New York.
[12] Gamma, E., Helm, R., Johnson, R. and Vlissides, J. (1995) Design
Patterns, Elements of Reusable Object-Oriented Software. Addison-Wesley.
[13] Coplien, J.O. (1994) A Development Process Generative Pattern Language.
Proceedings of PloP/94, Monticello, Il, August 1994.
[14] Coplien, J.O. (1995) A Generative Development-Process Pattern Language.
In: Pattern Languages of Program Design, Coplien, J.O. and Schmidt, D.C., eds.,
Addison-Wesley, New York.
[15] Ambler, S.W. (1998) Process Patterns, Building Large-Scale Systems Using
Object Technology. Cambridge University Press.
[16] Brown, W.J., McCormick, H.W. and Thomas, S.W. (2000) AntiPatterns in
Project Management. New York, NY: Wiley Computer Publishing.
[17] Allen, T.J. (1977) Managing the Flow of Technology: Technology Transfer
and the Dissemination of Technological Information within the R&D
Organization. Cambridge: MIT Press.
[18] Dispersed Agile Software Development and Dispersed extreme Programming
web site: (http://www.fastnloose.com/cgi-bin/wiki.pl/dad) 17.4.2003
[19] Yin, R.K. (1994) Case Study Research, Designs and Methods. Thousand
Oaks, California: Sage Publications.
[20] Patton (1990) Qualitative Evaluation and Research Methods. Newbury Park,
CA: Sage Publications.
[21] Stahl, J., Killich, S. and Luczak, H. (1998) Co-ordination, Communication,
and Co-operation in Locally Distributed Product Development. Proceedings of the
5th International Product Development Management Conference, Como, Italy,
May 25-26, pp. 947-959.
[22] Project Management Institute (2000) A Guide to the Project Management
Body of Knowledge (PMBOK Guide).
[23] Rising, L. and Janoff, N.S. (2000) The Scrum Software Development
Process for Small Teams. IEEE Software, July/August, pp. 26-32.