Good digital scholarship, like good analog scholarship, will never be finished. This does not simply mean that digital projects will always need upgrading (though that will certainly be the case).[9] It means that a project’s ways of being and knowing will be subjected to constant scrutiny as time goes on and new data are incorporated. At a 2012 roundtable on digital humanities and digital pedagogy at the conference for C19: The Society of Nineteenth-Century Americanists, Kenneth Price raised the question of how scholars “know” their subjects. Speaking of the challenges facing the Walt Whitman Archive as its editors encounter objects like Whitman’s grocery lists or, even more problematically, letters and official correspondence transcribed by Whitman but composed by others, Price wondered, who is the Whitman we “know” in the context of the Whitman Archive? Is it Whitman’s handwriting? Whitman’s mind?

I would argue that such questions, about how we know our subjects, are endemic to ongoing digital humanities projects, whether those projects archive a particular author’s works, transcribe and translate ancient documents, investigate and represent geospatial data, or comb through massive textual corpora. “Knowing” is not the outcome of scholarly endeavors; it is a process that is furthered collaboratively by members of a project team (and by its users), and that process will continue and change for as long as the project survives.

At the Blake Archive, the Blake that we know is Blake-as-craftsman. The Archive’s earliest publications sought to make available to scholars digital editions that would reflect the unique artistic processes that Blake used to create his illuminated books, and so our most basic ontological units are the work, the copy, and the object: art-historical terms that, in the case of Blake’s work, exist on a kind of sliding scale from the theoretical to the material.[10] The work is largely an editorial concept: The Marriage of Heaven and Hell, for instance, is a work by Blake that we, as editors and readers, recognize only by virtue of the nine complete and individually printed copies in existence. Each of these copies is made up of twenty-seven objects printed on paper from a set of copper plates and arranged in an order that need not remain consistent among copies. (There are also three additional copies of the Marriage consisting of only three or four objects each.) The texts and images that make up each of these objects can also vary greatly depending on whether and how Blake inked each of the copper plates, what colors he used, and whether he added or altered the objects with pen or wash after printing. In other words, there is no definitive copy or edition of the work known as The Marriage of Heaven and Hell.

Confusing as this may seem, in an illuminated book the distinction between the work, the copy, and the object is actually relatively clear, and is represented hierarchically in the Archive’s three-level structure, in which users progress via hyperlink from a list of Blake’s works, to a list of available copies of a particular work (The Songs of Innocence and of Experience, for example), to a list of objects in a particular copy (such as copy Z), and finally to an individual object (say, “Infant Joy”). But these ontological distinctions have become less obvious as the Archive has begun acquiring and publishing Blake’s works in other media, including engravings, watercolors, tempera paintings, manuscripts, and letters. A watercolor drawing such as “The Great Red Dragon and the Woman Clothed with the Sun,” for instance, is a one-of-a-kind creation in which the work, the copy, and the object are one and the same; Blake’s notebook, in which he sketched preliminary drawings and drafted verse and prose, is a manuscript work that exists in only one copy made up of multiple objects. The matter of ontology extends to every aspect of the Archive’s design, from individual object view pages to our main index: since the Archive’s basic organizing principle is the medium of the work in question, image filenames include designators like “WC” for watercolor and “MS” for manuscript, and the site’s table of contents is arranged by medium, with illuminated books followed by commercial book illustrations, then separate prints, then drawings and paintings, then manuscripts and typographic works. Under such conditions, issues of classification and organization must be perpetually renegotiated: how, for instance, should we classify a book of poetry composed by Blake, printed for him by others, and then emended in Blake’s hand? Is this a typographic edition or a manuscript?

