🚀 go-pugleaf

File 3 of  6

                          Behind the Terminal:
             The Critical Role of Computing Infrastructure
         In Effective Information Systems' Development and Use


                               Rob Kling
             Department of Information and Computer Science
                  Public Policy Research Organization
                        University of California
                            Irvine, Ca 92717
                              714-856-5955
                        email:kling@ics.uci.edu

                               Draft 4.02
                      July 17, 1991 (Aug 4, 1991)

To appear in: Challenges and Strategies for Research in Systems
Development. William Cotterman and James Senn (Ed.). John Wiley,
London.

3.0 THE CASE OF THE DESKTOP COMPUTING RESEARCH PROJECT (DCRP)

Concrete examples can help illustrate key ideas of web analysis.
The following case of computerization to support the work of a
research team illustrates key ideas about the management of
infrastructure. Infrastuctural resources can be developed or
"accepted" from the web of social relations within which a group
works. The nature of available infrastucture should influence key
choices about ways to computerize, but it can also requires
continual attention for effective computer use. This case differs
from many traditional information systems cases since the
research team does not use one major information system. Rather,
they develop and use many small information systems, including
their collections of survey and interview data. And they use
computing for some of their primary tasks, such as writing memos
and papers. They represent a major new style of computerization
in professional work groups with multiple systems used for
diverse activities. The details of this work group differ from
those of many other organizations, in terms of their specific
activities, resources, technologies, and social relationships.
But the case helps illustrate key processes which are relevant to
many computerization projects: the ways that groups can depend
upon others for key resources, the ways that affordable computing
infrastructure helps shape the computing systems adopted, the
ways that resources are negotiated, and the ways that important
commitments become institutionalized.

The Desktop Computing Research Project (DCRP) is a research team
whose subject of inquiry is the ways that computerization alters
work. The DCRP team uses computing for a variety of tasks,
including writing memos and papers, keeping research records,
analyzing extensive survey data from nearly 1000 respondents, and
communicating via electronic mail. Their own use of computing is
the subject of this case.  Even though I am the faculty principal
investigator (PI) of the DCRP, I am reporting the case in the
third person to help create distance between the analysis of
infrastructure and my narrative of this case. Further, this case
is based on substantial observations by other project members and
is not anchored only in my own observations.

The PI initiated the DCRP in 1985 as a longitudinal study of
computerization and changes in work life. The PI holds his
primary faculty appointment in the Department of Information and
Computer Science (ICS). The project is administered by a campus
social science research institute -- Public Policy Research
Organization (PPRO). PPRO provides its research projects with
office space, and recharges for grant management, statistical
computing and secretarial work. PPRO provided much stronger
grants management and liaisons with Federal funders than did ICS,
even though its office services were of comparable quality. The
PI valued PPRO's grants management and was willing to manage the
resulting complexities of working in two organizations which were
in different building complexes and which relied upon conflicting
computing environments.

The project team varied in size between 3 and 8 people during the
six years of its duration. It consists of the PI, between one and
three Research Associates and Assistants (Ras) with bachelors or
masters degrees, several undergraduate assistants (paid and
unpaid), and a part-time office assistant. One important social
characteristic in university-based research teams is the wide
variation in turnover rates.  The PI developed the DCRP along
with one full time research associate who helped define key
research methods during her three and a half years on the team.
Graduate Ras work with the DCRP for two or three years.  The paid
undergraduate staff may work for up to a year, seldom longer;
many have worked for just one or two ten-week terms. The
independent-study students come and go term-by-term;  a few have
remained for two or three terms. The office assistants usually
work on the project for one academic year, although one assistant
stayed for two and a half years.

