^o/
TBC.^,
HD28
.M414
no. 171285
1985
APR 02 1990
to
INFLUENCE OF TASK TYPE
ON THE RELATION BETWEEN
ICOMMUNICATION AND PERFORMANCE:
THE CASE OF SOFTWARE DEVELOPMENT
Oscar
Hauptman
90s: 85-013
INFLUENCE OF TASK TYPE
ON THE RELATION BETWEEN
COMMUNICATION AND PERFORMANCE:
THE CASE OF SOFTWARE DEVELOPMENT
Oscar Hauptman
90s: 85-013
May, 1985
Sloan
®
WP#1712-85
O.
This paper appears
Hauptman
in
the April, 1986 issue of
R&D Management
Management in the 1990s
Sloan School of Management
Massachusetts Institute of Technology
APRC:
1390
Management
in the 1990s is an industry and governmental agency supported
research program. Its aim is to develop a better understanding of the managerial
issues of the 1990s and how to deal most effectively with them, particularly as these
issues revolve around anticipated advances in Information Technology.
Assisting the
workmg
work of the Sloan School
partners
in
scholars with financial support
and
as
research are:
American Express Travel Related Services
Arthur Young and Company
British Petroleum Company, p. I.e.
BellSouth Corporation
Digital Equipment Corporation
Company
Eastman Kodak Company
General Motors Corporation
International Computers, Ltd.
MCI Communications Corporation
United States Internal Revenue Service
The conclusions or opinions expressed in this paper are those of the author(s) and
do not necessarily reflect the opinion of Massachussetts Institute of Technology,
Management
in
the 1990s Research Program, or
its
sponsoring organizations.
3
- 1 -
INFLUENCE OF TASK TYPE ON THE RELATION BETWEEN COMhfUNICATION
AND PERFORMANCE: THE CASE OF SOFTWARE DEVELOPMENT^
»
2
,
Oscar Hauptman
Sloan School of Management
Massachusetts Institute of Technology
Cambridge, Massachusetts 02139
Abstract
The relations between communication patterns and performance of
software development projects mostly resemble those of technical
services, and not development projects, in hardware R&D. The
local
focus
of
software
development
projects
their
in
information requirements is emphasized by the positive influence
only of the informal and mostly internal literature, while
external contacts, participation in conferences, and formal and
external literature were inconsequential. The implications are
two-fold:
a)on
the
conceptual
level
they
suggest
that
a
trade-off between coordination and innovation requirements of
the
task
might
be
an
important
determinant
of
optimal
communication patterns; b)on the practical level it suggests
that "software development" consists of "software engineering"
and "software production". Consequently, it should be recognized
that as such, these activities should be managed differently the former as R&D, the later as manufacturing.
INTRODUCTION
Coordination versus innovation in software development
Coordination of task activities comes through as a key requirement
in what is usually defined as "software development".
Mythical
notion
Man-Month"
that
"Adding
(Brooks,
manpower
1982)
to
a
brings
late
up
the
software
The seminal "The
counter-intuitive
project
makes
it
later" (p. 25). The reasons given by Brooks are that the coordinating
1
2
3
The research presented in this paper has been sponsored by the
Mangement
in
Nineties Research
the
Program,
Sloan
School
of
Management, MIT.
This study has been facilitated by an exceptional level of support
by ICL, UK. My gratitude goes to the Applied Systems members whose
continuous participation in this study made it possible. Special
acknowledgement to Hugh MacDonald (Technical Directorate), Asa Lanum
(Director Applied Systems), and Ken Bodenham (C&TS) of ICL, for
their unwavering support.
My gratitude to Tom Allen whose review and critique significantly
contributed
to
the
quality
of
this
Michael
study.
Finally,
Scott-Morton's help was invaluable in launching this research.
-
2
requirements
of
the
which
project,
increase
as
second
a
power of the
number of project members, substantially dilute the contribution of added
A
manpower.
significant
part
of
goes
It
Initial
to
learning
and
integration of the new member into the project team. Another component Is
the continuous, day-to-day coordination of individual's work with the
activities of other team members.
The
importance
of
coordination
requirements
emphasizedby the time allocation of
the
data
typical
indicate
(1978)
that
interacting with other
20%
are
process
System
(Abdel-Hamid
losses"
development
and
available
Simmons,
modeling
of
with
this
individual;
they
is
spent
the
base-line
with
other
as
of
team
spent
is
working alone;
The
software
phenomenon
recent
development
"communication
single
a
members
person
represents
Using Brooks's formulation (see also Mills,
1975)
of
might
it
constitute
thirty members team.
a
interfaces
have
to
up
be
between
This
of
the
upon,
a
1976;
total
overhead consists
and of increased work-load,
software
agreed
50%
to
is
McCabe's
time
administration.
the
communication
"man-months"
necessary
the
30%
and
of both verbal coordinating interactions,
to
programmer's
while
describes
1984)
,
"team",
a
individual programmer.
travel
on
Dynamics
coordinating overhead.
Scott
spent
Compared
(p. 183).
of
team members,
non-productive,
comprehensive
50%
software
in
modules
produced
formalized
by
through
due
each
design,
executed in software code, and finally, documented.
simplified
A
model
(Hewlett,
which
1985),
assumes
constant
coor-
dinating requirements per dyad, and a totally divisible task, examplifies
this issue. The net useful output of the team can be computed as:
W(n) = n - kn(n-l)
(1)
when n Is the number of team members, and k is the constant proportion of
time
consumed
kn(l-n)
premises
by
component
coordination
the
is
the
adding another
can be computed by:
oriented
coordinating
person will
communication
cost
result
of
in
a
effort.
The
the
project.
net
contribution which
On
these
- 3 -
W(n+1) - W(n) = [(l+k)(n+l) - k(n+l)^] - [(l+k)n - kn^] =
=l+k-2kn-k=
= (1+k) -k(2n+l)
l-2kn
The "break-even" point of the net contribution,
is
in
realistic
the
range
premises,
communication
contention
that
non-productive
is
when
regarded
only
which
time
"the
values
of
(Somerville,
time"
group
a
(2)
at which it equals zero,
k=5%,
n=10.
costly
a
spends
On
these
overhead.
communication
on
p.2A8)
1982;
and
widely
is
The
is
accepted
a
by
software management academics. It sounds quite axiomatic.
In comparison with this articulate treatment of planning, control and
coordination issues in
of
it
fails
project
address
to
performance
software
the
value
the
through
well-understood
product"
administration
of
references
software
to
software
related
communication
of
technological
Dijkstra (1976) on task discipline
and
management
emphasizes
activities.
emphasis
of
problem
this
in
structured
and
other hand,
the
innovation
organization
major
to
The
On
technology transfer
a
contributing
formal
the
instance Boehm (1980) argues that
constitutes
most
achieve a more reliable
to
technological
related
in
innovation.
"in order
development
literature,
are
industrial
the
to
field.
For
few.
He
advocates
better training of software professionals in the intricacies of real-life
software
development,
emphasizing
software than just programming.
of
technological
Innovation
estimating
their
half-lives
ranging
He
in
"half-lives".
between
fact
the
much
is
also addresses the issue of
software
Most
10
there
that
and
related
have
them
of
40
core
years,
more
the pace
technologies
comparatively
with
exception
the
to
by
long
of
hardware based technologies such as microprocessors, with a half-life of
approximately
two
years.
But
even
In
statement
his
technological
the
Issues do not seem to be quite as salient as the coordinative ones: fully
55%
and
37%
government
of
acquisition
identified
reports
and poor control (respectively) as the problem (p. 50),
18% Identifying technology related factors.
special
role
of
the
designer
in
software
poor
planning
in comparison with
Freeman (1980) emphasized the
technology,
and
advocated
the
development and implementation of advanced design tools.
This
concepts
one-sided approach is puzzling
and
empirical
evidence
from
in view
the
of
the well articulated
hardware
R&D
environment
- 4 -
provided
Allen
by
associates.
and
comprehensively
is
It
summarized
in
"Managing the Flow of Technology" (Allen, 1977). The studies in the frame
of
this paradigm reliably showed the usefulness of internal and external
communication
contributing
in
performance.
project
to
The
central
two
premises on which the theory of communication in R&D is based are:
the
sufficiently complex,
typical R&D task is
assortment of technical expertise that
on
information
adequate
because
Second,
technologies,
the
flow
from
typical
R&D
team
task
the
technical
information,
emphasize
the
need
especially
depends
inflow
also contributes
"gatekeepers"
on
wide
a
to
date
duration.
Both
up
information,
inter-organizational
the
project's
to
team.
evolving
rapidly
technical
of
task
the
long
of
addition,
In
to
adequate,
projects
continuous
for
external
maintain
in
usually through informal channels.
flow through
sources
cannot
such
successful completion depends
its
task
requires
and
first,
success
(Allen
and Cohen, 1969).
This controversy can be summarized in the following lines:
hand,
development
software
coordination
to
effectiveness.
development
management
planning,
regulations
thought
represents
Their
field
control,
and
researchers
and
factor
experience
success
suggests
failure.
proper
rules
This
managerial philosophy in the field.
the
the
software
that
formal
and
or
consider
determining
in
structure
project's
decide
will
salient
most
the
be
practitioners
on the one
On
and
trend
the
of
other
hand, in view of the image of software development as an unstructured and
intellectually abstract activity,
Allen's
premises
Consequently,
are
expected
would
we
of
operate
to
expect
complexity resembling hardware R&D,
this
In
innovation
environment
carrying
as
well.
communication
to
contribute to software development effectiveness.
The process of software development
Before trying to resolve this controversy it is important to consider
the
idlosyncracies
consensus
about
development
publication
components
b)Program
of
the
software
list
process,
and
this
area
in
of
process
the
design,
of
c)
development.
activities
their
lists
as:
Programming,
that
temporal
in
similar
There
is
constitute
vocabulary
and
d)Verif Ication
and
the
software
every
Almost
sequence.
a)Requirements
considerable
the
typical
specifications,
validation,
and
- 5 -
(Boehm,
e)Malntenance
list
(1982)
contents is almost Identical:
of
Programming
Practice,
and
Testing
6.
2.
Engineering"
Requirements
Language,
Programming
The
4.Implemetation:
"Software
Somerville's
p. 54).
1979;
Design,
3.
,
Implementation
5.
Debugging,
II:
Documentation
and
explicated
the
7.
Maintenance (p. ix-x).
nature
The
activities
these
of
can
briefly
be
in
following product development scenario: The first stage is the generation
of
an idea
for
new application
a
or
usually through an
new product,
a
Interaction between marketing experts and designers from the development
step
second
The
unit.
terms
technical
architects,
this
and
programmers
Next,
and
designers
by
analysts.
focusing
over,
take
"draftsmen".
The
result
iterations
several
"policing"
with
reliability
the
Here,
!
electronics
consumer
the
of
constitutes the final product
from
work
industries,
manufacturing
hardware,
military
to
other
is
actually
prototype
with
contrast
After
which
department,
this
and
prototype.
the
is
program,
in
engineers"
"civil
assurance
quality
the
"code-
and
performed interactively
the
are
programmers'
of
design
the overall program designer Is
If
programmers
the
construction
program architecture.
detailed
is usually
It
and iteratively with detailed design.
"architect",
on
specification into
resemble
They
stage is usually described as
cutting" - the actual programming.
the
product
translation of
the
is
or
reproduction of the software development prototype is a trivial procedure
of
and
simple copying from various memory devices,
diskettes.
floppy
comparable
contribution
contrast
packaging
to
of
the
to
added
value
The
documentation
and
marketing.
In
But
"charter" of
the
the
process
this
and
in
is
probably
differences
R&D staff
to ROMs
disks and tapes,
not
do
hardware
negligible,
lower
than
end
there;
Industries,
the
in
the
software development team is also responsible for maintenance and support
final
product
emotion-loaded
reaction
of
the
Alert"
telex
"bugs"
in
personal
the
from
the
the
with
the
of
software
field
program,
responsibility
a
end
salesman.
and
for
the
their
It
manager
explicitly
occurance
witnessed
have
I
development
development
situation is not atypical in view of the
Boehm, 1979; Somerville, 1982)
user.
spelt
manager
in
this
a
"Red
trouble
to
correction.
and
literature
had
to
the
area
-
assume
This
(e.g.,
- 6 -
In
light
the
development
process
special
above
the
of
over-emphasis
the
attributes
of
coordination
on
software
the
might
well
be
grounded. Still it is interesting to know whether the innovation carrying
communication is inconsequential for this type of task.
nature
The
of
task
the
as
determinant
a
the
of
relation
between
communication and performance
that
Andrews
and
Pelz
develoment
software
classification
(1966)
neither
is
R&D
of
basic
task
types
applied
nor
suggests
research.
The
process is well structured, and is based on specific routines of design,
production,
and
testing.
Intended to apply to
a
It
obviously
is
hand,
other
application
of
in
attributes
task
facts
and
theory
design,
study,
(development)
systems"
Lee and
its
exploratory
through
be
new
of
using
systems
(technical
products"
suggest
existing
improvements
that
the
effectiveness
and
services)
impact
(there,
project
of
performance
"The
testing
existing
1980)
(
.
patterns
neither
or
existing
and
al
On
problem
for
et
communication
omnipresent,
either
to
markets
Allen,
p. 4).
team
not
is
new
Opening
knowledge.
p. 3).
components
products, processes, or systems. Recombination, modification,
of
nature
particular
a
testing
and
1980:
can
it
solve
to
"Cost/performance
or
Tushman,
(Allen,
view of
known
general
of
broad range of application or to the devlopment of
a
new knowledge about an area"
the
"Work
not
on
its
uniform.
In
their conclusions they emphasize that:
Many
have
long
realized
research and engineering
that
distinctions
the
laboratory
needs
from
These
in
that
will
staff
behave
must
made
be
According
are
to
their
especially
projects
technical
service
did
rest
marketing
not
while
of
and
follow
projects
more
tasks
in
those
appears
subtle
than
an industrial
quite
process
and
basic
different
development.
concerned with product
(p. 11).
findings,
the
from
Now it
even
have
and
product
turn are quite different
from communication with
firm,
with
concerned
university
laboratories.
differently
very
modification and adaptation
service
industrial
in
between
staff performing more reserach-oriented
that:
the
difference
the
development
the R&D laboratory
production,
this
pattern.
consistenly
and
research
In
benefited
benefited
projects
the
and
addition,
from
rest
of
technical
only
the
management
.
- 7
with
communication
controlled
environment
the
external
project
to
the
in
addition
team (see Allen et al., 1980, Table VI, IX, XII-XIV)
results
These
suggested
those
nature
team,
task
et
While
al.
determines
implications
it
Informational
the
needs
in more structured and routine tasks.
be as salient
plausible
very
is
of
It
is
to
that
the
project
the
organizational demands for coordination and
usual
the
interesting
have
Allen,
by
the
of
might
control
can
reasonable to
assume that the tasks for which coordination is more important might have
lower needs for informally acquired external technical information.
inverse
two
relation actually
types
implies
-
communication
of
situation
a
trade-off
of
coordination-oriented
the
This
between
versus
the
one
the
which enhances technology transfer and innovation.
nature
The
of
development
software
address the above questions:
which coordination seems
the
relations
Allen
similarity
essential.
results
relations
with
hardware R&D continuum.
be
important
between
for
for
communication
which
tasks
In
and
require
R&D
coordinative
than
a
with
first,
development,
nature
provide
compare
to
development
of
to
for
task,
reasons:
two
coordination
the
performance will
more
for
software
development,
of
software
in
research,
because
addition,
type
setting
interesting
be
either
for
exciting
performance
and
classify
to
software
would
It
an
structured
hardware
for
found
technical service will help
to
well
a
communication
between
(1980)
al.
et
is
it
provides
along
or
the
considered
is
the
relations
"measuring
innovation
stick"
carrying
communication.
RESEARCH SETTING AND METHODS
The
study
division of
was
carried
International
out
at
the
Computers
application
Limited
(ICL),
software
UK.
The
development
division
is
responsible for development and support of a variety of software product
-lines,
from
language
compilers
software
and
super-structures
to
self-
contained software packages for end users. These product are marketed all
over the world to a variety of customers,
(turn-key and custom-made)
consists
of
systems,
data
knowledge
dictionary,
to
small
firms.
engineering,
graphics,
from large public bureaucracies
The
language
and
technological assortment
compilers,
recently
CAD
and
relational
artificial
8 -
intelligence. Most of the products share the core technology of software
technology,
This
development.
approximately
being
twenty
years
old,
is
presently reaching maturity.
facilities
The
of
division are
the
another
two
Kidsgrove,
Manchester,
Groups
sites.
several
geographic
Berkshire includes the divisional headquarters
sites in the UK. Reading,
and
among
spread
of
35
Smaller
Bracknell.
and
employees
150
to
are
groups
located
one
of
in
ten
to
employees are spread in London, Leeds, Slough, Birmingham and Newcastle.
time
the
At
of
study
the
approximately 650 people,
mostly
included
some
technical
Applied
the
of
Systems
them part-time
professionals,
division
freelancers.
marketing
experts
employed
study
The
various
and
operational and technical consultants (N=503). The division was organized
Business
three
into
These
administration.
between
contained
Centers
units
were
and
three
one
Sectors,
four
and
sub-divided
software
not
including
departments
into
development
which
projects.
The
projects were comparatively stable work areas.
Internal communication
Communication data were
collected
via
questionnaires
were
asked
distributed
in
August-September
198A.
the names of all
the members of survey population the most recent date at
which
The
communication
work-related
a
participants
took
to
The
place.
against
indicate
preliminary because the data of October and December 1984,
results
and
are
May 1985
surveys are not included here.
response
The
generate
least
at
rate
approximately
was
unilateral
nominations
60%,
of
which
were
communication
sufficient
partners
to
for
95% of the population.
Aggregate
coefficient
and
mutually
measures
of
variation
exclusive
of
for
units
communication
average
project
were
members
computed
with
intensity
and
its
progressively larger
similarly
to
Allen,
Lee
&
Tushman (1980).
1.
Intraproject communication:
one's immediate project team.
Communication with all the members of
- 9 -
communication:
Intradepartmental
2.
members
of
A department
department.
the
core technology,
graphics,
e.g.
Communication
usually
was
with
based
all
either
or focused on a specific market
the
on
a
segment.
This aggregate does not have an analogue in Allen, et al. (1980) study.
similarly
Allen
to
2)Inter Business
a
with
Communication
3.
segment,
of
division:
the
l)lntra
into:
al.
Business
This
was
divided
Center/Sector;
and
Business Centers/Sectors usually address
Center/Sector.
market
larger
et
rest
the
Public
e.g.
Administration
which
includes
projects in legal and health data base markets.
The intradepartmental and intra Business Center/Sector communications
eventually
were
divided
communication
into
with
a)programmers,
b)designers, and c)managers.
Other sources of information
Literature
performance
project
Lee,
&
external
and
contacts
(Allen,
1977;
were
useful
found
Tushman,
Allen,
Tushman, 1980). The following data,
&
development
to
Lee,
Allen,
1979;
standardized for project size,
were collected via questionnaires to test the importance of these sources
for software development:
Frequency
1.
readership
of
of
informal,
and
mostly
internal
publications such as internal ICL reports, software and hardware manuals,
informal
and
technical
reports
from
government
universities,
and
other
firms.
2.
as
Frequency of readership of formal, and external publications such
scientific
and
professional
conference
journals,
proceedings,
trade
periodicals, and textbooks.
3.
Frequency of communication with suppliers,
university
staff,
staff
other
of
customers,
finally
and
firms,
consultants,
was
friends,
aggregated into an overall index of external communication of the project.
A.
Participation in external conferences
by
project members between
1982 and 1984.
Project performance
Project
most
of
purpose.
performance was
the
These
twenty
evaluated
managers
criteria
were
in
on
several
Applied
similar
with
criteria,
Systems
those
suggested
inteviewed
mentioned
by
for
by
this
numerous
- 10 -
publications in software engineering or software development area.
The criteria that were selected are of two types:
which
managerial,
success
emphasize
meeting
in
coordinative
the
designated
project
2) technological,
which emphasize
meeting
specifications
project
quality of the
product
of
and
budget
the
-
and
-
task
schedule,
dimension
functionality,
of
and
success
in
comparative
the
maintainability and flexibility.
reliability,
in
dimension
Innovative
the
l)organizatlonal or
An overall measure of project success was also collected.
evaluations were collected separately from
The project
evaluators
manager,
and
Applied
in
and
for
which
six,
and
experts.
1978).
most
use
aggregate additive
of
number of
quality assurance,
evaluators was
sufficient
both
project
the
between
cost-efficient
and
reliability of the additive scales for
with
adequately
were
included
marketing,
the
computing
by
criteria,
the
of
The
typically
The
considered
is
criteria was assessed
f lexibiltity,
the
manager,
design
and
(Libby and Blashfield,
each
They
department
the
structure
three
Systems.
variety of
a
Cronbach alpha.
exception
the
high
its
(between
scales
based
of
on
maintainability
and
0.71
the
alphas
The
justifying
0.87),
scores
and
of
individual
evaluators.
important
An
communication
from
collection
performance,
to
these
of
which ensures
factor,
is
performance
data;
the
the
direction of the causal
months
5
evaluations
between
lag
were
link
the
collected
in
February 1985.
It
should
between
0.78
separate
be
and
mentioned
0.92)
analysis
here
among
that
the
various
organizational
of
the
high
correlation
performance
(coordination
(Pearson
criteria
r
prevent
oriented),
and
technological (innovation oriented) criteria
RESULTS: RELATIONSHIP BETWEEN COMMUNICATION AND PERFORMANCE
Communication within the project
Similar
to
communication
(Table 1).
Allen
seems
et
al
.
(1980),
inconsequential
In addition,
as
the
far
frequency
as
of
performance
intra-pro ject
is
concerned
the variation of intra-pro ject communication
- 11 -
Table 1
Relation Between Performance and Communication
Among Project Team Members
Results from
Allen, Lee and
Tushman (1980)2
Research
- 12 -
relations between Intra-pro ject
Though positive
performance might be expected,
the above results.
makes
which
members,
First,
6
several
possible causes
for
the project teams are not larger than eleven
coordinating
their
Brooks's premises, minimal.
vary between
there are
communication and
requirements,
view
in
of
Second, because the number of team members
and 11, the coordinating requirements do not vary
significantly across projects.
assume
we might
In addition,
that
the
project members expertise is based on similar core technologies, which
should reduce the value of innovation oriented internal communication.
Communication within the department
The
department
consists
thirty
of
communication intensity within
The
technical.
usually
people,
all
of
department
the
them
clearly
contributes to project performance on all of the performance criteria,
statistically significant for meeting designated
specifications and overall project success
contribution
is
valuable
for
both
the
functional
schedule,
(Table
3).
coordination
In
a
sense
the
and
the
oriented
innovation oriented criteria.
Table 3
Relation Between Performance and Communication Among Department Members
Results from the Software Environment (present study)
Overall
Meeting
Meeting
Success
Meeting
Functionality
in ReliaProject
Designated Designated
Success
Schedule
Specifications bility
Budget
-*-
0.40**
0,37**
0.13
0.28*
0.22
1-Kendall's Tau; **p=0.05, *p=0.10
The
data
Table
in
communication
should
be
4
suggest
evenly
spread
that
intradepartmental
the
among
the
project
members,
especially if consider the functionality and reliability criteria.
Although
there
Allen et al.,
the
is
no
analogue
for
this
grouping
intermediate
results are quite similar to the
next
level of
in
the
organizational structure - the Business Center/Sector or the division
in Allen et al.
These data are presented in Tables
5
and 6.
- 13 -
Table 4
Relation Between Performance and the Variation (st .dev/mean)
Across Project Members' Communication Within the Department
Results from the Software Environment (present study)
Meeting
Meeting
Meeting
Success
Overall
Designated Designated
Functionality
In RellaProject
Budget
Schedule
Specifications blllty
Success
-^
-0.12
-0.36**
-0.22
-0.26*
-0.22
1-Kendall's Tau; **p=0.05, *p=0.10
Communication with the rest of Applied Systems
As
mentioned
before,
Business
a
Center/Sector
Is
addressing
a
specific market segment but is not based on a specific technology.
In
addition to technical staff It Includes marketing experts as well.
It
is
significantly larger than a department,
strong.
Business
The
Center/Sector
environment (Table
setting,
in
significant
and
project
with
people
performance
in
resemble the relations at the
5)
Allen
communication
between
relations
between 80 and 200 people
et
al.
correlation
with
study.
functionality
is
the
software
the
technical service
presumably
The
within
statistically
rendered
insignificant
in view of a higher probability for its occurance solely by chance due
to multiple comparisons.
Table 5
Relation Between Performance and Communication With the Rest
of the Division: Intra-Buslness Center
Allen, Lee and
Tushman (1980) ^
Results from the Software Environment
Meetlng
Meeting
Meeting
Functionality
Designated Designated
Specifications
Budget
Schedule
(present study)
Success
Overall
In RellaProject
blllty
Success
-0.17
0.30*
Research
0.13
0.20
Development 0.31*
Technical
Service
0.18
[Most similar to present study]
1-Kendall's Tau; 2-Pearson Correlation; *p=0.10
The
also
relations
similar
distribution
to
of
-*-
0.23
0.16
between communication variation and performance are
those
of
technical
communication
of
service
the
in
software
the
sense
development
that
the
project
- 14 -
team with the divisional staff, external to its
is
inconsequential
different
from Allen
performance
proejct
for
et
al.
results
for
immediate department,
(Table
This
is
quite
projects,
which
6).
development
benefited from evenly spread communications.
The
similarity
technical
service
communications
the
of
continues
(Table
results
for
and 8).
for
the
development
software
inter
Business
reasonable
with
Center/Sector
assume
that
the
while
the
technology carrying communication is either irrelevant or missing.
The
coordinating value of
7
these
It
is
communication
is
to
non-existent,
negative relations are somewhat puzzling. They might be the result of
a
situation when intensive communication was
spurred
by
an
internal
problem, which this communication could not resolve.
Table 6
Relation Between Performance and The Variation (st .dev/mean) Across Project
Members' Communication with the Rest of the Division; Intra-Business Center
Results from the Software Environment
Meeting
Meeting
Results from
Designated Designated
Allen, Lee and
Budget
Tushman (1980)
Schedule
-*-
Research
Development
Technical
Service
1-Kendall's
-0.17
-0.25*
-0.03
-0.02
(present study)
Meeting
Success
Functionality
in ReliaSpecifications bllity
-*-
-0.09
-0.02
Overall
Project
Success
0.00
-0.02
[Most similar to present study]
Tau *p=0.10
;
Table 7
Relation Between Performance and Communication
With the Rest of the Division: Inter-Buslness Center
Results from
Allen, Lee and
Tushman (1980) ^
Results from the Software Environment
Meeting
Meeting
Meeting
Functionality
Designated Designated
Budget
Schedule
Specifications
-0.44**
-0.35**
-0,30*
-0.34
Research
Development 0.09
Technical
-0.47**
Service
[Most similar to present study]
1-Kendall's Tau. 2-Pearson Correlation. ** p=0.05, * p=0.10
(present study) ^
Overall
Success
Project
in ReliaSuccess
bllity
-0.47**
-0.44**
- 15 -
Table 8
and
The
Variation (st .dev/mean) Across Project
Relation Between Performance
Members' Communication with the Rest of the Division; Inter-Buslness Center
(present study) ^
Success
Overall
In RellaProject
blllty
Success
Results from the Software Environment
Meeting
Meeting
Meeting
Designated Designated
Functionality
Budget
Schedule
Specifications
Allen, Lee and
Tushman (1980) ^
-0.20
0.34*
Research
0.28
0.24
-0.27**
Development
Technical
Service
0.15
[Most similar to present study]
1-Kendall's Tau; **p=0.05, *p=0.10.
0.51**
0.49**
The most relevant network; programmers, designers or managers
the
communication networks
various
The
rest
division were
the
of
separated
and managers. Although most of
project
department
and
comparison
with
technical
team
and
designers
least at the level of
trained,
such
staff
they represent the formal,
programmers,
at
technically
are
project
the
programmers,
into
the managers,
managers,
purely
between
still,
designers
as
in
and
coordlnative dimension of the
organization.
Intra-departmental
The
managers,
provide
department
the
the
information
most
useful
can
still
data
head,
Table
in
project
Information
positional responsibilities of managers,
indicates
managers,
the
to
innovation
be
9
it
team
and
view
in
should be noted that in contrast with Allen
of gatekeepers
this
of
the
should be coordlnative as
Those managers might be the departmental gatekeepers,
well.
its
leaders
Although
project.
oriented,
that
&
though it
Cohen (1970) description
(see also Allen, 1977) they are usually second or third
level supervisors, and they do not design or program themselves.
On
other
the
designers
or
hand,
managers
communication
the
should
not
with
neither
channelled
be
programmers,
through
few
individuals; the lower Is the coefficient of variation - the higher is
the
project
departmental
performance
management
communication with most
(Table
team
of
10).
It
indicates
maintains
open
and
project
team
members,
the
provide them with the necessary Information.
that
direct
it
when
the
channels
of
succeeds
to
- 16 -
Table 9
Relation Between Performance and Communication
within the Department with Programmers, Designers and Managers
Communication
with:
Programmers
Designers
Managers
Results from the Software Environment
Meeting
Meeting
Meeting
Designated Designated
Functionality
Budget
Schedul e
Specifications
-0
(present stu dy)-^
Success
Overall
in RellaProject
bllity
Success
- 17 -
Table 11: Relation Between Performance and Use of
Various
- 18 -
comprehensive
Frank's
languages.
structured
technologies,
computer
interactive
review
programming,
industry
the
of
and
(1983)
emphasizes the cases of the MARK IV high-level computer language, and
-
ADA
programming
a
All
technique.
those
purely
are
process
technologies.
My
communications with software development
informal
ICL validate
Applied Systems,
they had already
that
started
fabrication"
"software
situation.
this
to
of
them
at
indicated
describe application programming as
"code-cutting".
or
Some
managers
On
other
the
most
hand,
emphasized that the development of system and super-structure software
presents
challenge
a
this
type
of
different
typical
more
activities,
from
resemble
more
than
It
oriented
Development
of
manufacturing,
in
programming.
R&D
volatile.
"code-cutting"
the
application
of
products will
technologically
and
unstructured,
complex,
more
is
the hardware vocabulary.
In
view of
Information,
this
overwhelming
the
similarity
of
the
relations between communication and performance with technical service
should
treated
be
insignificant
team,
not
especially
a
includes
mostly
super-structures,
results might
tasks.
development
be
the
On
assortment
application
and
only
software
with
for
system
single
a
this
type
an additional software
projects,
to
of
operating
the
sample
a
few
the
above
only
products
validate them.
environment, containing
representative
On
the
program,
does
and
additional data available
These results are still preliminary;
from the Applied Systems should be used
spectrum.
in
the
project
development
software
of
by
the
to
projects
the
of
R&D
the
in
software,
probably
valid
external
communication,
activity,
judging
hand,
one
the
communication
of
intra-flrm
because
hand,
caution.
contribution
qualify as
other
with
systems,
a
A study of
sufficient number of
super-structures,
and
applications, will be very useful for internal and external validity.
Still,
a
misnomer;
on the
basis of the data ad hoc,
more specific constructs of R&D,
maintenance should be used for
its
"software development" is
production,
composists.
But
more
and
than
probably
that
-
these composists should be managed differently. While the coordinatlve
- 19 -
might
approach
appropriate
be
activities,
maintenance
for
premises
the
quasi-manufacturing,
the
communication
of
technological innovation will apply to software R&D.
the
image
R&D,
in
of
the
software
development
context
of
quasi-manufacturing
being
information
different
so
flow,
Software
activities.
only
is
the
carrier
as
It
and
implies
that
from
hardware
true
for
engineering
the
design
and
probably will benefit from informal communication, which will be
familiar
vehicle
technological
of
innovation,
This hypothesis could and should
non-software R&D.
the
similarly
to
through
tested
be
of
additional rigorous research.
The coordination-innovation trade-off
in addition to Allen et al.
The results from software development,
(1980)
technical
from
data
studies
numerous
First,
emphasize
services
based
interesting
an
on
premises
the
communication-as-innovation-carrier showed that
point.
of
internal communication
of project team members with other professionals in the R&D laboratory
is a strong determinant
monopolization
of project performance.
communication
of
with
On the other hand,
professionals
these
the
project
by
managers was beneficial for technical services.
integrated when we
These diagonally opposite views can be
innovation
coordination
and
oriented
Coordination
requirements
communication
in
could
trade-off
a
more
be
regard
situation.
salient
than
innovation carrying communication for tasks which are more structured,
maturing technology.
based on a stable,
end
of
probably
the
R&D
software
These are
represented
spectrum,
production
.
They
do
tasks at
technical
by
require
not
a
acutely
threatened,
organizations,
many
as
especially those
R&D
departments
operating
in
a
lower
services,
and
wide variety of
They also are
technical expertise for their optimal performance.
as
the
not
technology-based
of
project
structure,
by
the rapid professional obsolescence of their technical staff.
An
alternative
interdepedence
require
close
level
perspective
of
task
interaction
for
this
activities.
with
each
phenomenon
If
the
other,
requirements will increase parabolically. Although
could
task
the
be
the
composites
coordination
technical
services
.
- 20 -
software projects seem to present such a highly
do not fit this mold,
interdependent
program's modules is
inherent,
pre-requlsite
strong
Because
environment.
a
the
interdependence
closely controlled
adequate
of
of
software
interaction is a
functionality,
usability,
reliability, maintainability, and flexibility.
In
view of Allen et
results
al.
from
services,
technical
it
is
clear that the issue of the coordination-innovation trade-off presents
itself in hardware R&D.
is
the
result
researchers
on
trade-off,
and
of
the
The fact that it had not been addressed as yet
somewhat
technological
its
one-sided
Innovation.
significant
focus
of
R&D
analysis
The
potential
of
this
implications
for
suggests an exciting agenda
organizational design of R&D,
management
for
future
research in the area of R&D management.
REFERENCES
Abdel-Hamid, T. K. (1984). The dynamics of software development project
System
Dynamics
perspective
An
integrative
management;
Unpublished doctoral dissertation, MIT. Cambridge, Massachusetts.
.
Allen, T. J. (1977). Managing the flow of technology
Massachusetts: MIT Press.
Allen, T. J., & Cohen, S. (1969).
laboratories. ASQ, lA, 12-19.
Allen, T. J., Tushman, M. L.
transfer as a function
development to technical
22(4), 694-708.
,
.
Cambridge,
Information flow in R&D
Lee, D. M. S. (1979). Technology
the spectrum from research through
services. Academy of Management Journal
&
in
,
Allen, T. J., Lee, D. M. S., & Tushman, M. L. (1980). R&D perf romance
as a function of internal communication, project management, and
the nature of work. IEEE Transactions on Engineering Management
EM-27 (1). 2-12.
,
Boehm, B. W. (1980). Software engineering - as it is. In Freeman, H. &
Lewis, P. M. Ill (eds.). Software engineering (pp. 37-73). New
York: Academic Press.
Brooks, F. P. Jr. (1982). The mythical man-month (2nd ed
Mass: Addison-Wesley
Dijkstra, E. W. (1976). A discipline of programming
New Jersey: Prentice-Hall.
.
.
)
.
Reading
Englewood Cliffs,
- 21 -
(1983). Critical Issues in software
Frank, L. F.
.
New York: Wiley.
Freeman, P. (1980). The central role of design in software
engineering: Implications for research. In Freeman, H.
M.
Ill
(eds.).
Software engineering
(pp. 121-132)
Academic Press.
.
Howlett, J.
(1985).
&
Lewis, P.
New York:
Informal correspondance. UK, Harwell.
Llbby, R., & Blashfleld, R. K. (1978). Performance of a composite as a
function of the number of judges. Organizational Behavior and
Human Performance 21 121-129.
,
,
Mills, H. D. (1976). Software development. IEEE Transactions on
Software Engineering 68(9).
,
McCabe, T. J. (1976). A complexity measure. IEEE Transactions on
Software Engineering SE-2 308-320.
,
,
& Andrews, F, M. (1966). Scientists in organizations:
Productive climates for R&D New York: Wiley.
Pelz, D. C.
,
.
Scott, R.
F.
& Simmons, P. B. (1975). Predicting programming group
productivity - a communication model. IEEE Transactions on Software
Engineering SE-1 (4).
,
,
Somervllle,
I.
(1982).
Software engineering
.
London: Addlson-Wesley.
63^1
3i
MIT
3
TOfiO
LIBRARIES
00563015
GASEMBNTe
Du
pT^r"^***?*
^^U&.31 iaJ4
Lib-26-67