Division among the ranks : the social implications of CASE tools for system developers

.M414

WORKING

PAPER

ALFRED

P.

SLOAN

SCHOOL

OF

MANAGEMENT

Division

Among

the

Ranks:

The

Social

Implications

of

CASE

Tools

for

System Developers

Wanda

J.

Orlikowski

Sloan

Working

Paper #3053-89-MS

MASSACHUSETTS

INSTITUTE

OF

TECHNOLOGY

50

MEMORIAL

DRIVE

Division

Among

the

Ranks:

The

Social

Implications

of

CASE

Tools

for

System Developers

Wanda

J.

Orlikowski

DIVISION

AMONG

THE

RANKS:

THE

SOCIAL IMPLICATIONS

OF

CASE

TOOLS FOR

SYSTEM

DEVELOPERS

Wanda

J.

Orlikowski

InformationTechnologies

Group

Sloan Schoolof

Management

Massachusetts Instituteof

Technology

Cambridge,

MA

02139

AUe

1

8

1989

DIVISION

AMONG

THE

RANKS:

THE

SOCIAL IMPLICATIONS

OF

CASE

TOOLS FOR SYSTEM DEVELOPERS

ABSTRACT

This paper explores

how

the introduction of

CASE

tools in systems

development changes

the social relations

among

project

team

members.

An

investigation into the role of

CASE

tools

on

projectsfound structural changes duetomodificationofthe systems

development

division of labor

and

shifts in patterns of

dependency

among

project

team

coalitions.

These changes

triggered a polarization

among

the system developers

which

was

evincedin actsofcoercion andrebellion,the

display ofterritorialism, resentment, and stereotyping, as well as the enactment of subcultures.

These

findings areinterpreted within a broadersocial theoretic framework, and theirimplications

forresearch andpractice arediscussed.

1.

INTRODUCTION

Today

we

are seeing

tremendous

interest

and

investment in the automation of the systems

development

process. This trendtowards

Computer-Aided

Software Engineering

(CASE)

toolsis

an attemptto

remedy

theapparentlackofcomputer-based supportforsystemsdevelopers, a lack to

which

many

of the ills of the systems building process

have

been attributed.

CASE

tools are

software

programs

which

automate or support tasks typically constituting information systems

development

practice.

There

is

no

general agreementas to

what

functionality a

CASE

tool should

provide, but

most

would

agree that

CASE

toolscomprise

some

subsetofthefollowing elements: screenandreportdesign aids, textand diagrameditors,datamodelingtools, datadictionaries, code generators, testing anddebugging tools.

The

major

advantagesthathave beenadvertised for

CASE

tools include: increased responsiveness to user needs in the face of

changing

requirements,

increased systems

development

productivity, decreased systems

development

time,

enhanced

system quality, standardization, ability to replace project personnel easily,

and

the capability to

solvelargerand

more complex

problems [Case 1985;

Freedman

1986;

Stamps

1987].

While

some

ofthese benefits

may

be realizable, the

mechanisms

through

which

CASE

tools are

successfully

implemented

are not identified.

There

are few, ifany, detailed analyses ofactual

CASE

tool implementations, and little empirical data is available

on

the organizational effectsof

using automated

means

to develop systems.

Most

discussions of

CASE

tools focus

on

technical

andproject

management

criteriawith littlediscussion and hencelittle understanding, ofthe social

implicationsofusing

CASE

tools. Informationtechnology, as is

by

now

well accepted, can never be deployedin a

vacuum.

Its

form

and functionare always influenced

by

the social context within

which

itis

embedded

[Boland 1979; Kling

and

Scacchi 1982;

Markus

1983;

Weick

1984], and it

invariably exerts areciprocal influence

on

thatcontext [Giddens 1984]. Similarly,

we

can expect thatthe information technology deployed to support/automate systems

development

(CASE

tools) will interact with the organizational context, introducing perturbations into the social relations surrounding tool

development and

use.

Drawing

on

an empirical study, thispaperrecounts

how

thedeploymentof

CASE

tools in systems development

changed

social relations

among

developers, providing insight into

some

organizational changestriggered

by

automating systems development.

The

following section provides

background

to the research study, outlining the organizational context

and

history within

which

CASE

tools

were

introduced. Section three investigates the structural changes

engendered by

CASE

tools, and describes the behavioral response of system

developers. Section four discusses the

meanings

ofthese changes for the developers in terms of their perspectivesand subculture affiliations. Section five reviews the findings, recasting

them

in

terms of a

more

general, social theory.

The

paper concludes

by

outlining

some

implications for practice

and

for futureresearch intothe social issues surrounding

CASE

tools.

2.

BACKGROUND

TO

THE RESEARCH

The

Research Study

The

discussion in this paper

draws on

a research study that investigated the automation of the systems

development

process in a large, northeastern software consulting firm.^

The

software consulting firm, in operation since the sixties,

employs

about

600

consultants

and

develops computer-based information systems for its clients across various industries: financial services, manufacturing, retail, and government.

These

information systems are typically large, transaction-processing applications used

by

clients to support their

major

administrative activities. Beta's operationsare organized byproject, withproject teams varying

from

around ten tooverahundred

personnel,

and

projects extending

from

a

few

months

to a

number

of years in duration. Project

costs range

from

a

hundred

thousand to a

few

million dollars.

As

a

consequence

of the

growing

demand

for large,complex,integrated application software. Beta has - over the last

two

decades

-attempted tostreamline as

much

ofits systems

development

practice as possible.

The

most

recent

and

visiblemanifestation ofthisstrategy is the construction and

deployment

of

CASE

tools within

projectteams. Thisshifttowards computer-based systems development supportin Betadates back

more

thanfive years, incontrast to

most

firms

which

havenotyet seriously

committed

to

CASE.2

The

findings discussed here are partofa largerresearch study that focused

on

the organizational

changes

that

accompanied

Beta's implementation of

CASE

tools in its systems

development

operations [Orlikowski 1988].

The

study

employed

ethnographic techniques

[Agar

1980;

Van

Maanen

1979, 1988] such as observation of participants, interaction with

CASE

tools, documentation review, social contact, unstructuredand semi-structured interviews.It

was

executed

over eight

months

within Beta and in those client sites

where

Beta developers

were

building application systems. In the firstphase oftheresearch, historicaldata

on

theBeta corporation and

its systems

development

practices

was

gathered

from

published material (inhouseand trade press),

and

from

interviews with senior

managers

who

had been involved in Beta's traditional systems development, as wellas itsadoption ofacomputer-based systems

development

process.

With

some

background

