DHQ: Digital Humanities Quarterly
Volume 8 Number 1
2014 8.1  |  XMLPDFPrint

Managing an Established Digital Humanities Project: Principles and Practices from the Twentieth Year of the William Blake Archive

Ashley Reed  <reeda_at_email_dot_unc_dot_edu>, University of North Carolina


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.


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, ¶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]
Screenshot of William Blake Archive showing views of different Blake
                     works juxtaposed in different windows.
Figure 1. 
Object 6 of Blake’s engraved illustrations to The Pastorals of Virgil (center) alongside a proof impression (upper left) and two preliminary drawings (right). Though these various objects were executed in different media, they are related in the Archive’s terminology (and tagged as such in our XML documents) because they represent stages in Blake’s production process for the finished work known as the Pastorals.
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.
Figure 2. 
The Archive’s recently launched Supplemental Views feature offers additional photography for objects displayed in the Archive. In this case, a full leaf view of object 2 of Visions of the Daughters of Albion copy H shows the poor registration of the plate to the leaf; an explanatory note indicates that the printed object “appears low and tilted to the right.”
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, ¶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, ¶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.
Screen shot of an entry from Blake: An Illustrated Quarterly
Figure 3. 
Work in progress toward online back issues of Blake/An Illustrated Quarterly. Like the Archive itself, these issues will be highly searchable and require no subscription fees. Digitization and XML encoding were performed by an outside vendor, with DTD design and interface development handled in-house by Technical Editor Will Shaw, Technical Consultant Joseph Ryan, and assistants Michael Fox and Adam McCune.
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.
Screen shot of an object from  alongside objects from
Figure 4. 
Compare feature windows showing images printed from the same copper plates but appearing in different works. The top row shows an object, far left, from A Small Book of Designs alongside objects from The Book of Urizen. The bottom row shows an object, far left, from A Large Book of Designs alongside objects from Visions of the Daughters of Albion.
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, ¶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, ¶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.
Object 5 of Blake’s manuscript work .
Figure 5. 
Object 5 of Blake’s manuscript work Vala, or The Four Zoas. The Archive’s former Project Manager, Justin Van Kleeck, completed a tagged edition of The Four Zoas as part of his dissertation work. This tagged edition will help to enable the Four Zoas's eventual publication in the Archive — an event that will require a considerable expansion of the Archive’s current markup tagset.
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.
Screen shot of The Blake Archive’s workflow tracking site
Figure 6. 
The Blake Archive’s workflow tracking site, designed by former project assistant Michelle Langston (now a front-end web developer at Automattic, the company behind Wordpress.com) and accessible only to project staff.

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.


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, ¶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.


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.


