This article will describe the ongoing project plan to create a digital edition of a rare manuscript from a stationery bookbinder and manufacturer of account books. The project’s manuscript, the Works Manual and Business Guide in the William Townsend and Sons collection is part of an internationally known special collection of the history of print materials and bookbinding within the Rochester Institute of Technology’s libraries system. It offers an intimate and complex look into the little known world of nineteenth-century bookbinding practices referred to as stationery or vellum binding. This type of bookbinding was considered practical binding for the use of business, understood as binding of lesser value to letterpress binding used as decoration. The manuscript is idiosyncratic enough that the scanned visual display, even with flat transcription, is inadequate for scholars and online readers. Figure 1 showcases a representative page from the manuscript. The text is not organized in any conventional structure. The index is unreliable and filled with topics such as “missives” and “jottings.” Dates appear, but are not chronological. There are no chapters or paragraphs. In other words, there is no clear textual hierarchy. Furthermore, there are many numerical figures and formulae, often recorded in messy lists and tables. We have decided to encode the manuscript following the Text Encoding Initiative (TEI) Guidelines to provide the data and metadata necessary for the manuscript to be accessible (TEI Consortium).

Given the manuscript’s complexity, the numerous TEI editorial decisions, and the rigorous documentation of our processes, the team found project management—hierarchy, roles, timelines, and deadlines—to be a challenge. As we developed our project management approach, we found that we needed more flexibility than current models allowed for in their design. We began to experience our project life cycle as one that was non-linear, and we needed a management approach purposefully designed to treat continuous change as an interdependent project phase. As such, we identified a project management model that is informed by an iterative, cyclic approach to project stages and collaborative decision-making so as to address the complexities of the project. Project Management for Development (PM4DEV) is an adaptive management approach, consisting of six stages: Initiate, Plan, Implement, Monitor, Adapt, and Close (Siles, “The Project Management Cycle”). In this model, the project proceeds through an iterative and adaptive cycle as it unfolds: “Plans are changed based on feedback from the monitoring process, changes in the project assumptions, risks and changes in scope, budget or schedule” (Siles, “What is Iterative Planning?”). There is constant movement between the core stages of Plan, Implement, Monitor, and Adapt. This cyclic approach emphasizes that outside of the usual hierarchical structure every team member will collaborate closely.

We will describe the process by which our team has navigated a cyclic process and deeply collaborative team structure to transcribe and encode this rare primary manuscript according to TEI Guidelines, for a volume that does not easily lend itself to representation by those Guidelines. This management approach was particularly important for emphasizing the change and adaptation that were continuous to encoding the manuscript according to TEI Guidelines. In our description, we will offer examples of team success navigating project management and applying encoding practices.

Literature Review

Salient themes in the literature for this project are team dynamics and student skills and training. The nature of digital scholarship projects necessitates smooth collaboration among a team (Siemens; Leon). Historically, humanities scholars are sole actors in their research and output, and not all are trained in collaborating well with others to produce successful projects. Collaboration is a skill that must be learned by scholars and those who work with them, and by nature digital scholarship projects like ours require a diverse set of skills and tasks that need to be split between team members.

In her 2009 article “‘It’s a Team If You Use “Reply All’: An Exploration of Research Teams in Digital Humanities Environments,” Lynne Siemens surveys teams and generalizes the results to produce insights on team functionality and dynamics. In essence, she finds teams seek clarity in tasks, structure, and goals while attempting to maintain good working relationships. Importantly, Siemens found that productive working relationships between team members may be more important than having clearly defined tasks (228). The implications for practice Siemens highlights all involve deliberate action—by the project manager, training intentions for team members, deliberate commitment by team members to the project (230).

The literature consistently discusses team roles in varying levels of prescriptive role delineations. In her article “Project Management for Humanists: Preparing Future Primary Investigators,” Sharon M. Leon addresses the role of a project manager at length. A project manager must be able to “balance the intellectual work of the project and the mundane processes that are necessary to successfully accomplish the project’s goals.” The project manager is also in charge of communication, which is vital to team stability and happiness. Regardless of the stage a project is in, project managers need to keep team members on task, balance to dos, and push forward research and outputs while encouraging a welcoming atmosphere with clear communication (Leon). Katrina Anderson et al. provide a different approach in their article “Student Labour and Training in Digital Humanities.” They suggest that, “[t]he distribution of authority should be as diffuse as possible” in order to encourage the transparency necessary for a successful project (para. 29). The authors also emphasize the recognition of the skills of students (existing skills and training of skills) in the digital scholarship process, another major theme in the literature. The literature recognizes the skills of students in the digital scholarship process. Students need to learn to collaborate as a vital skill for teamwork, and specifically learning project management skills is a key form of learning on projects. Teaching students project management methods is a central way to help build their context knowledge and expertise (Anderson et al.; Rockwell and Sinclair). Training must be a deliberate and planned activity and included in a model of active teaching (Anderson et al., para. 30).