The other key infrastructural feature of this research team is
the computing expertise of the individual members.  The PI is a
computer scientist;  the RAs have come from both computer science
and social science. More important, the undergraduates and even
some graduates -- accustomed to an individualistic student life
-- vary widely in their abilities to coordinate effectively and
work reliably in the DCRP. The overall computing expertise within
the DCRP is at least equal to that of most research (or business)
work groups. But expertise is not evenly distributed among work
group members.  One staff member is an expert in computer
operating systems and utility programs.  Another is an
experienced applications programmer.  Yet another is proficient
in operating and interpreting the DCRP's statistical package.
Some of the undergraduates have had specialized hardware
maintenance experience.  But the DCRP does not have the luxury of
specialization:  the DCRP's members use most of the applications
software to accomplish their tasks.  Some staff have had to learn
virtually all of the project's software after joining.  Even a
group with significant computing expertise can experience many
subtle complexities and anomalies which add unexpected time and
skill demands to the continuous process of computerization.

3.1 Tasks and Resources

The DCRP's computing equipment and management strategies were
chosen to facilitate its specific mix of tasks with equipment
that the PI could afford in 1985 and which would enable project
staff to work easily at home and their campus offices.

3.1.1 Data Complexity. The central tasks of the DCRP were to
study computerization and changing work by conducting surveys and
ethnographic studies and publishing the results in conferences,
journals, and book chapters. During the study, the DCRP staff
collected a significant amount of interview and survey data,
which was facilitated by the availability of computing, and which
also influenced key patterns of computer use. The complexity of a
research computing environment can be driven by the data required
to conduct a specific project. The DCRP's data environment has
become increasingly complex as the multi-year project has
progressed.  Between 1985 and 1991 the DCRP collected a
substantial body of research data (interviews, surveys, and
article abstracts) and administrative data (site information,
professional mailing lists).

     For example, the first wave of survey data for the
longitudinal survey was stored in a 600KB file containing the
responses of 300 individuals, to a questionnaire with about 200
items.  and a second file which included summary indices of key
measures of computerization and work life.  In the second and
third years (1989 and 1990) the DCRP added similar data sets, for
a total of six master files and numerous derivative files to be
maintained, compared, and analyzed for changes over time.  The
site contact data base grew during the project to accommodate
changing organizations and contacts. It contains information
about 12 organizations, over 40 work groups, over 60 key
individuals, and survey details. It is organized in a database of
12 linked files -- each contains from 10 to 20 separate data
fields and from 50 to 200 individual records. Other DCRP
documents - papers, memos, reports, and correspondence --
multiplied significantly.  The complexity of the DCRP's data
environment is reflected in the project's computing hardware and
software.

3.1.2 Money. The DCRP was funded primarily by grants from a
federal agency and received most of its computing equipment from
the PI's academic department.  The grants provide funds for
personnel, supplies, administration, travel, services, computing
software and computer operations that are needed to conduct
research and to disseminate research results. The PI obtained
most of the DCRP's 8 PCs through funding from his academic
department.  However, he competes with other departmental
research groups for allocation of hardware (through a committee
process), and has negligible control over the mix of resources
procured by the department or the schedule on which they become
available. The DCRP benefitted from the technological tastes of
ICS faculty. Most of them value engineering workstations or Macs,
and the DCRP had little competition in seeking PCs which the
department was allocating to faculty and staff in 1988 and 1989.
But the DCRP has little direct computing support from ICS, since
their computer support staff focus on numerous networked
computers which run Berkeley Unix and (more recently) several
instructional Mac labs. The campus computing facility provides
statistical computing on a DEC VAX minicomputer, but it's use is
relatively expensive.

     The PPRO office can provide some computing services (e.g.,
statistics with SPSS on a dedicated IBM minicomputer and word
processing with Microsoft Word on PCs) but not others (such as
database support for field contacts and abstracts).  These
services would be recharged to the DCRP, and would also require
specific computer file formats to match PPRO's systems.  Finally,
the PI and some RAs privately purchased PCs for  home use that
they utilize for some research tasks.  The DCRP's control over
resource decisions -- especially computing resources -- depends
on the funding source (NSF, ICS, PPRO, or private purchase), the
total budget allocated to computing, and the actual dollar
amounts involved.  Like many groups, the DCRP has much greater
discretion in smaller purchases (e.g., a software package) than
in major ones (such as hardware selection).

