Dimensions of I/S planning and design technology

5*1.'*l'»*»ijpW^iWV".*s *»*

ytf?

?')•'

HD28 .M414 no. 2077-83 1988b '?T\t

MAR

3

_-1930

Dimensions

of

l/S

Planning

and

Design

Technology

John C.

Henderson

Jay G. Cooprider

Dimensions

of

l/S

Planning

and

Design

Technology

John C.

Henderson

Jay G. Cooprider 90s; 88-059

September

1988 Sloan

WP#

2077-88

CISRWP#

181 •1988 J C. Henderson, J. G. Cooprider

Management

in the 1990s Sloan School of

Management

Management

in

the 1990s

Management

in the 1990s isan industry

and governmental agency

supported

research program. Its

aim

istodevelop a better understanding ofthe

managerial issues ofthe 1990s

and

how

to deal

most

effectivelywith them,

particularly asthese issuesrevolve

around

anticipated advancesin Information

Technology.

Assistingthe

work

ofthe Sloan School scholars with financial support

and

as

working

partners in research are:

American

Express

Company

Arthur

Young

and

Company

British Petroleum

Company,

p.I.e.

BellSouth Corporation

CIGNA

Corporation

Digital

Equipment

Corporation

Eastman

Kodak

Company

General

Motors

Corporation

International

Computers

Ltd.

MCI Communications

Corporation United States

Army

United States Internal

Revenue

Service

The

conclusionsoropinionsexpressed in this paper are those ofthe authors

and

do

not necessarily reflect the opinion of the Massachussetts Institute of

Technology, the

Management

in the 1990s Research Program, or its sponsoring

organizations.

Acknowledgements

The

authors

would

like to

acknowledge

Mark

Hunsburger

forhiscontributions to thiswork.

ABSTRACT

Information technology isincreasingly

an

integral part of the competitive strategiesfor

many

organizations.

As

thistrend continues, itisnot surprising that thereis

an

increasing

emphasis

placedonthe abilityoforganizations to plan,design

and implement

criticalinformation systems.

A

major

strategy toimprovethe

effectiveness ofthese processesisto utilizecomputer-based planning

and

design

aids.

And

yet,thereis little empirical evidence thatdemonstrates asignificant

performance impactof thistechnology.

One

factorlimiting researchon theimpactof

technology

on

planning

and

designisthe

manner

in

which

thistechnologyhas

been

conceptualized inordertoprovide

measures

ofusagebehavior. Thisresearch

develops a functional

model

ofI/S planning

and

design support technology that distinguishes

among

three general functional dimensions: ProductionTechnology, Coordination

Technology

and

InfrastructureTechnology.

An

empirical analysisis

used totestthe robustnessoftheproposed

model

and

its abilitytodiscriminate

between

currentdesign aidsina

meaningful

way. Implications fortheuseof this

model

in the studyofI/Splanning

and

design processes are discussed.

1.0

Introduction

Intoday's businessenvironment, a critical

management

issueis

"time-to-market", that is,the length oftime ittakes

an

organization toconverta product

concept intoa viable product thatisavailable in aspecificmarket.

The

Xerox

Corporation, for example, argues that their

improved

abilityto

manage

time-to-market

while retaining orimprovingqualityhas

been

amajor factor in theirefforts . to rebuild theircompetitiveness.

Extending

thisnotion, Hewlett

Packard

focuseson

the "time-to-break even" as a

measure

of successforproductdevelopment. This

perspective incorporates directly the aspects ofquality

and

maintainability while

highlightingthe criticality ofrapidresponse.

Itis not surprising thattheI/S function within a business facesthis

same

challenge.

As

information technology

becomes

an

integral partof

an

organization's

competitivestrategy, theI/S function faces increased

demands

to improve itsability to

manage

the"time-to-market"for I/S products

and

services. In fact,

some

(Martin 1988)

have

suggested thatthe inabilityofan I/S function toboth reduce the backlog

of

demand

for systemsproducts aswell as

meet an

increasing

new demand

forI/S

products represents aserious

management

failure.

While

many

factors afTectan organization's ability todeliverhigh quality productsin a short time frame

(Ancona

and Caldwell 1987), one key tool to address

forexample, Xerox, Ford

and

many

other organizations focusing onthe role of

CAD/CAM

technologiesasone

means

to radically

change

theircapacitytoquickly

develop

and

deliverproducts tospecific markets. Similarly,

we

have seen the growth

of a

major

industry that seekstodelivercomparabledesign aid technology tothe L'S function. Often referred toas

CASE

technology

(Computer

AssistedSoftware

Engineering), this technology istargeted at those

who

wish to useautomation to

affectthe timing,costs

and

quality ofproducts

and

services delivered by theI/S

function.

Beck and

Perkins(1983), for example, found that56outof97

organizations theysurveyed used

automated

tools asa

means

to improvetheirI/S

planning and

design processes.

The

impact

ofthese tools, however, on the productivity ofsoftware developers

and, ultimately, on time-to-marketisunclear.

Semprevivo

(1980)

and

Neccoetal. (1987),for example,

have

reported that designaid technologyimprovesthe

productivityofdesigners. Incontrast. Card, etal. (1987)

and

Lempp

and

Lauber

(1988) found, aftercontrolling forfactorssuch asexperience

and

task complexity, that the useofsoftware

development

aidsdid not

have

asignificantefi'ecton productivity

and

a relatively

weak

effecton quality.

The

explanationsforsuch confiicting resultscould be attributed to

many

factors.

For

example,

some

ofthe studies thataddress productivityimpact from narrowly

defined tasks such asthe encodingof specifications or the developmentoffiow

representations (Case 1985). In contrast,otherstudies focus on the entiresystem

design life cycle (Cardetal. 1987).

Perhaps

more

fundamental is the lack ofclarity

asto thedefinition of

what

constitutes usage of the

CASE

tools. It is often unclear

whether

usage refersto access, e.g., such technology

was

available to the team,or, in

fact,

measures

actual usage behavior. Further, it is notclear that the levelof

to actuallypredictperformance impact. Forexample,ifa

macro

usage variable is

employed, ("didI use thispackage"),

teams

may

indicate asimilar usage levelof

designaidsbututilize quite differentsubsets of functionality.

As

a result, the

impact

of this technology could be easilymixed, leadingto an overallassessment

across design

teams

thatindicates little orno impact.

The

need

to better define

and measure

technologyusage behaviorsuggests a need

to develop a

model

of

CASE

technology thathas a correspondence

more

closely to key

designerbehaviors.

That

is, ratherthan define

CASE

technologyin economic terms

(e.g., costs), technologyterms (e.g.,

PC-based

ornetworked),or in termsofgeneral characteristics (e.g.,

having an

embedded

design language orstructured code compiler),