A pressing literature topic for all digital scholarship projects is that of sustainability and planning for project closure. Susan Brown et al.’s 2009 article “Published Yet Never Done: The Tension Between Projection and Completion in Digital Humanities Research” offers insight into how to consider the life of an evolving project. The authors write that “[t]he case of the Orlando Project[…] reveals an arbitrariness, even a fictiveness or contradictoriness, to the notion of completion of the project as a whole or even of its major online product” (para. 1). Text encoding projects (such as the Orlando Project) can continue seemingly endlessly because there are always more layers of decisions to make regarding what could be useful to encode. Much of the literature focuses on generating products that will remain accessible technologically, such as via licensing choices and technology specifications (Brown et al.; Goddard and Seeman; Fitzpatrick; Stapelfeldt et al.). The Endings Project from the University of Victoria published principles to follow to build a project prime for long-term conservation (“Principles”). These principles are exhaustive and potentially vital for the long-term health of a project. Lisa Goddard and Dean Seeman’s chapter “Negotiating Sustainability: Building Digital Humanities Projects that Last” outlines tenets to create a project ideally suited for preservation in a university library. We follow the data and documentation principles outlined by The Endings Project and look to their other principles, as well as scholars like Goddard and Seeman, for guidance as we consider our project’s longevity.

Reviewing Project Management Models

Several project management models specific to digital scholarship projects exist. When reviewing these models in aggregate, patterns among them emerge. This is a sign that there is consensus about the requirements of managing a project, but the nature of the patterns and overlap also suggest a potential lack of flexibility and indicate that without all components of the suggested project management aligning, managing a successful project will be difficult or impossible.

Existing models for digital scholarship project development include PM4DH (Project Management for the Digital Humanities) out of the Emory Center for Digital Scholarship, UCLA’s Library Special Collections Digital Project Toolkit, and that outlined by Siemens in her work across publications (e.g., “It’s a Team”; “Project Management”; “Project Management and the Digital Humanist”). The general steps in these models emphasize methodical action in planning and executing projects and highlight a mostly linear trajectory of project development. Table 1 demonstrates a sampling of project models and their defined steps.

Table 1: Project Management Models in Digital Scholarship and their Defined Steps

PM4DH serves as a standard example of successful project management in the world of digital scholarship creation. The stages outlined of Proposal, Initiation, Planning, Execution, and Closing definitely help keep a project on track, but they do not leave space for ambiguity or projects that may require a more iterative approach—whether the team not be quite ready to set all the steps, the budget is a moving target, or the infrastructure for personnel that comprise an ideal team is not in place. We will highlight how our project environment and structure encourages (requires) an even more iterative and flexible approach.

Other resources developed by institutions to facilitate effective project management within specific use cases like the Women Writers Project’s (WWP) Guide to Scholarly Text Editing are extremely useful, if not official models. The WWP’s comprehensive guide is particularly salient to our encoding project and has been instructive at every step. It is incredibly detailed and methodical—nearly to the point of being overwhelming from the perspective of a relatively new digital project manager.

The agile project management approach, designed for software design and used in technical projects of various kinds including digital scholarship, is designed (as the name suggests) for maximum flexibility. The Agile Manifesto includes “emphasis on individuals and interactions” and “responding to change over developing a plan” (Beck et al.). These items are inherent to the model we use in our project, as collaboration and adaptation are key. Miriam Posner has observed the agile model at work and describes its beneficial use as well as its flaws in Logic magazine. A key difference between agile and the approach we use is an emphasis on speed. The agile approach is not only fluid but also fast-paced. Working with undergraduate students in a text encoding process, however, we continue to find the language of cycles and adaptation through unlimited stages of process attractive, as we understand slow work, as well as economical decision-making. Posner offers a significant caution, however, as she describes a tension between democracy and responsibility. She warns of the potential for this model to create “a work culture that is increasingly revealed to be toxic for women, people of color, and members of gender minority groups.” Finally, while referencing corporate entities, she notes, “No matter how flexible the workplace or how casual the meetings, the bottom line has to be the organization’s profits” (para. 49). Posner’s observations are valuable reflections on assumptions regarding collaboration, flexibility, and change and on team diversity, decision-making, and stakes.

The literature in the field speaks to our project design and the relationship between team members, and we are heavily informed by the ideas and structure laid out by them. Our project is informed by the literature and models present in it, but its design is different. The project is unpredictable and constantly changing, and our approach must deliberately account for the time our team will spend encountering change and modifications.

Cyclical Model: PM4DEV

We are using the cyclical project management model put forth by PM4DEV, designed for and marketed to nonprofit organizations. Their Project Management Cycle defines six phases: Initiate, Plan, Implement, Monitor, Adapt, Close. It emphasizes the inherent iterative and interlocking nature of these phases. The phases move in a “spiral fashion,” allowing for project uncertainty, dynamic change, and regular adaptation. At every phase, the cycle “allows opportunities to review the original project assumptions and plans” (Siles; “The Project Management Cycle”). Given that our project timeline has corresponded with the COVID-19 pandemic, we needed to manage a fully online team process and negotiate student accountability while they juggled their academics with illness, housing, and various other personal issues. PM4DEV is designed explicitly to respond to environmental issues and dangers. A project might or will return frequently to any of the phases as adaptations are made to meet internal or external challenges. The cycle persists throughout the project’s lifecycle until the project reaches the Close stage.