[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.
[3] A 2011 Digital Humanities Questions & Answers exchange, for instance, centered on how to “future-proof” a 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.
[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, ¶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.
[24] Dr. Van Kleeck’s essay on the process of tagging The Four Zoas can be found at http://www.rc.umd.edu/praxis/editing_blake/vankleeck/vankleeck.html.
[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.
[27] Basecamp (http://basecamp.com/), Github (https://github.com/), and Jira (http://www.atlassian.com/software/jira/overview) are tools for project management and issue tracking. Basecamp and Jira charge per-month subscription fees; GitHub is free for open-source projects but charges a fee for those who wish to keep their activities private. There are other tools available; see this DH Questions and Answers exchange (http://digitalhumanities.org/answers/topic/best-dh-project-management-system) for a discussion of their advantages and disadvantages.
[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.”

Works Cited

ACH 2011  “Best DH Project Management System?” Digital Humanities Questions & Answers. Association for Computers and the Humanities, 2011. Web. 22 Sept. 2012. http://digitalhumanities.org/answers/topic/best-dh-project-management-system.
ACH 2013  “Founding Staff for a New DH Center?” Digital Humanities Questions & Answers. Association for Computers and the Humanities, 2012. Web. 20 July 2013. http://digitalhumanities.org/answers/topic/founding-staff-for-a-new-dh-center .
Bamboo 2013a  About Project Bamboo - Project Bamboo - UCB Confluence. wikihub.berkeley.edu. Web. 17 Aug. 2013. https://wikihub.berkeley.edu/display/pbamboo/About+Project+Bamboo.
Bamboo 2013b  Standards & Specifications - Project Bamboo - UCB Confluence. http://wikihub.berkeley.edu. Web. 13 Jul. 2013. https://wikihub.berkeley.edu/pages/viewpage.action?pageId=68619301.
Burgess and Hamming 2013 Burgess, Helen J, and Jeanne Hamming. “New Media in the Academy: Labor and the Production of Knowledge in Scholarly Multimedia.” DHQ: Digital Humanities Quarterly 5.3 (2011). http://www.digitalhumanities.org. Web. 4 Jun. 2013. http://www.digitalhumanities.org/dhq/vol/5/3/000102/000102.html
Croxall 2011 Croxall, Brian. “12 Basic Principles of Project Management.” ProfHacker (Chronicle of Higher Education). Online ed. 3 Mar. 2011. Web. 13 June 2012. http://chronicle.com/blogs/profhacker/12-basic-principles-of-project-management/31421.
Eaves 2006 Eaves, Morris. “Multimedia Body Plans: A Self-Assessment.” Electronic Textual Editing. Ed. Lou Burnard, Katherine O’Brien O’Keeffe, and John Unsworth. New York: Modern Language Association of America, 2006. 210-223. Print. Preview ed. available online: http://www.tei-c.org/About/Archive_new/ETE/Preview/eaves.xml. Web. 20 Aug. 2012.
Eaves et al. 2012 Eaves, Morris, Robert N. Essick, Joseph Viscomi, et al. “Xediting Blake’s Tiriel: How It Lives and What It Lives For.” The Cynic Sang: The (Un)Official Blog of the William Blake Archive. William Blake Archive, 31 Aug. 2012. Web. 12 Oct. 2012. http://blakearchive.wordpress.com/2012/08/31/xediting-blakes-tiriel-how-it-lives-and-what-it-lives-for/ .
Fiormonte et al. 2010 Fiormonte, Domenico, Valentina Martiradonna, and Desmond Schmidt. “Digital Encoding As a Hermeneutic and Semiotic Act: The Case of Valerio Magrelli.” DHQ: Digital Humanities Quarterly 4.1 (2010). www.digitalhumanities.org. Web. 4 Jun. 2013. http://www.digitalhumanities.org/dhq/vol/4/1/000082/000082.html.
Kirschenbaum 2008 Kirschenbaum, Matthew. “Managing the Blake Archive.” Romantic Circles Features & Events: Editors’ Dispatches. Romantic Circles, Mar. 1998. Web. 7 June 2008. http://www.rc.umd.edu/dispatches/column7/.
Kirschenbaum 2009 Kirschenbaum, Matthew. “Done: Finishing Projects in the Digital Humanities.” Digital Humanities Quarterly 3.2 (2009): n.pag. Web. 31 May 2012. http://www.digitalhumanities.org/dhq/vol/3/2/000037/000037.html .
Leon 2012 Leon, Sharon M. “Project Management for Humanists: Preparing Future Primary Investigators.” Getting There. Ed. Bethany Nowviskie. #alt-academy: a media commons project, 6 May 2011. Web. 13 June 2012. http://mediacommons.futureofthebook.org/alt-ac/pieces/project-management-humanists .
McGann 2013 McGann, Jerome. “Philology in a New Key.” Critical Inquiry 39.2 (January, 2013): 327-346. CrossRef. Web. 20 July 2013.
NEH 2012  “Data Management Plans for NEH Office of Digital Humanities Proposals and Awards.” NEH.gov. National Endowment for the Humanities, n.d. Web. 8 Oct. 2012. http://www.neh.gov/files/grants/data_management_plans_2012.pdf .
Nelson and Bath 2012 Nelson, Brent, and Jon Bath. “Old Ways for Linking Texts in the Digital Reading Environment: The Case of the Thompson Chain Reference Bible.” DHQ: Digital Humanities Quarterly 6.2 (2012). www.digitalhumanities.org. Web. 4 Jun. 2013. http://www.digitalhumanities.org/dhq/vol/6/2/000137/000137.html
Nowviskie 2012a Nowviskie, Bethany. “Eternal September of the Digital Humanities.” Debates in the Digital Humanities. Open access ed. Minneapolis: U of Minnesota P, 2012. http://dhdebates.gc.cuny.edu. Web. 9 Aug. 2013. http://dhdebates.gc.cuny.edu/book
Nowviskie 2012b Nowviskie, Bethany. “Ten Rules for Humanities Scholars New to Project Management.” nowviskie.org, 2012. Web. 13 June 2012. http://nowviskie.org/handouts/DH/10rules.pdf .
Nowviskie and Porter 2010 Nowviskie, Bethany, and Dot Porter. “The Graceful Degradation Survey: Managing Digital Humanities Projects Through Times of Transition and Decline.” 2010 Conference of the Alliance of Digital Humanities Organizations. Digital Humanities (DH 2010). Web. 9 Aug. 2013. http://dh2010.cch.kcl.ac.uk/academic-programme/abstracts/papers/html/ab-722.html
Pitti 2013 Pitti, Daniel V. “Designing Sustainable Projects and Publications.” A Companion to Digital Humanities. Oxford: Blackwell, 2004. XTF. Web. 20 Jul. 2013. http://www.digitalhumanities.org/companion/.
Price 2012 Price, Kenneth. “Whitman’s Democratic Vistas and the Poetry of Democracy.” Digits, Data, and Dilemmas: A Roundtable on Digitization and Knowledge Production. C19: The Society of Nineteenth-Century Americanists Conference. Berkeley, CA. 13 Apr. 2012. Conference presentation.
Ramsay 2004 Ramsay, Stephen. “Databases.” A Companion to Digital Humanities. Oxford: Blackwell, 2004. XTF. Web. 20 Jul. 2013. http://www.digitalhumanities.org/companion
Scheinfeldt 2012 Scheinfeldt, Tom. “Intro to Project Planning and Management: Bootcamp Session in Advance of THATCamp CHNM 2011.” 3 June 2011. Web. 13 June 2012. https://docs.google.com/document/d/1Ex-b6zWtiuQWZw6DkV7B4cEGNovUWznvFV0fPvHXpN0/edit?hl=en_US&pli=1
Shaw 2012 Shaw, William. “Re: WBA tools.” Message to the author. 10 Oct. 2012. E-mail.
Siemens 2010 Siemens, Lynne. “The Balance Between On-line and In-person Interactions: Methods for the Development of Digital Humanities Collaboration.” Digital Studies/Le Champ Numérique 2.1 (2010).www.digitalstudies.org. Web. 22 Jun. 2013. http://www.digitalstudies.org/ojs/index.php/digital_studies/article/view/184/236.
Van Kleeck 2012 Van Kleeck, Justin. “Editioning William Blake’s The Four Zoas.” Editing and Reading Blake: A Romantic Circles Praxis Volume. Ed. Wayne C. Ripley and Justin Van Kleeck. Sep. 2010. Romantic Circles. Web. 1 July 2012. http://www.rc.umd.edu/praxis/editing_blake/vankleeck/vankleeck.html .
What Does it Mean to Future-Proof a DH Project? 2012  “What Does it Mean to Future-Proof a DH Project?” Digital Humanities Questions & Answers. Association for Computers and the Humanities, 2011. Web. 7 Aug. 2012.http://digitalhumanities.org/answers/topic/what-does-it-mean-to-future-proof-a-dh-project.
2014 8.1  |  XMLPDFPrint