we

must

develop a

model

of

CASE

technology thatisfunctionality oriented.

Such

a

model would

then provideone

means

todirectly relate usage ofa

CASE

tool todesign

team

performance.

The

literature onI/Splanning

and

design doesofferastartingpoint.

Hackathorn

and Karimi

(1988)

and

Welke

and Konsynski

(1980),forexample,differentiate

between

design methodologies

and

designtools.

The

formerdefine the logical

disciplinesunderlyingI/S planning

and

designactivities.

The

latterinstantiatethe principlesin a softwareapplication.

Hackathorn

and Karimi

(1988),

Beck and

Perkins(1983)

and

otherssupportthe notion that softwareengineering

and

information engineeringinvolvesthe applicationofsound engineeringprinciplesto

the task ofI/Splanning

and

design.

Understanding

these principlesoffersone

means

to

map

the functionsof

CASE

technology onto key usagebehaviors.

The

difficultylies in thediverse setof concepts, principles

and

subsequent methodologies thatcould be used to generate a designaid environment. Chikofsky

definition of

CASE

technology thatsatisfiesthisdiverse range ofdesign concepts

and

methodologies. In a similar vein, Osterweil (1981) recognizesthisinherent diversity

and

arguesthat a research

program

insoftwareengineering

must

address

the full rangeofdesign related activities.

He

states

"The

task ofcreatingefi"ective environments isso difficultbecause it is

tantamount

to understandingthe

fundamental

natureofthe software processes.

A

specific

environment

does notmerit the

name

unless it

provides strong, uniform supportforthe entire processitis intended to

facilitate; thatis notpossible unless the processisfully appreciated

and

understood."(Osterweil, p. 36)

In the following sections, the the

development

ofa functional

model

of

CASE

technology thatcan be usedto address a wide range ofplanning

and

design activities

isdescribed.

The

results ofin-depthinterviews with leadingacademic

and

industry

designersof

CASE

products concerning the range of possible

CASE

functionality .

serves as astartingpointfordeveloping thisfunctional model. Past research on

CASE

functionalityisthen used toorganize these functionalities intosix general

dimensions

of

CASE

technology.

The

ability forthese dimensions toserve as a

model

for

CASE

technologyisevaluated empirically through both a Q-sort studywithI/S

planners

and

designers(familiarwith

CASE

technology)

and

use ofthe dimensions

to characterizethe strengths

and weaknesses

ofcommercially available

CASE

products. Implications forthe use ofthis functional

model

forresearch onthe impact

of

CASE

technology isdiscussed.

2.0

A

Functional

CASE

Technology

Model

(FCTM)

There

are several reviewsof the range offunctionality foundacrossvarious

CASE

environments.

Hackathorn and Karimi

(1988),forexample, categorize

CASE

which

the

environment

provides fora range ofsupportfrom conceptual toexplicit

design techniques.

The

functionality of the

CASE

technologyisthen implied _by the

method(s) incorporated in the

environment

and

the aspectof theplanning

and

development

for

which

the support

environment

istargeted. Thus, a toolthat

embraces

the

Gane-Sarson

(Gane

and

Sarson, 1979)

method

could be expectedto

provide features such asfunctionaldecomposition ordata flowdiagram.

Of

course,

the tool

might

provide

much

more

incontextof

communications

or analysis.

Such

distinctions, however, are notclear.

Reifer

and

Montgomery

(1980) provide a

more

generalschema.

They

begin with

a general

model

ofdesignas

having

three components: input, process,

and

output.

Each

component

is

decomposed

until a setof52 functionsare identified.

They

argue

thatthis

taxonomy

permitsclassification ofall current softwaredevelopment tools

(given the time of theirstudy)

and

allows easycomparison

and

evaluationoftools.

While

one couldargue thevalidity ofsuch

an

ambitiousclaim, their

taxonomy

does

provide a directlinkage todesign behavior. For example, theyidentifyfeaturessuch

as tuning, structure checking, scheduling, auditing

and

editing. Clearly, sucha

model

can be linked tothe actual behaviorsofdesigners. Similarly approachesare discussed

by

Rajaraman

(1982)

and

Houghton

and

Wallace(1987).

These

models, however, do appearlimited. For example,the functionality

associated with

teams

isnotclearly identified. Featuressuch as those foundin

COLAB

(Stefik etal., 1987)or

PLEXSYS

(Konsynskietal., 1984) thatsupport

groups through structured processesforbrainstorming, communication,voting,

negotiationsor the

key team

behaviorsappearto belacking.

To

theextentthat

"time-to-break even" will involve the use of

teams

assuggestedby

Ancona

and

Caldwell (1987), Cooprider

and Henderson

(1988)

and

others, there is aneedto

incorporate these functions into

CASE

technology.

-5-In this research,

we

pursue

an

objective consistentwith priorresearch that

attempts to characterize the

key

dimension ofdesign support technology.

That

is,

we

will develop a function

model

ofdesign support

(CASE)

technology.

To

achieve this objective

we

used a four step process. First, leading designersof

CASE

related

technologywere interviewed to generate a setofcritical functions thatcould be of

value to

an

I/Splanneror designer.

The

specificfunctional definition used

was

required tocorrespond to

an

observable design behavior. Second, this setof

functions

was

reviewedby 25 practicingdesigners familiarwith

CASE

technologyto

refine

ambiguous

items

and

reduce

any

obvious redundancies. Third, aclassification

scheme was

developed based on a review ofthe design literature

and

usedas a basis

tosorteach specific functionalitygenerated during the interviewprocess.

The

Q-sort

was

done

by an

independent group of34 I/Sdesignersexperiencedin

CASE

technology.

The

intent of this step in the process

was

to evaluate the robustnessof themodel. Finally, the

model

was

used to evaluate currentlyavailable

CASE

products. Thisstep representsone testofthe model'sabilityto adequatelyrepresent

and

discriminate

between

actual

CASE

environments.

In the firststep, open

ended

interviews with leading

CASE

designers(both

academics and

practitioners)

were

usedto develop a listof possible

CASE

functionalities.

A

totalofeleven interviews, eachlastingfrom two tothree hours,

were

conducted.

Each

interview subject

had

extensive personal involvementin

CASE

technology research or

had

actual

development

experience with a rangeof

commercial

CASE

products. Subjects included three academics

and

eight

practitioners.

The

interviews consisted ofprovidingthe subject with a listof functionalities extractedfrom the literature.

To

ensure adequate discussion, the lists were divided

into five sections.

The

subjects reviewed each functionaldescription, noting

ambiguity

or biasin definition.

At

the end ofeachsection, problems with definitions

were

discussed

and

new

functionalitiesadded.

The

orderofpresentation ofeach section