This paper traces decisions through the project phases Initiate, Plan, Implement, and Close. We will emphasize how the project negotiates a fluid process in each of these phases, circulating to Monitor and Adapt through several interactions before progressing. At each phase, we will provide specific illustrations to describe necessary monitoring and adapting iterations. These illustrations will use two TEI editorial decisions: representing (1) numerical and financial information and (2) the disperse network of people and organizations appearing in the manuscript. From the outset, we knew the research questions would include both of these aspects of the manuscript, and so we started to work with the elements <num> and <persName>. Even when we believe we may have reached some closure regarding these elements, we have had to review assumptions and make changes. As we move through these illustrations of our cyclic process, we will describe how undergraduate students successfully collaborate to work through the knowledge cycle and build expertise to ask good questions, raise hard questions, and recommend future directions. Our students thrive with this model, as they know to expect it to be iterative and understand that while sometimes frustrating, it encourages trial and assumes there will be error.

Project Format and Institutional Context

The institutional context and team make-up, as well as the complexity of the project, required that we begin with a management approach that mirrored the “cycle of knowledge” we fully expected to encounter. Our management approach supports risk-taking by relying on consistent monitoring in every phase. It fosters collaborative problem-solving review and allows for adaptation at any point in the project.

This project aims to make the rare bookbinding volume Works Manual and Business Guide accessible to readers. It is the most complex volume, given its record of day-to-day activity of a print firm. The work manual contains inserted receipts, price lists, and leather samples amidst details about workday life, commercial transactions, labour, and unionization. Our project will use TEI Guidelines to capture the structural, renditional, and conceptual features of the text. The resulting digital edition will feature a searchable database of people, places, and dates illuminating such key topics as the firm’s social networks, information on the men, women, and apprentices who worked for the firm between 1830 and 1910, and the web of economic partners with whom the firm did business.

The project began through collaboration, when in January 2019 the project directors met with special collections curators to discuss the manuscript collection and its significance, and from there discussed starting an encoding project on one of the manuscripts. From 2019–2021, the library’s digitization lab imaged all five volumes in the collection and made them available for public view in the online digital collections with accompanying descriptive metadata.

This project is situated at a large four-year technical institution in the Northeastern United States. The blend of STEM (science, technology, engineering, and mathematics), arts, and liberal arts degrees contribute to a dynamic campus. Our technical institution does have significant computing resources available, but little coordination exists to support faculty research projects that require setting up websites or allocating server space. While the library has many resources to support digital scholarship projects (digitization lab, institutional repository, online digital collections), only one library staff member’s time is dedicated to the assistance in developing or managing these projects with researchers outside the library. The library has its own IT staff but does not dedicate space or time from IT resources to develop collaborative projects of this nature. As such, the project is being built by the small core team developing it, and project management becomes even more important when the small team needs to be self-sufficient.

The team consists of four members: one faculty member, one librarian, and two student researchers. We also consult with a respected expert in the field of TEI who has helped us shape the project and anticipate needs. Our manuscript is complex enough to require detailed attention to the TEI guidelines, so our consultant has been particularly helpful in this regard. As two scholars relatively new to daily digital project management, we learned important lessons along the way, but our approach to building the project from the ground with our consultant and students allowed us to embrace a constantly iterative management plan that relies on deep collaboration, and propels the project forward with successful readjustments. We have taken inspiration from our unique and intricate material to complicate current advice about project design and management.

Given the institutional context, we knew we needed to make decisions that would allow for a project manageable by a small team. The co-directors work together to ensure the success of this project. They mutually arrange and lead meetings, manage relationships and consultations, assign tasks, and ensure we use best practices and provide documentation for the project. The faculty co-director serves as the primary investigator and directs research questions. The librarian co-director establishes the system of documentation and initiates most internal communication and meeting minutes. We typically employ undergraduate students for two-year terms on a part-time basis. They (to date) have had no experience with TEI, so they train with collaborators in XML markup using tutorials, reviewing other TEI projects, and learning our project’s TEI practices. Students serve as encoders and central team members. They contribute to the intellectual content of the project and participate in key decision making. We take advantage of students’ experience as project managers, as they are now enrolled in project-based courses every semester and have skills we sometimes take for granted. It is worth noting that at our technical institution, students may be more familiar with iterative project management, coding and text editors, and tools like GitHub than at other institutions. As a STEM university with an emphasis in undergraduate scholarship, the university’s policies regarding students as researchers align with the UCLA Student Collaborators’ Bill of Rights (DiPressi et al.).