Questions of classification are, of course, intimately related to problems of presentation and display: “one needs to balance the goals of correctness against the practical exigencies of the system and its users”  [Ramsay 2004]. At the Archive the problem of classification drove the development of a new “Related Works” feature that links objects in different media across wings of the Archive. Every new digital edition published in the Archive (a set of watercolor drawings, for instance, or Blake’s engraved illustrations to a commercially published book) includes a list of works related to the newly published work. In the early years of the Archive these lists, generated by the editors, often included works illustrating texts by the same author, so that, for instance, every one of Blake’s watercolors illustrating one of Milton’s texts was considered “related” to every other watercolor illustrating Milton. But when Archive staff began building a tool that would actually link related works within the Archive (rather than just listing them for users to seek out on their own), we began to question this bibliographic definition of “relatedness” and its epistemological implications for our project. Were Blake’s watercolor illustrations to Milton’s Comus, commissioned by Joseph Thomas in 1801, “related” to the designs for Paradise Regained, completed no earlier than 1816, by virtue of anything other than Milton’s authorship? And if “texts by the same author” was a valid definition of “relatedness” for the Archive’s purposes, then was every one of Blake’s illustrations of the Bible “related” to every other one — with God understood as “author”?[11]

Unsurprisingly, the conclusion we eventually came to brought us back to the project’s original vision of Blake-as-craftsman: within the context of the Archive, works are now considered “related” if they are part of the same production sequence — a material definition of “relatedness” that reflects Blake’s unique creative processes. By the Archive’s standards, then, objects are related if they represent different stages in the creation of a work.[12] Thus, the monochrome wash drawings that Blake produced for his influential illustrations to The Pastorals of Virgil (1821) are related to the wood engravings published in that book because they represent earlier stages in Blake’s artistic process.[13]

Further disambiguation of the term “related” has recently led Archive staff to create another, similar feature: “Supplemental Views.” This category contains additional photography of an object, showing, for instance, the entire leaf on which an impression was printed. “Supplemental Views” are distinguished from “Related Works” because they refer not so much to the Blakean object itself but to the digital reproduction of the Blakean object — they offer a second, somewhat different photographic representation of the same physical object. Hence their classification as “Supplemental Views ” rather than “Related Works ” — work, in Archive nomenclature, being a term reserved for creative productions by Blake or his contemporaries.