was

randomized acrosssubjects.

A

total of124distinct functionalities

were

generatedvia the interview process.

The

second stepinvolved a clarificationprocedure to

combine

or eliminatevague

and/or

redundant

functional definitions. In thisefTort, three to five expertusersfor

each ofeightexisting

CASE

productswere asked to evaluate theirproductusingthe

124 functionalities.

Each

subject indicatedthe ease ofuse of a givenfunction on a

one to fiveLikertscale

where

one equalsverydifficultto use ornonexistent

and

five

equals very easyto use or essentially automatic.

The

reliabilityofeach functional definitioncan be assessed by analyzingthe variance (orcorrelation) across subjects fora given product. Ifthedefinition is

unambiguous,

subjectexpertsshould assign the

same

ease ofuse ratingtoa given functions. Functional definitionsreceiving

high

varianceor inter-rate reliabilitybelow .8 were reviewed

and

eliminatedor refined.

As

a resultofthisprocess, 98 distinct functionalitiesweredefined.

The

third step in the process involveddevelopinga

model

thatreflected thescope ofthese98 functions. This model, calledthe Functional

CASE

Technology

Model

(FCTM),

was

developedin a twostage process. First, areviewofrelevant design literature

was

used to define apriori a generalmodel. Then, a

new

setof34 expert

CASE

users

were

giventhe task ofsortingeach function into oneof the apriori

dimensions

defined

by

thismodel.

The

extentto

which

thisQ-sortprocess reflecteda consistent sorting pattern across subjects isthentaken as evidence thatthe apriori

model

isa

meaningful

abstraction

and

can be used to representa wide range of

CASE

functionality.

That

is, it is

more

than a unique artifactoftheresearchers interpretation ofexistingliterature.

-7-An

alternative approach fordevelopingsucha

model

isdiscussed bySherif

and

Sherif. In thisapproach the subjectis askedto

manually

cluster attributesthereby

developingasubject specificmodel.

The

models generated

by

asetof subjectscan

then

be analyzed for underlyingsimilarities and, hence, formthe basisfor

generating

an

overall model.

The

strengthofthisapproach liesin the abilityto

eliminate thebias createdby

an

a priori model.

However,

such

an

approach requires

extensive time

and

may

resultin dimensionsthat

have

little theoretical grounding. Inthis case, thetime

demand

forthe clustering taskwith approximately 100 items

exceeded

the time subjects

were

willingto provide. Further,yearsofboth theoretical

and

empirical researchon I/Splanning

and

design provide abasis fordeveloping

an

a priorimodel.

Given

these two factors, a Q-sorttestingstrategy

was

utilized.

I

As we

will discuss ,the final step then teststhis

model

by usingittodiscriminate

between

actual

CASE

products. In thefollowingsection, eachdimension ofthe

FCTM

isdescribed

and

the results of the Q-sort processare provided.

The

section

concludeswith a

summary

ofthe

adequacy

of thismodel. Section 3 then uses the

model

toevaluateactual products

and

discusses the implicationsofthese results.

Finally,Section 4

summarizes

the findingsof thisresearch

and

discusses the implications forfuture research.

2.1

Three

Dimensions

of

CASE

Technology

Reviews

ofthe organizational literature on technology (Fry (1982),Fry

and

Slocum

(1984)

Slocum

and

Sims

(1980),

Withey

etal. (1983)) reveal a diversity of

approaches

to the

measurement

oftechnology.

Perrow

(1967)definestechnology as the actionsused to transforminputs intooutputs. In thatcontext, technologyisa

production variable,describingthe

way

inputsare converted todesired outputs.

Economists

have

long characterized technologyasproduction technologyconcerned

with creating, processing,

and

handlingphysical goods. Thus, as illustratedin

Figure 1, oneperspective of

CASE

technologyisto

view

itas

an

underlying

production technology.

Figure

1

Functional

Dimensions

ofI/S

Planning

and

Design

Technology

A

secondconcept thathas been used toevaluate technology iscoordination.

Thompson

(1967) arguesthat coordination isneeded

when

interdependenceoccurs

among

businessprocesses. Interdependence requires thatperformanceofone or

more

discrete operationshas consequencesforthe completionof others.

The

concept ofinterdependence isa

fundamental

principle indesigningorganizations

(McCann

and

Galbraith (1981), Galbraith(1977), Thompson(1967)). Differenttypesof

interdependence create differentcoordination structures

between

participants

involved.

Malone

(1988) defines coordination technology as

any

