Managing Labor and Managing Management in a Distributed Online Humanities Project: The H-Net Experience

Managing Labor and Managing Management in a Distributed Online Humanities Project: The H-Net Experience
David Halsted
H-Net is a large online Humanities project with a highly distributed structure. Our 75 academic e-mail lists reach over 54,000 subscribers around the globe, and our Web site was receiving 200,000 hits weekly as of late September 1996. H-Net's lists are edited by 250 volunteer academics from all over the world. Policy is set by the H-Net Executive Committee, which meets primarily by e-mail; the Executive Committee is elected by H-Net editors and staff. Labor, administration, list maintenance and Web site design and maintenance are all centralized at Michigan State University. The H-Net project thus provides an interesting model for large and highly distributed collaborative online projects in the Humanities. It may be a useful example for smaller collaborative projects as well.

H-Net began as a relatively small project in 1993 (three e-mail lists with 500 subscribers and a handful of editors). As we have grown we have had to develop ways of coping with that growth. One major step came in the fall of 1995, when H-Net MSU began to hire a large staff of part-time student workers. This new work force brought a host of new difficulties (payroll, management, supervision, training, etc.), each of which has had to be addressed. In the meantime, the growth of the H-Net editorial community from a few individuals to the current corps of 250 has meant that we have had to develop mechanisms for training editors and providing them with technical help.

Our rapidly-growing subscriber base requires a different form of technical help from the help we offer our editors, and subscribers require the academic equivalent of customer service. Individual projects, such as the H-Net review project and H-Net's Job Guide, require training, staffing, and their own customer service. Finally, the establishment of the Gopher and Web sites, which account for the bulk of our labor costs, has generated new needs in training, supervision and quality control. The Web site in turn generates inquiries from new potential subscribers as well as current H-Net participators, causing us to create yet another level of response to customer concerns.

My paper will briefly summarize the challenges we face and the solutions we have reached, in the hope both of providing an example to others (even if only a negative one) and of learning from other projects. I will discuss the following major areas:

1) Software

To reduce labor costs, we have found that it is crucial to make the best use possible of tracking databases and project management systems. Unlike some other major Humanities computing projects, we write our own software, which reduces upfront costs and increases our ability to customize; however, writing the software places an added burden on our technical staff. It is also important to keep abreast of potentially labor-saving developments in the commercial software world; for example, we are moving to using three or four different programs for different purposes in the mark-up process.

2) Customer Service

Customer service, or the academic equivalent, is a major concern and should be taken very seriously from the beginning of any online project with a potentially large audience, since a large audience will inevitably include a number of "newbies" who will need help to use online resources effectively. Large distributed projects will have to consider providing effective and prompt technical help to customers (like our subscribers) and collaborators (like our editors) alike.

3) Equipment

Every Humanities project with which I am familiar faces considerable challenges when it comes to keeping up equipment. Equipment purchasing and on-going maintenance must be taken into account in planning for labor costs. On-going costs are generated by improvements in technology (students really prefer working on Pentiums to working on 486 machines; next year, no doubt, they'll want Pentium Pros), by the ever-increasing memory demands of contemporary software packages, and by the simple fact that complex, delicate machines used by a number of users just plain break a lot.

4) Training and turnover

Training and turnover in a student workforce are also typical difficulties for online Humanities projects housed in universities. Students who already know what you need them to know can often command much higher salaries off-campus than a Humanities project can muster; students also have an annoying tendency to graduate. This creates an on-going turnover and training problem. Training a workforce is a problem that must be addressed early if student staffers are going to be used. Training for management should also be considered.

5) Decision-making structures

The clearer the hierarchy and the division of decision-making powers is, the better a distributed project will work. My guess is that there will be a certain amount of ambiguity about hierarchy in any collaborative academic project of any size, even where shared enthusiasm generates good will among collaborators. Shared Web-authoring, for example, can lead to conflicts over content, aesthetics, and the exact scope and purpose of a site or sites. Since the vision of what Web sites can do is evolving so rapidly, it may be too much to expect a binding a priori statement for new projects, but a shared sense of vision and some understanding of the division of responsibilities will turn out to be crucial as projects (inevitably) evolve.

.