This kind of thematic linking goes against the grain of current web development trends, which favor dynamically-generated links created in response to the behavior of users rather than the exigencies of content. As Brent Nelson and Jon Bath note, a static-linking system based on principles inherent to content and subject matter “requires editorial direction and is thus inherently biased and selective rather than (potentially) exhaustive: it is fixed and non-generative. For this reason, it is also necessarily labour-intensive”  [Nelson and Bath 2012, ¶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.

New and early-stage projects are often plagued with the problem of “scope creep,” a phenomenon in which a manageable and fairly well delineated project is derailed because the primary stakeholders cannot or will not limit their ideas of what the project will be: as team members with varying levels of technical knowledge and content expertise envision all of the directions a project could take, they can find themselves going everywhere and nowhere at once. In the beginning stages of a project, one of the project manager’s major duties — and the reason why they sometimes come across as spoilsports — is preventing scope creep by holding the team to agreed upon project parameters. For this reason, “project management for beginners” articles often emphasize the importance of setting realistic goals and limiting a project’s early ambitions.

But projects that are ten or twelve years along are less likely to suffer from scope creep than those in the beginning stages. If a project’s founders did their jobs well (and if a project is functioning productively after a decade, the chances are good that they did), by this point team members and collaborators probably have a realistic understanding of the task at hand. Once a team has mastered the primary functions of a project and brought it beyond the planning stages, widening the project’s scope becomes the next logical step in its development. At this point, a project manager’s priorities shift from preventing unwanted change to facilitating productive growth.

At the William Blake Archive the project team has recently made a move to widen the scope of our endeavor by adding to our database 40 years of back issues of Blake/An Illustrated Quarterly, the journal of record in Blake studies.[15] The Blake Archive has been publishing digital editions of Blake’s work for sixteen years; its publication processes have been relatively stable over that time, though they have been adapted somewhat to reflect both changing technology and the nature of Blake’s work. (The Archive is designed such that a publication process that works flawlessly for an illuminated book will require tweaking for a manuscript or watercolor.) The decision to incorporate searchable back issues of BIQ came about not only in response to changing paradigms of scholarly publishing, with many major journals now available in digital form, but as a way of maximizing the Archive’s existing assets. As back issues of BIQ are scanned, transcribed, and marked up for inclusion in the Archive, images that appeared as halftones in the print edition are being replaced, whenever possible, with the same high-resolution color-corrected JPEGs that make up the Archive’s digital editions. Thus, scholars reading Eugenie R. Freed’s article from the Winter 1998 issue of BIQ on the Christian symbolism in plate 78 of Blake’s illuminated book Jerusalem will see a full-color inline illustration of plate 78 and can also access the Archive’s digital edition of Jerusalem copy E (consisting of 100 objects in all) with one click.[16] Once this new resource is made available the Blake Archive will contain over forty years of BIQs history, making the Archive the premier source, not only for high-quality digital editions of Blake’s work, but for scholarly commentary on that work. The incorporation of BIQ represents scope change of the best kind: a manageable improvement that was perhaps not foreseen by the Archive’s founders, but which aligns with the primary goal of the Archive — to make Blake’s work, and excellent scholarship about it, available free of charge to as wide an audience as possible — and thus enhances the project’s scholarly value.

But while “scope creep” is less a problem to be avoided than a fact of life for older projects, “feature creep” — the wish to make existing tools perform more and more functions, just because they can — can be a major source of contention in ongoing projects. While the manager of a new project can often nip feature creep in the bud by appealing to time, staff, or budget constraints — the “let’s just get this up and running and then we’ll see” strategy — a digital project that is humming along happily is rife with opportunities for tinkering. Add to this what I call the “educator imperative” — the wish, common among academics, to give users/readers as much information as possible — and project managers may find themselves fighting the notion that because an existing tool could do something — and because making it do so is neither prohibitively difficult nor particularly expensive — it definitely should do that thing.

As with scope change, feature change is sometimes a logical outcome of a project’s continued mission: tools that were designed to do only one thing in the early days of a project may grow more complex as that project fulfills its early goals and develops in new directions. The Blake Archive’s Compare feature, for instance, was built to automatically display objects in the illuminated books that were printed from the same copper plate, regardless of the order in which they appear in individual copies; it does so automatically based on the bibliographic information included in our XML BADs.[17] Clicking on “Compare” beneath any impression of “The Ancient of Days” (object 1 in most copies of Europe a Prophecy), for instance, opens a window that displays every impression of the plate that is currently available in the Archive. Over the years, as the Archive moved from publishing only Blake’s illuminated books to his works in other media as well, Archive staff realized that objects in different media would not automatically display in the Compare window. In response to this situation the Archive’s Technical Editor, Will Shaw, revised the Compare code to allow for manual inclusion of objects in different media. In the image below, for instance, objects from The Small Book of Designs (a series of separate plates) appear alongside corresponding images from The Book of Urizen and Visions of the Daughters of Albion (both illuminated books). Like the integration of BIQ (though on a much smaller scale), this change reflected the logical development of an existing tool rather than feature creep run amok.

In many cases, however, feature creep reflects, not the logical expansion of an existing tool, but a kind of techno-utopianism (often felt most strongly by those team members least responsible for coding and programming) that, if allowed free rein, can quickly lead to unnecessary redundancy. At the Archive, the danger of feature creep is that every tool will be expected to do everything: the Compare feature, the Virtual Lightbox, the Related Works feature, and any number of other tools would all perform the same functions, leading to confusion for users and frustration for technical staff. As Morris Eaves has argued elsewhere, tools in the Blake Archive should not do the work of scholarship for the user, but should instead enable users “to make useful things for themselves. With tools, applied to the primary textual and pictorial materials, users construct the contexts most relevant to their purposes” [Eaves 2006].[18] Will Shaw, now Digital Humanities Technology Consultant at Duke University, notes that “containing feature creep is simply good software development practice; smaller tools load faster and may be more responsive to user input [while] multipurpose tools are almost certainly larger and possibly less efficient from a computational standpoint, not to mention that they can be unwieldy for users”  [Shaw 2012].[19] As new software development tools and web technologies emerge, project managers must work with programmers and content providers to determine which new features and tools will support the project’s mission and which will create unnecessary redundancies or tie up resources that might be better employed elsewhere. And they must make these decisions with an eye both to the project’s past progress and to its future growth.

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.

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.

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.

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.

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.