3.1.3 Physical Environment. The DCRP's office space was stable,
even though the size of the DCRP's research team has varied.  The
DCRP is administered by a social science research institute --
Public Policy Research Organization (PPRO). PPRO provides its
research projects with office space, and recharges grants for
administration, statistical computing and secretarial work. The
DCRP staff shares a large partitioned office with other research
groups. The DCRP's own small (160 sq. ft.) office is delineated
by modular, movable partitions and is configured for 5 or 6
workers, each of whom has a small desk, a chair, some limited
file and shelf space, and a PC.  Some assets are devoted to
common use:  one table, several file cabinets, and additional
shared computing equipment for specialized applications.  In
contrast, major businesses often provide private space for
workers at the level of the PI and graduate RAs D perhaps over
700 square feet for the present team composition.

     The cramped space  which PPRO allocates for the DCRP's
office has largely determined many other structural conditions of
work life and choice of computing arrangements. The RAs find that
working in the office can be distracting D- especially when
others are in.  Crowding encourages discussion, but reduces the
opportunities for private thought, data analysis, or writing.  As
a result, some of the RAs do much of their analytical work and
writing on PCs at their homes. The PI has a departmental office
(in another building), but no private space in the research area.
Although he could use some of the DCRP's desk space, he has ceded
this to the other project staff and often works at home. In
addition, he set up an additional computer in a second home
office for a part-time office assistant. Given the small research
office and the staff's unpredictable academic schedules,
coordination among team members requires flexibility and
ingenuity.  The PI and RA's use electronic mail daily, frequently
discuss issues via telephone;  frequently share files through a
Sequent mainframe computer; and meet at least once a week in a
project-wide staff meeting.  Managing this environment is an
important element of the DCRP's computing strategy.

3.2 Computerization strategies

     Computerization strategies in a work group are more complex
than simply selecting system components.  They include practices
of controlling access to equipment and data and infrastructure
development (e.g., training, equipment repair) (Kling and Iacono,
1989b).  The preferences of research groups as they develop or
enhance their computing environments may be incompatible or even
mutually exclusive. The PI and key RAs of the DCRP organized
computing in accord with these five preferences:

3.2.1 Cost containment:  Many research managers work within fixed
budgets and cannot recharge their funders when they do more work.
PIs resolve competing demands for their fixed budgets between
items such as staff salaries, supplies, contracted services, and
travel for research or conferences.  Computing resources are
usually subordinate.  Two types of computing expenses must be
balanced:  capital expenditures (i.e., equipment procurement) and
operating expenditures (for computing services, supplies, staff,
etc.).  Funding for capital and operating expenses may each come
from different sources; each source has different restrictions
about how much money can be spent for different categories of
expenses.  The DCRP's operating budget has been a key constraint.
The DCRP has found in-group computing to be more consistent with
its budget than outside sources D- especially in document
preparation and statistical analysis.

     The PI also valued knowing the range of likely expenditures,
as well as their absolute magnitude of expenses.  He found it
difficult to get accurate cost estimates for a variety of tasks
from the local service providers. Further, in a recharge system
with delayed reports, some costs can mount unexpectedly. For
example, student assistants can spend a large fraction of the
annual computing budget during a few fiendish weeks of
statistical analysis, and the bills may not show up for well over
a month. Since the PI wanted to encourage students to experiment
with data analysis and not have to exercise tight control over
detailed analyses, he preferred statistical facilities which had
low marginal costs for additional use. As a result, the DCRP has
continued to develop computing at the cost of some staff time and
infrastructural complexity.

3.2.2 Good technological capabilities: The PI and some of the RAs
had personal preferences for high performance software,
especially to support text processing, statistical analysis and
database management. In addition  the increasing size of data
files lead some staff to desire larger hard disks.  Some analyses
may take an extraordinary amount of time to run on the available
computers, or may be accomplished only with more sophisticated
software.  The staff's desires for advanced technological
capabilities conflicted with their budgetary constraints.

3.2.3  Ease of use and maintenance:  While this value may be
consistent with lower support costs, it may conflict with
technological evolution.  For the DCRP it has implied
standardization in a common "core" of software and hardware for
use by all group members.  This strategy limits the flexibility
of individuals to customize their computing arrangements to
personal tastes.  At the most basic level, "ease of use" may
simply mean getting routine jobs done efficiently.  But some
research tasks D for example, preparing papers with data tables
for final journal submission D may entail work that is far from
"routine."

