BASEMENT
Floor Lay-out Design for Effective
Software Production:
Applying the Implications
from the Optimal
Communication Pattern of a Software
Project
Oscar
Team
Hauptman
90s:
86-024
Management
i^:mi^.i^:i0Mi^^
Sloan School of
Manage
in
the 1990s
r
Floor Lay-out Design for Effective
Software Production:
Applying the Implications
from the Optimal
Communication Pattern of a Software
Project
Oscar
Team
Hauptman
90s:
86-024
June 1986
Sloan
WP#
1798-86
©Massachusetts Institute of Technology
Management in the 1990s
Sloan School of Management
Massachusetts Institute of Technology
um
I
y 198/
'ED
Management
an industry and governmental agency-supported
to develop a better understanding of the
managerial issues of the 1990s and how to deal mosteffectively with them,
particularly as these issues revolve around anticipated advances in Information
in
the 1990s
research program.
Its
aim
is
is
Technology.
Assisting the
work of the Sloan School
working partners
in
scholars with financial support
research are:
American Express Travel Related Services Company
Arthur Young and Company
British Petroleum Company, p. I.e.
BellSouth Corporation
Equipment Corporation
Eastman Kodak Company
General Motors Corporation
International Computers, Ltd.
MCI Communications Corporation
United States Internal Revenue Service
Digital
and
as
- 1 -
FLOOR lAY-OOT DESIQ) FOR EFFECTIVE SOFTHARE FRODOCTION:
APPLYING THE IMPLICATIONS FROM THE OPTIMAL CWOTONICATION
PATTERN OF A SOFTHARE PROJECT TEAN^
Oscar Hauptman
Management of Technological
Innovation Group
Sloan School of Management
Massachusetts Institute of
Technology
Cambridge, Massachusetts 02139
2
Production Operations
Management Group, Morgan Hall,
Harvard Business School
Harvard University
Soldiers Field,
Boston, Massachusetts 02163
ABSTRACT
The article takes the design of the IBM Santa Teresa software
development laboratory, as described by McCue [13], and suggests
modifications for the floor lay-out of a departmental module.
These modifications are based on recent findings by the author
about the information flow which seems to be most
[9]
[8],
effective in enhancing performance of software development and
production project teams.
THE INFLUENCE OF PHYSICAL LAY-OUT ON COMMUNICATION AT THE WORK-PLACE
Architectural lay-out of organizations has been found to be one of
the most powerful ways
structure.
to
influence
the
organizational communication
For instance, an analysis of changes in the communication
The research presented in this paper has been sponsored by the
1
Management in the 1990s Research 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 Sloan School, MIT Professors
Thomas Allen and Michael Scott Morton.
2
The author completed his Ph.D.
studies at Sloan School of
Management, MIT, June 2, 1986, and joined the faculty of the Graduate
Business School, Harvard University July 1, 1986.
- 2 -
patterns of a technology-based organization by Allen and Fusfeld
[2]
shows that weak or non-existent communication links were strengthened
or
change
reinforced by architectural
from one building
organizations,
findings in different
data
Tomlin's
instance,
Institute
show
[9]
influence
is
structure
will
mediated
(e.g.,
[1],
of
more
study
Allen's
each
in
Research
the
of
[1]
on
Hauptman's
communication
Obviously, the influence of physical
-
[9])
other
the
of
members of
the
their
daily
The
tasks.
members
than
of
because they
same
applies
larger organizational units such as departments and divisions.
logical for organizational structures to reflect
team
project
same
frequently
more
formal
organizational
controlling for physical separation,
interdependent
For
United Kingdom all
separation
physical
design
the
[17],
with
communicate
different projects,
are
by
Ireland
of
these
countries.
IBM Watson Research Center,
the
patterns in these organizations.
lay-out
Republic
the
departments
of
corroborated
and
from International Computers Limited,
direct
the
studies
industries,
Industry,
non-territorial office at
results
from
[17]
Food
the
of
Subsequent
another.
to
relocation
and
It
to
is
task interdependence
by teaming together those members of the organization who are involved
in similar or complementary tasks.
Before
emergence
the
technologies
such
as
the
of
electronic
new
information-communication
organizational
mail,
and
physical
re-design could be considered one of the few effective means for the
modification
of
organizational
research
members.
effort
technologies
to
communication
Although
concerning
modify
patterns
the
there
power
organizational
and
daily
interactions
interest
of
and
is
significant
of
information-communication
communication
patterns,
e.g.,
- 3
the Management In the 1990s Research Program at the MIT Sloan School
of Management,
or the Social Science Research in Computing Program at
University,
Carnegie-Mellon
evidenced
be
through
from
above,
presented
findings
and
premises
to
Consequently, this paper is based on
empirical and reliable research.
the
yet
is
it
the
pre-inf ormation-communication technologies era.
After establishing the basis for the use of architectural lay-out
the objective of this paper is to
as a communication modifying tool,
apply some of the findings [8],
project
flow
information
effective
teams
for
development
software
architectural
the
to
about what could be considered an
[9]
lay-out
of
a
and
production
typical
software
development environment.
OPTIMIZING THE INFORMATION FLOW TO THE SOFTWARE DEVELOPMENT TEAM
The findings from an empirical study of the software development
division of International Computers Limited, UK [8],
the
relationship
development
between
projects
requires
can
be
a
and
indicate that
performance
communication
specific
of
software
pattern
from
The prescriptions which were derived from this
the development team.
study
communication
[9]
summarized
in
the
terms:
following
first,
the
intra-project communication among managers, designers, and programmers
This finding is very much in line with Brooks's
should be minimized.
experience
suggests
mutual
[7]).
described
that
there
re-training
Second,
in
is
of
the
a
seminal
high cost
members
of
Mythical
to
large
be
Man-Month
paid
project
for
[A],
which
coordination and
teams
([15],
[14],
open and intensive communication among the managers of
- 4 -
a
department, which Is usually based
on a common technology such as
is conducive
graphics, data base access tools, or language compilers,
Third, the frequency of communication of
to high project performance.
the project team members beyond their department with the members of
the
business
application,
center,
usually
management
e.g.,
administration
which
software,
a
software,
support
inconsequential
seems
performance is concerned.
addresses
specific
market
or
public
CAM,
far
as
as
its
communication beyond the business
Finally,
center with the members of other business centers should be minimized
and
the
in
time
same
controlled
by
few managers
a
—
project
the
managers, and the head of the department.
These prescriptions are contingent upon various qualifiers such as
the complexity of the software,
They
comparative difficulty.
or its
probably do not apply to all types of software development projects,
primarily
but
application
to
projects
those
software.
For
findings presented in [8],
type
this
[9],
which
of
produce
moderately
in
projects,
view
novel
of
the
software "development" is a misnomer.
More specific constructs of R&D and production should be used for its
composits.
But
differently.
as
a
more
than that
-
these
composits
should
production or manufacturing activity,
familiar vehicle
the
managed
While programming or coding should probably be managed
software
engineering and
design probably will benefit from informal communication,
be
be
of
technological
which will
innovation of non-software
R&D [1].
It
formal
should
phase
be noted here
that
the
suggestions above imply a more
demarcation between design and
coding,
which
seems
to
,
- 5 -
some
extent
ignore
to
integration
It
[6].
recently
the
possible that the
is
feasibility
achieved
their
of
recently evolving software
CAD and code generators, as well as fourth generation languages (4GL)
will
be
here,
able
organizational
the
Nevertheless,
technological means.
by
organizations
producing
software
Furthermore,
technologies.
the
[18],
replace
to
availability
as
is
present
suggested
most
of
without
convincingly argued
technologies
these
of
at
operate
still
it
demarcation,
does
by
not
the
these
Yourdon
make
the
principles of phase demarcation or structured design and programming
obsolete.
Assuming that this is the type of software we have to deal with,
the
section
following
provides
recommendations
some
concerning
the
architectural floor lay-out design for a typical software development
and production department.
MODIFYING THE ARCHITECTURAL LAY-OUT OF IBM SANTA TERESA
SOFTWARE DEVELOPMENT LABORATORY
The
Santa
Teresa
IBM
Software
development
provides
center
the
lay-out, which will serve as a strawman for the ideas derived from the
studies
software
what
the
relations
development
might
attempts
for
of
to
software
be
teams
considered
create
a
between
([8],
one
of
comfortable
development
and
design process in detail.
It
communication
[9]).
The
the
most
and
and
center
performance
of
designed
in
was
thoughtful
and
functional working
production.
McCue
[13]
careful
environment
describes
the
started by defining the task as project
work, which includes operating systems and application programming and
- 6 -
testing,
documentation,
design,
and
The
support.
work
had
to
be
conducted in teams of two to five members, and was to be intensive and
creative.
Every two to four teams were incorporated into a department
with a manager and administrative support.
The designers of the lab
assumed that the members of the project teams would spend 30% of their
time alone, 50% in groups of two and three, and 20% in larger groups.
This
time
findings.
work
allocation
similar
quite
is
McCabe's
to
3
[12]
empirical
The most essential characteristics of the individual level
which
environment,
were
derived
from
several
at
IBM
distraction,
and
terminal
and
surveys
include:
work
1. Personal
discourage
area
interactions;
to
it
screen
concentrate,
should
also
contain
a
sufficient space for storage of documentation and print-outs;
2.
Proximity
to
common
terminal
rooms
for
team
work
and
small
meetings;
3. Proximity to conference rooms;
4.
Proximity to computer rooms.
The team level requirements were:
1. To
encourage effective communication-interactions within teams
and departments;
2.
Flexible spatial arrangements;
3. Integration
of
the
administrative
area
with
the
programming
area.
McCabe found [12] that members of software development teams
spent 30% of their time working alone, 50%
interacting with other,
and 20% non-productively, on travel and administration.
- 7 -
Figure
-
1
:
JBM's Santa Teresa Software Development
Laboratory:
A Departmental Module
[13]
Project
Module
Terminal
Rooms
Programmers'
Offices
Department
Manager
1
1
- 8 -
designers
The
of
Teresa
Santa
the
center
to
has
achieve
privacy
for
the
programmer
individual
the
of
For instance, the
numerous contradictions these requirements contain.
lay-out
aware
were
individual work space close
concomitantly with open office planning;
enough to aggregate work areas; small scale identity close to central
The final
services; Informal atmosphere in a large scale laboratory.
results of this design endeavor are provided in Figure 1.
These
conflicting
requirements
Lab
Teresa
Santa
at
are
atypical of software development elsewhere; Deutch and Taft
in
empirical
their
importance
comparative
programming
that
study
of
There
although
first,
recognize
differences between design and coding, (e.g.,
be
this
present
the
the
good
a
for
reasons
at
show
[5]
about
should
what
of
several
are
most
consensus
little
is
dimensions
the
environment.
situation:
there
not
the
[16]), very few are
[5],
ready to formalize this separation organizationally and architecturally.
But
about
probably
optimal
the
understanding
of
most
the
teams and departments"
"effective
really means.
better.
Based on my empirical findings
actually
intra-project
try
coordinative
to
communication;
minimize
overhead
this
(e.g.,
confusion
implicit
incomplete
the
is
The way
without much empirical evidence,
for
the
within
communication-interactions
implies,
true
of
environment
programming
what
cause
central
type
[16],
is
worded
in
[13]
that more communication is
[8],
on
of
it
[9],
the
this is not quite
contrary,
communication
4
[10] ).
And
as
we
should
a
costly
while
the
1
Howlett [10] formulates the total output of an n members team
working jointly on a totally divisible task as W(n)=n-kn(n-l) , where k
is
coordinative
the
constant
consumed
by
of
time
proportion
9
-
Lav-out of a Software Development Department:
Applvinq the Results About the Optimal Information Flow f91
Figure
Legend
DM
PM
•
2:
Project
:
Module
Department Manager
Project Manager
Mr- Marketing Expert
V- Validation
TA - Technical Author
•
D • Designers' Offices
P- Programmers' Offices
PS • Project Secretary
S - Secretary
C • Conference Rooms
Project's
Tl
71
Common
Area
lo
.
- 10 -
intra-departmental communication is conducive to project performance,
the
intra-business
inter-business
communication
center
center
communication
inconsequential,
is
even
has
the
on
effect
negative
a
and
project performance.
In addition, because the domain of the project was found to be so
local, this implicitly suggests that a diverse, multi-functional staff
at the department level would be more effective.
components
important
product
software
the
of
production process as the validation team,
the
Consequently,
such
development
and
technical author,
and
possibly the marketing expert should be incorporated in the department
The
floor
which
lay-out,
takes
Santa
the
Teresa
software
development house, and modifies it according to the findings about the
in Figure
presented
optimal information flow prescribed above is
2.
This lay-out should facilitate a better technical coordination among
the key members of the department by bringing the designers, managers,
validation
staff,
a
marketing
expert,
and
a
reduce
designers
through
and
amount
the
programmers,
physical
Teresa
Lab
widespread
[13],
in
and
isolation:
individual offices,
as
and
the
organizational
of
among
first,
the
the
suggested by the
not
an
software
open
International Computers Limited, UK).
coordination
programmers
programmers
between
themselves,
will
occupy
initial design of the Santa
space
industry
author
At the same time it
physically together at the center of the floor.
should
technical
floor
(e.g..
with
partitions
Applied
so
Systems,
Second, the designers are to be
communication.
Consequently, the net contribution of a new member
added to the team, after integration and training is W(n+l)-W(n)=l-2kn.
- 11 -
located
closer
towards
the central
core
not very restrictive,
of
the
it should
programmers,
the
Although this separation is
floor.
emphasize the differentiation between
designers'
and
structured
design-programming approach -
programmers'
from
separately
somewhat
together,
tasks,
and
also
should
it
completion
the
enhance
the
software
of
design before the product is moved to the coding stage.
Concerning
center
intra-business
the
communication,
design
initial
the
and
center,
of
the
inter-business
Santa
the
Teresa
departmental module fits the information flow requirements described
above:
its
location
in
a
module,
separate
one
on
floor,
naturally
Isolates the department from other departments of the business center,
and
from
other
business
On
centers.
the
other hand,
the
suggested
location of the managerial staff of the department close to the hub of
the
building,
by
the
stairs,
will
make
managers
the
of
different
departments and business centers more mutually accessible.
SDMMA&T
The modified lay-out described in Figure
can
be
regarded
as
the
software
2
manufacturing
puts the coders,
who
onto
the
personnel,
periphery of the floor, and the software engineering specialists - the
designers,
support
towards the center of the floor.
staff
such as
validators,
technical
The managerial and
authors,
and
the
marketing
specialists are concentrated as closely as possible to the managerial
and support staff of other departments and business centers.
It also
creates the small group environment for the development team, in which
the
rest of the organization
is not
quite visible and accessible to
- 12 -
most of its rank-and-file members.
In a sense,
the isolation of the
project team developing a software product enhances its productivity,
in contrast with the non-software R&D project teams (e.g., [3], [11]).
It
is
on which
findings
[9]),
important
emphasize
to
the
at
architectural
this
stage
Systems
division
of
ICL.
the
They
should
In
addition
this
to
word
of
([8],
in this case - the
corroborated
be
additional research in other organizations in the USA and
Japan.
empirical
based
recommendations are
stem from a study of a single organization,
Applied
that
caution,
the
by
possibly,
architectural
recommendations for floor lay-out of a software development department
presented in Figure
Teresa
or
conceptual
an5rwhere
2,
have never been tested empirically at IBM Santa
else.
guidelines
development facilities.
Consequently,
about
they
architectural
can
serve
design
as
of
general
software
The influence of the suggested environment on
software project teams communication and performance should be tested
empirically by managers of software development and production.
- 13 -
REFERENCES
[I]
Allen, T. J. (1977). Managing the flow of technology
Massachusetts: MIT Press.
[2]
Allen, T. J.
architecture
Management
[3]
,
.
Cambridge,
Fusfeld, A. R. (1975). Research laboratory
communications.
the
structuring
of
and
153-164.
&
5^,
R&D
Allen, T. J., Lee, D. M. S., & Tushman, M. L. (1980). R&D
performance as a function of internal communication, project
the
nature
of
work.
IEEE
Transactions
on
management,
and
Engineering Management EM-27 2-12.
,
,
[4]
Brooks, J. R. (1982). The mythical man-month (2nd ed.). Reading,
Massachusetts: Addison-Wesley.
[5]
Deutch, L. P., & Taft, E. A. (eds.) (1980). Requirements for an
(Report
CSL-80-10,
June
experimental programming environment
1980). Palo Alto, California: Xerox Palo Alto Research Center.
[6]
Freedman, D. H. (1986, April).
Technology 38-45.
Programming without tears. High
,
[7]
Gordon, R. L.
& Lamb, J. C. (1977). A close look at Brooks's
Law. Datamation 23, 81-83, 86.
,
,
[8]
Hauptman, 0. (1986). Influence of task type on the relation
between communication and performance: The case of software
development. R&D Management 16 127-139.
,
[9]
,
Hauptman, 0. (1986b). Managing software development;
Unpublished
Communication
as
a
success
factor
dissertation, MIT. Cambridge, Massachusetts.
doctoral
.
[10] Howlett,
J.
(1985). Informal correspondance. ICL, London, UK.
[II] Katz, R., & Allen, T. J. (1982). Investigating the Not Invented
Here (NIH) syndrome: A look at the performance, tenure, and
communication patterns of 50 R&D project groups. R&D Management ,
12, 7-19.
[12] McCabe, T.
J. (1976). A complexity measure. IEEE Transactions
on Software Engineering SE-2 308-320.
,
,
(1978). IBM's Santa Teresa Laboratory - architectural
design for program development. IBM Systems Journal 17 4-25.
[13] McCue, G. M.
,
[14] Mills, H,
D. (1976). Software development.
13-27.
on Software Engineering SE-2
,
,
IEEE Transactions
,
P. B. (1975). Predicting programming
group productivity - a communication model. IEEE Transactions
on Software Engineering, SE-1, 7-14.
[15] Scott, R. P., & Simmons,
- 14 -
[16] Somerville, I.
(1982). Software engineering . London: Addison-
Wesley.
B. (1979). Dyadic technical communication in a
research
geographically-dispersed
organization
Unpublished
doctoral dissertation, MIT. Cambridge, Massachusetts.
[17] Tomlin,
.
(1986). What ever happened to structured analysis?.
Datamation, 32, 133-134, 136.
[18] Yourdon, E.
63^
u40
iBR'^'JIEf,
i
3
^060
005b7MbE
M
MIT
3
TOflD
LIBRARIES DUPl
1
00St.7Mb2
M