Our small team operates without rigid roles or distinctive areas of expertise. We find our team dynamics and elements of success match those outlined by Siemens in the article “It’s a Team,” namely that productive working relationships and respect within the team regardless of training may be more important than absolute clarity of tasks (228). We have worked with our undergraduates to build this project from the beginning, and they provide vital input and (we hope) appreciate the experience of generation and revision that is core to digital scholarship of this kind. We work with the undergraduates to develop collaborative goals and work towards them—another thing Siemens highlights. Our highly collaborative environment supports experimentation and risk-taking as we make encoding decisions, in major part because of our built-in system of review.

Students take ownership of different aspects and decisions of the project, and are drawn into the generative aspects of researching and co-creation. The students take independent lead on project facets or important decisions: one student worked for months on compiling representative examples of numbers and measurements that appear—perhaps the thorniest set of decisions for our manuscript. Eventually they said (with some frustration), “everything is a measurement!” Another student leads the encoding review and independently created reference documents for GitHub and code formatting. They describe the project as “dang cool.” Recently, a student started a database of the hundreds of people and places recorded in the manuscript in anticipation of developing an orgography, which will use TEI structure to provide contextual information about Sheffield organizations and businesses. This student shares interesting tidbits that emerge from their contextual research, such as a water company from the 1850s that still exists today as a pub. When we are all involved in imagining the world of this bookbinder, we are all more invested. Our project management promotes this kind of collaborative, sometimes meandering work in which, as one student said, “we build things.”

Examples of Success

This description of our modified project management approach incorporates successful project milestones, demonstrating how an inherently iterative process and deeply collaborative teamwork can be especially productive in nonlinear projects. Any TEI project requires encoding flexibility and consistency, and we understand that the project plan may go through dramatic changes if original assumptions are challenged. In our experience, the success of our project can be attributed to the way we approach project management to deal with changing assumptions within a collaborative environment. We discuss three of our model’s six phases: Initiate, Plan, Implement, (and eventually Close). We emphasize, however, how two additional cycles, Review and Monitor, occur in each of the phases. At no point has our project spent its time in just one phase, as we continually adapt to accommodate new procedures to reflect our deeper understanding of the manuscript. Here we will illustrate how the cyclic model works by following phases of that model and highlighting management milestones:

• Initiate: Customizing the encoding schema using TEI guidelines

  • Monitor and Adapt

• Plan: Developing robust internal documentation

  • Monitor and Adapt

• Implement: Testing encoding and revising documentation

  • Monitor and Adapt

As we show how these phases are interlinked, we will include examples of success from our project work.

Project Stage: Initiate

Throughout the project’s Initiate phase, we generated our TEI customization, built our internal documentation, and created a schema which guides (and confines) what we encode. Early in the project, we needed to decide what information from the manuscript to capture and how to make that information accessible. Once we had an initial orientation to the manuscript, it was evident that a simple transcription would not be meaningful. We decided to use text encoding with the TEI guidelines. At this early moment in the project timeline, given the size and complexity of the project, we knew our project management model would need to be cyclic, allow for iteration, and rely on undergraduate students in a collaboration that would guide our project. Over the course of the project, we have collaborated with undergraduate students Jacob Pachron, Jay Long, Cael Burkhardt, Kadin Benjamin, and Jamie Cortigene.

A major early decision involved applying structure to the unruly text. The text is not organized in any generic structure. It might be described as a manual/historic financial document/commonplace book. There are no chapters, paragraphs, or punctuation–no discernible textual hierarchy. The TEI requires the text to be divided (using the element <div> for division), so the team had to develop its own theory of hierarchical divisions that would allow us to place order on an unorderly manuscript. We decided to apply categories to the divisions, using an attribute, @type, on the division element. We generated a list of categorical labels, starting with what we thought might be recognizable literary and rhetorical features, and everyone on the team reviewed the manuscript to identify literary tropes or rhetorical forms. We compiled a very long list of possible values for @type: allusion, aphorism, hyperbole, etc. On a first pass, we realized our divisions were too granular to be meaningful, could not be applied consistently, and ended with extensive encoding time. The team re-worked the division types into a manageable list by trusting our own understanding of the text as a guide: Moral Principle, Work Ethic, Shop Advice, Active Instruction, Log, and Undetermined. The team members each encoded 12 pages using this shortened list for @type and compared our encoding for consistency. We had all marked the place for a <div> (element) and used the same @type (attribute). This first work product is the result of a cycle of project Initiation, in which the team made decisions and adapted the encoding practice after extensive review. While we considered this decision to be Closed, we were fully aware it may change in the future. Indeed, we have returned to this practice three years later to consider adding a subtype for Instruction that would denote bookbinding_instruction. We continue to monitor this encoding decision at strategic points in our project cycle, especially as new team members join and raise new questions.

Our initiation to the manuscript helped us decide that we would customize the full TEI Guidelines to address the specifics of our project. To do this, we reviewed 18 of the 23 total TEI modules in detail, each member assuming primary responsibility for approximately five modules.