3.2.4  Accommodating the geographical dispersion of team members
between PPRO, ICS, and their home offices:  Not only has this
arrangement set structural conditions on work life, but it has
strongly influenced the DCRP's selection of computer tools, such
as those which support text processing.

3.2.5  Making the DCRP's computing arrangements congruent with
those of the organizational units with which the team  members
most frequently interact -- PPRO and ICS: Since PPRO and ICS
relied on fundamentally different operating systems and
applications software, compromises were not simple.

     No one of these five criteria dominated in most of the key
choices. But the DCRP found ways to resolve them into generally
coherent computing strategies. The details of this strategy
depended upon the mix of economic, technological, and human
resources available to the research team and the researchers'
tastes.

3.3 Computer Use and Support on the DCRP

     Computerization projects are often dynamic. Their
participants change equipment, the social organization of access
to equipment, data, and computing skills over time. The term
developmental trajectory  denotes "the sequence of ... past
social and technical configurations and the sequence of ...
potential future configurations (Kling and Iacono, 1984:1219)."
The hardware and software used by the DCRP's staff changed over
time (Jewett and Kling, 1991). Moreover, the DCRP's staff
participate in several academic units whose computing
arrangements were also being changed along independent
trajectories. Some key strategies of the DCRP's staff were
negotiated in terms of computing developments on the campus, in
other academic units, and in PPRO (Strauss, 1978).

     In the 1970s the PI and his students computed on a DEC PDP10
mainframe system owned by the university's central academic
computing facility. In the early 1980s, they shifted to a DEC
PDP20 minicomputer operated by ICS. He purchased a PC with his
own funds in 1983, but he and his students continued to use ICS'
DEC PDP20 minicomputer for a substantial fraction of their work
and communication via electronic mail.

     ICS was moving along a developmental trajectory from
reliance on central computers towards a collection of distributed
computers running Unix and linked by ethernet. During the early
1980s, the department acquired DEC Vaxes and other Vax-clones
which used Berkeley Unix. As part of a negotiation to sell a DEC
PDP20 and to help the PI move from it an overloaded DEC VAX/750
minicomputer which ran Berkeley Unix, ICS donated funds for him
to purchase his own microcomputers. The PI selected six PC-XT
clones with 20MB hard disks, dot-matrix printers, and key
software. Apple Macs did not yet have a large suite of varied
application software, and the PC's enabled the PI to build on his
existing expertise. In 1987, the PI purchased a -286 PC clone and
a color monitor with his own funds when he found that relational
databases ran slowly on the XT's.

     Starting in 1988, the ICS department began making -286
clones with EGA monitors which were part of an equipment gift
from a computer vendor sporadically available to the PI. The
staff found their speed more satisfying, even for routine tasks
like word processing. Because computer science faculty preferred
engineering workstations or Mac-IIs, the PI was able to obtain 8
PC/AT clones with little contentiousness in 1989. He gradually
replaced individual computers D- sometimes one at a time and
sometimes in groups. All of the DCRP's machines are PC-AT
compatibles (one with a "-386" processor).  In 1989, the project
modified some of the "-286" machines with additional disk drives
that were "cannibalized" from the XT clones.  In 1990, they again
increased the disk storage capacity of several computers by
swapping for other PCs owned by ICS. At the same time they
upgraded the video displays of a few machines to the "VGA"
standard.

3.3.1 Document writing, formatting, and production

     The DCRP uses software for writing, data analysis, and
record keeping. We could illustrate the way that managing
infrastructure influenced the choice of any of the DCRP's
database or text processing software. We have chosen to focus on
text processing since the issues should be more accessible to
readers. Moreover, many professionals (except perhaps for
lawyers, school teachers, and senior managers) and clerks in the
US use computers to write, so the tasks and issues are now
becoming commonplace.

     A central focus of the DCRP's computer use is preparing