useo(technologyto

-9-help people coordinatetheir activities. Since a design

team

consistsofmultiple

agents with a variety ofgoals

and

skills,coordination technology

may

emerge

as

an

important dimension of

CASE

technology.

A

lastdimension oftechnologyisinfrastructure. Infrastructure technologyis

viewed

as

an

organizational supporttechnology.

Even

though

there are few

who

use

thisterm, this is

an

importantdimension ofdesign aid technology.

A

given design

team

may

interactwith other

teams

in order toobtain resources, coordinate work,

make

decisions,

and exchange

inputs

and

outputs. In this regard, infrastructure

technology isconcerned with the interaction with personsor units

which

are outside ofa givendesign team, i.e.,

key

stakeholders. Thus, amajor difference

between

coordination technology

and

infrastructure technology isthefocus ofthe infrastructure technologyon providing

an

organization-wide design support

environment.

Taken

together,technologycan be conceptualizedasproduction technology,

coordination technology

and

infrastructure technology. In the following

we

will

build from these three perspectivesoftechnologytocharacterize the dimensionsof

CASE

technology. In each section

we

will

examine

relevant research onI/Splanning

and

design aids

and

define the

components

ofproduction, coordination

and

infrastructure technologyfrom thisviewpoint.

In this sectioneachmajor dimension isdefinedin termsofdistinct

sub-dimensions

(Figure 1). Results ofthe Q-sort processare providedin Section 2.2.

A

summary

ofthe

FCTM

is provided in Section2.3.

2.1.1

Production Technology:

Representation

As

discussed above, one perspective on technology is action used totransform

inputtooutputs

(Kottemann and Konsynski

1984).

At

an

individual level,

Simon

(1976, 1981) argxies that

bounded

rationality ultimately limits thecapacityof

human

information processing and, hence, thistransformation process. This

information processing perspective isoften used tocharacterize the planning

and

design task

(Thomas

and

Carroll 1979)

and

provides a basisto characterize the

production dimension ofdesign aid technology.

The

first

component

ofproduction

technology islabel representation to emphasize the notionofabstractingor conceptualizing a

phenomenon.

Schon

(1984),

Zachman

(1986)

and

othershave

identifiedthe process ofevolvingabstractions

and

presenting

them

in a

communicable

form as

an

essential activityin planning

and

design.

Zachman

(1986), forexample, listscategoriesoffunctionalitysuch as processflowdiagrams, functional chartingor entity

modeling

thatreflectalternative

means

torepresent conceptsor

phenomena.

Kottemann

and Konsynski

(1984)identified ahierarchy of

knowledge

representation thatincluded

names

orlabels,

domain

set specifications,

associationor relations

mapping

and

complete

meaning

thatsuggestthe needfora

range

ofrepresentation functionalities.

From

our perspective, eachofthese

categoriessuggests the

need

for specificfunctionality to supportthe process of externalizing

and

communicates

a designconcept.

Specifically, the representation dimension isdefined as functionalitytoenable theusertodefine, describeor

change

adefinition or description of

an

object,

relationship or process.

The

interviewsresulted in a range of functionalities that

appear

to operationalize thisconceptual dimension.

As shown

in Table lA,these functionalitiesreflecta general notionof

knowledge

representation

and

acquisition.

-11-Table 1'

ComponentsofDesignAidTechnology

Functionalitiessuch as

an

ability tomaintain a single masterdefinition or the ability to describe a process in terms ofaninformation flow reflectbasic

requirements to representknowledge.

A

second aspectofthe representationdimensionreflectsrequirementsfor

adaptingor

changing

representations,

and

forstoringorretrieving representations.

For example,the ability to propagate a change through a

model

supportsa userin

an

adaptation or

change

task.

Finally the ability to use alternative

modes

ofrepresentation,e.g., textversus visual representation, isreflected. Infact, assuggestedby

Konsynski

etal. (1984),

oursubjects

viewed

the ability toshift

between

alternative representationsas

an

importanttype of functionality.

Severalobservations

seem

appropriate.

As we

willdiscussin Section4,a

distinctionoften

made

between

design support

environments

isthe easeofuseofa functionality.

For

example,

two

design aid

environments

may

support data flow

diagramming.

They

may

differsignificantly,however, in terms of theease ofuse of this functionality.

Ease

ofuse canbe

viewed

as a

measure

ofeffortrequiredto

exercise the functionality and, thus, arelative

measure

ofcost.

Combining

a

functional

model

with thenotion ofeaseofuse will permitthe researchertoexplore the usabilityof

CASE

technology.

Secondly, the levelofspecificity ofthe functionality reflects the goal ofcreating a

correspondence

between

the functional

model

and

usage behavior. For example,

intervieweesrejectedas too general the use of"documentation"as a type of functionality. Rather, discussions indicated thatdocumentation isa formof representation (a passive form) that requires particular functionality.

The

needto

-15-develop a parsimonious

model

in a research setting (particularlyonethat requires users ofa system to describetheirusage behaviors) argues againsta micro model.

The

functionality described herein reflects the subjects'

judgment

as toan

appropriate level ofaggregation.

Finally, there is no claimthat the functionalitylisted inTable

lA

constitutes

an

exhaustive set forthe representationcomponent. Rather,this functional setis

viewed

as

spanning

or reflectingthe scope ofthiscomponent.

As we

will discuss,the

convergence found in the Q-sort process

and

the ability to discriminate across actual products supportthe conclusion that these functionalitiescanbe meaningful group

under

the proposed definition ofrepresentation.

2.1.2

Production Technology:

Analysis

This

dimension

ofanalysisreflects theproblem-solving

and

decision-making

aspectsofplanning

and

design.

Simon

(1981), forexample, portrays designas a

problem-solvingprocess

and emphasized

thecriticalityoftasks involvingevaluation of multiple alternatives

and

choices

made

by thedesigner. In asimilarvein,

we

define the analysis dimension to befunctionality thatenables the usertoexplore,

simulate, orevaluatealternaterepresentations or modelsofobjects, relationshipsor processes.

We

see thisrequirement reflected in the functionalitylisted inTable IB. Similar

tothefunctional building blockof a decision supportsystem (Keen and Scott

Morton

(1978),Treacy(1981),

Sprague and

Carlson(1982)), these functionalities reflectthe

need

tocompare, simulate, evaluate, ask

"what

if with respecttoa criteria,

and

choose oroptimize. It isinterestingtonote that

some

functional definitionsimply

an

embedded

intelligence in thedesign aid. For example, theability toexplain

why

a

-16-desi^

decision isbestreflects the useofexpert system

and AJ

conceptsin the

development

ofdesign aids.

In each case, the functionality in thisdimension (Table IB)

assumes

the existence ofa

knowledge

base(often a model)

and

seeksto manipulate this

knowledge

in order

to investigate alternatives, resolveconflicts orsupport achoice. Itisa proactive analysis process that builds

upon

oradds toknowledge. Thus,

we

would

expectthe

result ofusing analysisfunctionality to be the

enhancement

or adjustmentofa given representation (i.e., theuse of

modeling

functionality).

The

significant interaction

between

these two dimensions suggests thattheyconstitute

components

ofthe

more

general

dimension

ofProductionTechnology.

2.1.3

Production Technology: Transformation

The

nature ofplanning

and

design has been conceptualizedasaprocessor series

oftransformations

(Kottemann and Konsynski

1984,

Zachman

1986).

A

transformation is

an

internally complete

and

consistent

change

indesign conceptor

artifact.

The

need

forcompleteness

and

consistency reflectsthe attribute thata

transformation is a

non-random

purposeful activity and, hence,isrepeatable. For

example, convertinga logicaldata

model

intoaset of definitionsrepresented inthe

language

ofa given data basesystemconstitutesa transformation.

In general, the notion oftransformation has been the

mechanism

to represent

important aggregatesor

chunks

ofdesignactivity.

At

a macro-level, the system designlife cycle describes a series ofdesign transformations. Researcherssuch as

Zachman

(1986)

and Hackathorn and Karimi

(1988) have suggesteda range of

transformationsthatare central toI/Splanning

and

design processes.

We

define the

dimension

oftransformation tobefunctionality that executesasignificantplanning

ordesign task, thereby replacingor substitutingfora hunxan designerIplanner.

•17-This dimension of

CASE

technology reflectsa straightforwardcapital/labor substitution. Itdiffersfrom analysisinthatit replaces

human

activityratherthan providingsupport. In this sense, itis analogous tothe distinction

between

decision

supportsystems

and

process automation.

Of

course, transformation technologycan

enhance

the overall performance of

humans

by allowingredistribution of

human

resources. Still, at task level, the intentoftransformation functionality isdirect

substitution forthe

human

resource.

The

functionalities listed in Table IC correspond to the transformation

dimension. Several observations are appropriate.

As

might

be expected, the bulk of

these functionalities addressactivities late in the design cycle,e.g.,code generation.

As

such, these functionalities often depend ona

minimum

setof functionsbeing *

available in the representationcomponent.

However,

as

we

willdiscuss in Section4,

current technology often does noteflectivelylink these two functionalcomponents.

A

second observation is thatthe abilityto delivertransformation functionality often implies

embedding

intelligence into the

CASE

technology. For example, the ability to automatically normalize adata

model

is

an emerging

typeof

transformation functionality that

makes

extensive use ofexpertsystems

and AI

technology.

As

we

seeincreased use of intelligent

CASE

technology

we

might

expect

to see

new

typesoffunctionality

emerge

forthisdimension. Thus, the setof functionality

shown

inTable

IC

should be viewedasa current

benchmark.

2.1.4

Coordination

Technology:

Control

The

focus ofthedimensionsoftechnology discussed thusfar has been production-oriented.

That

is, the technology hasprovided a directimpactonthe abilityofan

individual to produce aspectsof the design. In thiscapacity, the technology

-18-represents aclassic productivity-enhancing investment, i.e., a capital/labortradeofT.

Through

the investments in technologythe task of a design

team

is accomplished

with less resources.

Williamson (1975) notes , however, thatthe constraints on

human

information

processingcan arise from both

bounded

rationality of a particular agent

and

from

the

communication

requirements

stemming

from interaction

between

agents.

Bakos

and

Treacy (1986) also identifythe needto reflectboth

bounded

rationality of individuals

and communication

costs in a general

model

ofinformation technology.

Malone

(1988) defines coordination as "the additional information processing

performed

when

multiple,connected actors pursue goals that a single actorpursuing

the

same

goals

would

not perform".

The

use oftechnologyto reduce the cost of *

coordination can enable an organization to utilize alternative organizational structures in pursuitoftheir strategies, and, thereby, achieve

new

levelsof

efficiency

and

eflectiveness. Forexample, Applegate, etal. (1986) andStefik, etal. (1987) describe technology thatisintended to improve the productivity ofmeetings

in partthrough

enhanced communication

functionality.

Such

technologycan not

onlyafTectthe efTiciency or effectiveness of a given

meeting

but alsoenable

organizationsdecision

making

or

problem

solving processes that

maximize

the useof

teamsortask forces.

The

intervieweesalso identified a range oftechnology that focusedon the need to

effectivelycoordinate individuals. It

was

interesting to note thatduringthe interviewssubjects

seemed

to shift from conceptualizingthe planningordesign process asan individual activity to one involvinga group orteam.

When

this shift

occurredthe design aid functionality discussed reflected issuessuch as the need to

•19-exchange

information, enforcepolicies orsecuritymeasures, orunderstand or resolve conflicts.

Itis not surprising thatone aspectofdesign aidtechnology thatemerges from the design literature reflects a

component

ofcoordination: control. This

component

reflects a notion ofa

manager/employee

orprincipal/agent relationshipin a planning

ordesignprocess.

That

is,design activitiesoften involve

an

explicitcontractto

deliver aproductor service toacustomerfor a given price. In orderto ensure that thecontract isfulfilled, acontrol systemormonitoring system isrequired.

Similarly, with the activitiesof a design team, a projectleadermaycontractwith

an

individual. Again, the projectleaderrequires

some

informationtoensure thatthis

individual does, in fact,carry outthe contractin the intendedway.

I

In additionto the need tomonitor, the principal or

manager

may

want

to impose

restrictionson the activitiesofa givenagentoremployee. For example, he/she

may

want

torestrictaccess toparticular dataor preventchanges to

some

aspectof

an

existingorproposedsystem.

At

a

more

abstractlevel, theprojectleaderneeds

an

ability to

communicate

projectgoals (even the

means

to achievegoals)

and

toensure

that the resourcesofthe

teams

are allocated in a

manner

thatbestachievesthe goals.

Of

course, requirements tocontrol theactivitiesof a group

have

longbeen

recognized

by

the developersofcomputer-aideddesign technology.

Houghton and

Wallace

(1987),Reifer

and

Montgomery

(1980)

and

others identify arangeof

functionality

spanning

notionsofproject

management,

configuration control,

and

access control.

We

define the control dimensionto bethe functionality thatenables theuserto

plan

for

and

enforcerules,policiesorprioritiesthat willgovernorrestrict

theactivitiesof

team

members

during theplanningordesignprocess.

-20-The

functionalityofthisdimension identified in the interviews is

shown

in Table ID.

There

appearto be two general typesofrelations tothisdimension: resource

management

and

access control. Resource

management

pertains to that

functionalitythat enables a

manager

toensure that the behaviorofindividuals

and

hence, resource utilizationbythe

team

isconsistent with organization goals.

The

capabilityto budget, toidentify a critical path orsetofactivities, tomonitorprogress orservicelevels, orto

communicate

orenforce appropriategoals are examplesof this

type offunctionality. In essence, itisfunctionality that supports arange of traditional control activities.

As

will be discussedlater, the potential for

CASE

technology to enable effective internalcontrol, i.e.,substitute individual control

behaviorfor

managerial

control,has majorimplicationsforperformance.

A

secondtype involves access or

change

control. Thisfunctionality assumes that issuesofsecurity

and

access

must

be carefully

managed.

As shown

inTable ID, this functionalityincludes configuration control, authorization

management,

and

the ability toidentify

and

audit the activityof designers, particularly

when

these

activities

change

existing

work

or directlypertain toa

team

policy. In essence,these types of functionality

assume

thatthe design

team

utilizes

and

producesa valuable

asset. Hence,accessto or

changes

to those assets

must

bemonitored

and

controlled.

2.1.5

Coordination Technology:

Cooperative

Functionality

The

controldimension addresses the needto establish

and

enforce goals, policy,

procedures,standards

and

prioritiesduring adesign process. It isthe traditional

conceptof

manager/employee

that

assumes

the needtoenforce a

work

contract.

Information isrequired both to ensure effectiveexecution oftask

and

to monitorthe contract.

An

alternative

mode

ofcoordination

assumes

thatthe participants operate ata peerto peerlevel. In this

mode,

the interaction

among

individualsis basedon a

sharedset ofgoals

and

a perception of

mutual

gain froma given interaction. Thus,

cooperative behavior isnot enforced byasetofrules. Rather, such interaction reflects a sense ofpeerinvolvement

where exchange

isoften voluntary.

Davis

and

Smith

(1983),

Henderson

(1988)

and

Malone

(1988) describe the conceptofcooperativebehaviorin this

manner.

For example, Davis

and

Smith

(1983)

argue

thatthe

need

forcooperation

among

experts arisesfromboth shared goals

and

knowledge

interdependence

among

the experts with respectto thesegoals.

Inthis research

we

willdefine the dimensionofcooperative functionality as

functionality thatenables the userto exchange information with another

indwiduaKs)

