Engineering Management International, 4 (1988) 287-297

Elsevier Science Publishers B.V., Amsterdam - Printed in The Netho-lands

287
Rick Thomas
Evenvie w Corporation, P. 0. Box 9204 15, Norcross, GA 30092 (U.S. A .)
and Robert Drury
Systems Management Consultant, Atlanta, GA (U.S.A.)
ABSTRACT
Engineering managers, faced with ever greater
system integration challenges, must actively im-
prove team communications. As a conceptual
tool, the work activity of a system. development
team may be described in terms of a group of cou-
pled conversations. Based on this approach, a
model is outlined which offers a graphic repre-
sentation of team resources and a metaphor for
interactive communication activity. Use of the
model encourtzges complete consideration of the
requirements for a given conversation and helps
to explicitly document successful interaction
patterns. Models with these features are ex-
pected to lead to broader use of computer work-
stations for managing system development. Until
then., the concepts are valuable to managers to
help to organize and clarify their teamwork.
INTRODUCTION
There is no doubt that skills with language
are among the primary factors determining
management success. To gain cooperation,
managers communicate.
A project can be seen as a series of conver-
sations which result in reaching a goal. By no-
ticing and sharing common conversatinn
patterns as explicit entities, effective patterns
are refined and reused, serving as an organiza-
tional tool. Productivity improves because of
*Paper presented at the First International Conference on
Engineering Management, Washington, DC, September
22-24,1986.
more certain and quicker conversations.
Such extended uses of language will appear
as tools begin to support richer structuring by
communicators. Current management skill de-
velopment can anticipate these tools. These
skills in turn will influence the tools and the
structures that they support. In this way, every
team may be a test bed for future communica-
tion m&hods.
The purpose of this paper is threefold: to con-
sider the potential of teamwork communica-
tion tools; to illustrate the use of explicit models
for communication in management; and to en-
courage management effort in these areas.
This work is not empirical. It offers a synthe-
sis of current developments into a conceptual
0167-5419/88/$03.50 0 1988 Elsevier Science Publishers B.V.
288
design. The approach is intended to be prag-
matic. The authors are managers who seek to
realize the potential value of advanced com-
munication methods.
First, premises on management and human
nature are presented. Then there is a review of
some significant technical developments. In the
context of engineering projects, requirements
for team communication support tools are pre-
sented using a graphical model for resources.
Finally, implications for current action are
sugg:;sted.
MANAGEMENT AREA OF INTEREST
As an illustration consider a group of mana-
gers/engineers who are forming a team to han-
dle a major project. Through clear personal
agreements, they seek excellent team perform-
ZYJC. Given a preliminary specification for a
commercial elertronic product, the team is to
build a new factory including structure, auto-
mation equipment, and initial staffing and op-
eration. Not only must the team consider many
technical and market issues, but must also con-
stantly refine ad hoc procedures for corre-
spondence, accounting, calendars, documen-
tation, contracts, and the like.
This example is from a field referred to as
systems management (Silverman, 1983, p.
1052). Systems management includes both de-
velopment and operations aspects of a large
technical system. It is characteristic of such
teams to develop complex, one-of-a-kind prod-
ucts. These products typically have diversity of
physical structure, of formal contractual rela-
tions, and of required operations knowledge. In
the projects many parallel activities, there are
many unforeseen contingencies to address.
Generally, when there are complex require-
ments, when the work product is not immedi-
ately tangible, and when there are many people
in dependent efforts, a project plan does little
to insure success when Yaken to the bank,
What are the limitations of a team that intui-
tively concern a conservative banker or tech-
nical manager when presented with a proposal?
First, we are limited as communicators. Dif-
ficulties include:
(1)
(2)
(3)
(4)
Sustaining communications goals such as
making complementary tradeoffs and
reaching consensus.
Keeping a complete, shared view of the
current work design and possibly over-
whelming options.
Dealing with the mechanics of communi-
cation such as the need to send messages
when certain events occur, and the need for
many people to participate in a meeting at
the same time.
Bearing the high development cost of com-
munication procedures.
We are also limited in acquiring and using
system knowledge.
(1)
(2)
(3)
(4)
When working with large systems, there is
less breadth of experience in a career.
There are only limited policies of recording
experience.
There is a disinclination to search for so-
lutions. Experts are scarce and the system
manager is very busy.
Early choices in a design may become costly
blind alleys when it is necessary to restruc-
ture a system (Silverman, 1983, p. 1052).
New management challenges demand new
methods. Robert Goizueta of Coca-Cola put it
this way: The acceleration in technology growth
has accelerated everything else in our world,
including the obsolescence of business experi-
ence. . ..in all our plans we must also plan to
quickly change our plans if necessary. (Goi-
zueta, 1986)
To achieve the called-for flexibility, tech-
niques are needed which allow the team (and
its partners ) to follow a coherent joint course
of action.
A VIEW OF WORK
What one can imagine clearly, one can re&
ize. Along the way, one learns to recognize fa-
miliar situations and to know what is
289
significant. Frequently, one must take experi-
mental paths, responding with confidence to
surprises, while alert to meaningless events,
At every turn there is the opportunity to im-
prove skills and tools. This is the nature of
craftsmanship: experience in following an un-
hldi2~ path and unconsciously using (and
spontaneously learning) guiding patterns or
old friends.
As a team member, one proceeds coopera-
tively, with shared directions, in constructing
quality results. Communication patterns de-
velop, based on that richest of unconscious pat-
terns, natural language ability.
All of this goes on all the time, a sort of man-
agement by going somewhere. The key quality
that a person brings to work is awareness, a
willingness to experience and act, which is di-
rected towards work through communication.
The focus here is on team communication
tools which complement these aspects of hu-
man nature, while taking them as given. A val-
uable tool will enable a team to form
conversational environments which will mu-
tually reinforce the team members intuitions.
This approach encourages us to treat as ele-
mental units the conversations surrounding co-
operative work effort and also to avoid
untestable concepts such as mental informa-
tion processing. (For a philosophical treat-
ment of this issue, see Winograd and Flores,
1986, pp. 68-73) where the authors argue
nothing exists except through language.)
In this paper, organizational boundaries and
functions are purposedly blurred in favor of a
focus on conversations as elements. So while
the level of interaction varies widely within the
team, the action of every team member impacts
to some extent the action of every other Like-
wise, little consideration is given here to spe-
cific administrative systems within which
people might work. These are seen as accumu-
lated results of conversations which serve to
address the resource needs of the team.
ORGANIZING VHROUGH
COMMUNICATION
The ways that managers have happened and
chosen to organize have brought us to this junc-
ture. Enterprise can be seen as structure accu-
mulated through a series of past conversations
plus the presently active conversations. To-
gether these working conversations, when
characterized, are our baseline for synthesizing
new communication designs. Past conversa-
tions may be characterized by observing struc-
tural remnants and starting new conversations
concerning the record. And current conversa-
tions may be sampled with empirical tech-
niques such as those of Mintzberg (1973). A
first step is to describe the range of manage-
ment work as a scheme of conversations, as il-
lustrated with the following statements.
System management work is seen conven-
tionally as simultaneous planning, implement-
ing, and monitoring processes, though the
defining lines are usually quite blurred (Sayles
and Chandler, 1971) .
(1) Planning is a process of communicating
about opportunity. A plan is a snapshot of a
continuing discussion.
( 2) Team members implement components
of a system. They direct their crafts according
to conversations. They also communicate about
cooperation and thereby structure the conver-
sations about results. We usually think of this
as action.
( 3) Monitoring, or measurement, is key to
meeting the requirements of a complex project.
Having a clear view of present situations and of
inherent possibilities, managers direct their en-
terprises better. This view is gained in large part
through conversation.
Organizational development, cast as com-
munication, includes &ill building, team build-
ing, and tool building.
(1) In skill building, we learn how to do
something by watching, doing, and through
conversation. Through conversation, we also
learn about sources of work-related experience,
290
personal management habits, and communi-
cation skills.
(2) In team building, we seek to develop co-
operating units by promoting good personal re-
lations and a common point of view. A ?ommcn
language helps immensely. Coordinating the
viewpoints of team members requires recurring
conversations. These recurring conversations
are the source of team structure. In this sense,
the design of effective conversation patterns re-
places organization charting and policy making.
( 3 ) Tool building includes the establishment
of the infrastructure by which conversations are
held. Conventional media ( meeting room, tele-
phone, correspondence) offer a channel but no
inherent aid for structuring. On the other hand,
computers used as communication media pro-
vide for structure. A computer program, such as
a spread sheet or database, is most often seen
as a way to represent some aspect of the work.
A different view is that these programs are
waystations for segments of conversations ar-
ranged in patterns.
To complete this view of organizational de-
velopment, note that measurement of effective-
ness at development efforts is critical in building
successful teams just as measurement of work
results is critical in building successful prod-
ucts. By clearly observing the teams conver-
sations with its public and itself, we find
direction for our next steps.
Using this approach, both system manage-
ment work and organizational development
work are cast as similar conversational pro-
cesses. Conversation is used as a common con-
ceptual thread through the processes of
producing work and building team ;. This offers
a more general design metaphor but more im-
portantly allows us to think explicitly about
conversations which operate on other
conversations.
NICAL DEVELOPMENTS
Current developments in communications
and computer technology are discussed here for
two reasons: First, these technologies, used in
products and in organizing, present growing
opportunities for the system manager. Second,
and more importantly for this paper, they illus-
trate and support abstract designs useful in
management work.
Communication standards are established so
that users with different equipment needs can
coexist in a common framework. In order to de-
velop this framework, an industry group typi-
cally forms a standards development committee.
This process is an ongoing agreement, to agree
on a standard.
Currently, the Manufacturing Automation
Protocol (MAP) (Kaminski, 1986) and the
Technical Office Protocol ( TOP) (Farowich,
1986) are good examples. In these cases, a model
for communications standards practices, estab-
lished by the International Standards Organi-
zation
(ISQ),
was used. Several nnajor
manufacturing companies adopted this model
and initiated a long process of proposal an.d re-
view to build consensus.
The IS0 model is made up of several layers
of services. The lower-level services are con-
cerned wit*h physical connection, network ad-
dresses, message routing, session management,
and terminal compatibility. Each layer ldeals
with specific technical issues and provides a
service which makes its implementation trans-
parent to other layers. At the higher levels, ap-
plication layer services support user messages,
electronic mail, file transfer, and database ac-
cess. Building on this level, user groups can
standardize messages about their local environ-
ments. Figure 1 shows a summary of the IS0
layers plus two non-standard layers illustrated
here by workstation applications.
The Apple MacintoshTM and other desktop
metaphor user interfaces present the user with
a visual means to organize files. In some cases,
basic operations are common to all application
programs. These user interfaces serve as pro-
prietary standards to implement a layer sup-
porting communication of a capability in
software form from a developer to the user.
Fig. 1. Communication standards.
On the desktop, there may be another layer
of software specialized to support interpersonal
communication concerning the work at hand.
A recent development, software generically re-
ferred to as coordinators (Winograd and Flo-
res, 1986), permits coworkers to jointly track
their commitments. These systems enforce a
standard framework for a conversation so that
action is more likely to result. By representing
working conversations, they, in effect, repre-
sent (or model) the work product.
While these two software systems are not
currently being developed as communication
standards, they suggest that the standards Ipro-
cess can continue to higher levels of communi-
cation function.
Programming language usually brings to mind
a familiar procedural language. These lan-
guages, now highly developed, use a sequence of
instructions to manipulate data. Seeing limi-
tations in this approach, computer scientists
have developed programming methods which
can more clearly represent real situations.
One such method is known as object-oriented
programming (Booth, 1986). Classes of ob-
jects can be defined which represent physical or
conceptual things. This includes abstract ob-
jects such as a task in a project management
program, and material objects such as a me-
chanical component. The programming lan-
291
guage is used to describe internal states of
objects, and message generation and receipt by
the objects. Some programming systems also
support on-screen visual objects.
Useful properties of programming objects in-
clude these:
(1) There is no dichotomy between instruction
and data; definitions of object classes in-
which are trig-
received by the
(2)
(3)
(4)
elude action instructions
gered when messages are
object.
Objects can be combined
objects.
t.o produce new
Sub-classes of objects can be created which
provide more specific features while inher-
iting the properties of the original, more
general class.
Objects can be viewed by either specifica-
tion or implementation. This allows an ob-
ject to be used on a trial basis before it is
complete.
Object-oriented programming is mecha-
nism that captures a model of the real world
(Booth, 1986, p. 220). The primary reason for
presenting this technique here is to introduce
modeling concepts and the possibility of intui-
tive manipulation of computer-based artifacts.
It is important to note that this is a computer
language formalism that is not a valid model for
human communication.
Knowledge engineering, specifically the devel-
opment of expert systems, offers to represent
operations knowledge in a usable form. A typi-
cal expert system contains numerous, unique
representations of expert knowledge. These
rules describe situations and resulting deci-
sions. An expert system also includes a scheme
for chaining rules together in order to reason
from an existing situation to a desired outcome.
(See Hayes-Roth (1984) for more depth.)
An integral part of most expert systems are
tools that the developer/expert can use to help
manage the collection of rules. Maintaining
consistency and accuracy can be difficult when
many rules interact.
It is natural to think 0.f managing this devel-
292
opment process with the help of rules about
building expert systems. Rules may describe
how other types of rules are used. Different
types of rule-making knowledge may be distin-
guished and the development process can be
made more explicit. Neches (1985) argues that
this step is essential if one is to be able to ex-
plain and change an expert system. In other
words, for an artificial expert to be trustworthy,
it must be clear how it came to lay claim to
expertise.
Expert systems serve to facilitate a dialog of
evolving understanding among a knowledge-
able community ( Winograd and Flores, 1986,
p. 76). These technical systems are tools for
managing communication about expertise and
are not equivalent to human experts.
With this in mind, an analogy can be sug-
gested between expert system deveivpment and
team management. In each case, there is an in-
cremental integration of new knowledge into an
existing framework. For the expert, system, this
framework is the collection of rules. For the
team, the framework is the established patterns
of communications.
Richer metaphors can be used to describe
communication practices (independent of
computer technology) and can become part of
our natural language. These technical devel-
opments suggest several management policies:
(1)
(2)
(3)
Working language, a complex, open sys-
tem, can serve more effectively when more
clearly defined and taught.
Actions, recorded in a usable form, can
guide future action and allow continuing
refinement of methods.
An explicit process of development, re-
corded in a usable form, can allow easier
changes to and more trust in an
organization.
MANAGEMENT MODELING CONCEPTS
Management science often presents a model
of a management situation as part of a program
of action for the practitioner. A primary limi-
tation of such models is that they do not share
a global framework and as a result are difficult
to plug in to an organization. Two authors
who address these issues are considered briefly.
DeMarco (1982) provides a framework for
modeling software projects. Integrated models
serve to represent the specification (environ-
ment ) , the design (product), and the develop-
ment process (project). Since software
development is done on computers it is rela-
tively easy to maintain these explicit models.
Such models offer the possibility of using pre-
viously recorded experience as components of a
new effort.
In other management domains, good means
for maintaining models are not so readily avail-
able and it is correspondingly difficult to reuse
experience.
In general engineering projects, modeling re-
fers primarily to representation of the product.
Numerous representation conventions are es-
sential in complex projects, but are limited in
their ability to provide complete integrated
views. Media used for modeling are diverse.
(1) A common model medium is human
memory and shared assumptions, with re-
nowned failings. (Though a lot can be accom-
plished using simple, persistent slogans. )
(2) Physical analogs, such as model bridges,
serve well as long as the product is primarily
physical.
(3) More effective are visual forms such as
drawings, and diagrams, as well as written spec-
ifications, precedence networks, spreadsheets,
data bases, and collected memoranda.
(4) For successively more complex projects,
the need is apparent for a framework in which
models are refined. One can envision consider-
ably more powerful schemes leading to a uni-
fied work representation from which team
members can select views as needed. (To some
extent this is accomplished in CAD systems for
designing microcircuit chips. )
In any field, it is the responsibility of a team
to adopt an effective work modeling scheme to
help team members share work. A few team
members have the responsibility for selecting
293
the work models which support the team. The
teams ability to represent work (and stay on
target ) grows with the successful paticipation
of these team members.
The focus of this paper is not on models of
the environment and product. Instead, models
of the project communication and team capa-
bilities are of interest. So to proceed with a con-
ceptual design, a graphical model for team
resources used in systems projects is presented.
The goal is to define a token that serves as a
general representation of a team.
Consider the properties of the popular tokens
called money. Money serves a purpose because
of its equivalence to common goods and serv-
ices. Homogeneous tokens are used as currency
to simplify exchange. Money is easy to use be-
cause we only have to count to use it.
Books, seminars, software, and professional
time can be thought of as an offering of expe-
rience. In the?Fe cases the goods may be under-
stood in terms of a token: liner notes,
brochures, and resumes. Unfortunately, the re-
liability of this understanding falters as the
services become complex and costly. Value of
these services is context dependent and is dis-
covered only as they are used. In other words,
market value for one-of-a-kind system prod-
ucts is undefined.
What is needed is for such experience to carry
with it a self-description in the form of a famil-
iar resource token. Then a busy user has a
handle on the situation. If tokens can be de-
signed which are more descriptive, yet still iso-
morphic to some degree, tokened experience can
be a currency of exchange.
A specific model to address this need is based
on the work of Low (1976). This work gives a
rich, static scheme for viewing teams and man-
agement activity. It is offered here as an illus-
tration, rather than a design. Any model for this
purpose is inherently incomplete until it stands
the test of implementation.
Figures 2 and 3 show outlines for models of
team and team member. For each of the six cor-
responding functional aspects, there is an anal-
ogy between the team and team member
.
Fig. 2. Team model.
capabilities. These six aspects for a team are:
Market need analysis or search,
Development,
Preparation of production resources,
Production,
Evaluation including finance and mea-
surement, and
Linking of products to the customer.
Associated with this model Low applies de-
sign criteria in evaluating a resource. Two of
these address the internal state of the resource:
simplicity and completeness. Two others ad-
Fig. 3. Team member model.
294
dress the interaction of the resource to the en-
vironment: fit to requirement and clarity of
purpose. Used as a framework for working con-
versation, such models may aid in making
judgements about these criteria.
Low also presents valuable perspectives on
the relation between structure and process and
on the role of limits in directing an enterprise.
Finally, the hexagon and cube geometry sug-
gests graphic representations of resources and
their relations. If elaborated, such graphical ob-
jects may offer a physically manipulated struc-
ture which represents the capabilities of teams
and their conversations.
REQUIREMENTS FOR A TEAM
MANAGEMENT MODEL
The ultimate goal of management design is
simple, clear conceptualizations which enable
broadly improved joint action. With this in
mind, the remainder of the paper offers the ba-
sis of a framework for enhanced team
communication.
A representation or modeling scheme for a
team is an agreement on a standard description
that aids in communicating about human re-
sources. The hexagon-shaped tokens may serve
as a general outline for such a standard. With
this in mind, several perspectives are consid-
ered: (1) the view of a team in representing its
capability, (2) the view of a team forming in-
ternal relations, and ( 3 ) the view of an individ-
ual developing workskills.
The model must provide a complete, yet sim-
ple, description of a team. To be complete, it
must allow a team to describe all of the major
functional aspects of its work. It must be simple
enough so that by seeing its mode! a team can
be easily recognized. This allows models to serve
as a token of exchange.
Similarly, a model must provide a way to rep-
resent a team member. A model of a team mem-
ber is a way for him to represent his capability.
The person works by establishing contact with
others by way of this representation. It is not a
mechanical substitute for that person. In a
sense, the model serves as a resume, not only in
matching a person to a job role, but also in day
to day offering of service within a team.
Externally, the representation for a team
should look like the representation for a team
member as suggested by Figs. 2 and 3. In other
words, the team resume and personal resume
can be read with the same familiarity. If job re-
quirements are then represented using the same
model, a manager can direct a team by match-
ing modeled expertise to modeled need.
From the outside, a model of a team nlusi
provide a way to represent, in a structured way,
the services offered. Since we are concerned with
professional work activity, another way to say
this is that the model must present communi-
cation patterns that the team will engage in.
When implemented this model may define for-
mal channels for actual communication to/
from the team.
As a team forms, it is necessary to model the
make up of the team from individual team
members. The model must represent specific
relations while supporting the standard exter-
nal interface. Given this tool, team members can
construct relations by defining patterns of
communication. The resulting structure may
then serve as a channel for communication
within the team. By creating a description of a
team and its commtinication patterns, effective
conversation is guided, in a way similar to cre-
ating and using forms or spreadsheet tem-
plates. Team members can use this facility to
manage their conversations and agreements. As
a by-product they can capture effective pat-
terns in useful form.
A model must also provide a way for the team
member to organize and view his capabilities.
A model should prompt a team member to con-
sider important aspects of the job role. And it
should guide the measurement of current effec-
tiveness. Finally, as a working environment, the
model becomes a channel through which con-
versations are conducted.
AS descriptive tokens, these models are to
295
serve as building blocks in the use of productive
resources. The team manager is a model builder,
combining resource tokens to form teams and
thereby produce systems. The modeling pro-
cess, though, is not like writing computer pro-
grams. Instead it can be a communication
process in which a manager operates as if he
were exchanging tokens, collecting a set which
represents a capability to accomplish the task
at hand.
To make a functional modeling scheme, while
maintaining the simplicity of the money ana-
log, several further requirements are needed.
The modeling process should apply, not only
to a teams own development, but also to an-
other, independent team being commissioned.
Since much of the function of system products
is team communication, the product and the
team building the product can be mod.eled with
the same methods. In other words, we are in-
terested in a team that produces teams: both
refinements of itself and new systems teams.
Much of the communication of a systems
team consists of messages about resource ca-
pability. If, conceptually, all work-related con-
versation seeks to match capability to need at
some level, conceptually, a resource model can
be extended to serve as an outline for most mes-
sages. Messages to/from models of team mem-
bers are tokens which represent capability and
specific action.
If this is accomplished, then each communi-
cation act can be both a message and an act of
modeling. Each message, in the form of a rec-
ognizable token, is a commitment in an action
conversation. As a model for future messages,
it may be part of the establishment of a pattern
in an action network. And as a description of
part of a system, cumulatively, these messages
form a model of the product, created by
communicating.
The relation between a resource model and a
message should be direct and clear. A resource
model represents the potential to address a pur-
pose and grow to meet it. Messages are in-
stances of this capability. Furthermore, the
messages are components in the construction
of a developing resource which serve to extend
the framework of cooperation. Successive stages
of growth are reached by conversing about re-
sources and enabling these resources to func-
tion well.
The value of viewing teams, individuals,
messages, and system components with a com-
mon model lies in simplifying and integrating
working conversations. All of these things are
similar in that they are ideas or words of
importance to system managers. In any orga-
nization a special jargon develops as a short-
hand for issues in the work at hand. Resource
models, as suggested by the tokens, can be part
of such a specialized language. The benefit of
using these words is in their participation in
the structure of a cooperative effort. A token
may have meaning in a specialized context. At
the same time it has standard handles that can
relate it to those who might not need to under-
stand its full capability.
WORKSTATIONS TO SUPPORT
MODELING
TO support such concepts of management
modeling, adaptive teamwork communication
tools will be developed. These workstations will
be more than document handling systems. They
will be used more like the telephone for diverse,
short messages which can be compiled and
reused. Graphic software will support the type
of models described above.
First, a workstation might present a working
environment in t.he shape of the resource model.
This working environment would prompt the
user to apply a well-rounded set of considera-
tions to a problem at hand. At the same time, it
could provide a framework for organizing de-
tailed capabilities pertaining to the job.
By using a recurring physical layout for work
situations, the design of a working environ-
ment can invoke the power of human visual
memory and hand/eye coordination. Similar to
current desktop operating systems which pro-
296
0
Person
Workatation Screen
Fig. 4. Communications modeling.
vide pictures of nested file folders, the multi-
level model for resources can enhance access to
needed resources. Capability, in the form of
models, is associated with an artificial place
which is recalled by a person pointing to tokens
in familiar contexts.
A workstation serves as an interface between
a person and a resource model that he is re-
sponsible for maintaining. One can think of it
as a project scope for viewing a team and its
communication patterns. Software tools will
provide a facility for maintaining these graph-
ical representations of teams. Figure 4 illus-
trates this.
And, of course, the workstation must allow
the team member to formulate and direct mes-
sages within the network that the team has
established.
The workstation must also support conven-
tional application software for representing
physical and numerical aspects of the work. For
example, CAD software allows representation
of mechanical designs, or accounting software
provides a financial summary of a large volume
of activity. The sources and uses of the infor-
mation in these programs would be managed
using the communications environment.
This resulting artificial working environ-
ment will address these major requirements:
(1)
(2)
It supports a view of resources, and allows
resource modeling.
(3)
It merges the major modes of human ac-
tion, conversation and eye/motor coordi-
nation, for mutual support.
It suggests significant job aspects to the user
and promotes common measures of
performance, 1
(4)
It permits the use of job-specific software
tools.
(51
It encourages combined effort.
(6)
It supports participation in conversations.
If realized, such systems will provide a basic
apparatus supporting self-sustaining, creative
growth of a team. A team will gain a broader
vie-m of -work, greater interconnectivity, and
better guidance toward its goals.
GENERAL IMPLICATIONS
These ideas are useful in todays operation.
Consideration should be given to these action
items:
(1)
(2)
(3)
(4)
(5)
(6)
Create simple metaphors and instill them
through consistent language and images.
Teach advanced communication and mod-
eling skills to all team members.
Enroll each team member to comment on
and record methods.
Use clerical support to explicitly record
project action and to measure the teams
success.
Design projects with internal knowledge
products in mind.
Encourage an on-going level of effort on
these forms of organizational remember-
ing and teaching.
This discipline can enrich our communica-
tion environments, progressively offering ex-
perience for the use of new tools. A team can
operate as if advanced workstations were
available to all team members now.
Changes of this nature will have both routin-
izing and liberating aspects for the individual.
Working through workstations tends to be im-
personal. Furthermore, spending long periods
of time in the grips of a powerful symbol system
draws one out of touch with basic humanness.
But rather than a big brother that dictates
language rules, new tools present an opportu-
nity for all to participate in the extension of
language. Advent of such systems will allow a
team to build its own communication environ-
ment. The result will be greater clarity, respon-
siveness, and satisfaction in our working lives.
This conceptual work suggests much further
study. This might include:
(1)
(2)
(31
(4)
Developing examples to test the usefulness
of various resource tokens.
Developing a formal model for resources.
Conducting mathematical studies, e.g., is
there an effectiveness multiplier effect in
the use of integrated communication
environments?
Investigating possible interim standards as
a way of bootstrapping.
Evolution is a process of adaptation on suc-
cessive levels. At this point in human develop-
ment, what could be more adaptive than making
language more useful? Language as we know it
is a preliminary framework for dynamic, image-
based action structures. Through awareness of
297
human abilities, and by design of human corn--
munication, teams can become much more ca-
pable. AS this is done, people will ask larger
questions, and find paths to greater integration.
REFERENCE
Booth, G., 1986. Object oriented programming. IEEE Trans.
Software Eng., SE-12 (February): 211-221.
DeMarco, T., 1982. Controlling Software Projects: Man-
agement, Measurement, Estimation. Yourdon Press,
New York, NY.
Farowich, S., 1986. Communicating in the technical office.
IEEE Spectrum, 23 (4) (April) ; 63-67.
Goizueta, R., 1986. Quoted in The Atlanta Constitution,
May 8.
Hayes-Roth, F., 1984. The knowledge-based expert system:
a tutorial. IEEE Comput., 17(9) (September): 11-28.
Kaminski, M., 1986. Protocols for communicating in the
factory. IEEE Spectrum, 23 (4) (April) : 56-62.
Low, A., 1976. Zen and Creative Management. Anchor
Press, Garden City, NY.
Mintzberg, H., 1973. The Nature of Managerial Work.
Harper and Row, New York, NY.
Neches, R., Swartout, W.R. and Moore, J.D., 1985. En-
hanced maintenance and explanation of expert systems
through explicit models of their development. IEEE
Trans. Software Eng., SE-11 (November): 1337-1351.
Sayles, L.R. and Chandler, M.K., 1571. Managing Large
Syctens: Organizations for the Future. Harper and Row,
New York, NY.
Silverman, B., 1983. Analogy in systems management: a
theoretical inquiry. IEEE Trans. Syst., Man, Cybern.,
SMC-13(6) (November): 1049-1075.
Winograd, T. and Flores, F., 1986. Computers and Cogni-
tion. A New Foundation for Design. Ablex Publishing
Corp., Norwood, NJ.