information

on

Beta and its practices, fivedifferent application projects (four large and

one

small)

were

selected forindepth analyses.Projects

were

not selected at

random

but

were

strategicallyidentified toguaranteeexposure totheuseof

CASE

toolsin allmajor phases

ofthesystems

development

life cycle (requirements analysis,conceptualdesign, detailed design,

implementation, and testing).

An

average offour

weeks

was

spent

on

each project, observingand

interviewing

team

members

in theirdaily systems

development

work, and intheirinteractionwith

eachotherand the

CASE

tools.

One

hundred

and twenty interviews

were

conducted,eachlasting an average of

one and

a half hours. Participation in the research

was

voluntary

and

while the particular projects

examined were

selected

by

Beta's senior

management,

individuals within

projects

were

invited to participatein thestudyby theresearcheralone.

These

individuals spanned

Beta's hierarchic levels

from

the

most

junior analysts

and programmers,

to senior project

^ Itisestimatedthat, in theU.S to date,only7 or 8 percentofinformation system workershavebeen exposedto

managers.3

Other

key

informants

were

identified

and

sought out both within and outside Beta,

such as the seniorrecruiting officer, the director ofresearch

and

development, sales directors, majorclientmanagers, and former Beta employees. Data

was

alsocollectedthroughoutthe studyat

monthly

(allday)division meetings, andinproject training sessions

on

CASE

tools.

Beta

has not diffused its

CASE

tools

on

a corporate-wide basis, but has followed a

phased

implementation with

major

offices first adopting the tools, followed

by

the smaller offices.

Because

offices regularly share personnel totake advantage ofslack resources,it

was

possibleto find developers havingdifferentialexposure to the

CASE

tools.

Thus on

the projects studied there were developers

who

had never used

CASE

toolsbefore, as well asdevelopers

who

were

four

and

fiveyearveteran tool users. Thisdifferentialexposure totool use facilitateda natural contrast that

revealedinterestinginsights into

how

systemsdevelopers perceive andinteractwith

CASE

tools.

Project

Teams

before the use of

CASE

Tools

The

historyofproject

team

composition inBeta indicatesthatgraduallyoverthelast

two

decadesa partitioning betweenfunctional andtechnical expertise

was

establishedwithin system development

teams."* This partitioning, however,

was

onlyinstitutionalized with theintroduction of

CASE

tools

during the lastfive years,

when

a

number

ofstructural changes underscoredthedivision

among

the

project

team

members,

accentuatingrelations of

power

and dependence. Before proceedingto the

discussion ofthese organizational changes (in section three below) the evolution ofproject

team

relations inBeta overtime issketchedout.

In thelate sixties. Betapersonnel

working

on systems developmentprojects

were

notdifferentiated by expertise so

much

as

by what

stage in the systems

development

process they serviced. Thus,

some

people specialized in the upfront conceptual

work

of systems specification, performing

^_{Betahas asingle}careerpathwiththe stages:junior analyst(twoyears), senior analyst(twoyears),juniormanager

(4years),projectmanager(2-3 years),andsenior projectmanager.

* Functional expertiserefers toknowledgeofan indusU7suchasaerospace or banking,andknowledgeoffunctional areassuchasproduction,marketingorsales.Technicalexpertise refers toknowledgeof software productssuchas

information requirements determination

and

systems analysis, while others conducted actual

system implementations

via functional

and

technical design,

programming,

testing,

and

installation.

While

thistypeofspecializationdid lead to differentiated

knowledge

andexperience,

the lines

were

not

drawn

along functional

and

technical expertise. Largely as a result of the

unanticipated

weaknesses

ofthis temporal schism - _having

two

differentteams develop a single systemfor a client oftenresulted in

many

development

inefficiencies^ as well as duplicateclient

negotiations - the tasksofthe

development

process

were

bundled together, so that asingle

team

carried a project through initsentirety.

A

division oflabor

which encouraged

functional

and

technical specialization quickly

emerged

within such a single project

team

structure. This specialization

was

driven

by

the size and complexity ofapplicationsthatBeta began todevelop,

and

encouraged

by

the softwareengineering

tenets gaining

ascendancy

in the early seventies.

But even

as different tasks

were

assigned to

variousteam-appointed specialists, allthe tasksconcernedthe buildingof an application- the target

system - for the current client.

None

ofthe project

team

members

was

responsibleforsupporting the activities of other

team

members.

Hence, dependencies

on

the project resulted

from

coordinating disparate tasks, rather than

from

a differential distribution ofresources. Functional

and

technical specializations

on teams were

informally negotiated

and

sustained,

were

merely temporary (lasting only the duration ofa project),

and

were

not officially recognized

by

Beta's structuralapparatus (its hierarchy, assignment

mechanism,

promotion

and

reward schedule). Beta in theearlyseventiesdid not formallydifferentiate itspersonnelalong linesofexpertise.

3.

RESPONDING

TO

CASE TOOLS

AND STRUCTURAL

CHANGE

Setting the

Stage

for

CASE

Tools

In themid-seventies, however, information technology

became

increasingly integrated, diverseand technically complex.^ Beta recognized that todeliver"leadingedge" systems,projectteams

would

^duetomisinterpretation,ambiguity,rework,andmultiple, separate learning curves.

°encompassingdifferent hardware and software standards, sophisticated operating systems,database management

have to

augment

their level oftechnical expertise. Senior Beta

management

formally designated

some

individuals as the firm's technical "experts" anda separate division within Beta

was formed

to

house

them. Personnel for the technical division

were

specifically recruited

from computer

science schools

and were

not assigned to particular project teams. Instead of spending time

on

clients' sites buildingapplication systems, they

were

locatedat Beta'sheadquarters toresearch

new

technological innovations

and

to serveas generaltechnical consultantsto projects

on

an as-needed basis. This latter responsibility required

them

to travel to projects for a

few days

at a time to provide the technical

knowledge

that local project teams lacked.

While

the technical expertise of these specialists

was

formallyrecognized

by

Beta, little

power

accruedto

them

astheirinvolvement with projects

was

minor,

and

it is project

engagements

that earn revenues

and

hence influence within Beta.

The

technical specialists

were

generally perceived as advisors, andreferred toas the

"consultants' consultants."

The

technical expertise furnished

was

strictly

concerned

with the

hardware

and software

environment

within

which

application systems

were

being built .

There

was, asyet,

no

notionofusing information technology tosupport systems

development

work.

Beta's systems

development

practice

grew and

the

demand

for technically

complex

application

systemsincreased.

Time

pressure

on