*

for thepurposeof influencing(affecting) theconcept,processorproduct ofthe

planning/design team.

The

interviewprocessgenerated a rangeof functionalities thatare

modeled

as

cooperative functionality (Table IE).

These

functionalitiesreflectarole of

CASE

technology both asa

communication

channel

and

as a facilitation aid. Reifer

and

Montgomery

(1980) identify

communication

functionality asan importantaspect of

computer-aideddesign technology. Certainlyin a groupcontext

communication

isa

key

issue.

The

basic

communication

functions inTable

IE

address the needfora

range

of

communication

functionality from basic

messaging

to

enhancements

such

as theabilityto attach a note to a diagram. In essence, thisfunctionality provides a

platformfor electronic interaction

among

members

of a team.

The

second classofcooperative functionalityuses technology to help facilitate

group interaccion. Thisincludes functionality that providesforelectronic

brainstormingor

manages

thedegreeof

anonymity

ofinput(i.e.,votes). Applegate,

-22-et al. (1986) describe technology that provides this type of functionality.

The

userof

PLEXSYS

technology can choose

between

several structured group processes

and

adaptthe technology to facilitatethe execution of the particular approach used.

The

technology has

an

impact on the process both through efilciency, e.g., the ability to

capture the outputof a brainstormingsession,