Team members synthesized module contents and recommended elements for inclusion in our schema. We had two productive flashpoint meetings that led to the creation of our schema. The first was a long meeting at which we reviewed the TEI module recommendations from all team members. Student encoders participated fully in this process. They made smart recommendations, objected with good questions and comments, and contributed to the difficult and minute decision-making necessary.

For example, one student encoder took on the task of recommending how we ought to represent the many tables and formulae that occur throughout the manuscript. The student gave reasonable first recommendations for the complexity of options in the module that addresses tables. Given the hand script and the various nineteenth century algebraic notations, we knew we would return to this module. We continue to struggle with the encoding of tables, and our markup has moved from Initiate to Plan and cycled back with various Review and Monitor iterations. Nevertheless, this student encoder was thrilled at the prospect that tables in the manuscript could be represented in some meaningful way. Figure 3 shows an example page with interlocking tables.

At this point of project Initiation, the collaborative approach to modules not only moved us through an important phase in our project but served to solidify our collaborative relationships, encoder confidence, and the team’s commitment to the project.

At the second flashpoint meeting, we officially constructed the schema. We started with the TEI’s schema-building tool Roma and all elements we had identified as relevant. What we anticipated would be a long meeting went smoothly and required only two hours of our time. The meeting was productive because we all started to feel more comfortable with the TEI Guidelines and we could see our project design at work. The group made collaborative, sometimes tedious decisions quickly because of the work reviewing and monitoring we had done to that point. Students uncomfortable with “iteration” began to expect it and appreciate their role in every phase of the project. This meeting was not only productive and successful for delivering a product—it was energetic, participatory, and celebratory. While this iterative process sometimes seemed uncomfortable, we nevertheless recognized the value of deliberate decision making, always being adapted. The cycle could also provide momentum.

Review and Monitor

What might be termed sub-cycles occur at successful milestones or intervals during the life of the project. Each sub-cycle is a process of reviewing and monitoring for the next cycle. There are two specific examples of review between our Initiate and Plan phases: names and numbers. A student encoder who started by recommending the TEI Lite element for encoding names of people understood quickly that we could not easily distinguish between “Thomas Fox” the person and “Thomas Fox” the organization. Many of the organizations were named for their proprietors, and we would need to rely on context to guide our encoding. In addition, “Thomas Fox & Sons of Sheffield” required encoding that would be descriptive of people, organizations, and places. As we continued in our cycle, the decision remained open as we considered encoding for more detail.

Perhaps the best example of the interlocked cyclic phases and reviewed decision-making is our constant work with the numbers in the manuscript. At first, we thought it would be most economical and also meaningful to simply encode each number that appears with the <num> element. However, as we all read pieces of the manuscript again, we realized we needed to challenge our assumptions about how to manage numbers. Numbers were rarely acting simply as symbols or labels. A number was nearly always a unit in a more complicated numerical expression. As a group we asked what we could capture with TEI. Once again, the complexity of the manuscript required that the team collaborate to interpret how numbers were being used, whether to count something, measure something, or purchase or sell something.

Project Stage: Plan

In our project management approach, the Initiate phase informs the Plan phase but remains open indefinitely, with knowledge that there will always be modifications. At every phase, the plan may need to change course. The risk is that a cycle will spiral for too long, decisions will not be made, and momentum will be lost. The way to limit such risk is to build tools that provide stability over time. Our documentation has to be robust enough to manage decisions during every phase as it is used consistently in real time. In our approach, attending to documentation is perhaps the most important, high-stakes activity as it must record continuous changes across phases, account for encoding practices that have been agreed upon by the team, record team member tasks and progress, update a schema, etc. This documentation changes often and yet provides a framework to which we all contribute and a map to which we refer in every meeting and in online chats.

We have developed a few core pieces of documentation—the primary of which is the Internal Encoding Document (IED). We started the IED on the recommendation of our project consultant in 2019, and it has evolved into a twenty-page document that details decisions for the manuscript encoding by heading: “Abbreviations,” “Lists,” and “Punctuation,” among many others. This serves as the authoritative documentation for our encoding decisions and encompasses all decisions—how we markup tables, how we define text blocks, how we capture the complex measurements that appear. We use the document to describe complicated examples in the text, provide encoding snapshots, and use comments to track team member input and where we stand on decisions. We have been working on this document since we began the project and consistently revise it as we refine encoding practice or decide to capture additional textual features.

Other documentation includes our encoding schema, a specialized file type that applies rules to the TEI files we create within our text editor. The schema remains an evolving document, but the method by which we record changes in encoding practices and editorial features is standardized. To date, our documentation includes meeting minutes that track all action items, who is responsible, what is expected, and expectations for the next project meeting. Action items can then be extracted and made into an ongoing list of items “completed” or “open” or “need more information.” We use a central spreadsheet to track all pages in the manuscript along with the initial encoder assignment, reviewer assignment, and status (“in progress,” “completed”). A shared Google Drive includes an “Essential Documents” folder with the most frequently used and updated information. Team members each keep a file of their own work in progress. We use GitHub for version control and centralized sharing of encoding files, and we are all supported by the text editor Oxygen.