technical specialistshmited even furthertheir alreadysporadic contact with project teams, andas a resulttheircontributionsto local systems

development

efforts

were

shortlivedand superficial.

The

general sentiment

from

local project

managers

was

thatthese technical specialists

were

too inexperienced in functional matters, too focused

on

narrow

technologies,

and

too

removed

from

the daily exigencies of projects to benefit applications

development.

Out

ofthese pressures and frustrations the concept of"localized technical groups"

emerged

in Beta about ten years ago.

Each

local office

now

develops its

own

cadre of technical

experts - _consultants specializing in technical matters - _to supportclient projects specific to each local officethroughclose anddaily involvementinsystems development.

By

establishing local technical groups.Betapersonnel inlocal offices areformally differentiated

by

assigned toclientprojects

on

a full-time basis.

Each

project

team

now

comprises

two

distinct types

ofpersonnel: the"functional

team"

(drawn

from

the general p>ooloflocal functionalconsultants),

and

the "technical

team" (drawn from

the local technical group). Initially functional consultants

developed applicationsystems, whiletechnical consultantssupported theirfunctionalcolleagues in

the technicalaspectsofapplication

development

Technical consultants

were

the experts

on

CICS,

VM/CMS,

IMS,

ADABAS,

UNIX,

telecommunications,

performance

tuning, the technical

feasibility ofvarious proposed designs, and soon.

They

were

largely uninvolved in developing

application systems, playinga staffrole to thefunctional consultants' line role. In particular(with

the rareexceptionofapplicationsbased

on

sophisticatedtelecommunications networks oresoteric systems software), theydid not represent significant

components on

a project'scriticalpath.

Enter

CASE

tools

With

the

growing

sophistication of systems being

demanded

by

clients,

and

the consequent

increased system

development

time-frames andproject costs. Beta

management

decidedthatlocal technical consultants shoulddevelop capabilities to supportthe restofthe project teams.

At

first,

thesecapabilitiescomprised

what

came

tobe

known

as the technical architecture.^ Senior

managers

in Betarealizedthatthey could leveragetheirprojects

by

allowing a

few

ofthe technical consultants to build the generic, technical foundation forall ofa project's application programs, rather than

have

each functional consultant developtheir

own.

They

foundthey could avoid duplicatedeffort and the inevitable inconsistenciesthat arise

when

team

members

work

in isolation. Inthis

way

time

was

saved and the

work

was

easier to correct, validate, and refine (thusimproving the quality of the product).

There

was

also less need forfunctional consultants to be technically

knowledgeable

before theycoulddevelop application systems.

This represents

somewhat

ofa shift in the

work

performed

by

technical consultants

on

projects, changing

from

a purely advisory role, to

one

that builds a substantial portion ofthe application

^_Thetechnical architectureisthat setofsoftwaremodules

common

tomostprogramsof an application system,and whichistypicallytechnicallycomplex(e.g.screenmapping,screencommunication,databaseI/O,macros).

system under developmentfortheclient.This technical architecturebuilt

by

the technical

team

does

not strictly constitute

CASE

tools, as it forms partoftheclient's application system rather than a technology

owned

by

Beta.

However

it clearly

was

its forerunner, as in practice it

amounts

to

information technology thatassists functionalconsultants'

development

work

by

eliminatingtheir needto build

complex

technical proceduresintheirprograms.

In the early eighties the idea of fully-fledged

CASE

tools, in-house technology dedicated to

supportingsystems developers, hadtaken hold inBeta, and overtime a

number

ofdifferent

CASE

tools

were

developed

on

separate Betaprojectsandquickly diffusedthroughoutthe firm.

As

CASE

tools

became

more

widely

known

throughout Beta, theybegan tobe a

common

featureofall large system

development

projects, mediating

many

systems

development

practices. Concomitantly, the role oftechnical consultants

on

projects

began

to change.

Not

only

were

they responsible for

providing technical adviceand building the technical architecture, they

were

now

alsoresponsible

for setting up, modifying,and maintaining Beta's

CASE

tools ateachclientsite.^

Structural

Changes

following

CASE

tools

As

the technical architecture

and

CASE

tools

became more

critical to the systems

development

process, the technical

team

responsible for

them began

to play a pivotal role

on

each project.

Reflecting this

change

in scope, the technical contingent

on

projects increasedin size.^

The

useof

technical architectures and

CASE

tools radically

changed

the

dependence

relations ofthe project team.

Whereas

before, the functional consultants called

on

the technical

team on

an as-needed basis,

now

they

had

to rely

on

the technical consultants to set

up

the tools

and

the architecture

before they could

perform

any substantive work.

The

technical team's installation oftools and

building of the technical architecture had

become

key

stages

on

the critical path of systems

development

projects. Further, the technical

team

had to

become more

intimately involved in

^

_CASE

_{toolsin Betaemerged out of individual projectendeavorsandare notgeneral enough} lobefully portable across multiple environments. As each of Beta's clients has a unique hardware and software environment, the

CASE

toolshave be adaptedateachclient installation tofitthe particularcomputerconfigurationathand. ^From some5 percentoftheprojectteam memberstoabout20percent.

analysis and designdecisions. That is, the structureofthe technical architecture and

CASE

tools

were

constraints

on

possible application designs, while theconceptual systems design influenced

the content ofthe technical architecture and

CASE

tools implemented.

The

technical team, thus, began to

assume more

ofa productionrole as

opposed

to itsprior, purely supportrole,

which

had

notinvolved anydirectinvolvementinapplications development work.

The

division oflabor

on

systems

development

projects

had

changed, with functional consultants relinquishing

many

technical tasks to the technical consultants,

whose

involvement in project

activities

had

shifted

from

theperiphery to the center.

Accompanying

theincreasedvisibility and activityofthe technical

team

had

come

increasedresponsibility and power, as thefunctional

team

became

heavilydependent

on

the technical team,

whose

activities facilitated theirproductive work.

4.

MEDIATING

THE MEANING

OF

STRUCTURAL

CHANGE

Following

the increased

dependence

of project

teams

on

a technical infrastructure (technical architecture

and

CASE

tools) project social relations

became

polarized around

two

verydifferent

perspectives: the technical

and

the functional.

Each

ofthese perspectives represents a separate subculture that has

formed

within Beta, reflecting different perceptions of

and

interactions with

clients, project goals,

and

systems

development

activities in general.

The

strength of the polarization

was

surprising given the fairly strong and relatively

homogeneous

corporateculture that pervades Beta, but it adds support to Riley's [1983] contention that multiple subcultures

develop

even

within a

more

overarching culture.