and

also by changing parametersof

thegroup processwithin an efilciencylevel. Forexample, the technology can permit

significantly largergroup size than isoften associated with abrainstormingsession.

To

the extent that participation

and

involvementafi'ects the successofa project,this

increased capacity could

have

significant benefits.

These

functionalities,

particularly those that

implement

structured group process, have aspects of control

embedded

in them. For example, electronicbrainstormingenforces

an

interaction

protocol

on

members

ofthe team. Thisassociation

between

control

and

cooperative I

functionalityis tobe expectedsince theyare both

components

of the

common

dimension

ofcoordination.

The

key

distinction is that cooperativefunctionality

assumes

a peer relationship

among

participants

and

isbasedona conceptofsharing.

The

technology functionsprimarily as a conduitorenablerofinformation exchange.

Control functionality,in contrast,

assumes

that ahierarchical relationshipexists

and

provides a

mechanism

to

exchange

information necessarytoestablish, monitor

and

enforce this hierarchy.

Each

relates to coordinationbutdoesso from adifi"erent

perspective.

2.1.6 Infrastructure

Technology:

Support

Simon

(1976) notes that

bounds

ofrationalitycanbe increased not only

by

increasing individualcomputational power, butalsobyinstitutionalizing

organization-wide standards to help individual performance. Thiscapability,

we

term

infrastructure technology, canbe defined as organization-wide

mechanisms

groups to

overcome

theircognitive burdensofinformation processing.

March

and

Simon

(1958) argue thatbyestablishing organization infrastructures, whichthey

call standardoperating procedures, the organizationcan reduce burdensof

information processingbecause search proceduresare

automated

in the standard

operating procedures to

some

extent. Similarly, Galbraith (1977)arguesthat

implementing

avertical informationsystem

and

the implied standardsofdata

and

language

associated with such asystem isonestrategy to increase theinformation processing capacity ofthe firm.

Malone

(1988) extendsthisnotion todescribe a

range

oforganizational structuresenabled

by

the use ofcoordination technology.

Computer

based design toolscan also provide organization-wide infrastructure forthe

development

of

complex

software. Often,

complex

software isbuilt

module by

module

by

several design teams. Ifthe

teams

donotproceedcarefully, the

idiosyncrasiesof

an

undisciplined

team

can leadto expensivefailure. Design aid toolshelp thedesign

team

manage

complexitiesof

development

byprovidinga

common

foundation forthe

development

ofI/S.

As

aresult, theorganizationgains

the potential to introduce parallelism aswell astime share scarce talent

among

teams.

The

design aid tools also help train designersin advance techniques

and

enforce consistent techniquesusagethroughouttheorganization.

However,

because enforcementoforganization-wide infrastructure

comes

primarily

by

limiting

what

design

teams

cando with the tools, there isthe potential that

an

inflexible infrastructure can stand in the

way

ofdesigningeffectivesystems. Therefore, while theultimate

power

ofinfrastructuretechnology liesin theability to

widen

asfaraspossible the range ofsolutions

and

approaches thatcan be handled by

infrastructure technology, the actual impact on the

development

process isunclear.

24-One

component

of the infrastructure dimension addresses the skillsto use technology rather than the task ofplanning

and

design.

At

issue is the rangeof support required to help the design aid user learn about

and

utilize the design aid in themost effective

way

possible.

We

define thisdimensionto be thefunctionality to

helpan individual user understand

and

useeffectivelyaplanning

and

design aid.

Table

IF

lists the range offunctionality relating to thisdimension. These

functions range frompassive functionality,e.g., an on-line help function,to describe

parameters ofa function, to proactive functionality that uses

domain knowledge

or

past user behavior patterns to diagnoseor

recommend

appropriate action, e.g., the ability toexplain

why

a particular functionality should be used.

I

Many

characteristics of"userfriendly"systemsincorporate these types ofsupport

functionality. Forexample,

Houghton

and

Wallace (1987)describe a range of

support functions that reflect the range ofskills (expert to novice) of a typical user population. Itshouldbe noted that thegeneral interface technology isnot

incorporated as asupportfunction. Forexample, the use ofa

mouse

or

point-and-click is a feature thataffects the effortnecessaryto exercise a functionality (either physicalormental).

As

such thisaspectofthedesign

environment

shouldbe incorporated into the

measure

ofease ofuse of asetof functions.

2.1.7 Infrastructure:

Standards

Ultimately, the need todevelop

and

sustain an organizational infrastructure

demands

attention to the need for standards.

As

suggested above, standardsofTer the potential both to increase organizational flexibility

and

to limit the creative process ofplanning

and

design. For example,

Lempp

and Lauber

(1988)

have

argued

practice is a strategic concern toorganizations thatdepend

upon

information technology.

A

major functionof the standard

component

functionality isto provide portability ofskills

and

data. Portable skills

and

data will be promoted through standardized relationshipsbetween various activitiesofdesign life cycle.

The

abilityto introduce

simultaneous design processesisenhanced. For example, adopting a standard

structure for representingthe

knowledge

generated in adesign process increases the ability to share this

knowledge

with other teams. Similarly, itprovides a basis to

traindesigners asto

what knowledge

is available

and

how

other teamsfunction.

As

aresult, increased organization performance can be achievedbya given team's

ability to anticipate

when

coordination is required.

I

The

intervieweesgenerated few

examples

offunctionality that couldbe thought