Because the team worked with a high degree of uncertainty in our initial phase, we became comfortable with a cyclic, collaborative project management method. However, as with all projects, it became clear that we would need to develop strong communication habits, with each team member asking questions and providing feedback. We meet weekly in person or remotely and communicate frequently on Discord, a text and voice messaging tool. At key moments, when work has been paused or at semester breaks, we schedule day-long meetings—someone has discovered something that affects how we encode people’s names vs. businesses; someone seeks clarification for how we categorize measurements that appear in table cells, etc. We discuss issues and possible solutions openly, and all four team members provide input on our decision. The students, as the primary encoders of the IED document, are crucial to this process as they can speak directly to changes in the encoding rules and how we might practically implement what we decide.

Because every team member contributes to the documentation, we all know where and how to access information. Each of us can review the information to make sure we are on the right track. Our IED is now a lengthy and detailed document with images from the manuscript and concrete examples for encoding. The IED will never truly be closed while the project is ongoing. As long as we are working on the project, we will consider documentation an open stage in our cycle. Additional tasks will require documentation at various points as our orientation to the manuscript continues to mature.

Review and Monitor

This Plan phase was interlocked with the Initiate phase as we returned to the TEI modules for customized encoding. The information we learned from the Initiate phase regarding names and numbers again offers two examples of our cyclic approach and collaborative decision-making. This review guided our encoding customization and the documentation in our IED. When an undergraduate encoder pointed out that a customized module of TEI would allow us to capture more information than just names of people, we cycled back to the TEI Guidelines to try out <persName> and <orgName> and <placeName>. Given the importance of the firm’s business and its network, we decided to use this encoding. As such, Thomas Firth & Son is encoded as both a person’s name and an organization’s name.

<orgName type=”proprietorName”>

<persName>

<forename>Thomas</forename>

<surname>Firth</surname> 

</persName> &amp Son

</orgName>

We recorded this encoding practice to our IED and added it to our schema. While an iterative process requiring new encoding practices can seem chaotic, the changes in the IED prevent us from getting stuck or lost in our process.

In the Initiation phase we decided to document the encoding for numbers with the generic use of <num> as in this example:

<num>57</num>hours.

However, our consultant pointed out that for some cases we were encoding a measurement and would need to decide whether to treat this and other numbers as such. As we attempted to use the TEI Guidelines to encode for <measure>, we found it difficult to determine unit, commodity, and quantity—attributes of the element measure. At this Plan stage we struggled quite a bit. Certainly, here we encountered the risk of a cyclic approach. We considered various encoding strategies, most either nonconformant or not economical. At this point we paused and decided to use this encoding:

<time ana="#labor" when-iso="P57H">57 hours</time> per week

The use of the <num> element was only a temporary practice that would allow us to retrieve these cases once we had a fully-formed plan. We were able to indicate minimally that some “thing” was being measured. Or that a number was acting as an expression. We knew that this encoding was insufficient. Our documentation would need to be monitored closely as the encoding practices changed and were adapted–then reviewed and changed again.

Project Stage: Implement

In a project management cycle, every phase is interdependent with the previous stages. In addition, several iterations in a Plan stage may intersect with iterations in both the Initiate and Implement phases. We have indeed closed some structural and semantic decisions, like punctuation and capitalization, as well as text emphasis like bold or underlined words and letters. We have settled on how to encode for jotted or marginal notes and textual rotation. Now we have moved to more sophisticated encoding decisions that require deep, granular understanding of the manuscript, as well as greater familiarity of the TEI Guidelines–informing the possibilities and limits of encoding for our primary source document.

Rather than focusing on the final execution of our project plan, we have been attuned to success at every phase, but mainly so at the intersection of Review and Monitor. Higher level encoding decisions often remain in this intersection for lengthy periods of time. As a team, we discuss, try out, and evaluate recommendations. Circumstances may change (and often do), so that these decisions will be modified yet again. Our team works through and around the cyclic approach to project management, as each iteration leads us to more information from the manuscript, more experience with TEI, and new project milestones.

Review and Monitor

The Implement phase is no less interconnected in the cycle than are the other phases. Working in this phase, we understood more deeply what decisions needed to be reviewed and we monitored those closely in our documentation. In terms of names and places, we began to ask research questions that clarified for us which questions were important. We decided we needed to encode more robustly, with street addresses. A student suggested an early practice for encoding a case like this: “Allen Son Cutlery Manf 73 Granille St.”

<orgName type=“proprietorName”>

        <persName>

<surname>Allen</surname>

</persName>Son Cutlery Manufacturers

</orgName>

<placeName>

<street>73 Granille Street</street>

</placeName>