The

following discussion

examines

how

the norms,orientations, and interestsofthe different subculturesmediatedindividuals' understanding ofandactions towards

CASE

tools and eachother.

4.1

FUNCTIONAL SUBCULTURE

Functional

Perspective

Functional consultants performthe substantive

work

ofBeta's systems developmentpractice.

They

functional solurions for client business

problems

through the

medium

ofinformation technology.

The

medium

is considered less important than the functionality that is provided. Information technology is

apprehended

as the

means

through

which

valued ends are achieved,ratherthan an

end

in itself.

Hence

the information technology used

by

functional consultants is valued for its

instrumental contributionto theirwork. Theirgeneral stance towards

human

activity [Schein 1987,

p.101] reflects a results orientation, that is, a focus

on "doing"

(achievement

and

accomplishment)rather than a focus

on

"being" (process and development) [Schein 1987,p.102]. Their time orientation is the present,

and

their context local.

They

concentrate theirenergies

on

building a systemforthecurrentsituation, andforgetting the

immediate

projectcompleted. Their attitude towards information technology (both the

CASE

toolsand the actual technology usedto buildclient application systems)reflects theirresultsorientationandinstrumentalism; theyobjectify

it. Thus, functional consultants,even though they use information technology as a

raw

material in

their

work

- building

and

fashioning a system for clients out of an

amalgam

of

hardware and

software - _{appear to be}

_unaware

of, or toignore the often arbitrary

and

nontechnical aspects of

information technology.

They

treat

CASE

as a neutral, abstract object, that facilitatesrational and deliberatemanipulation, and thatcan be deployed across clientcontexts, applicationdomains, and

problem

types.

Conflict

over

Expertise

When

local technical groupswere firstinitiated within Betaandtechnical consultantsjoinedproject teams to provide technical advice, functionalconsultantsappreciatedthe supportand service they received

from

these

"backroom

guys" ^^

_who

_{resolved tricky} technical issues inthesystems being

built, thereby helping functional consultants achieve their desired ends.

The

central role of the

functional consultants as

primary

producers of application systems

was

not threatened or

challenged.

There

was

little felt

dependence on

the technical consultants,

who

kept a

low

profile

'"_{Commentsin italicsconstitutestatementsmadeby Betapersonnel duringthefieldstudy.}

and

whose

advicedealtwith theinformation technologyitself.

The

technicalconsultants did notin

anysubstantial

way

shapethe direction or contentof

work

performed

by

functional consultants.

With

the implementation of

CASE

tools

on

projects

came

a change inthe responsibilities

and

role of technical consultants. Perceptions

among

functional consultants

and

relations

between

the

technical and functional teamshave been noticeably affected.

The

technical consultants are

now

seen toperform

many

development

functions.

They

are

no

longer the "technicalgurus" offering backstageadvice; they have

moved

firmlyintocenter stage, both interms oftheimportance oftheir

work

to theproject

and

in terms ofthe financialinvestment their

work

represents to Betaand its

clients.

The

functionalconsultants feel

somewhat

upstaged, and less incontrol oftheexigenciesof

theirwork.

The

activities ofthetechnical consultantsare

now

on

the critical pathofthe project, so theydirectly influenceandconstrain the

work

offunctional consultants. Functional consultants are acutely aware oftheirdependence

on

the technical team,

whose

tools and technical architecturethey

arerequired toemploy.

A

functional

manager

commented

on

thechange:

The

technical

team

had no formal

role

on

the

team

beforetools.

They

did technicaladvising,

and

resolved technical issues.

Now

they are the key part ofthe project, building

and

running the engine thateveryone

works

off.

There

is resentment that the technical consultants

no

longer provide support to the functional

consultants,

who

stillregardthemselves as the

main

actors. Technicalconsultants are perceived as having "stolen the

show"

and "doing their

own

thing," with little or

no

regard for the needs or

activities ofthe functional players.

A

functional consultant expressed the sense of

abandonment

generallyfelt

by

thefunctionalteam:

Now

[after

CASE

tools

were

introduced] thereis

a

distinct lackof

communication between

the

technical

and

functional teams,

because

we

have

mutually exclusive tasks

and

motivations.

Before

we

worked

on

the

same

thing. Their focus

was

on

providing technical support

and

expertiseas

needed

and

demanded

byus, thefunctional team.

They

provided aservice; they

were

the internal consultants.

Now

they

produce a

product: the

program

shells

and

the bridges,

and

they are less

concerned

with support.

There

has

been

a big

change

in roles

between

the two

teams.

The

onus forsolving technical

problems

is

now

afunctionalresponsibility.

The

technical

team

feel theyhaveother things to

do

thansupportus.

But

we

feel theyarethere tosupportus...

There

is a concern that they are getting too caught

up

in the design, that they

may

dictate the design.It is importanttliatthe tech

team

assume an

advisoryrole

and

not drivethe design.

Such

differentperceptionsindicatethat functional andtechnicalconsultantshave well-defined, yet opposingexpectationsofeach others' rolesandresponsibilities, resultingin conflictoverexpertise

and

the

bounds

of legitimate action.

A

subtle territorialism has

emerged

within Beta

which

is

manifest inthe stereotyping and subculturalactivities

engaged

in

by

thegroups ofconsultants.

Stereotyping

the

Technical

Consultants

There

is a deeply felt sense

among

the functional

team

that the technical consultants arejust interested in the technologyand in "hacking" the

most

elegantdesign orcode withoutregard for

what

support thefunctional teams needs, or

when.

One

functional consultant

commented

on

the technical team'sattitude bynoting:

The

technical

team

shouldrely

more

on

thefunctional

team

than they do.

They have

their

own

ideas

and

don't

want

to

know

thefunctional story.

They

are not

open

to criticism.

They

feel

some

ownership ofthe tools

and

so areverydefensive. Iguess that's

human

nature. ... theyjust

don't

want

to

know

thattlieir toolsare defectiveor weak.

A

lot of"fingerpointing" is apparent, with each

team

usingthe otheras a scapegoat

when

things

go

wrong. Typical

comments

from

functional consultants aboutthe technical

team

included:

The

technical

team

don't understand

what

we

need. ... They're the ivory tower. ...

They

never

give us

what

we

want.

Stereotypingisrampant, asa functional

manager

explained:

Therereallyis

an

us-themmentality.

The

functional

team

viewthe technical

team

as restrictive,

while thelatterview the

former

as unrealisticin terms ofbudgets, efficiency, volumes

Losing

Autonomy

Functional consultants feel that they

have

lost

autonomy

by