ofasstandards. In general,there isa potential standards issuein

many

of the

elements of the coordination functionality.

However,

during debriefingwith

organizations, the issueofstandards

was

highlighted.

The

discussion ofstandards

functionality often reflected system utilities

and

architectures. Forexample, one

functionality focused on the ability to port

between

technology platforms.

Another

focusedon the ability to function in a highlydistributed environment.

The

issue of the consistency ofthe structure used to store data definitions with the

emerging

standards for a central repository

was

also highlighted.

In essence, the feedback

was

to incorporate a dimension ofdesign aid technology thatreflects a potential to support organization change

and

fiexibility.

As

such

we

define the standards

component

as functionality thatpromotesportability_ofskills,

knowledge, or methodsacross the organization(s).

-26-2.2

Summary

A

finalconcern in the

development

ofthe functionalityitems istheability to

reliably associate a particular functionality with actual

CASE

product.

As

discussed in Section 2, areliability checkresulted in atotalof98functionsformingthe pool

with

which

to define thefunctional dimensiondescribed above. In the following

section, a Q-sorttest usedto

examine

the robustness ofthe proposedmodel is

discussed.

The

testconsists ofgivingindependentexpertsin

CASE

technologythe definitions ofeach

component^

and

asking

them

tosortthe 98 functionsinthese categories.

The

listingoffunctionsby each

component

shown

inTable

lA-lF

isthe result of this Q-sortexercise.

To

the extent that the subjectssortthe functions in the

same

way,

there isevidence that theproposed

model

isameaningful I characterization ofwide range of

CASE

technology.

A

secondtestexaminesthe

extentto

which

the

model

actually discriminates

between

CASE

productsin

an

interesting

and

useful way.

The

followingsection presents the results ofthisQ-sort

and

the application ofthe

model

toevaluate eightcommercially available

CASE

products.

3.0

Evaluating

the

FCTM

The

resultsofthe Q-sorttest are

shown

in the right-hand columnsofTable 1.

A

total of34 subjects (notinvolved in previous

development

ofthismodel)sorted the98

functionalities accordingtothe definition described in Section 2.

The

resultsare tabulatedbased on the categoriesreceivingthe

most

frequent assignments.

^

_As

_{discussed in Section 2.1.7,the standard}

_component

_{resulted from feedback}

Functionalityis listed in orderofdecliningfrequency

among

the 34 subjects.

Each

column

has two

numbers.

The

firstindicates the specific

component most

receiving

most

assignments, the second indicates the percentage ofthe total assignments

followingin thatcomponent.

The

first, second

and

third frequencyare shown. This accounts for almost

100%

of

assignment

inall cases.

A

second aspectofthe

model

canalso be

examined

with thisdata.

Even

if

assignmentsdo not indicate

agreement

asto aprimary component, there

may

be

agreement

atthe

more

general dimensionofproduction, coordination or

infrastructure. Ifthis istrue then there issupportforthatthese

more

general

dimensions

adequately reflectcurrent

CASE

technology.

A

simple chi squaretestis used to testthe hypothesis that assignments are

random.

The

results ofthissimple test in Table 1 can beevaluatedat boththe

component

level, i.e., thesix

component

that

were

usedin the sort,

and

atthe

dimension

level,i.e., production, coordination

and

infrastructure.

At

the

component

level, there are onlytwofunctions for

which

a chi squaretest ofuniformdistribution