Our team recently evolved our recommendations on names to provide detailed information about a business network. We shared our student encoder’s recommendation with our consultant and they responded as a part of the team, with a sincere collaborative spirit. Our student encoder also noted that there are many organizations within Sheffield named for the proprietor, and some could be difficult to distinguish. As an example, there is Lee & Wigfull, which makes metal plates, and Joshua Wigfull & Sons, which is a flour mill. Both are important to bookbinding. While our in-line encoding for <persName> and <orgName> and <placeName> has gone through each phase, we continue to encounter odd cases that must be reviewed and documented. The work will most certainly follow this iterative cycle for some time before it is closed.

The team continues to struggle with measurements. These often appear in lists, lists within lists, lists within tables and tables that put out formulae (see Figure 3). To avoid too much time for encoding and risk of uncertainty, we have decided to limit a first pass at encoding to measurements of currency. These include firm finances: purchases of materials, payments for gas and water, and the cost of labour. In this example we indicate that a foreman’s labour is paid in the recorded currency: “Type 1 working foreman 1.17.0.”

Type <num>1</num> working foreman <measure ana=“#labor” commodity=“currency” quantity=“444” unity=“pence”> 1.17.0 </measure>

Given the prolific anti-union sentiment in the manuscript and the space given to recording payments to employees, we decided to encode for measurements of labour and wages. After cycling through phases to determine what numerical information to encode, and after spending much time in review, we have added this practice to our documentation. Again, our understanding of the manuscript and options for encoding practices will change as we monitor consistently throughout the project, before the IED is closed, and until we are satisfied with this encoding procedure. It is true that the team may never truly be satisfied with what encoding will allow or whether some encoding decisions are economical. We knew we could not manage customized encoding for all numbers. In terms of other decisions, for example, we determined we could not encode for paper sizes and account book price keys without additional research and context. As Kretzschmar notes, “the idea of finishing big humanities computing projects once and for all is just an illusion” (para. 15). However, we hope this is also a part of our iterative cycle and that given more time, expertise, and funding, we could have the option of returning to this process.

Takeaways and Conclusion

The cyclic approach is well suited to an unpredictable project that is iterative by nature and benefits from real collaboration. By focusing on a project team rather than project manager, we are relying on collaboration, fostering expertise, and participating in shared learning. As a result we are making better decisions and moving forward together.

We align our approach to team collaboration with Anderson et al. in their 2016 article “Student Labour and Training in Digital Humanities” when they state, “Too often training is viewed as a necessary step towards the project’s completion, rather than as part of an active model of teaching and learning. Training must be a deliberate and planned activity that is formally budgeted and accounted for in the project’s timeline[…]” (para. 30). The authors also emphasize the importance of students learning from one another as a form of professionalization.

Students have been so involved in the development and ongoing management of our project, that they help us consider new questions and add personal deliberation and reflection to the project. The review of the manuscript included editorial questions regarding how much information to encode, how to represent textual features, and how much historical-cultural context can be captured. Each student found some interesting way of contributing to these editorial decisions that would affect encoding later. One undergraduate student became very interested in primary sources regarding the historical-cultural context of bookbinding techniques and the family firm. Another student decided to investigate the handwriting. They researched nineteenth-century penmanship and sought out the rare books library curator. They remain agnostic about handshift as issues like pen and ink types, as well as change in hand over time, and with the writer’s age and health. While one student only recently came onto the project, they have become intrigued with the content of the manuscript, sharing unusual passages. They drew our attention to an anecdote in which a carriage passenger put his head out of the window (“God bless him”) to admonish the driver. The road was rugged before the railway was put in. These vignettes bring the manuscript to life—and tell us something about the timeline as well.

At this point, we cannot describe any clear examples of the Close stage. In the cyclic approach we are using, however, closure might also be iterative. Clearly, closure would be obtained upon completion of a deliverable—a view that aligns with Brown et al. in their 2009 article about the Orlando Project, in which they posit the importance of focusing on discrete deliverables in order to create a structure for completion (para. 10). However, a team might celebrate closure upon phase completion, or at designated times during the project’s life. Nevertheless, we consider our project to be in one of the phases we describe here, with much review and monitoring ongoing. The cyclic management approach allows us to work toward task completion as the project develops through interrelated phases. It is likely that even after a first pass at encoding the entire manuscript, our project may want to explore a research question regarding book history or union labour. A project would need to develop detailed encoding for measurement if they wanted to understand the cost of binding materials or to record union labour, hours, vacation, and wages. The project may not actually reach the Close phase (Kretschmar). Indeed, projects using markup like TEI are designed to remain open, with a continuous need to accommodate subsequent researchers and research projects. We share the TEI understanding that, even at a local level, “text encoding is evolving and progressing,” and “scholars’ use of digital resources is constantly changing” (TEI Consortium). As such, our team will decide when we have provided enough encoding for the text to be meaningful and have come to a point at which we agree to the editorial principles as they exist in the IED, and publish an edition of the manuscript. Even here, however, the project will be in a Review and Monitor phase as it links out to other texts in the collection, scholars in the history of the book with additional research questions, and the TEI community who may have suggestions or who may contribute encoding to some piece of the manuscript.