having to follow the dictates ofthe technical team, and being forced to

conform

to thelanguage ofthe

CASE

tools. In particular,

now

that systems

development

work

consists primarily ofinteraction with

CASE

tools, the functional

consultants' designs

and

code

are subject to review by the technical team. This generates

much

resentment.

A

functional senior analyst's

view

istypical:

Withoutthe tech

team

we

would

never have

made

the

CASE

tools work. ...

But

there is

some

resistance to theirpresence.

When

one

of

them would

ask usto

change

the

name

of something, we'dresent it.

Who

are they totell us

what

to

do?

With

the

CASE

tools mediating systems

development

activities,

many

ofthe tasks previously

handled

by

analysts, are

now

automated. For example, screens

and

reports are "ergonomically" designed

by

the tools

on

receipt of the data items to be displayed, and

up

to

75

percent of the

program code

forstandard, transactionprocessing systems isgenerated

by

the tools

on

receiptofa

few

customizingparameters. Functional consultants

no

longer

engage

in inanydetailed design and implementation processes.

They

resent being excluded

from

decisions

which

directly impact the

form

andfunctioning ofthe application systems theyare constructingforclients. In particular, the

functional consultants objectto the technical

team

developingand installingtechnical architecture and

CASE

tools withoutconsulting them, taking exception to having to use technology they did not help design.

While

some

ofthisresentment

may

haveexisted before theonsetoftools withthe systems software that functionalconsultants used, thissoftware

was

typically perceived as "in the background,"

and hence

as dissociated

from

application work.

CASE

tools,

however,

directly confront the functional consultants in the

performance

of their work, being very

much

in the "foreground" of systems

development

work, mediating almost everything the functional

team

does.

A

functionalconsultant

commented

on

theresentmentthathe and hispeersfeel towards

what

theyperceiveas elitism

among

the technical consultants:

Toolshave developed a tech

team

ofegotists,

who

feel they have alltheknowledge,

and

thatthe

more

theycan keep hidden

from

us, the

more

knowledge

and

power

theyhave

and

can keep.

Asserting

Control

The

lossof

autonomy

thatthefunctional analystsfeelrelative to the technicalteam, frustrates their

ambitions to get the job done.

And

the fhistration

and

tension can

sometimes

lead to rebellious action, to a defiance of Beta's

norms

that require

team

play, cooperation,

and

conformity.

A

number

offunctional consultants described resorting to sabotage ofthe

CASE

tools in orderto reassert their sense ofcontrol.

For

example,

on

a particularly technically

complex

project with

many

CASE

tools rigidlyenforced

by

the technical team, the control over systems

development

work

was

soeffective that,as onefunctional

manager

described, it:

... drovepeople

on

thefunctional

team

to break the tools right

and

left.

As

soon as thingsstarted

going

wrong

with the tools

we

circumvented

them

so that

we

couldget

on

with our work.

A

functional consultant recounted asimilartale

on

anotherproject. His storyis worthcitinginfull:

On

this project the tech

team

had

set

up

two kinds

of

ids to use the system, the

one

was

a

technical or powerfulid

which

allowed

you

to

romp

around

intheoperating system, createfiles, etc.

The

other

was

an

idforthefunctional people,forthe coders,

which

only

gave

you

accessto

the codingpanel [a

menu

of optionsto use the

CASE

tools]

where you

couldonlyeditor

browse

files, compile

programs,

print

program

listings,

and

you

couldnot test

some

programs,

lookat

some

files, or create

new

files.

So

we

were

very restrictedfunctionally,

and

we

found

this

extremely limiting to

our

work.

But

the tools

were

often causing a lot_{of unnecessary work.}

For

example

they

would

time

and

date

stamp

the object

modules

when

they

were compiled

and

the

test data

when

they

were

generated.

And

these time

and

datestamps

were

oftenoutofsync.

And

ifthey

were

out of sync the tools wouldn'tlet

you do

anything like usethe data torun

an

object

module, so

we

would

have torun to thetech

team

each time so theycouldfix things up.

The

tech

team

was

reluctant togive us technicalidsortheir

passwords

so

we

couldusetheirids

and

fix up

things ourselves.

They

thought

we'd

wreak

havoc.

But

somehow

technical

passwords were

gotten holdof.

Some

people looked overthe tech consultants'shoulders; I

had

a friend

on

the

tech

team

so I couldget hold ofhis.

And

we

used thesepowerful ids to

go

into thesystem

and

we

changed

our

own

ids to give us

more

power, so

we

had

greater functionalcapability.

And

we

couldget

on

with our work.

Of

course

when

allthis

came

out,a bigpolitical stink

blew

up.

We

were

told

we

weren't

team

players.

But

eventually

we

convincedthetech

team

that

we

needed

to

manipulate alittle

more

_ofthefiles.In the

end

they createda three-tieredsystem, withthose

who

were

fullytechnicallike the tech

team

having allaccess,

some

who

were

semi-technical like us,

who

did functional

work

but

needed

to

sometimes

go around

the tools,

and

then the fully

functional typeslikecoders

who

onlydid application

work

and

onlyusedthecodingpanels.

So

apartial victory had been

won

for the functional consultants

who

forced the technical

team

to

give

them

more

computer

capability, but the access given

was

very

much

on

the technical team's

terms.

The

technical consultants

managed

toregain thecontrol that had been temporarily usurped.

They

did not give the functional

team

more

powerful ids,

which

would

have given the functional consultants control over

when

and

how

to use or bypass the tools. Instead the technical

team

modified thefunctional consultants' coding panels sothat fora

few

simple functionsthe functional

consultants could exit the tools to

do

a

few

restricted actions outside the realm of the tools.

However

this only allowed

them

to

do

a little

more

than they

were

able to

do

before theirrevolt.

More

importantlyitdid notgive

them

the optiontochoose

when

and

how

touse the tools.

Rebellions such as these arenot

common

withinBeta.

The

strong corporatecultureandideologyof

teamwork

discourages dissension

among

the functional consultants,

who

are concerned with

personal career

advancement and do

not

want

to be labeled as "troublemakers."

However when

rebellious action

by

functional consultantsdoes occur, it isparticularly revealing.

On

the one

hand

it indicates

how

frustrating task restrictions can be to people with the appropriate expertise

who

realize that things could be

done

differently.

On

the other

hand

itdemonstratesthat socialization,

corporate culture,

and

career ambitionsnotwithstanding, individuals can

and do

act in

ways

that undermine

mechanisms

oforganizational control.

4.2

TECHNICAL

SUBCULTURE

Technical

Perspective

