Abstract
Scholars and practitioners of the digital humanities generally recognize the
importance of solid project management and oversight. But coursework and publications
related to DH project management tend to focus heavily on the difficulties of
planning and launching a new project rather than the challenges of maintaining an
established one. Meanwhile, online advice for would-be managers is couched in the
language of “tips and tricks” or “steps for
beginners”. Together these phenomena downplay the professional skills
needed to successfully manage a project while suggesting that project management is
necessary only in the beginning stages of an endeavor. They may even give the
impression that scholarship in the digital humanities is inherently ephemeral.
Through a case study of project management practices at the William Blake Archive,
which began publishing electronic scholarly editions in 1996, this essay details the
challenges and rewards of managing an established digital humanities project.
Managers of mature projects may be called upon to oversee expansions in scope and
mission, research and recommend new features and tools, grow or shrink the number of
project staff, seek out alternate sources of support when early grants run out,
maintain continuity as collaborators join and leave the project, and develop new
workflows and procedures to reflect these and other changes.
Introduction
When project management principles are made explicit among digital humanists, they
are often presented with little project-specific grounding and usually from a
beginner’s perspective. At THATCamp sessions, summer institutes, and other meetings
of scholars working in or intrigued by the digital humanities, audiences are offered
“basic principles,”
“tips and tricks,” or “top-ten lists” that give the impression that project
management is a) simple and b) primarily a problem at the early stages of a project.
Most of the roundtables, seminars, forums, and blog posts devoted to digital
humanities project management, such as Bethany Nowviskie’s “Ten
Rules for Humanities Scholars New to Project Management,” Brian Croxall’s
“12 Basic Principles of Project Management,” and Sharon
M. Leon’s more extensive “Project Management for
Humanists,” are concerned with how to plan and launch a new project rather
than how to guide an ongoing one. The various “PM boot camps” that appear on the
programs of THATCamps and DH conferences (or traditional humanities conferences
hoping to attract a DH crowd) also usually operate on the assumption that
participants are launching new projects and that they bring to the table little or no
prior project management experience.
[1] Even intensive
seminars like those offered at various summer and winter institutes tend to focus
heavily on project planning rather than project management.
[2] Meanwhile, scholars and collaborators involved in
ongoing DH endeavors find that many of the questions raised by these articles and
seminars have long since been answered, while the challenges of managing a project
that is well past the planning stages go largely undiscussed.
While these “just for beginners” offerings perhaps reflect the recent surge in
attention and popularity experienced by the digital humanities — many scholars are
newly interested in launching digital humanities projects and will need at least
rudimentary management skills in order to do so — they can also give the mistaken
impression that digital humanities projects are inherently disposable: that long-term
project management is unnecessary because creating a project is more important than
developing or sustaining it. This impression, in turn, contributes to the phenomenon
that Nowviskie has characterized as the “Eternal
September” of the digital humanities: the sense among those just coming to
DH that “all of this is new and… that the
current scene is all there is”
[
Nowviskie 2012a]. But funding agencies that support digital humanities scholarship appear to be
moving away from models based on project proliferation and ephemerality and toward an
emphasis on preservation and permanence — at least of data, if not of entire
projects.
[3]
The NEH Office of Digital Humanities’ decision to require a data management plan from
all potential grantees, for instance, will likely encourage scholars building digital
projects to consider more deeply the eventual fate of their work.
[4] While not every project
needs to last forever, some funding agencies may soon begin insisting on the
long-term sustainability of projects as a condition of their funding, making the
question of how to maintain and manage an ongoing project a more urgent one.
[5]
This article seeks to fill a gap in scholarly discussions of project management for
the digital humanities by discussing the challenges, not of launching a new project,
but of managing a mature one. It does so through a case study of project management
activities at the William Blake Archive, one of the longest-running digital
humanities projects in existence. The Blake Archive, launched in 1993 at the
University of Virginia’s Institute for Advanced Technology in the Humanities,
published its first digital scholarly editions in 1996 and now includes over 120
electronic editions of works by William Blake.
[6] As Project Manager of this ongoing and actively publishing
digital archive,
[7] I will offer insights into the challenges of
managing a digital humanities project that is approaching its twentieth year. These
challenges differ significantly from those of launching a new project but should
nevertheless be considered by scholars just beginning their DH endeavors. I begin
with a discussion of the important but sometimes hidden role that project management
skills play in successful DH projects, and then follow with a set of general
observations about managing mature projects, illustrated with specific examples from
recent activities at the Blake Archive.
Making the Implicit Explicit: Project Management for the Digital Humanities
Project management is often described as a “soft skill” and placed in opposition
to — or in competition for scarce resources with — the “hard skills” of
programming and software development. In a 2012
DH
Answers discussion on “Founding staff for a new DH
Center,” for instance, several discussants asserted that a project manager
is a relatively low-priority hire for a new DH initiative; one respondent asserted
that because “most academics already have
experience managing projects,” programmers and developers should be hired
first and a manager only later [
ACH 2013]. Early Project Bamboo
documentation refers to best practices for project management as “the softest kinds of standards,” placing them
behind “domain-specific technical
standards” in terms of importance [
Bamboo 2013b].
[8] The distinction between “hard” and
“soft” skills or standards imports a number of unfortunate connotations; a
better formulation might center on the difference between explicit and implicit
skills. While a new hire or graduate student’s mastery of a programming language can
be codified in certifications or a portfolio of existing projects, it is much more
difficult to test for the capabilities — including organization, planning and
follow-through, prioritization, grant administration, human resources management, and
conflict resolution — that are essential in a project manager. If you want to assess
someone’s technical skills, you can always invite them to a hack-a-thon. There is no
such thing as a manage-a-thon.
As a position defined, in most cases, largely in terms of implicit skills, project
management can be usefully placed in a category with those forms of “material
labor” defined by Helen Burgess and Jeanne Hamming that encompass
both physical movement and the kinds of
“material” actions necessary to provide an infrastructure for digital
media. On an immediate level, these actions can be thought of as a nodal network
of bodies and machines in which machines combine with humans to
perform tasks…. In addition, we have the even wider infrastructural support
necessary for producing such media objects: the institutional search for grants,
the subvention of copyright clearances, the securing of financial support for and
mentoring of graduate students, and [the coordination of] technical assistance
provided by, variously, presses, contract programmers, videographers, and
animators. [Burgess and Hamming 2013, par. 8]
Such skills and activities are generally understood, Burgess and Hamming note, as
related to the form of a project rather than its content, and thus are often
overlooked or even denigrated under scholarly models that elevate content (writing
about new media) over form (the production of new
media). The importance of project management for digital humanities scholarship thus
risks demotion on several fronts: because project management skills fall under the
heading of neither subject matter expertise nor technical expertise — both much more
explicit and quantifiable modes of knowledge than the implicit skills of project
management — they often go unexamined, and because they primarily affect the form
rather than the content of a project, they can be underappreciated according to
traditional evaluative models for scholarly work.
But it is precisely those practices and standards that are most hidden from immediate
view — those considered to be implicit, assumed, or already mastered — that should be
most assiduously excavated and explored by scholars wishing to further the
collaborative work of the digital humanities. This is perhaps especially true when
the tasks of project management are performed, not by a professional hired
specifically for the purpose, but by a project’s principal investigator or by
programmers or developers who are expected to manage themselves. Making explicit the
tasks and aptitudes required for good project management can help to reduce the
frustration felt by principal investigators or developers who find themselves
unexpectedly occupied with organizational tasks and stakeholder relationships that
seemingly have little to do with researching content or writing code. Once these
implicit tasks and expectations are made explicit, it becomes easier to recognize how
indispensable they are, whether a team has one member or 100.
Managing an Established DH Project: Observations from the William Blake
Archive
In the following subsections I offer some general principles, gleaned from my work at
the William Blake Archive, that demonstrate how the management of a mature and
ongoing project differs from that of a newly established one. While these principles
may not apply to all established projects — there is considerable difference, for
instance, between maintaining a static project that is still in existence but no
longer being actively developed and one that, like the Archive, is still growing and
changing — I believe they can provide guidance to project managers (as well as
content providers, developers, and other collaborators) who have moved beyond the
planning stage and are anticipating a long relationship with their ongoing
project.
Questions of Ontology and Epistemology Never Go Away
Good digital scholarship, like good analog scholarship, will never be finished.
This does not simply mean that digital projects will always need upgrading (though
that will certainly be the case).
[9] It means that a project’s ways
of being and knowing will be subjected to constant scrutiny as time goes on and
new data are incorporated. At a 2012 roundtable on digital humanities and digital
pedagogy at the conference for C19: The Society of Nineteenth-Century
Americanists, Kenneth Price raised the question of how scholars “know” their
subjects. Speaking of the challenges facing the Walt Whitman Archive as its
editors encounter objects like Whitman’s grocery lists or, even more
problematically, letters and official correspondence transcribed by Whitman but
composed by others, Price wondered, who is the Whitman we “know” in the
context of the Whitman Archive? Is it Whitman’s handwriting? Whitman’s mind?
I would argue that such questions, about how we know our subjects, are endemic to
ongoing digital humanities projects, whether those projects archive a particular
author’s works, transcribe and translate ancient documents, investigate and
represent geospatial data, or comb through massive textual corpora. “Knowing” is not the outcome of scholarly endeavors; it is
a process that is furthered collaboratively by members of a project team (and by
its users), and that process will continue and change for as long as the project
survives.
At the Blake Archive, the Blake that we know is Blake-as-craftsman. The Archive’s
earliest publications sought to make available to scholars digital editions that
would reflect the unique artistic processes that Blake used to create his
illuminated books, and so our most basic ontological units are the
work, the
copy, and the
object:
art-historical terms that, in the case of Blake’s work, exist on a kind of sliding
scale from the theoretical to the material.
[10] The
work is largely an editorial concept:
The Marriage of Heaven and Hell, for instance, is
a work by Blake that we, as editors and readers, recognize only by virtue of the
nine complete and individually printed
copies in existence. Each of
these copies is made up of twenty-seven
objects printed on paper from
a set of copper plates and arranged in an order that need not remain consistent
among copies. (There are also three additional copies of the
Marriage consisting of only three or four objects each.) The texts and
images that make up each of these objects can also vary greatly depending on
whether and how Blake inked each of the copper plates, what colors he used, and
whether he added or altered the objects with pen or wash after printing. In other
words, there is no definitive copy or edition of the work known as
The Marriage of Heaven and Hell.
Confusing as this may seem, in an illuminated book the distinction between the
work, the copy, and the object is actually relatively clear, and is represented
hierarchically in the Archive’s three-level structure, in which users progress via
hyperlink from a list of Blake’s works, to a list of available copies of a
particular work (The Songs of Innocence and of
Experience, for example), to a list of objects in a particular copy
(such as copy Z), and finally to an individual object (say, “Infant Joy”). But these ontological distinctions have become less
obvious as the Archive has begun acquiring and publishing Blake’s works in other
media, including engravings, watercolors, tempera paintings, manuscripts, and
letters. A watercolor drawing such as “The Great Red Dragon
and the Woman Clothed with the Sun,” for instance, is a one-of-a-kind
creation in which the work, the copy, and the object are one and the same; Blake’s
notebook, in which he sketched preliminary drawings and drafted verse and prose,
is a manuscript work that exists in only one copy made up of multiple objects. The
matter of ontology extends to every aspect of the Archive’s design, from
individual object view pages to our main index: since the Archive’s basic
organizing principle is the medium of the work in question, image filenames
include designators like “WC” for watercolor and “MS” for manuscript,
and the site’s table of contents is arranged by medium, with illuminated books
followed by commercial book illustrations, then separate prints, then drawings and
paintings, then manuscripts and typographic works. Under such conditions, issues
of classification and organization must be perpetually renegotiated: how, for
instance, should we classify a book of poetry composed by Blake, printed for him
by others, and then emended in Blake’s hand? Is this a typographic edition or a
manuscript?
Questions of classification are, of course, intimately related to problems of
presentation and display: “one needs to balance the goals of
correctness against the practical exigencies of the system and its
users”
[
Ramsay 2004]. At the Archive the problem of classification drove the development of a
new “Related Works” feature that links objects in
different media across wings of the Archive. Every new digital edition published
in the Archive (a set of watercolor drawings, for instance, or Blake’s engraved
illustrations to a commercially published book) includes a list of works related
to the newly published work. In the early years of the Archive these lists,
generated by the editors, often included works illustrating texts by the same
author, so that, for instance, every one of Blake’s watercolors illustrating one
of Milton’s texts was considered “related” to every other watercolor
illustrating Milton. But when Archive staff began building a tool that would
actually link related works within the Archive (rather than just listing them for
users to seek out on their own), we began to question this bibliographic
definition of “relatedness” and its epistemological implications for our
project. Were Blake’s watercolor illustrations to Milton’s
Comus, commissioned by Joseph Thomas in 1801, “related” to the
designs for
Paradise Regained, completed no earlier
than 1816, by virtue of anything other than Milton’s authorship? And if “texts
by the same author” was a valid definition of “relatedness” for the
Archive’s purposes, then was every one of Blake’s illustrations of the Bible
“related” to every other one — with God understood as
“author”?
[11]
Unsurprisingly, the conclusion we eventually came to brought us back to the
project’s original vision of Blake-as-craftsman: within the context of the
Archive, works are now considered “related” if they are part of the same
production sequence — a material definition of “relatedness” that reflects
Blake’s unique creative processes. By the Archive’s standards, then, objects are
related if they represent different stages in the creation of a
work.
[12] Thus, the monochrome wash
drawings that Blake produced for his influential illustrations to
The Pastorals of Virgil (1821) are related to the wood
engravings published in that book because they represent earlier stages in Blake’s
artistic process.
[13]
Further disambiguation of the term “related” has recently led Archive staff
to create another, similar feature: “Supplemental
Views.” This category contains additional photography of an object,
showing, for instance, the entire leaf on which an impression was printed. “Supplemental Views” are distinguished from “Related Works” because they refer not so much to the
Blakean object itself but to the digital reproduction of the Blakean object — they
offer a second, somewhat different photographic representation of the same
physical object. Hence their classification as “Supplemental
Views
” rather than “Related Works
” — work, in Archive nomenclature, being a term reserved for
creative productions by Blake or his contemporaries.
This kind of thematic linking goes against the grain of current web development
trends, which favor dynamically-generated links created in response to the
behavior of users rather than the exigencies of content. As Brent Nelson and Jon
Bath note, a static-linking system based on principles inherent to content and
subject matter “requires editorial direction and is
thus inherently biased and selective rather than (potentially) exhaustive:
it is fixed and non-generative. For this reason, it is also necessarily
labour-intensive”
[
Nelson and Bath 2012, par. 21]. In the case of the Blake Archive, links between Related Works represent
technologically the collective knowledge of Archive editors and staff, who decide
before each publication which works are related to the new publication and in what
way they are related. Related Works links are thus “declarative about the nature of their linkage. Each link
indicates the nature of its target” by virtue of its inclusion in the
Related Works menu [
Nelson and Bath 2012, par. 14].
[14] This feature is entirely in keeping with the scholarly
principles of the Archive, where relatedness is defined as an attribute of
artistic objects and their place in historical production processes. But the
Related Works feature is meant to supplement rather than to replace the
user-generated connections enabled by other tools in the Archive. Users seeking
works related to one another by virtue of a particular textual or visual motif
rather than by their place in Blake’s production processes can employ the
Archive’s search engines and Virtual Lightbox (a basic image editor) to find and
collect, for instance, textual mentions of the pope or images that include the
mythical figure of Comus. Such searches are not bound by the Archive’s own
standards for relatedness, but are left to the user’s discretion.
There is a Fine Line between Scope Creep and Scope Change
New and early-stage projects are often plagued with the problem of “scope
creep,” a phenomenon in which a manageable and fairly well delineated
project is derailed because the primary stakeholders cannot or will not limit
their ideas of what the project will be: as team members with varying levels of
technical knowledge and content expertise envision all of the directions a project
could take, they can find themselves going everywhere and nowhere
at once. In the beginning stages of a project, one of the project manager’s major
duties — and the reason why they sometimes come across as spoilsports — is
preventing scope creep by holding the team to agreed upon project parameters. For
this reason, “project management for beginners” articles often emphasize the
importance of setting realistic goals and limiting a project’s early ambitions.
But projects that are ten or twelve years along are less likely to suffer from
scope creep than those in the beginning stages. If a project’s founders did their
jobs well (and if a project is functioning productively after a decade, the
chances are good that they did), by this point team members and collaborators
probably have a realistic understanding of the task at hand. Once a team has
mastered the primary functions of a project and brought it beyond the planning
stages, widening the project’s scope becomes the next logical step in its
development. At this point, a project manager’s priorities shift from preventing
unwanted change to facilitating productive growth.
At the William Blake Archive the project team has recently made a move to widen
the scope of our endeavor by adding to our database 40 years of back issues of
Blake/An Illustrated Quarterly, the journal of
record in Blake studies.
[15] The
Blake Archive has been publishing digital editions of Blake’s work for sixteen
years; its publication processes have been relatively stable over that time,
though they have been adapted somewhat to reflect both changing technology and the
nature of Blake’s work. (The Archive is designed such that a publication process
that works flawlessly for an illuminated book will require tweaking for a
manuscript or watercolor.) The decision to incorporate searchable back issues of
BIQ came about not only in response to changing
paradigms of scholarly publishing, with many major journals now available in
digital form, but as a way of maximizing the Archive’s existing assets. As back
issues of
BIQ are scanned, transcribed, and marked up
for inclusion in the Archive, images that appeared as halftones in the print
edition are being replaced, whenever possible, with the same high-resolution
color-corrected JPEGs that make up the Archive’s digital editions. Thus, scholars
reading Eugenie R. Freed’s article from the Winter 1998 issue of
BIQ on the Christian symbolism in plate 78 of Blake’s
illuminated book
Jerusalem will see a full-color
inline illustration of plate 78 and can also access the Archive’s digital edition
of
Jerusalem copy E (consisting of 100 objects in
all) with one click.
[16] Once this new resource is made available the Blake Archive will contain
over forty years of
BIQs history, making the Archive
the premier source, not only for high-quality digital editions of Blake’s work,
but for scholarly commentary on that work. The incorporation of
BIQ represents scope change of the best kind: a
manageable improvement that was perhaps not foreseen by the Archive’s founders,
but which aligns with the primary goal of the Archive — to make Blake’s work, and
excellent scholarship about it, available free of charge to as wide an audience as
possible — and thus enhances the project’s scholarly value.
But while “scope creep” is less a problem to be avoided than a fact of life
for older projects, “feature creep” — the wish to make existing tools perform
more and more functions, just because they can — can be a major source of
contention in ongoing projects. While the manager of a new project can often nip
feature creep in the bud by appealing to time, staff, or budget constraints — the
“let’s just get this up and running and then we’ll see”
strategy — a digital project that is humming along happily is rife with
opportunities for tinkering. Add to this what I call the “educator
imperative” — the wish, common among academics, to give users/readers as
much information as possible — and project managers may find themselves fighting
the notion that because an existing tool could do something — and
because making it do so is neither prohibitively difficult nor particularly
expensive — it definitely should do that thing.
As with scope change, feature change is sometimes a logical outcome of a project’s
continued mission: tools that were designed to do only one thing in the early days
of a project may grow more complex as that project fulfills its early goals and
develops in new directions. The Blake Archive’s Compare feature, for instance, was
built to automatically display objects in the illuminated books that were printed
from the same copper plate, regardless of the order in which they appear in
individual copies; it does so automatically based on the bibliographic information
included in our XML BADs.
[17] Clicking on “Compare” beneath any impression of “The Ancient of Days” (object 1 in most copies of
Europe a Prophecy), for instance, opens a window that
displays every impression of the plate that is currently available in the Archive.
Over the years, as the Archive moved from publishing only Blake’s illuminated
books to his works in other media as well, Archive staff realized that objects in
different media would not automatically display in the Compare window. In response
to this situation the Archive’s Technical Editor, Will Shaw, revised the Compare
code to allow for manual inclusion of objects in different media. In the image
below, for instance, objects from
The Small Book of
Designs (a series of separate plates) appear alongside corresponding
images from
The Book of Urizen and
Visions of the Daughters of Albion (both illuminated
books). Like the integration of
BIQ (though on a much
smaller scale), this change reflected the logical development of an existing tool
rather than feature creep run amok.
In many cases, however, feature creep reflects, not the logical expansion of an
existing tool, but a kind of techno-utopianism (often felt most strongly by those
team members least responsible for coding and programming) that, if allowed free
rein, can quickly lead to unnecessary redundancy. At the Archive, the danger of
feature creep is that every tool will be expected to do everything: the Compare
feature, the Virtual Lightbox, the Related Works feature, and any number of other
tools would all perform the same functions, leading to confusion for users and
frustration for technical staff. As Morris Eaves has argued elsewhere, tools in
the Blake Archive should not do the work of scholarship
for the user,
but should instead enable users “to make useful things for themselves. With tools,
applied to the primary textual and pictorial materials, users construct the
contexts most relevant to their purposes” [
Eaves 2006].
[18] Will Shaw, now Digital
Humanities Technology Consultant at Duke University, notes that “containing feature creep is simply good
software development practice; smaller tools load faster and may be more
responsive to user input [while] multipurpose tools are almost certainly
larger and possibly less efficient from a computational standpoint, not to
mention that they can be unwieldy for users”
[
Shaw 2012].
[19] As new software
development tools and web technologies emerge, project managers must work with
programmers and content providers to determine which new features and tools will
support the project’s mission and which will create unnecessary redundancies or
tie up resources that might be better employed elsewhere. And they must make these
decisions with an eye both to the project’s past progress and to its future
growth.
Revision Gets Harder Rather than Easier
In the planning stages of a digital humanities project collaborators must
constantly be sibyls: they must consider every decision in light of what it means
now as well as what it will mean for the future of the project. In the advanced
stages of a digital humanities project team members must constantly be Januses,
looking both forward — “how will this affect everything we want to do from now
on?” — and backward: “how will this affect what we have already done?”
Decisions that team members make will have consequences, not only for the future
of the project, but for work already completed, and those consequences may
determine or even limit the ways the project can develop and change.
At the Blake Archive this phenomenon causes issues ranging from the relatively
mundane to the borderline terrifying. At the low-consequence end of the spectrum
is our book of image search terms: as the Archive’s editors and project assistants
prepare new works for publication, they write descriptions of Blake’s images using
an art historical vocabulary specific to Blake’s iconography; these descriptions,
in turn, enable the Archive’s image search feature. As assistants add new terms to
our image description glossary, it often becomes necessary to comb through already
published works to see if these new terms apply; when we decided to add the term
“mane” to describe the numerous horse sketches appearing at the end of
An Island in the Moon, for example, we had to
retroactively add the term to every description of a horse (or lion, for that
matter) found elsewhere in the Archive.
In a move with more far-reaching consequences, the Archive’s Technical Editor Will
Shaw recently updated the Archive’s DTD
[20] to allow for XML attributes that would “hide” certain
documents from the XSL transformation that dynamically generates our tables of
contents. This will eventually make it possible for proofs and impressions of an
illuminated work to appear in the Archive’s Compare feature without also appearing
in the table of contents that lists all copies of that work. (The need to
distinguish between a proof of an illuminated work and a copy of that work
reflects the Archive’s ongoing concern with Blake’s production processes.) Once
this improvement was made to the DTD, however, a member of the Archive staff had
to add an XML attribute to the root element (<bad>) for every BAD in our
eXist database to prevent all of the Archive’s electronic editions from
simultaneously disappearing from their respective tables of contents. Since there
are scores of digital editions already published and hundreds left to publish, at
the Archive we find ourselves perpetually looking forward as well as backward,
pondering the possible consequences of our actions for future staffers.
The Longer a Project Lasts, the More Diffuse Its Collective Knowledge
Becomes
One of the most exciting and frightening aspects of digital humanities projects is
their reliance on distributed expertise. This need is present from the beginning
of nearly every project; rare (though not unheard of) is the digital humanist who
can single-handedly write code, mark up data, build a database, design web
interfaces, write grants, manage a staff, and provide expert content. (Rarer still
is the scholar who can do all of these things while teaching, publishing, and
serving on numerous committees.) The longer a project exists, the greater the
number of collaborators (or, to use the private-sector term, stakeholders) —
principal investigators, editors, project managers, grant administrators,
developers, deans, graduate students, undergraduate assistants — who will pass
through the project and contribute their particular strengths. Over time, the
distributed cognition necessary to continue the venture will change as the
project’s staff, size, funding, and location change, so the uncertainty that often
characterizes digital projects can have temporal, geographic, economic, or
personal dimensions. Wrangling a project’s collective knowledge, including the
lingering — could we call it “spectral”? — contributions of past
collaborators, is one of a project manager’s most challenging tasks.
Within the last few years the Archive’s collective knowledge has become more
geographically diffuse as the project, which is published at the University of
North Carolina at Chapel Hill, has opened a satellite office at the University of
Rochester, where Morris Eaves and Project Coordinator Laura Whitebell (who has
just replaced longtime coordinator Rachel Lee) oversee the production of digital
editions of Blake’s manuscripts.
[21] The
Rochester assistants have quickly become the Archive’s foremost experts on
manuscript tagging and markup, with the result that a large segment of the
Archive’s institutional knowledge is housed on a different campus from its primary
administrative and technical site. But in addition to its geographic dispersal,
Archive expertise has become more temporally diffuse as well, as graduate and
undergraduate staff members join and then leave the project, contributing their
analytical and practical skills to publications that take years to move through
the transcription and markup process.
The Archive’s decision, in recent years, to begin publishing electronic editions
of Blake’s unique works in manuscript — including his letters, his prose satire
An Island in the Moon, the notebook in which he
drafted poems and sketched designs, and the visionary poem
Vala, or The Four Zoas — has necessitated a major redesign of the
Archive’s markup tagset and transcription display protocols. Early Archive
publications reproduced Blake’s illuminated books, each of which Blake printed in
multiple copies from a copper-plate matrix that remained relatively stable from
printing to printing.
[22] The Archive’s original transcription
tagset was thus quite simple and straightforward. The publication of manuscript
works including
An Island in the Moon and Blake’s
late letters necessitated considerable changes to this tagset to reflect
strike-throughs, underlined text, carets, and other manuscript features not found
in the illuminated books. This more robust tagset has served the Archive well for
several years, but the Rochester team’s preliminary work on Blake’s
Four Zoas manuscript has revealed that another round of
substantial changes will be necessary — changes that will be undertaken over a
period of years and with an ever-changing staff.
[23]
A complex manuscript composed in several stages over a period of more than ten
years,
The Four Zoas is a far cry from the relatively
straightforward, almost “fair copy” clarity of
Island and of Blake’s letters. The poem combines drawings and text in
an extended response to Edward Young’s devotional poem
Night
Thoughts; during its composition Blake frequently erased large swaths
of his own writing and covered the erasures with new verse. Composed in part on
leftover proof sheets from Blake’s engraved illustrations of Young’s work, the
manuscript was unbound and reordered by Blake’s posthumous editors. As Fiormonte,
Martiradonna, and Schmidt have recently reasserted (the insight is one long known
to textual critics), “if we either look at the different
historical representations of a given text or at its documented writing
stages, we realize that there is not one text, but many texts, as many as
there are mechanisms of writing, material production, intertextual paths and
methodologies of reconstruction”
[
Fiormonte et al. 2010, par. 3]. The “many texts” of the
Four Zoas are a
Blakean’s delight and a textual editor’s despair.
In order to present the “many texts” of the
Four
Zoas in a coherent, readable, and philologically rigorous digital
edition, the Archive will need to call on the expertise of both its current staff
and past collaborators. The composition sequence of
The Four
Zoas has been successfully limned by the Archive’s former project
manager, Justin Van Kleeck, who created a fully tagged version of the manuscript
as his dissertation project.
[24]
Justin’s efforts to reconstruct the composition sequence of
The Four Zoas and to represent that sequence in XML are now guiding
the Archive’s Rochester team as they prepare the manuscript for publication in the
Archive. But the Archive’s publication processes, while not bound specifically by
the “printing bias” identified by Fiormonte, Martiradonna, and Schmidt [
Fiormonte et al. 2010, par. 3], are nevertheless subject to the
standards and protocols developed by the Archive in the twenty years of its
existence.
[25] The Rochester
team’s challenge is to expand the Archive’s markup tagset and transcription
display in ways that enable the symbolic representation of Blake’s composition
processes while remaining true to the Archive’s existing standards for textual
markup and representation.
Such temporal and geographical dispersals suggest that everyone involved with a
project — especially one with many years of history and change behind it — has to
commit to a certain level of perpetual uncertainty. This uncertainty, while a
function of all collaborative projects, is particularly germane to digital
endeavors, in which technical and administrative infrastructure are often
determined by geographic and funding considerations not entirely under the control
of the primary investigators. Morris Eaves, writing in the first decade of the
Archive, noted that “[w]e plow forward with no answer to
the haunting question of where and how a project like this one will live out
its useful life…. [T]he need to persist without reassurance is one of the
many unsettling conditions of life in new media”
[
Eaves 2006]. As Jerome McGann has noted in writing of the philological impulse of
digital archives, all forms of networked knowledge — electronic or otherwise —
have “memory lapses that they’ve forgotten.
You can never be sure what’s there or, if it’s there, where it is”
[
McGann 2013, 342]. Uncertainty and potential loss are the enabling conditions of ongoing
scholarship, and they do not disappear or mitigate with time.
Documentation and Communication are Additive Processes; They Will Remain
Important Throughout the Project, Though Emphases and Priorities Will Shift
It is easy to agree that documentation is a high-priority task for a collaborative
project: important technical and administrative information should not be
entrusted to chance or allowed to reside in a single (sometimes human)
repository.
[26] It is less simple to
maintain up-to-date documentation, which will always feel like the last priority
on an ongoing project: “one more task to add to an already
full schedule”
[
Siemens 2010]. But it must remain a priority nonetheless. Workflows and procedures often
change incrementally. A process that was once the sole province of programmers or
the technical editor will get easier for other staff to implement (or vice versa —
a seemingly simple task will get harder); a collaborator who shows a talent for a
particular task will take it over entirely; login procedures and passwords will
change as the university’s IT group tightens computer security; the number of
project staff will get bigger and harder to train individually, or smaller and
required to take on more tasks per person; the list of possible changes is
endless. In the day-to-day progress of the project these small changes can seem
unimportant, but in the aggregate they can, over time, completely change the way
project work is completed. If documentation is not updated frequently and
thoroughly, those responsible for documenting project history and necessary
procedures can be overwhelmed to find that workflows have been completely
transformed since the last update. This can necessitate weeks or months of
rewriting when an occasional well-timed revision, recorded immediately as
processes changed, would have required only an hour or two.
There is a corollary to this piece of advice: the longer a project lasts, the
harder it will be to alter workflows and organizational protocols, or to adopt
out-of-the-box tools like Basecamp, Jira, or GitHub.
[27] Entrenched work
habits are difficult to change, especially in large groups that have been working
together for some time. New project management and task tracking tools can seem
like catch-all solutions until it becomes clear that the time and effort involved
in training staff members to use a new tool negate the software’s time-saving
potential. If you are at the beginning stages of a digital humanities project, it
would behoove you to be as careful in your choice of project management tools as
you are in selecting the hardware and software that will help you process,
analyze, and present your data. They may be with you for a long time.
Because it is difficult to efficiently train a staff of approximately twenty
geographically dispersed collaborators — many of whom are graduate and
undergraduate students with short- to medium-term project tenures
[28] — to adopt new
tools, the Blake Archive relies on what might be considered “low-tech”
solutions to the problem of communication and collaboration between campuses. It
employs a simple staff listserv (called blake-proj and enabled by UNC’s Lyris list
management software) and a password protected “Work in
Progress” (WIP) site. The WIP site, accessible only to staff, includes a
training manual for new assistants (instructions for scanning, cataloguing, and
color correcting images; an introduction to Blake Archive Documents (BADs);
illustration and transcription markup guidelines) as well as essential technical
information, including our DTD and XML tagset documentation. It also provides
links to XML tracking sheets for both our electronic editions and the forthcoming
Blake Quarterly back issues project and acts as a
repository for project history, featuring grant reports and the minutes from our
annual Blake Camp meetings.
[29]
In addition to these two basic means of communication, the Blake Archive employs a
variety of tools and techniques to facilitate collaboration among Archive staff
and to maintain the Archive’s bimonthly publication schedule; this variety is
necessary to coordinate project staff on five different campuses (UNC Chapel Hill,
the University of Rochester, Duke University, Kansas State University, and the
University of California-Riverside). The Archive conducts an annual in-person
project meeting, Blake Camp, usually held at the Institute for Arts and Humanities
at UNC (though the 2013 meeting took place in Altadena, California, in conjunction
with a Huntington Library symposium organized by the Archive’s bibliographer, Mark
Crosby), that serves the dual purposes identified by Lynne Siemens in her study of
digital humanities collaboration tools: “[f]irst, the gatherings are an
opportunity to review the previous year’s work and outline the tasks for the
upcoming year. Second, they are also the time to resolve those ‘thorny’
issues that could not be easily resolved on conference calls or by email
during the year”
[
Siemens 2010]. To coordinate activities between the Archive’s primary office at UNC and
the manuscript markup division at the University of Rochester, I conduct biweekly
video chats with Project Coordinator Rachel Lee and Assistant Project Manager Joe
Fletcher using Google Chat (which we find more reliable than Skype). Because, as
Siemens notes, “unlike electronic communication tools such as emails and
listserves, no automatic record is created from these meetings,” Rachel usually
maintains a written record of our conversations [
Siemens 2010].
Other team members are then notified of important decisions via blake-proj,
creating an electronic record of essential points.
It is important to note that communication and collaboration strategies among team
members will change over time, and that communication at the beginning stages of a
project will take different forms than a mature project requires. The early years
of the Blake Archive, for instance, included an intensive period of on-site
collaboration and development at the Institute for Advanced Technology in the
Humanities at the University of Virginia, where Dr. Joseph Viscomi received a
one-year Residential Fellowship to oversee the design and launch of the Archive.
Such meetings, Siemens notes, “are particularly important at the
beginning stages of a project. It is at this stage of research projects
where the ambiguity and potential for conflict is greatest, especially when
individuals from different academic backgrounds and training are involved,
and when team members must develop a common understanding of the research
project, methodologies, tasks, and deadlines ”
[
Siemens 2010]. In recent years, by contrast, as the Archive has shifted from development
mode to a schedule characterized by frequent publication, ongoing site
maintenance, and occasional tool development, in-person collaboration has become
less essential, and the Archive has shifted to forms of long-distance
communication and the occasional in-person meeting.
Good DH Projects Are Like Strong Marriages: The Excitement Will Fade, But the
Love Will Remain
Like any large, ongoing project (including a traditional monograph), you are more
likely to stick with a digital humanities endeavor if you feel genuinely
passionate about it. But the nature of that passion will change over the years, as
the thrill (and occasional agony) of launching a new project gives way to the
satisfaction of maintaining an ongoing one. And there are moments when it simply
won’t be much fun, when nothing will go right: grants won’t come through,
deadlines will pass, programmers will be wooed away, collaborators will stop
answering email. While as a project manager one is trained to plan for achievable
goals and projected endpoints, at these moments it can help to think in terms of
relationships rather than deliverables. You wouldn’t give up on your partner or
your best friend after a few arguments; digital projects require similar patience.
This is the essence of collaboration itself.
[30]
In practical terms, it is often useful to think in terms of incentives: once a
project has moved from development to maintenance, the incentive structure that
enables it to proceed will have to change. Students and potential collaborators
who volunteered their time to initiate a new project may find an ongoing one less
appealing, so it may be necessary to rethink how credit is distributed, how work
on the project fits into graduate and undergraduate training, and where and how
students and faculty present and publish the results of their work. Such shifts,
while they require time and effort to initiate, can actually operate in a
project’s favor. For instance, while granting agencies are more likely to support
new, exciting projects than reliable, established ones, deans and department
chairs often value results and products that they can tout in annual newsletters
and the university magazine. Once your digital project has been underway for
several years, has grants and awards to its name, and has produced or inspired
articles and monographs, it may carry more weight with administrators not versed
in cutting-edge digital humanities research. That weight may then translate into
research assistantships, office space, or a teaching reduction.
Conclusion
In a 2009 issue of
DHQ Matthew Kirschenbaum recalled
one of the joys of his early days at the William Blake Archive: the satisfaction
of completing a task, of pronouncing something “done.”
“It was easy to measure progress as
I ticked off tasks in email messages to the archive’s editors,”
Kirschenbaum wrote. “In time, when enough of these
individual tasks were ‘done,’ the project might be finished”
[
Kirschenbaum 2009, par. 1]. As one of Kirschenbaum’s successors at the Archive,
[31] I too feel the joy of checking off boxes as the Archive’s staff complete
the tasks necessary to publish new electronic editions of Blake’s work every other
month. But the idea that the Archive might ever be finished is foreign to me;
since I arrived at Joseph Viscomi’s door in August of 2005 I have been perpetually
reminded that the William Blake Archive is a scholarly resource in a constant
state of growth and change. If the Archive ever manages to publish scholarly
editions of every illuminated book, watercolor drawing, manuscript, letter,
receipt, engraving, etching, sketch, scrawl, and scribble that Blake produced
during his long and prolific lifetime, there will still be Blake’s circle and his
throngs of admirers, both contemporary and modern, to include. In other words,
infinity is our project limit.
Fortunately, the project management practices that were established in the early
years of the Archive have paid off over the last decade, enabling the Archive to
surpass its goal of making high quality electronic editions of Blake’s work
available to scholars and to move toward its larger vision of becoming a catalogue
raisonné, critical edition, and comprehensive database of all or nearly all of
Blake’s work. Decisions made at the beginning of the project — about approaching
contributing institutions, curating images and data, and cultivating project staff
— were vital, and continue to influence the Archive’s day-to-day operations. But
the need for thoughtful management practices has, if anything, increased as the
project has achieved and moved beyond its early objectives. As the digital
humanities field grows, it will become increasingly important to consider whether
and how projects should be maintained beyond their early development stages.
Project management for the long term will become a pressing question for the here
and now.
Acknowledgements
For their generous assistance with this essay I would like to thank Morris Eaves,
Robert Essick, Jennifer Guiliano, Shawn Moore, Will Shaw, Rachel Lee, and Joseph
Viscomi as well as Julia Flanders and the anonymous reviewers for Digital Humanities Quarterly.
Notes
[1] There are a few exceptions, of course:
Bethany Nowviskie and Dot Porter’s “Graceful Degradation
Survey” gathered information from collaborators on digital humanities
projects in an attempt to determine how long-term projects can best be maintained
during periods of change and transition. Preliminary results of the survey were
presented at Digital Humanities 2010, but as of this writing no complete analysis
has yet been published. And Daniel Pitti’s essay on “Designing
Sustainable Projects and Publications” is a useful resource that takes a
long-term view of project design, planning, and management.
[2] Lynne Siemens’
excellent course on Issues in Large Project Planning and Management, for instance,
skews heavily toward the first part of its title: it is 80-90% project planning
and 10-20% project management. I was fortunate to take Dr. Siemens’s course as an
attendee of the June 2012 Digital Humanities Summer Institute (DHSI) at the
University of Victoria. As Lynne has done more to emphasize the professional role
of project managers in digital humanities scholarship than perhaps anyone else —
conducting on-site studies and publishing numerous articles on the topic — I
assume that her course’s emphasis on project planning over project management is a
response to student demand rather than a reflection on project managers as
scholarly professionals.
[4] See the NEH’s
guidelines at http://www.neh.gov/files/grants/data_management_plans_2012.pdf. I do not
mean to suggest that all digital humanities projects should be permanently
maintained at the behest of granting agencies. But if funding agencies are going
to favor long-term projects and value the preservation of data, digital humanists
who hope to appeal to these funding agencies would do well to cultivate project
management practices that facilitate these goals. [5] Not
all projects need to remain active any more than all monographs need to become
standard reading in their fields. (A librarian once said to me, “Of course we’re all glad the Blake Archive is
still around, but if you’d built it in, say, Second Life we’d want it to
disappear as soon as possible.”) But terminated projects and their data
should remain accessible whenever possible, for the same reason that libraries
maintain copies of out-of print books: because they are evidence of scholarship
completed and may be of use to future researchers. But the long-term maintenance
of such projects requires different management practices than those required for
print preservation or for early-stage project development.
[6] Founded by Morris Eaves, Robert
Essick, and Joseph Viscomi, the Archive published its first online digital
editions in November 1996 and its most recent (as of this writing) in July 2013.
Its first publication included five complete copies of Blake’s illuminated books:
three copies of Visions of the Daughters of Albion
and two copies of The Book of Thel. The Archive now
contains eighty-two complete copies of the illuminated books, as well as all of
Blake’s watercolor illustrations of the works of John Milton, Thomas Gray, and
Dante Alighieri; sketches, paintings, and engravings illustrating the book of Job;
manuscript works including An Island in the Moon and
the Pickering Manuscript; commercial engravings for
Mary Wollstonecraft’s Original Stories from Real
Life, John Gabriel Stedman’s Narrative of a Five
Years’ Expedition Against the Revolted Negroes of Surinam, and The Pastorals of Virgil; and scores of watercolors and
temperas illustrating passages from the Bible — over 120 digital editions in all.
The Archive’s other scholarly apparatus include biographies, bibliographies,
museum and library collection lists, a demonstration of Blake’s illuminated
printing process, and the Archive’s own technical and project documentation, among
other items.
[7] I began working with the Blake Archive in August 2005, when I
was assigned to a position as Joseph Viscomi’s research assistant during my first
year of graduate study. I brought to the job several years of experience in
project management and media production, and in June 2007 I took over as Project
Manager of the Archive.
[8] Project Bamboo is “a
multi-institutional collaborative initiative to guide the creation of shared,
interoperable tools, services, and content to meet the real needs of humanities
researchers”
[Bamboo 2013a]. [9] We have done our share of upgrading at the
Archive: from WBA 1.0 to WBA 2.0, from SGML to XML, from DynaWeb to eXist, and
then to later iterations of eXist. “WBA 2.0” was the Archive’s first major
site redesign, occurring in 2001. It streamlined site organization and featured
the launch of the new Compare and Navigator tools. At this point the Archive’s
digital editions were still created in the Standard Generalized Markup Language
(SGML); the transition to Extensible Markup Language (XML) began in 2005 and
was completed in May of 2006. The XML conversion also necessitated a change
from the DynaWeb SGML server to eXist, an open-source native XML database. The
Archive currently uses eXist version 1.4.
[10]
Work, copy, and object are terms
specific (though not exclusive) to Blake studies. They all refer to Blake’s own
productions; the copy in this case is not to be confused with the
digital surrogates presented in the electronic editions at
blakearchive.org.
[11] This question of relatedness occupied us for several years.
Each summer at Blake Camp (the Archive’s annual planning meeting, held in
recent years at the Institute for Arts and Humanities at UNC Chapel Hill) the
editors, the Technical Editor, our bibliographer Mark Crosby, and I would hash
it out again; between Blake Camps the discussion continued on blake-proj, our
staff listserv.
[12] Versions of the same basic design are sometimes also linked as
related even when they are not part of the same production process. Blake’s
vision of “Death’s Door,” for instance, is a motif that appears repeatedly
in his works in different media; these works are classified as related simply
because they are very nearly the same design.
[13] This protracted debate over the concept of
“relatedness” and how it should be represented in the Archive’s
interface naturally both reflects and was constrained by the affordances of the
Archive’s XML database. As Stephen Ramsay notes, the employment of databases by
humanists raises questions about “[t]he inclusion of certain data (and the attendant exclusion of others),
the mapping of relationships among entities, … and the eventual
visualization of information patterns,” and the answers to these
questions necessarily “imply a
hermeneutics and a set of possible methodologies” that have
far-reaching consequences both for individual projects and for the humanistic
field [Ramsay 2004]. [14] Nelson and
Bath’s study of the Thompson Chain Reference Bible and its sophisticated
textual linking system reveals many parallels with the systems developed at the
Blake Archive for linking related works and objects. As with the Thompson
Bible, the desire to create thematic links rather than, or in addition to,
semantic ones has driven the Archive’s development of multiple methods for
connecting objects across the Archive. This desire derives in large part, I
would argue, from the fact that readers of Blake, like readers of the Bible,
represent a “highly motivated reading
communit[y]”
[Nelson and Bath 2012, par. 25]. [15] This work has been spearheaded by Morris Eaves and
Sarah Jones of the University of Rochester, with the Carolina Digital Library
and Archives assisting with hard-copy scanning and textual markup, graduate
assistants at UNC preparing images for publication, and Technical Editor Will
Shaw building the necessary XSL transformations and XQuery code.
[16] We plan to begin releasing these electronic back issues
in spring 2014; like the Archive’s digital editions, they will be freely
available and require no subscription or access fees. Scanned PDFs of the
original issues will also be available for print on demand; these PDFs will, of
course, retain the halftone images that originally appeared in the print
journal. Since 2011 current issues of BIQ have
been published online (with a print on demand option); these current issues are
available only to BIQ subscribers, but will join
the Archive’s repository of back issues as they emerge from behind a five-year
“moving wall.”
[17] BADs, or Blake Archive Documents, are the building
blocks of the Archive. They contain all of the XML data related to individual
Blake works, and thus enable the standardized publication of digital
editions.
[18] Eaves’
“Multimedia Body Plans: A Self-Assessment” is a
detailed analysis of the editorial decisions that helped shape the creation and
early evolution of the Blake Archive; it provides a useful companion piece to
this essay. The article is available, in slightly different versions, online
and in hard copy. This quotation is from the online edition; information on
both versions can be found in my bibliography.
[19] Shaw invokes the Unix operating system’s “principles of modularity and
interoperability–you can chain together a lot of single-purpose tools to
do complex things”
[Shaw 2012] as an analogy for the importance of keeping user-facing features
lightweight and focused on a minimum number of tasks. [20] The Archive’s DTD, or document type
definition, restricts and records which tags can be used in the Archive’s XML
BADs.
[21] The Rochester staff christened themselves
BAND: Blake Archive Northern Division. Robert Essick, not to be outdone,
quickly claimed BAWD — Blake Archive Western Division — for his outpost in
Altadena, California. The UNC office, after some deliberation, settled on BATS:
Blake Archive Team South; a former UNC assistant who now works from her home in
Queens, New York, represents BARD: Blake Archive Roving Division.
[22] Though the copper plates, once etched, rarely changed,
Blake could alter the resulting texts before printing — by masking certain
portions of the plate or inking some lines of text and leaving others uninked —
or after, by obscuring text with watercolor washes or salvaging or altering
printed lines with pen and ink. These textual variants are important and are
reproduced in the Archive’s diplomatic transcriptions, but can be encoded using
a relatively basic markup tagset.
[23] Early attempts to mark up
the Four Zoas manuscript using the Archive’s
existing tagset produced ugly and unreadable transcriptions in which deleted or
overwritten text was represented by long black bars or grey highlighting. The
Archive’s fairly simple tagset, developed for works containing little
overwriting or deletion, was untenable in the context of The Four Zoas, in which erasures and overwriting are the rule
rather than the exception. The addition of this new work to the Archive’s
stable of editions-in-progress has thus required us to rethink our assumptions
about how to best represent Blake’s manuscript works.
[25] In another example of a development project marked by both
spatial and temporal diffusion, the Archive’s recently launched Virtual
Lightbox tool began at the University of Kentucky in 2000, was developed by
Matt Kirschenbaum and Amit Kumar at the University of Maryland, and was
developed further and finally adapted for the Archive by Will Shaw. Complete
credits can be found at http://mith.umd.edu/lightbox/credits.html. [26] Joseph Viscomi is fond of asking me, whenever I point to my
head as the source of some important piece of Archive-related knowledge,
“What if you get hit by a bus?” He has a gruesome anecdote about a New
York museum curator to reinforce this lesson.
[28] Compared to
many digital humanities projects the Archive has a fairly stable staff; the
three founding editors are still with the project, and most assistants are
Ph.D. students who remain with the Archive for an average of five to eight
years. Cultivating reliable collaborators who will remain more than a few
months is key to managing a successful long-term project.
[29] The Archive’s Rochester office maintains its own
internal Google site to track manuscript-specific tasks, including primary
source research and multiple rounds of proofreading.
[30]
Morris Eaves recently forwarded to me an email conversation that took place
off-list between the Archive’s editors. They were debating how best to
present Blake’s unfinished Tiriel manuscript
and its accompanying monochrome wash drawings. Should the drawings be
separated from the text or presented all together, producing the illusion of
a completed work despite the fact that no one is really certain how Blake
intended to fit the manuscript and drawings together? (Dr. Eaves has made
the text of this Tiriel debate available to
curious readers on the Archive’s (un)official blog, The
Cynic Sang
[Eaves et al. 2012].)
The detail with which the editors and staff discuss such topics (these
debates are a frequent occurrence, both on and off blake-proj) is
fascinating both to witness and to participate in; it is this kind of
devotion to Blake studies that has powered the Archive for almost twenty
years. But in this particular exchange I noticed something else: the editors
sign each of their emails to each other, not with “Best” or
“Regards” or “Your friend,” but with “Love” — a tiny
reminder of how long and happily they have worked together on this
project.
[31] Matthew
Kirschenbaum served as Project Manager and then Technical Editor of the Archive
from May 1997 until June 2003. In many ways this article is a follow-up,
fifteen years later, to his 1998 Romantic Circles article on “Project Managing the William Blake Archive.”