documents such as letters, memos, field notes, scholarly
articles, and questionnaires. Between 1985 and 1990, the DCRP
made substantial changes in the capabilities for producing
documents.  Between 1985 and 1988, the project staff drafted and
edited documents on PCs and printed most of their drafts on dot
matrix printers owned by the project. The PI formatted final
drafts for many of the DCRP's publications on a laser printer
owned by ICS. After 1988, the DCRP staff found ways to make laser
printing more accessible for a wider variety of memos and article
drafts.

     Laser printed papers became increasingly common in the
DCRP's research world. The project staff had three major
strategies for producing laser quality documents, such as
questionnaires for surveys and papers for professional
distribution. One strategy was to subcontract the final stages of
editing and printing to PPRO's office staff. They gave their text
files (on floppy disk) formatted in the DCRP's word processing
formats (e.g.,  PC-Write until mid-1988, and then WordPerfect
5.x).  PPRO staff translated these files into their word
processors format (Microsoft Word) and then reformatted them.
PPRO administrators continually encouraged DCRP to use their
staff for office services.

     But project staff found continual annoying problems. Since
DCRP and PPRO's text-processing group had incompatible word
processor formats, the project staff faced costly and tedious
reformatting when they wanted to "take a document back" after
passing it to them or they were faced with having the PPRO staff
recharge the project staff for all subsequent revisions. Further,
the PPRO staff were reluctant to purchase a word processing
conversion package that would translate files between PC-Write
and MS-Word or between WordPerfect 5.x and MS Word. This was a
particular problem with documents which were revised in several
discrete rounds of review, such as journal articles.

     In addition, the DCRP staff sometimes found turnaround time
to be excessive. New errors often crept into revisions of data
tables, requiring additional auditing.  But the most important
problem, in their view, was the high overall cost of PPRO's
production services.  The DCRP's interest in cost containment led
the PI and RAs to seek alternative ways to laser print complex
documents, such as journal articles and questionnaires.

     A second strategy was to print on an Image laser printer in
the ICS Department.  This solution involved a different set of
dilemmas. The laser printers were driven by a complex,
command-driven mainframe-based formatter (Tex or troff). Computer
scientists often prefer formatters like these because they allow
fine control over document layouts, support the printing of
complex mathematical equations, and are customizable. But they
also require significant time to learn and a taste for
programming; documents formatted with them can be easily garbled
with a misplaced character. The PI developed good skills in using
Tex, even though Tex's use was doubly cumbersome.  Once a
document was modified to include Tex's special commands and
delimiters, these would appear mixed into the document if it was
printed with the DCRP's PC-based text processors. The DCRP's
senior research associate at the time was reluctant to spend time
mastering Tex.  Because she wrote at home, she had no consultant
readily available to help with Tex's idiosyncrasies.  Worse, she
had no way to preview the effects of the formatting commands that
were embedded in a document.  In occasionally using Tex, she made
many trips back and forth between the on-campus printer (to pick
up output) and the office or home (to fix problems in the
output).

     The DCRP's third strategy before 1988 was to use a PC-based
print enhancement program, Lettrix, to refine the visual quality
of the dot-matrix printouts. It worked with the DCRP's primary
text editor (PC-Write 2.x) and could be used at any of the DCRP's
locations. However, it was painfully slow for long documents,
since it could take well over three minutes to print each page
(e.g., two hours to print a manuscript as long as this chapter).
Moreover, since PC-Write occasionally misformatted footnotes when
it was used with Lettrix, the PI and key RA's spent some grueling
hours reformatting and reprinting long papers close to
publication deadlines. Lettrix helped the staff use PC-Write to
produce more professional looking documents on a dot matrix
printer, but it was far from "what you get is what you expect."

     The capabilities of PC-based word processors have