Technical consultants are typically attractedto Beta because oftheirdual interest intechnology and business.

For

theirfirst

few

years in the

fum

however,businessinterests play asecondaryrole, as the specialization of roles

on

projects

demands

that they focus

on

technology.

Most

technical consultants are

more

than

happy

to oblige.

While

they

acknowledge

thatthe purpose ofprojectsis

to solve functional problems, they

welcome

the opportunity to concentrate exclusively

on

the

computer

medium,

and

leave the business details to their functional counterparts.

Many

see the technologyas the

means

through

which

theycan expressanddisplay their creativity, and a

way

for

them

to learn

new

technical skills

which

are highly prized

(among

their peers

and

in the larger "hacker" occupational culture to

which

they feel

some

affiliation). In this sense, exploiting the technology

becomes

an

end

in itself. Technicalconsultants are process oriented, intent

on

action

rather than results. Information technology is

more

than just instrumentally important to the

technical consultants in the execution oftheir tasks. It carriesmotivational significance as well. Technical consultants are less focused

on

the

immediate

client

problem

and

more

interested in

findingaunique and elegantsolution tothetechnicalproblemsat hand.

While

theirtimeorientation

is

somewhat

in the present, it also tends to look

beyond

the current project, to a

more

abstract,

timeless level

where

technical architectures

and

CASE

tools are perfectable according to

some

absolutecriteria. Technicalconsultants

commonly

rationalize

why

they spend inordinate

amounts

of timerecreatingaroutineormacro,

by

claimingthat theirproducts willbereused onfutureBeta

projects in otherclients' sites.

Hence

(they argue) their

work

transcends present-time

and

client-specific boundaries.

That

such reuse is not

commonly

realized in practice

seems

of little

consequencetotheirmotivation.

The

context of technical consultants'

work

is defined

by

the particular

hardware

and

software configuration ofthe current client's installation.

While

this context is specific to projects, it is

stripped of social or functional content

by

the technical consultants' exclusive

emphasis on

the

technology. Their attitude towards information technology reflects theirgreater involvement in process: thetechnology (both

CASE

tools andtheinformation technologyusedto build application systems) is created

and

manipulated,

and

henceis not objectified. Itis notperceivedas a tool for getting their

work

done, butratheras constituting thearena

on which

their

work

isplayed out.

Akin

to their functional counterparts, technical consultants

do

not see themselves as

system

developers.

While

they

do

subscribe to the "consultant"image, they

augment

this with aconstant reference to their status as technical innovators. This self-image allows

them

to differentiate themselves

from

the other

team

members.

One

technicalsenior analyst noted:

The

contribution _oftechnicalpeople toBeta is that

we

are crusaders.

We

findout all the neat things

done

in the labs

and we

figure out

how

to importthese into

our

monolithic development environment

and

procedures

.

An

aspectofBetathathelpstokeepthe technical analystsmotivatedis theirparticipation in a strong

and

active technical

community.

Part ofthis

community

is tied to the

computer

"hacker"culture

beyond

Beta [Turkic 1984] with

which

the technical consultants identify. Technical consultants pride themselves

on

being creative,

which

explains their dislike for the functional consultants' preoccupation with getting the application "out the door." Technical consultants are heavily

involved withthe technology, andthey can often avoid interacting with theircolleagues

and

users

ifthey wish.

A

technical senioranalystremarked:

/prefertojust

do

thetechnicalstuff. Iget quickerfeedbackthatway.

You do

something

and

then

when

you're finished itgoes away.

You

don't

have

users

coming back

allthetime with changes.

There

is a strong identification with being special, and different

from

the restofthe consultantsin

Beta.

One

technical

manager

remarked:

Alltfietechnicalpeople areso arrogant.

We

are the spoilt rottenbrats inBeta. We'retold

we

are so wonderful

and

we

tendtobelieve it.

We

thinkfunctional

work

is soeasy

anyone

can

do

it.

One

means

through

which

technical consultants reinforce theirdifference is

by

maintaining their

own

internal

communication

system.

One

of the local technical groups publishes a regular

newsletter:

"The

Technical

Times" which

is distributed to all technical consultants in Beta, and

which

contains reprints oftopical articles,^' transcriptsofpresentations given atBeta meetings,

and

some

notes

by

senior technical managers.

Another

way

ofsustaining the technical culture is

through

monthly

local technicalgroup meetings

which

usually comprisepresentationsofthelatest

technology, research anddesign innovations soas tokeep the technicalconsultants technologically

stimulated.

One

suchmeeting forexample,spanned a

whole day

and

was

devoted to the latestuser

interface technologies, with a

number

ofvendors bringing in their products

and

giving hands-on

demonstrations. Interspersed

among

the demonstrations

were

presentations

by

guest speakersand in-house personnel

on

issues in

ergonomic

design,

and

the dimensions of the person-machine

interface.

Such

meetings and

communications

serveto strengthen the sharedmeanings, values, and

norms

ofthe technical subculture, as well asproviding a

forum

in

which

to transmitandreinforce such shared

meanings

and interests.

The

resultis areaffirmationoftechnicalconsultants as special and different

from

therestoftheconsultants in the organization. This subculture identity in turn

helps to sustain the polarization of consultants

on

the projectteams.

Discounting

the

Functional

Consultants

The

technicalconsultantstendto stereotypeother

team

members

(whetherfunctional consultants or

client data processingpersonnel) as "tool users,"

and

hence as having little understanding ofthe information technology underlying the tools. This allows thetechnical consultants to rationalize their

need

tohide the tools

from

these "usertypes."

On

projects, the statusofactors in Betaand clientorganizational hierarchies is lessimportant thanactors' ability towield technical control.

On

one

project, forexample, a junior technical consultant

who

had been with Beta forbarely a year,

was

ableto limit the discretion offunctionalconsultants(two and threeyears his senior)andclient

data processing personnel (withfive toeight yearstechnicalexperience),through his authorization

^^

_A

_{recentissueincluded, forexample, the articles: "TheRise of Techno-Nationalism" by Robert Reich reprinted}

fromTheAtlantic,and"NoSilverBullet"by Fred BrooksJr.reprintedfromIEEEComputer.

oftheir

CASE

tool userprofiles. His attitude is evidentin thisrationale he

gave

for restricting the

computer

capabilityof other

team

members:

You

show

them

[the non-technical

members

ofthe team] thefunctions ofthe toolgradually, not

all at once, as

you want

to get

them

going as fastaspossible.

So you

don't

show

them

things they won't need, or things thatare too complicated as

you

don't

want

to confuse them.

