Ashley Reed served as Project Manager of the William Blake Archive from 2007-2013 and now serves as Consultant for Special Projects. She recently defended her dissertation on Protestant theology and personal agency in nineteenth-century American fiction and will receive her PhD in English and Comparative Literature from the University of North Carolina at Chapel Hill in May 2014.
This is the source
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
As your project matures your management must evolve. Management strategies for established and ongoing DH endeavors, as practiced by the William Blake Archive.
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
PM boot campsthat 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.
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
all of this is new and… that the current scene is all there is
future-proofa project to assuage granting agencies’ and administrators’ fears that funded projects would simply disappear after a few years. See http://digitalhumanities.org/answers/topic/what-does-it-mean-to-future-proof-a-dh-project.
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.
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.
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
most academics already have experience managing projects,programmers and developers should be hired first and a manager only later
the softest kinds of standards,placing them behind
domain-specific technical standardsin terms of importance
a multi-institutional collaborative initiative to guide the creation of shared, interoperable tools, services, and content to meet the real needs of humanities researchers
hardand
softskills 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
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
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.
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.
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).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.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.
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
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 (
WCfor watercolor and
MSfor 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
relatedto 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
relatednessand its epistemological implications for our project. Were Blake’s watercolor illustrations to Milton’s
relatedto the designs for
texts by the same authorwas a valid definition of
relatednessfor the Archive’s purposes, then was every one of Blake’s illustrations of the Bible
relatedto every other one — with God understood as
author?
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.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.
relatednessand 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 methodologiesthat have far-reaching consequences both for individual projects and for the humanistic field
Further disambiguation of the term related
has recently led Archive staff
to create another, similar feature:
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
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 highly motivated reading
communit[y]
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
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
moving wall.
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
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
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.Compare
beneath any impression of
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 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
principles of modularity and
interoperability–you can chain together a lot of single-purpose tools to
do complex things
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
In a move with more far-reaching consequences, the Archive’s Technical Editor Will
Shaw recently updated the Archive’s DTDhide
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.
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.
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
A complex manuscript composed in several stages over a period of more than ten years,
fair copyclarity of
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
many textsof the
In order to present the many texts
of the
printing biasidentified by Fiormonte, Martiradonna, and Schmidt
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
memory lapses that they’ve forgotten.
You can never be sure what’s there or, if it’s there, where it is
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.What if you get hit by a bus?
He has a gruesome anecdote about a New
York museum curator to reinforce this lesson.one more task to add to an already
full schedule
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.
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 tenureslow-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
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
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
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. 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
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.
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.
In a 2009 issue of
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 weredone,the project might be finished
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.
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