Revisiting the CDH Project Charter

In August 2019, the CDH published four of our project charters in response to increasing interest in our project management processes. Those processes have continued to evolve to meet new challenges, including a new research partnership chartered fully remotely (the Princeton Geniza Project ) and an experimental, genre-defying internal project (our research periodical, Startwords ). At the heart of both projects remains the CDH project charter, but it has undergone significant revision from the previous version. These changes are most visible in the charter for the Princeton Geniza Project research partnership, published in October of this year. What forces drove the revision?

Over the summer, the CDH conducted a week-long internal workshop on project management. Staff read and discussed selections from works like The Oxford Handbook of Project Management (2011) and Damian Hodgson and Svetlana Cicmil’s Making Projects Critical (2006). We used the concept of the “project ecology,” outlined by Oliver Ibert and Gernot Grabher in the former, to discuss how DH work frequently pushes collaborators to strive for novelty and innovation even as they aim to keep projects modular and reusable. With the latter, we reminded ourselves that projects are nothing if not socially constructed, and that “project management” can slip into a totalizing ideology if not carefully deployed. In applying these ideas to the CDH charter process, we drew several conclusions about what was working, and therefore worth preserving, and what needed to change in response to our experience with how projects worked in practice. To begin with the latter, we decided that:

1. Our charters needed to be more agile. In the past, charters attempted to see far into the future in too much detail, and they codified things that were likely to change later, such as when a particular set of features would be finished. In reality, the workflows that a team uses to achieve its goals are likely to change much less frequently than do its goals. Agile teams (which serve as the model for the CDH) also often work toward a goal of producing a demo or prototype rather than a finished project. Building with the mindset that you’ll ultimately throw something away—and that the bigger goal is answering important questions—helps the development process stay agile. The charter needed not only to capture, but to enact this approach.
2. Our charters needed to center design. Design is often treated as a means to an end of developing a project, rather than as a goal unto itself. In discussions of how a project planned to showcase innovation, design was frequently not involved except as a method of powering innovative technical features. Our previous charters treated design work as either implied, or proceeding in lockstep with development work. Design was also treated as synonymous with visual design and didn’t extend to cover architecture, behavior, or user experience. Our charters needed to integrate design with development and represent the many ways in which it was central to the project processes.
3. Our charters needed to foreground our values. A critical approach to projects necessitated thinking about the ways in which our values are implicit at every stage and led us to decide that we should surface them explicitly in our charters. As a community of researchers who collaborate on projects out of a desire to advance our fields and highlight work we consider important and timely, we must fully articulate those contributions and the motivations behind our commitment to a research partnership. We also aim to intervene on the side of those whose academic labor is precarious, such as graduate student project managers and undergraduate data workers, and to use the charter as one of several opportunities to recognize their labor and protect their time.
4. Our charters needed to specify the responsibilities accompanying roles. Naming someone the “PI” for a project has a fairly clear meaning in an academic context, but it doesn’t imply anything in particular about their responsibilities with regard to the project’s design and development. The CDH often (intentionally!) assembles project teams that bring together many different disciplinary contexts, which exacerbates the problem of identifying and allocating responsibilities. Even well-intentioned interactions during processes like design review can break down if the responsibilities for each role are not enumerated somewhere for easy reference. Our new documentation needed to clarify expectations for each role.
5. Our charters needed to document established practices and workflows. Though we may frequently adjust the scope and focus of a project, the CDH development and design team tends to adopt a set of tools and stick with them throughout the course of a project’s lifetime. This helped the team with easily replicability and meant that, in practice, we could document these workflows once and then reuse that documentation. When we work with new partners, including students and faculty who are unfamiliar with DH development, we could use our charter as the chance to provide them with this key background information.

In light of these lessons, we updated several important aspects of the charter:

1. The way work is planned. Instead of a detailed work plan, a CDH charter now includes a more abstract roadmap that divides planned work into stages. In the early stages, work focuses on assembling prototypes designed to help the project team answer key questions. Later stages on the roadmap are intentionally sketched out in less detail, on the assumption that they will be revised once more is known. The charter provides for regular project retrospectives that enable more accurate updates to the roadmap.
2. The role of design. The “project significance statement” now includes a “design” section that identifies how the project plans to innovate in the context of design as a field. Each of the phases of the roadmap also notes any planned design work, including usability testing and research, as a way of making our commitment to design more visible. The “roles” section designates project team members who are responsible for participating in important processes like design review, as well as their expected contributions to design-related activities.
3. The values of the CDH. We added a “technical” section to the project significance statement that identifies the potentially innovative contributions of the development team. The “roles” section now identifies the CDH technical lead as Co-PI, highlighting the role of the CDH as an equal partner in the research outcomes of the project. The “agreements” section—which is signed by the PI and the CDH faculty director—now includes a documented commitment to compensation and credit for all project labor.
4. The responsibilities of the project team. The charter lists each of the roles held by the project team and enumerates its responsibilities. Throughout the charter, team members are referred to by their role rather than their name, allowing for a rotation of team members into and out of certain roles. In defining roles and responsibilities explicitly, the charter also strives to empower the graduate project managers, who are in a particularly fraught position when their advisor is a PI for the project, and minimize the risk caused to them by academic hierarchies.
5. The tools and terminology used by the project team. Workflows and terms in common use at the CDH are now documented online for easy reference. Whenever these terms appear in the charter, they are hyperlinked to the relevant documentation. We’re also working on making our development process more visible to collaborators using this web platform via iteration reporting.

Amidst all these changes, many parts of the previous charter model remained largely intact, because the rationale behind them has not changed.

1. Adding context to the project. Everyone on a project team needs to be brought up to speed on the project’s academic focus and its history, including important events that may have shaped the direction of the project before it reached the CDH. Similarly—since all our major projects are built on a foundation of complex data—everyone needs to have an understanding of what constitutes the project’s dataset. The Princeton Geniza Project charter includes a graphic created by our UX designer Gissoo Doroudian to aid in understanding its complex data structure and bring parties into agreement about the data model the team will use throughout the process.
2. Making decisions about what’s in and out of scope. It is a core truth of project management that being able to exclude features of the project by early mutual agreement is a powerful tool. Making these decisions about project scope (particularly about limiting it) and documenting them in a signed agreement allow the development and design team to plan out the phases of the roadmap more accurately and with less fear of scope creep. Similarly, explicitly noting what’s in scope helps the team determine what constitutes the MVP (Minimum Viable Product) it intends to deliver.
3. Noting risks and dependencies. Making everyone on a project team aware of potential roadblocks remains paramount. For example, projects often come to the CDH with substantial digital history, including data that has been curated and assembled by other teams for other purposes. Working with the former or current stewards of this data often presents an initial hurdle to beginning development work. The Princeton Geniza Project is no exception, and its charter includes a discussion of the history of its data.
4. Publishing the charter as a citable document. The CDH is committed to open-source practices, not just for our code but for our project documentation. Although it may seem counterintuitive, the introductory section to the charter explains that the goal of publishing something that can be cited is not wholly in conflict with our desire to keep the document up-to-date. It is important to note, however, that the version we deposit is a digital snapshot of a living document. To minimize discrepancies, our practice has been to excerpt some parts of the charter into separate locations hyperlinked from the main document, and specify at the beginning of each section how and when it is to be updated.

You can find more information about the evolving CDH approach to project management, including charter templates, on our project management page. For more on the theories and practices mentioned in this post, look for Rebecca Munson and Natalia Ermolaev’s “Toward Critical Project Management for Digital Humanities,” forthcoming in Interdisciplinary Digital Engagement in Arts & Humanities. Join the conversation on Twitter by mentioning @PrincetonDH and using the hashtag #dhpm.