So

the

principleis

show

them

aslittleaspossible.

In othercircumstancesthistechnical consultant'sapproach might betaken asevidence ofa careful

teacher

who

does not

want

to

overwhelm

his/her students.

However

on

this particular project all

the functional

team

members

and clientdata processingpersonnel

were

technicallyexperienced. It

seems

that the technical team's

world-view

engenders a perception of other

team

members

as

necessarily incompetent without tools.

The

consultant's attitude is typical of

most

technical

consultants, whatever the realityoftheirfunctionalteam'sexperience and knowledge.

This

dim

view

oftheirfunctionalcontemporariesis however,

becoming

a self-fulfillingprophecy.

The

functional consultants' lackofexposure to technical issues coupled with Beta providing little

technical training to

new

recruits is creating a

growing

pool of technically illiterate functional consultants. This has the desired effect ofincreasing the use of

CASE

tools

on

projects (hence

increasing Beta's project leveraging factor) whilereinforcing the functional team's

dependence on

the technical team. It also has anunanticipatedconsequence, as itrequires technicalconsultants to

be

responsive to the

now

more-dependent

functional consultants. Technical consultants find themselves performing technical support tasks (repairing databases, installing

new

versions of tools, creating

backup

copies of software and data, training tool users, and answering technical questions)

when

they

would

prefer to be building

advanced and

complex

technical routines.

A

technical

manager

remarked:

With

the tools

and

technical architecture

we

completely hide

CICS

and

DB2

from

the

programmers,

and

can get incredible productivity

from

them.

But

we

also get

uneducated

programmers,

who

can't handle the smallest technicalproblem,

and

at the firstsign oftrouble

they

go

screaming forthe tech team.

Resisting the Results

Orientation

Notwithstanding the extensive control that technical consultants have over the conditions under

which

thefunctional

team

operates, the inherentresultsorientationoftheBetaculturecauses

much

frustration

among

technical consultants.

For

technical consultants Beta's results orientation is a

major

restriction

on

their creativity,

and

a constraint

on

their ability to refine the technical

infrastructure they construct

and

maintain.

They

feel that a results orientation is

myopic and

that such a short-term strategy inhibits the

development

of

good

technical solutions.

Given

the

dependence

ofthe

whole team on

the

CASE

tools,the technical team's

mandate

is to get the tools

operational

on

thecurrent

computer

environmentas soonas possible, inany

way

possible.

But

this

doesnot allow sufficienttime fortechnicalconsultantstodevelop thesmart, elegantsolutionsthey

would

liketo.

A

technicalconsultanthadthis say:

The

budgetary restrictions

on

theprojectcause

problems

inscope; theyforce

a narrow

view

on

the tech team. This isfrustratingforus, the technicalteam, as

we

see

and know

what

shouldbe

done

toimprove, refine,

and

generalizethe tools

we

carry

around

from

projecttoproject,but

we

can't

do

that. ...So it isfrustratingfor the technical types

who may

have

great ideas, but

who

don'thave the timeto developor implementthem.

Itis interesting to look at this issue ofresults orientation

from

the otherside.

A

functional senior

analystfeltthata beliefinthe "technicalfix"pervaded Beta'stechnicalconsultants:

There

is

a

preoccupation with tools in Beta, particularly

from

the technicalgroups.

They

are alwaysin search ofthegolden

goose

that willsavetime

and

money.

But

that'sjust toosimple.

Anotherfunctionalconsultantremarked on technical

team

priorities:

There

is

a

feeling that they [the technical consultants]

do

not

want

to release stuff until it is

perfect. ...

But

right

now we

need

basic transportation.

And

we

would

rather they give us

something towalkwith,

and

then theycan enhanceitlatertogive us

a

racingcar.

The

standoff

between

these

two

orientations reflects the functional interest in results

and

the technical interest in technological innovation.It isaconflictthat hasto be

managed

constantly, and theburden ofthis falls

on

the shouldersofthe projectmanagers,

who

must

supporttheirfunctional

analysts in getting the project

completed

on

time

and

within budget, but

must

also

keep

their technicalanalysts motivatedtoprovide areliable,efficientand useful systeminfrastructure.

Summary

of

CASE

Tools

Research Study

The

deployment

of

CASE

tools inBeta triggered structuralchangeswithintheproject teams,

which

institutionalized the existing, formalized fragmentation ofexpertise into technical

and

functional groupings.

Such

a duality ofinterests, orientations, skills, and tasks

on

projects

undermines

the

homogeneity

ofthe Beta

"team"

ideology

by

breeding subcultures and territorialism. Itresults in

tension

and

conflict

on

projectteamsthat

sometimes

lead toeruptions.

The

functional consultants

seem

typically tolose out in theseconfrontations,as

CASE

tools arethe stated policyofBeta, and

the technical consultants, as

implementors

of this stated policy,

have

legitimacy

and

Beta's

resources

on

their side. Rebellion

by

functional consultants is a

way

for

them

to reassert the

autonomy

they feel thetechnical

team

has usurped. In time such resentment

may

diminish, as

new

functionalconsultants enter Beta

and

take the presenceofa powerful technical

team

forgranted.

Not

being

aware

ofthe prior division of labor, and not having been

exposed

to projects

where

technicalconsultants

were

the

"backroom

guys,"these functional consultants are unlikelytofeel a loss ofcontrol, centrality, and territory.

The

following sectionre-examines thefindings describedabove

by

interpreting

them

in termsof a

broader social theoretic

framework,

so as to derive

more

general insight into relations

between

technicalexpertsand functionalworkers around the deploymentof information technology.

5.

THEORETICAL

INTERPRETATION

The

introduction of

CASE

tools in information systems

development

can be understood as an

instanceofthe

more

general

phenomenon

increasinglypervading contemporaryorganizations: the

deployment

of information technology in core production activities. In the particular instance of

CASE

tools in Beta, the production

work

being

mediated

by

information technology is the

development

of information systems, and the particularinformationtechnology being deployed isa

set ofcapabilities that support/automate the activities ofsystems development. Recognizing this,

the specific findings about socialrelations

on

project teams using

CASE

toolscan be articulatedin

termsofthe

more

generic organizationalprocessesof

which

they are amicrocosm.

The

insightprovided

by

this studypertains tochanges inthe divisionoflaborand the relationsof

dependency on

project teams following the introduction of

CASE

tools. This suggests that any substantial mediation of production

work

by information technology can be expected to lead to

changes

in the division of labor

and

patterns of

dependency

among

the actors involved.

Introducing information technology

commits

a production process to a technically

complex

infrastructure of hardware, software,

and

procedures, that necessarily involves

new

forms

of expertise.

As

aresult, specialized skillsare neededtoensure the reliable andeffectivemediation of

production

by

information technology.

At

least

two ways

ofproviding theseskills are possible.

1. If the existing production/functional personnel are able to adequately manipulate the information technology, theywill berequiredto integrate technical skills into theirwork. In

this case, functional workers also

become

technical experts,

and

social relations

among

workers need

not be disrupted (although disruptions

may

result

from

the role conflict,

ambiguity, and overload that such aninfusion of

new

tasks and skills couldengenderwithin individuals).

While

this

may

appear to be upskilling of work, in that the

workers

now

acquire technical skills, it need not be. Job upskillingonly occurs ifthe

new

skills increase

the discretion and

autonomy

oftheworkers

on

theirjobs. Ifthe skillsarerequiredjustsothat workers can perform the

same

taskstheyexecutedbefore (with the

same

level ofautonomy), therehasbeen

no

upskillingofwork. It isimportantto notethat the relationshipposited here

refers to

work,

and

not to workers.

The

processes of deskilling affecting jobs are not

synonymous

with thoseaffecting individuals [Attewell 1985;

Lee

1981].

For

example, while a particular task

may

bedeskilled

by

being

made

simplerand

more

routine,the particularjob

incumbents

may

not be deskilled for they

may now

work

at the

more

skilled aspects ofthe job, with thedeskilled task beingexecuted

by

a different setofworkers

(who

may

well find

that theirjobshave been upskilled).

2.

Given

theextreme specializationofroles

commonly

experiencedinorganizations however,it

is unlikely that functional workers will

have

the capability, resources, or inclination to

develop and maintain the information technologythat facilitates theirdaily work; end-user

computing

notwithstanding.

As

the

demand

for

and

supply of sophisticated and

complex

computer

capability escalates in

advanced

industrial economies, it is probable that the

information technologydeployed in production

work

willbe

beyond

the scopeoftheaverage end-user. In thiscase, functional workerswill merely use the information technology, while outside expertise in the

form

oftechnical specialists will be imported into the production

process todevelop andmaintain it.

New

technical exp)ertiseand