isnotrejected (transformation,

#32

and

support, #24).

Although

thisisa

weak

test,

itdoessupport the conclusion that the six

component

dodifiersignificantly.

At

the

dimension

level,seven functionsfailed to reject the testof a

random

assignment.

Again,thissupports the conclusion thatthese dimensionsdiffer.

A

reviewofthe

assignment

pattern is

more

revealing. Forrepresentation, only

nineofthe eighteen items received

more

than

50%

as a primarysort.

However,

as indication inthe

comments

section, five ofthe functionsbelow

50%

appearto

have

consensus as a general production functionality.

The

sorting resultsforanalysis appear

more

consistentwith seventeen of

nineteen function receiving

more

than

50%

primary assignments.

Again

the two

-28-items below SO'To appear to reflecta general production functionality with afairly

uniformdistribution across representation, analysis

and

transformation.

The

transformation

component

haselevenofthirteen functionsexceeding

50%

.

In general the functions appearto be clearlywithin the production dimension.

The

two functions thatare below

50%

is ambiguous. Both functions 47

and

32 failto

rejectthe chi square test at the dimension level,suggesting that there is significant overlap with

between

the production

and

control implications for these functions.

In the control component, twelve ofsixteenfunctionsreceive

more

than

50%

primary

assignments.

The

distribution ofassignmentsuggests a supportofthis

component and

a consensus with respectto a coordination dimension. For the four

functions not receiving

more

than

50%

assignment,

#43

appears toreflecta general |

coordination perspective, while functions83,39

and

7fail to rejectthechi square for differences atthe

dimension

levels.

These

functionsappearto

have

overlap with support

and

analysis, suggestingasignificantlevelofambiguity in the functional description.

The

cooperative functionality

component

receiveonly total ten assignments but nine ofthe ten received

more

than

50%

as a

primary

assignment. In general, these functions appearto reflecta coordination perspectivebutsubjectsdistinguished

them

from

the control component. Function 85 didnot receive

more

than

50%

primary assignment and

also failed torejectthe chi square test at the dimension

level.

The

component shows

significantoverlap with both analysis

and

support.

Finally,the support

component had

22 functionalitieswith only thirteen ofthe 22

receivingprimary assignment. This

component

appearsto be difficult forsubjects to

clearlydifferentiate.

Although

there aresix functionsthat have strong

agreement

as support, the

remaining

functions refiectboth aspects ofproduction

and

coordination .

Two

ofnine functions receivingless than 50'7c primary assignment

fail the chi square test. Function 98fails to reject the test at the dimension level and

function 24 fails to reject at the

weaker component

level test.

The

sortpattern across those assignments with less than

50%

primarysort appearsto reflectsignificant overlap with at leastone otherdimension. These resultssuggest a need to refine the definition forthe supportcomponent.

In

summary,

the sorting results provide supportforeach ofthe

component

concepts.

Only

thirteen ofthe 98 functionsfail to rejectthe chi square test atthe

dimension level or

component

level.

Twenty-seven

functions receive less than

50%

asa primarysort. Again, fourteen ofthese 27 have supportas the firstor second choice, reflecting the difilculty with the definition ofthiscomponent.

Of

the

I

remaining

thirteen functions, six reflect a general production perspective

and

one a general coordination perspective thereby providing additional supportfor the

dimension level concepts.

As

a nextstep in the analysis, the seven

components

are useto

compare

eight

commercially available

CASE

products.

The

comparisonwill be used to determine if the

FCTM

providesa useful tool toevaluate potential

CASE

environments.

3.1

Comparison

of

CASE

Products

In thissection, the

FCTM

is used tocharacterizeeight commercially available

CASE

products.

The

products were selected in

an

attempt tocoverthe full span of the system

development

lifecycle.

The

life cycle

was

divided into three general categories: planning, design

and

construction.

Two

products that appear totarget

each ofthese were selected forcomparison. In addition, two products that purportto

provide integration acrossall three

components

were selected forevaluation.

To

ensure theproducts did infact reflect thesecomponents, 25 experts userswere asked

-30-to indicate the level ofsupport provided by the productfor the seven tasks

shown

in

Table 2. These perceptions supportthe conclusion that the toolsselected for

evaluation both span the life cycle

and

have distinctive product features.

Table

2

Life

Cycle

Coverage

by Products

Product

Design

functionalityon representation while beingrelatively

weak

ontransformation.

Similarly, those products targeting construction provide transformation

functionality

and

are

weaker

on representation.

Secondly,onlyone product providessignificantcoverage forcontrol functionality. Further, all productsare

weak

on cooperative functionality. Thisresultssuggests

thecurrent products

may

have

limited impacton

team

performance issues. This

pointwill be discussed in

more

depth in the nextsection.

Finally,the products do provide supportfunctionalitybutthere is,in fact,

significantvariation across product.

As

we

will discuss, a

more

detailed analysis

shows

there existsgeneral level ofsupportin the form of basichelp

commands

but advanced, intelligentsupportfunctionalityisquite limited. '

The

detail analysisby

component

is

shown

in Table4.

At

this level,one

a

n

compare

functionality across products. For example,in support, thefunctionof

**provideon linehelp"

and

"quick reference to basic

commands"

(#56 and

77) is

generally available acrossthe lifecycle.

More

sophisticated

and

intelligentbased

supportsuch as"the ability to anticipate usermistakes based onpasterrors"(#58) is totally lacking.

A

final observation isreflected in the

summary

total used forTable4. This

row

indicatesthe

number

and

percentage ofthe total possible functionality thatappears

in atleastone product.

The

resultssuggest that claims forintegration

and

coverage by

CASE

productsare at best limited to notions ofproduction technology.

There

is a significant

gap between

possible

and

available functional in coordination, analysis

and

intelligent formsofsupport.

Furthermore

as the detail analysis suggestthe

These

resultssuggestthe

FCTM

isa

meaningful

way

tocharacterize design aid technology.

While

clearly notthe only possible perspective, this

model

doesappear

to reflect a reliable

and

valid

model

for awide range of functionality.

The

model does diflerentiate across products. In the followingsection, the implication foruse ofthis

model

oftechnology to study the impactofI/Splanning

and

design are discussed.

4.0 Implications

and

Future

Research

This research has led tothe

development

of a

model

of

CASE

technologythat has

three general dimensions: production, coordination

and

infrastructure.

The

FCTM

appears to be a useful

mechanism

to assess the range offunctionality available in a

givendesign support environment.

A

more

general issue relates to the implications ofthe

model

forstudying the impactof

CASE

technology on I/Splanning

and

design

teams. Figure 2 provides one

model

thatsuggests

how

the

CASE

may

resultin a

rangeofperformanceimpacts.

Figure

2

Impact

of

Technology on

I/S

Planning

and

Design

and

product quality(e.g., one

measure

often used is

number

ofdefect&'function point).

As

discussed in Section 2, these

measures

reflect a task, perspective

and

may

be associated with only a marginal impact on overall performance in the life cycle.

One

source ofthis limited impact

may

be reflectedby the factthatcurrent toolshave

limited analysis functionality.

The

toolsevaluated in thisresearch reflectpotential

for a broadcoverage ofrepresentation functionality (17/18)

and

transformation

(11/13).

However,

examination ofthese functionssuggesta relatively passive design aidenvironment.

That

is, the functionalityenables a designer to capture

and

present

an

idea orto transform a well defined design concept. Functionality to aid thecritical thinking processes that often constitute a majorcontributionofthe

designerappear to be lacking. Thus,

we

might

expect

emerging

functionality in this

area to

have

a major impact on the efficiency

and

efTectiveness ofindividuals.

At

the

team

level, coordination technologycan help to efYectsynergy

among

teanr

members

(or at leastreduce the loss in productivity often associated with group

interactions)

and

increase the validity of the product.

Synergy

might

occurthrough

both production efficiencies, (as

measured

by increased

number

ofalternatives considered)

and

social/political impactssuch asincreased involvementofkey

organization roles (as

measured

by participation orinfluence in the design process).

The

potential for

an

increased validity arises fromthe ability ofthe design process to

better

meet an

actual organizational need. This hypothesis arguesthat if coordination technology increasesthe ability ofthe

team

to effectively

manage

relationshipswith key stakeholders, this will increase the likelihood that a valid

need(asperceived bythe organization)ismet.

An

important interaction effect between the individuals

and team

levelcan also occur.

The

use ofproduction technology

may

effectively

empower

a key

organizational role orstakeholder by reducing the skill levelor time required to

participate

and

infiuence thedesign process.

As

such, production technology

may

have a significantimpactin that itcan change both the composition ofthe

team and

-36-the

way

in

which

roles on a

team

interrelate. Both ofthese impactshold promise for

significantperformance improvement.

Finally atthe organization level, the ability to use

CASE

technology tobuild an

infrastructure could increase the flexibilityofthe product

development

process

and

enable the organization design products across

teams

tooffera significant

performance impact. Thispotential arises in partfrom the potentialtodecentralize the

knowledge

necessary tocoordinate the activitiesofmultiple teams.

Decentralizingthe coordination

knowledge

requires individual

teams

to

know

or

have

accessto informationabout goals,critical procedures

and

resourceemployedor required

by

a

team

(Durfee, etal. 1987).

The

potential fora

CASE

environmentto

provide access to such

knowledge

via shareddesign

knowledge

bases,throughthe

useofstandardsdesign practices orbycreatingthe

means

totime sharingkey

human

resources across projectsofTers the potential foramajor performance impact.

Of

course,the ability to attribute performance impact to

CASE

technology

becomes

increasingly difilcultasone

moves

from theindividual unitofanalysis to

the organization.

However,

the abilityto

map

usage behaviorofthetechnology to

both individual

and

team

processes suggeststhe use of the

FCTM

may

helptobetter

understand theperformance impactof

CASE

atthese two levels.

The

functions reflecting

an

infrastructure dimension extend the

model

from the

team

to the

organization

and

require furtherrefinementbefore its potentialexplaining organization levelimpacts can be explored.