continually improved, and by 1987 some of the technically most
capable word processors began to include better capabilities for
handling footnotes than the word processor (PC-Write 2.7) used by
the DCRP. A key advantage of PC-Write was that it was very fast
in response time on any of the DCRP's 8088-based PC's, including
two with floppy disk drives. In 1987, the PI replaced these
floppy drives with 20MB hard disks and made a wide variety of
somewhat slower but more powerful word processors more
attractive.  The PI directed  a team of students in exploring the
possibility of shifting to one of two major word processors:
Microsoft Word 3.x and WordPerfect 4.x. The DCRP staff did not
see adequate advantages to either one. In 1988, WordPerfect 5.0
was enhanced with new features which allowed formatted documents
to be previewed on screen at any of the DCRP's locations, and to
generate Postscript files which could drive ICS' laser printers
without resorting to Tex. While PPRO's office staff continued to
use Microsoft Word, the advantages of previewing and simplified
laser printing at ICS were major incentives for changing. The PI
also found the newest version of Microsoft Word to be clumsier
for some key operations, even though it was a powerful and
popular package.

     The combination of the DCRP's new word processor (with
preview capability) and new Postscript compatibility for ICS
laser printer enabled the project staff to significantly reduce
their trips to ICS to preview laser printed documents. But the
DCRP staff could still not eliminate all trips to ICS. They
experimented with using a laser printer used by PPRO's office
staff which accepted Postscript files. PPRO wanted the project
staff to give them files to print and to recharge both labor time
and equipment use. The DCRP staff wanted to use it as a walk-up
self-service with charges for equipment use, akin to the
photocopier. Moreover, the DCRP staff wanted to be able to use
their own word processor on one of PPRO's PCs to make quick
changes to documents if there were unexpected formatting
problems. However, PPRO's office staff had their
postscript-compatible laser printer located inside their carrels
and attached to PCs and Macs which they used for ongoing work.
The PPRO staff was moving to Macs, and shifting the printer back
and forth between PCs and Macs required rebooting some systems.
Consequently, they found the DCRP's attempts at self-service to
be intrusive, and the DCRP staff were barred from continuing.

     In the summer of 1989, the PI negotiated with the ICS
department for two Hewlett Packard laser printers (in exchange
for a complex administrative assignment). During the first year
with the laser printers, some staff became seduced by strategies
to improve their usefulness.  When DCRP staff used ICS' laser
printer with Postscript output, the PI became used to the
flexibility of arbitrary font sizes (e.g., 11.2 point). Some
undergraduate students and one of the graduate research
associates spent substantial time working to create a larger
selection of font sizes than are provided by cartridges through
the use of soft fonts. Some of the staff spend time "tweaking"
the output based on new capabilities:  would the headings look
better in bold-face or italics? ... or maybe large print or a
different type face? ... can the DCRP staff meet a page count
with 12-point or 11-point type, or should it be 11.5 point? ...
maybe a little more or less spacing between the lines? ... how
about adding a border around the tables? ... ad infinitum.  It's
fun, seductive D and can take several hours more than planned.

     Increasing computer capabilities gave the project staff a
great deal of control over the final appearance of documents, and
enabled the project staff to meet page limits and format
specifications for conference and journal submissions quickly
with minimal marginal expenditures.

3.3.2 Staff Training

     All of the staff who work on the DCRP arrive with some sort
of computing skills. Many of the graduate students and
undergraduates own PCs. Even so, when they join the project, they
usually do not know the suite of application software, and
usually they aren't sufficiently sophisticated to easily manage
the complex array of project files.  For example, the DCRP
maintains dozens of different kinds of manuscripts,  memos,
databases, and charts in a myriad of topical subdirectories. Most
undergraduate students use subdirectories very crudely since they
usually manage a few papers and write a few programs.
Consequently we often have to teach them more sophisticated ways
to manage and catalog complex sets of files, as well as the use
of software to help manage a complex disk organization.

     The DCRP staff teach research substance and process in the
course of the work. But the DCRP staff also teach a significant
body of computer skills to new members. The undergraduates -D
upper-division computer science majors -D often require extensive
training in the specific software. They also require training in
practical procedures to effectively manage software and data in a
group setting -- such as carefully labeling diskettes and
informing others about ways that they reconfigure PCs.

     The project ability to develop infrastructure is limited by
its size, budget, and the many competing time demands. The DCRP
staff design jobs around the available staff, rather than trying
to force-fit individuals into duties for which they are
ill-equipped or in which they have little interest.  The result
is a pooling of expertise which emphasizes complementary skills
and cooperative effort; the DCRP staff help each other.  The DCRP
staff can usually find a group member who has encountered a
problem before.  It may take a phone call or an email message, or
it may have to wait until the weekly meeting, but there is
usually an answer available.

     The DCRP staff also maintain an extensive library of