new

technology-management tasks areintroduced into a given production process,and the existing division oflabor and patterns of

dependency

willcertainlybe affected, asevidencedin Beta'sexperiences.

In Beta's case, changes in tasks

and

expertise are reflected through changes in social relations

among

project

team members.

Rephrasing in

more

general terms, socialrelations

among

the key

actors in the production arena will be affected as a

consequence

of deploying information technology in production.

Power

is a feature of all

forms

of social relations [Giddens 1976,

p.ll2], sothatone ofthe

ways

in

which

the nature ofchangein social relationscan beinvestigated

is through studying shifts in

power

relations

among

key

actors.

Power

is the

means

ofgetting

things

done and

as such, actors

mobiUze

differentresources that they bring to bear

on

theirsocial interaction. It is through differential possession of

and

access to these resources that

power

is

exercised. In the light of the findings presented above, it is expected that in the context of

production

work

mediated

by

information technology, technicalexpertiseandunrestricted accessto

information technology

become

significantresources around

which

power

ismobilized.

The

study

ofBeta furtherdemonstrates that

CASE

tools, as central elements in social interaction, generate

conflict

between

functional

and

technical consultants

on

the project teams.

Given

differences

among

technical

and

functional

workers

in perceptions, interests,

and

work-pressures, the

differential distribution of technical resources can be expected to lead to or accentuate social conflictsaroundany production process beingmediated

by

information technology.

By

deploying information technology in production, traditional bases ofexpertise and authority (hencepower) in theexistingproduction process are threatened.

With

theincreased

dependence

on

technical expertise, conflict arises

between

the newly-arrived technical experts and theestablished

functionalworkers

whose

expertise and authorityis challengedand

changed

throughthe mediation of production

work

by

information technology.

How

this conflict is played out across various

production arenas remains

open

to empirical elaboration.

The

technical experts

may

triumph,

institutionaUzingtheirtechnocratic dominance, orproduction workers

may

reassertcontrolthrough

theircontinued resistance to the technical

dependence

that

now

inheres in theircomputer-mediated production tasks. Different

outcomes

will be generated across different contexts and different

outcomes

may

be generatedovertime within the

same

context.

While

such

outcomes

can never be

predicted unequivocally,

we

can determine thelikelihcxxl ofdifferent patternsof response based on an understanding of contexts, actors,

and

resources.

For example,

it is expected that

where

production

workers have

established legitimacy

and

influence - say they are accredited

professionals (physiciansor lawyers) - itis

more

likely thatinstitutionalized basesofauthority will persist,

even

in the face ofinformation technology.

On

the other

hand

where

production workers

have littlecredibility

beyond

theconfines oftheir

employing

organization -_asin the caseofBeta's

functionalconsultants -_{theinfringement ofauthority}

_by

_{technical specialistsis}

_more

_probable.

In Beta there

was

a shift of

power

to technical experts as prior,

more

established functional bases

of

power

were

undermined.

While

the technicalconsultantsexercisedconsiderablecontroloverthe circumstances

under which

functional consultants

worked,

their

power was

not inviolate.

Functional consultants, asknowledgeable andcapable agents,occasionally

were

abletorecognize

the constraints

on

theirbehavior,and take action tosubvert the

power

ofthe technical consultants. Thus,

by

refusing to

conform

to the tools and the

"team"

way

of doing things, such functional

workers reasserted their agency, underscoring the notion that

power

is always relational - _{not a}

static property of an individual or institution -

and

not only realized through social interaction [Giddens 1984].

They

also risked their status

and

job security.

The

message

here is that,

when

provoked

sufficiendy individuals canand

do

rebelagainst structural andtechnologicalimperatives.

The

frequency with

which "power

struggles" occur,

and

the extent to

which

functional workers

resist the conditionsofthe

power asymmetry

in their

work

context, will determine the

amount

of

dominance

technical experts amass.

Where

such resistance is

weak

or sporadic, the differential distributionoftechnical resourceswillbe reproduced overtime.

Where

technical expertsareable to

generate

outcomes by

affecting the conduct of functional workers - _through the application of

technical

knowledge

or manipulation ofinformation technology - _such reproduction will occur.

Through

theiractionor lack thereof, technicaland functional actorsthus recreate theconditionsof

their

dependence

relationship.

And,

in time, such

power

asymmetries

become

institutionalized into structuresof domination.

However

- _and this point

must

be stressed - such patterns of domination