Works Cited

Anderson, Katrina, et al. “Student Labour and Training in Digital Humanities.” Digital Humanities Quarterly, vol. 10, no. 1, 2016,  digitalhumanities.org:8081/dhq/vol/10/1/000233/000233.html#.

Beck, Kent, et al. “Manifesto for Agile Software Development.” 2001, agilemanifesto.org/.

Brown, Susan, et al. “Published Yet Never Done: The Tension Between Projection and Completion in Digital Humanities Research.” Digital Humanities Quarterly, vol. 3, no. 2, 2009, digitalhumanities.org/dhq/vol/3/2/000040/000040.html.

DiPressi, Haley, et al. “A Student Collaborators’ Bill of Rights.” 8 June 2015, humtech.ucla.edu/news/a-student-collaborators-bill-of-rights/. Accessed 3 Mar. 2023.

Fitzpatrick, Kathleen. Planned Obsolescence. New York University Press, 2011.

Goddard, Lisa, and Dean Seeman. “Negotiating Sustainability: Building Digital Humanities Projects that Last.” Doing More Digital Humanities, edited by Constance Crompton, Richard Lane, and Ray Siemens, Routledge, 2019, pp. 38–57.

Guide to Scholarly Text Editing. Women Writers Project, 2007, www.wwp.northeastern.edu/research/publications/guide/. Accessed 29 Mar. 2019.

Kretschmar, Jr., William A. “Large-Scale Humanities Computing Projects: Snakes Eating Tails, or Every End is a New Beginning?” Digital Humanities Quarterly, vol. 3, no. 2, 2009, digitalhumanities.org/dhq/vol/3/2/000038/000038.html.

Leon, Sharon M. “Project Management for Humanists: Preparing Future Primary Investigators,” #alt-academy, 6 May 2011, mediacommons.org/alt-ac/pieces/preparing-future-primary-investigators-project-management-humanists. Accessed 12 Aug. 2021.

PM4DEV: Project Management for Development Organizations, 2021, www.pm4dev.com/. Accessed 20 Sept. 2021.

PM4DH: Project Management for the Digital Humanities, Emory Center for Digital Scholarship, scholarblogs.emory.edu/pm4dh/. Accessed 8 July 2021.

Posner, Miriam. “Agile and the Long Crisis of Software.” Logic, issue 16: Clouds, 27 Mar. 2022, logicmag.io/clouds/agile-and-the-long-crisis-of-software/.

Rockwell, Geoffrey, and Stéfan Sinclair. “Acculturation and the Digital Humanities Community.” Digital Humanities Pedagogy: Practices, Principles and Politics, edited by Brett D. Hirsch, Open Book Publishing, 2012, pp. 177–211, www.openbookpublishers.com/htmlreader/DHP/chap07.html.

Siemens, Lynne. “‘It’s a Team If You Use “Reply All’: An Exploration of Research Teams in Digital Humanities Environments.” Literary & Linguistic Computing, vol. 24, no. 2, 2009, pp. 225–233, doi.org/10.1093/llc/fqp009.

Siemens, Lynne. “Project Management.” Digital Pedagogy in the Humanities, 2020, digitalpedagogy.hcommons.org/keyword/Project-Management. Accessed 6 May 2021.

Siemens, Lynne. “Project Management and the Digital Humanist.” Doing Digital Humanities: Practice, Training, Research, edited by Constance Crompton, Richard J. Lane and R. G. Siemens. Routledge, 2016, pp. 343–357.

Siles, Rodolfo. “The Project Management Cycle.” PM4DEV, www.pm4dev.com/pm4dev-blog/entry/10-the-project-management-cycle.html. Accessed 20 Sept. 2021.

Siles, Rodolfo. “What is Iterative Planning?” PM4DEV, www.pm4dev.com/pm4dev-blog/entry/what-is-iterative-planning.html. Accessed 9 Mar. 2023.

Stapelfeldt, Kirsta, et al. “Strategies for Preserving Digital Scholarship / Humanities Projects.” Code4Lib Journal, 53, 2022, journal.code4lib.org/articles/16370.

TEI Consortium, editors. TEI P5: Guidelines for Electronic Text Encoding and Interchange. Version 4.5.0, updated Oct. 22, 2022. TEI Consortium, www.tei-c.org/Guidelines/P5/. Accessed 28 Feb. 2023.

The Endings Project. University of Victoria, 8 Mar. 2022, endings.uvic.ca/principles.html.

“UCLA Library Special Collections Digital Project Toolkit.” UCLA Library, www.library.ucla.edu/location/library-special-collections/programs-projects/digital-projects-special-collections. Accessed 25 Oct. 2021.

Works Manual and Business Guide. William Townsend and Sons Ledgers and Account Books, 1885–1915, no. 3. Rochester Institute of Technology Libraries Digital Collections, albert.rit.edu/record=b3949118~S3. Accessed 28 Feb. 2023.