software documentation:  vendors' manuals, third-party tutorials
on the major programs, and about 120 pages in six tutorial
manuals in which the DCRP staff have characterized their key
software and procedures.  The simple availability of these
references is not sufficient: staff members must read them and
have the skills to understand them. Project members vary in their
diligence in reading the documents. Refining these customized
manuals involves a tradeoff:  staff time to write and update them
versus learning time saved for new group members (or learning
time available to read them).

     The DCRP staff try to adopt software for which there are
good books sold by trade publishers. This makes it easy for
undergraduate student assistants to buy instruction manuals and
to learn the software with less administrative complexity. In
particular, there are numerous books for the DCRP's primary word
processor and relational data base.

     Finally, the DCRP staff use informal one-on-one training,
conducted by either the PI or one of the senior RAs.  At best,
individualized tutorials allow the project staff to tailor
training to the specific needs of each individual.  At worst, the
time the DCRP staff invest in new undergraduates might not pay
off, if their class schedules and outside work commitments limit
the time they can devote to this research project.

     In order to contain costs, the DCRP staff try to maintain
their own hardware and to perform minor upgrades, when it is
possible. Some changes may require internal modifications to the
computer (e.g., adding boards or wiring, resetting switches), and
not all users will be willing or equipped to undertake these
tasks themselves.  The DCRP staff usually evaluate the potential
gains of an upgrade against the direct expenses and the likely
staff time required to fiddle with equipment. But even seemingly
straightforward modifications can involve unexpected work.

     Learning and competence building are continuous processes
for all the DCRP staff for several different reasons. It takes
most staff about 3 months to have adequate competence in the word
processor, database,  analytical packages and utilities which
they use for their primary tasks. The undergraduate students are
often exploring new software, and some of their experiments lead
to adoptions. The DCRP usually upgrades key software to be able
to exploit new features, and the upgrades involve some new
learning. Periodically, the staff finds system anomalies, and
debugging them often leads to some new minor skills. Finally,
staff who are more experienced in a particular package are often
advising less experienced staff, and both learn in these
interactions..

3.3.3  Computer system administration

     Maintaining compatible configurations on all of the eight
DCRP PCs is not a trivial task.  The DCRP staff rely on an ICS
undergraduate "system administrator" to provide support for the
computing milieu in exchange for special study course credit.
Designing this job is a delicate balance so that it has
legitimate academic learning value to the students and also helps
leverage PI and RA time. This student normally devotes about ten
hours per week to these activities, and works under the
supervision of a graduate RA from ICS or the PI.  Most system
administrators have worked for the project staff for two
quarters, since it takes them much of one quarter to effectively
learn the computing environment. Occasionally the DCRP staff have
two students working together.  Other project staff provide
varying kinds of computer support (e.g., training) depending on
their interests, time, and skills. The PI channels key support
activities, such as exploring new software, installing upgraded
software, performing routine maintenance and repairs to the
unpaid undergraduate assistants. It is doubtful that the strategy
of computerization examined here would have been effective
without the availability of skilled undergraduates.

     Support is the hidden soft underbelly of computerization.
The DCRP staff have estimated the overall time required for
computer support and maintenance within the DCRP to be in the
range of 700-850 hours per year.  This estimate assumes one
undergraduate per quarter (350-400 hours/year), 5-7 hours per
week of RA time (250-350 hours/year), and 2 hour per week of PI
time (100 hours/year) D and these figures seem very conservative.
The distribution of hours may vary depending on the available
staff.  A skilled undergraduate with a high level of personal
initiative will reduce the time that graduate RAs spend on
computing support tasks.  In turn, a graduate RA with
well-developed computer skills and interests can perform many
support and supervisory tasks that would otherwise fall to the
PI.  The total time which all staff members devote to the project
is approximately 5000 hours/year.  Therefore, computing support
consumes at least 15% of the DCRP's time budget -- a significant
commitment.