The importance of project planning has increased dramatically due to work shifting to hybrid or remote environments during the coronavirus pandemic, and there is now an even greater need to communicate across teams and between individuals. Centers for Digital Humanities and Digital Scholarship Centers (CDH/DSC) now widely practice project management, and project management skills specific to DH have been taught for over a decade in courses (Bailar and Spiro) and workshops (Siemens 343). Yet, communication needs themselves may shift in hybrid and remote contexts. For example, the Princeton CDH (Center for Digital Humanities) recently changed their project charter in response to how projects were working in practice. Two projects, including one chartered fully remotely, were key in the centre’s decision to make those changes. Their work plan became “a more abstract roadmap that divides planned work into stages” rather than a detailed plan because work changes as the projects develop (Budak). In other words, the work plan acknowledged inevitable uncertainties. While uncertainty has always been a reality in digital scholarship work because the field changes rapidly, remote work has encouraged a rethinking of how to plan for this uncertainty with more flexible models. In addition, remote work has increased the need to intentionally build trust in collaboration. Derek Thompson writes that “it’s hard to build true intimacy via Zoom and chat. One of the most profound things that I’ve heard in my two years reporting on remote work is the idea that digital communications can be a minefield for trust” (“The Biggest Problem”). DSC/DHCs now often need to create project planning documents that include uncertainty: this includes uncertainty in how the field is developing, how staff will build new skills to meet the new demands of the field, how external collaborators will respond to project plans that have uncertainty built into them, and uncertainty in working in remote and hybrid teams. While not all of these uncertainties are specific to digital scholarship work, uncertainty is constant in the field. For DSC/DHC, a central concern throughout project planning is the importance of balancing uncertainty with the need to trust staff and build trust with external collaborators (e.g., faculty). With this in mind, this paper aggregates project planning literature from the point of view of DSC/DHC management in order to analyze three questions inherent to project planning that have not yet been brought together: First, how can management determine the feasibility of taking on a project while also transparently communicating professional development needs to external collaborators? Second, how can management provide professional development opportunities for the team to build skills while simultaneously putting those skills into practice? Third, how can management invite faculty collaborators (or external collaborators more generally) to join in project planning while still ensuring that the project remains feasible in terms of the work the DSC/DHC is performing?

Determining Project Feasibility and Communicating with Collaborators

How can management determine the feasibility of taking on a project while also transparently communicating professional development needs to external collaborators?

DSC/DHCs often assist with a variety of digital projects requiring different methodologies and skill sets, and so there are nearly always uncertainties regarding how staff will be able to perform the tasks required for a project. There are a variety of helpful articles, blog posts, and presentations about project planning in digital scholarship, such as Ashley Reed’s 2014 article “Managing an Established Digital Humanities Project,” Sharon M. Leon’s “Project Management for Humanists,” and the panel “Project Management for the Digital Humanities” at the Digital Humanities 2018 conference (Ermolaev et al.), though none of the resources on project planning, to my knowledge, focus on DHC/DSCs and their specific needs. Staff at DSC/DHCs often have a breadth of expertise rather than a deep knowledge of a specific area. This is because staff have many responsibilities in supporting scholars across disciplines and at all levels at the university. They also often manage undergraduates who are eager to learn and contribute to the project. As these DS/DH teams work together to experiment with and apply different technologies to produce original research, learning new technologies and theoretical framings is often a significant part of the process. The Brown University Library’s CDS, for example, has specialists in different areas: data visualization, data management, GIS and mapping, text mining, web design, and digital publishing. The CDS is the central hub for digital scholarship across the university, and the staff work on faculty projects across disciplines. In this case, the specialist in text mining might support projects in the fields of public health, English, mathematics, and more. Sociologists often use STM, an R package for structural topic modelling, while other disciplines often use Latent Dirichlet Allocation (LDA) topic modelling using MALLET, a Java-based package for statistical natural language processing (Roberts). As the specialist works with diverse faculty, they may need to learn new programming libraries and even experiment with new programming languages to work on this broad portfolio of projects. If the teams involve undergraduate and graduate students, they will need time to learn about the field more broadly as well as learning relevant technical and/or theoretical skills. The text mining specialist will need to put together a range of responsibilities for the student team that will help them learn and grow. In addition, that same specialist will teach workshops on text mining, assist with classes, hold consultations with faculty and students, and more. These specialists maintain a wide range of skills within their area for good reason: a staff member’s breadth of knowledge about relevant technologies helps the project team, individual students, or faculty assess options and make the best choice of tools for their particular project. In a project that requires specific skills, however, the DS/DH staff will often need to experiment and learn new skills.

DS/DH projects that require experimentation and planning require a different approach than those that are more standardized. As Aaron Shenhar notes, the standard approach to project management is derived from a predictable and simple model that does not take into account changes or needs within the field. The project planning required by the US Air Force to integrate engineering and production of missile development programs, for example, requires a different set of considerations than in digital scholarship and other fields (Morris et al, “Introduction”). Digital scholarship is boundary-pushing, widely collaborative, and fast moving. The field often relies on multiple scholars and technical specialists from different disciplines. The traditional model of project management underplays the “role of uncertainty, learning, and informal processes” (Brady and Hobday 276). DSCs/DHCs often adopt models that are more agile to accommodate for how a project evolves. This often involves adapting project management frameworks to address issues specific to DH/DS projects (Ermolaev et al.). Table 1 shows some published project management resources by several CDS/DHCs. The table includes a short quote from the DHC/DSCs website that articulates the organization’s view of each respective project management document.

 Importantly, in each of these examples of project planning for specifically DHC/DSCs, agile project plans are important even though each centre goes about handling that in different ways.

A central reason project planning in digital scholarship is often agile and flexible is due to the field’s boundary-pushing tenets, making professional development necessary when taking on a project. There is uncertainty in professional development: while staff members can confidentially provide estimates of how long they need to learn a skill, they may be thinking optimistically rather than realistically, or they may have what Dan Lovallo and Daniel Kahneman describe as “optimism bias” (56). In addition, people who have been historically and strategically excluded from technical work, such as women and LGBTQ+ people, may not feel confident even if they know or can learn the skills necessary to do the work. While every centre has a different process for how to take on projects, the CDS at Brown University Library takes on projects that meet the following criteria: 1) The research question is in line with the Library’s strategic plan; 2) Staff are interested in the project and in learning the methodologies required for it; and 3) Staff are confident that learning the methodologies and/or tools necessary for the project is possible within the window of time needed. In my role as Director of Brown’s CDS, I encourage staff to take on projects that will challenge their skills. If someone has done successful topic modelling using MALLET and will need to learn R for a new project, I encourage them to embrace the uncertainty of learning the new skill in order to accomplish the project’s goals.

While it is important to encourage staff to pursue professional development opportunities, it is then also important to communicate the value of that uncertainty to external collaborators, such as faculty, so that they know work plans are tentative based on how the project develops. At Brown’s CDS, then, we document periods of uncertainty. We map out our project lifecycle, which includes a period of experimentation and learning for at least a couple months at the project’s beginning. It is important for the faculty member to be involved in the process of project planning so that they value and understand both the goals of professional development within the work plan and that timelines may need to be adjusted.

Transparently communicating the value of professional development to external collaborators is important if we are to build trust. There are many other aspects to a project that are uncertain. Team members can get sick or need to take a break from work for other reasons; more broadly, people may not be able to devote the time to the project that they originally expected. A classic way to handle this uncertainty is to overestimate: tell the stakeholder that a task can be done in two months when it can ideally be done in one. While there is good reason to do this in an attempt to overperform rather than underperform, good collaboration comes from a place of trust. Brown’s CDS focuses on trust building to work together in the best way we can. Building trust comes from speaking and writing honestly about the possibilities, limitations, and uncertainties inherent in working with a team.

Professional Development Opportunities and Putting Skills into Practice

How can management provide professional development opportunities for the team to build skills while simultaneously putting those skills into practice?

Many digital scholarship and digital humanities centres offer a range of services requiring their specialists to have breadth of knowledge on digital approaches rather than deep knowledge of one or two specific technologies. This means that the specialists in these centres are nearly always learning and, often, are not deeply familiar with a given technology needed for a project. When the team writes the charter for a given project, the breadth of knowledge they use to determine necessary methods may differ from the skills the project needs. One way to go about understanding how much flexibility a project might need is to chart out available staff expertise and compare it to the needs of the project. The below visualization demonstrates this: on the x-axis there are a variety of skills for which a digital scholarship centre might have staff support and on the y-axis there are numbers up to five (see Figure 1). There are also two stacked bars that indicate the technical and theoretical skills a team may have. The lines indicate the current skill set of the team, which may or may not be equal to what the project requires.

If, for example, a stakeholder would like to use topic modelling to explore a large quantitative dataset, a staff member may have the knowledge to run the MALLET application or topic modelling tool, but they may not know how to preprocess the dataset. Alternatively, a data scientist on the team may be well equipped to handle all the technical portions of the project, but they may not be grounded in the theoretical questions and concerns of using algorithms to understand human language. The numbers on the y-axis indicate the proficiency levels (Table 2).

Table 2: Proficiency Levels of Staff

In order to more accurately plan projects, it is essential to understand staff’s levels of expertise and what level is needed. This will allow the project manager to accurately estimate timelines and explain to stakeholders how a partnership will work. In addition, it is important for all stakeholders to understand up front that a project will require staff to learn more about the required technologies for the project so that all parties can decide if proceeding with the project is realistic. Learning is helpful long term as DHC/DSCs can, in theory, take on similar projects in the future and create more accurate project planning timelines. While the majority of the projects at the Center for Digital Scholarship at Brown University consist of using “off the shelf” tools like Omeka or Mukurtu, we also take on a few projects that, for good reason, require custom coding.

A current example of a customized project at our CDS is Stolen Relations: Recovering Stories of Indigenous Enslavement in the Americas, a community-based project led by history professor Linford Fisher. Stolen Relations is a collaborative effort to build a database of enslaved Indigenous people throughout time across the Americas in order to promote greater understanding of the historical circumstances of Indigenous enslavement and the ongoing trauma of settler colonialism. The archival documents for the project require a custom form and relational database for collection, transcription, and documentation. The data––documents on enslavement that indicate Indigenous presence or ancestry––require specific fields in the back end of the MySQL database. On the front end, the project displays the data alongside accompanying decolonizing contextual information. We are currently working with thirteen tribal nations in the Southern New England area in order to ensure that we are building a project that meets the needs of our community partners first. The CDS leads all technical aspects of the project, and we are eager to learn as we go to build this large and continually expanding database project. Our work over the years was devoted to producing a prototype and project idea; work that directly translated into the project winning a Digital Humanities Advancement Grant through the National Endowment for the Humanities (NEH) (“Stolen Relations Awarded NEH”). The CDS decided to take on this project seven years ago not only because of its importance as research, but also because our staff were eager to learn the technologies required for it. As no project like this currently exists, our knowledge of the relevant technologies was relatively low, and building a timeline presented a challenge. How long would it take to explore relevant JavaScript libraries, for example? How much troubleshooting would we need to do? How might we produce a data model for documents related to Indigenous enslavement that allows us to connect to other projects on enslavement more broadly using linked open data? These types of questions are hard to answer, and it is important to support staff in learning new technologies and research methods. In order to do this, we continuously adjust our project planning structure for customized projects, especially in how we create our timelines. While CDS did not have a project planning system when we initiated our work on this project, the chart below (Figure 2) displays our skill and experience levels when the work began:

The majority of the skills required for the project include those on the right-hand side of the chart: front-end design, front-end development (CSS, HTML, JavaScript), MySQL, and Python. While we were experts in Python, a level four in the chart above, there was a significant amount of learning that we needed to do in order to support other aspects of the project. If our current project planning process had been available at this project’s conception, we would have been able to confidently say that taking on this project would require a significant amount of time devoted to learning necessary technical skills and theoretical knowledge.

Involving Collaborators in Project Planning while Maintaining Project Feasibility

How can management invite faculty collaborators (or external collaborators more generally) to join in project planning while still ensuring that the project remains feasible in terms of the work the DSC/DHC is performing?

A study from the University of North Carolina at Chapel-Hill found that staff–faculty relationships can be challenging for a number of reasons. Working on project documentation together can help manage expectations and clarify the work the CDS/DHC will perform (Devereaux et al.). The study found that there are “misperceptions about roles and responsibilities” that can lead to misunderstandings, “communication challenges” at the interpersonal and university level, and skill gaps for faculty and staff in supervisory and managerial roles, compounded by variations in security, power, and recognition between faculty and staff. Documenting the project and team decisions in project planning are important for working with faculty collaborators and the rest of the team to ensure that everyone is on the same page. Where there are uncertainties in the planning document, those should be listed. Several scholars have written about helpful documentation including a “Collaborator’s Bill of Rights” (Clement et al), project charters (Ruecker and Radzikowska), and Memorandums of Understanding (MOUs) (“Digital Scholarship Framework and Policy”). Scholarly literature provides many excellent examples of documentation templates for digital scholarship, including those cited above. An adjustment that Brown’s CDS has made in our project charter template is to provide clarity about expectations for skill development along the way. Brown CDS charters explain the uncertainties we see in the project plan and where the timeline may need adjustments. The Brown CDS adapted a project charter document based on existing templates and processes from the Princeton CDH and the Emory Center for Digital Scholarship. Princeton’s CDH has graciously published their charter templates online as well as several examples of charter documents. Rebecca Sutton Koeser notes that participants at the 2019 Association for Computers and the Humanities (ACH) conference expressed renewed interest in how the Princeton CDH charters and plans projects. Princeton’s project charter documents are deeply considered, thorough, and extensive. They are a model every CDS or CDH should consult for project planning support and education. While the project team can adapt a project charter or MOU template for each project they work on, inviting faculty to participate in writing project planning can help manage expectations. The faculty member can write out a description of the project, identify priority items, and list their role on the project. In turn, staff on the project can also list their responsibilities. By documenting all aspects of project planning, the DHC/DSC and external collaborators can then begin a new conversation around any revisions to that project charter or MOU as needed. This allows changes around the project to be managed so that everyone on the team can weigh in, and the faculty member or external collaborator understands that such changes require rethinking the project plan as a whole.

In addition to this up-front documentation, Brown CDS puts ample work into writing a closeout document. This document explains, at the project’s close, the work the team has accomplished. Regardless of whether the project included technologies we were familiar with and confident about using, or whether everything went to plan or not, we create this document at the end of a project that details the process. This is not a new approach, of course, and there are ample examples of excellent closeout reports from other DS and DH centres. We were inspired by Emory Center for Digital Scholarship’s closeout document and their entire project planning framework is available on their website (“PM4DH”). Their closeout document offers staff members the opportunity to write about what they did, what worked well, what could have worked better, and more. It also offers a place to explain if the project charter goals were met. The Yale DHLab website also features an excellent Project Closeout document (“Project Planning”). In addition, The Endings Project, out of the University of Victoria, explores how to design and develop projects for digital longevity. In our closeout, we list any aspects of the project that remain unfinished, any technical debt the project acquired,1 necessary information to access the project (for example, passwords), dependencies, and a preservation plan. We consider our closeout document the “message in a bottle” to our future selves and others who come to the CDS after us. We keep the closeout document, the project charter, and all associated documents for the project in our shared Google drive and on the CDS server.

Planning for uncertainty within digital scholarship project plans is important for the quickly changing field, for remote and hybrid work arrangements, and for taking care of staff. In order to juggle the many priorities and projects in a DHC/DSC, it’s important to know the skill level of staff and understand how to include professional development and other forms of learning within timelines for path-breaking digital scholarship work. In order to plan for uncertainties, however, building trust with external collaborators and staff is essential. I have recommended a few ways to do so here. Rather than overestimating how much time it will take staff to do something, communicate with transparency the inherent uncertainties in completing each task within the expected time. This allows team transparency throughout the project and creates avenues for the team to share what they have learned. Documentation, too, is essential to communicate project goals and plans to reach those goals. If the faculty member or other collaborator wants to change the goal, the team has a document to reference and then revise accordingly with input from the full team. At the CDS at Brown University, we trust staff by building flexible month-by-month timelines of our work for highly customized projects. We trust staff and want to give them the flexibility to prioritize what they want to do and learn in a given month in order to build towards the overarching project goal. In turn, staff at CDS/DSCs also build trust with collaborators by producing honest estimates in timelines, documenting work, and transparently explaining how we work on projects.

Works Cited

Bailar, Melissa, and Lisa Spiro. “Introduction to Digital Humanities.” 2013. digitalhumanities.rice.edu/fall-2013-syllabus/.

Brady, Tim, and Mike Hobday. “Projects and Innovation: Innovation and Projects.” The Oxford Handbook of Project Management, edited by Peter W. G. Morris, Jeff Pinto, and Jonas Söderlund, Oxford UP, 2011, doi.org/10.1093/oxfordhb/9780199563142.003.0012.

Budak, Nick. “Revisiting the CDH Project Charter.” 15 Dec. 2020. cdh.princeton.edu/updates/2020/12/14/revisiting-cdh-project-charter/.

Center for Digital Scholarship. “Projects.” library.brown.edu/create/cds/projects/. Accessed 23 Nov. 2022.

Clement, Tanya E., et al. “Collaborators’ Bill of Rights.” Digital Pedagogy in the Humanities, edited by Lynne Siemens, 2021, hcommons.org/deposits/item/hc:31187/.

“Data Curation.” The Center for Digital Humanities at Princeton, cdh.princeton.edu/research/data-curation/. Accessed 23 Nov. 2022.

Devereaux, Diana, et al. “Transforming Staff-Faculty Relationships: Closing the Great Divide.” ULEAD, 2019.

“Digital Scholarship Framework and Policy.” University of Michigan Library, www.lib.umich.edu/about-us/policies/digital-scholarship-framework-and-policy. Accessed 12 July 2022.

The Endings Project. University of Victoria. endings.uvic.ca/. Accessed 15 November 2021.

Ermolaev, Natalia et al. “Project Management for The Digital Humanities.” DH 2018, 21 June 2018, Sheraton Maria Isabel, Mexico City. dh2018.adho.org/en/project-management-for-the-digital-humanities/.

Koeser, Rebecca Sutton. Document ALL the Things! The Center for Digital Humanities at Princeton University, Aug. 2019, cdh.princeton.edu/updates/2019/08/12/document-all-things/.

Leon, Sharon. “Project Management for Humanists: Preparing Future Primary Investigators.” #alt-academy. Media Commons, 6 May 2011. mars.gmu.edu/handle/1920/8048.

Lovallo, Dan, and Daniel Kahneman. “Delusions of Success: How Optimism Undermines Executives’ Decisions,” Harvard Business Review, July 2003, pp. 56–63.

MALLET: MAchine Learning for LanguagE Toolkit. University of Massachusetts Amherst. mallet.cs.umass.edu/. Accessed 7 September 2011.

Morris, Peter W. G., et al. “Introduction.” The Oxford Handbook of Project Management, 1 Feb. 2011, doi.org/10.1093/oxfordhb/9780199563142.003.0001.

Omeka. Digital Scholar, Roy Rosenzweig Center for History and New Media. omeka.org/. Accessed 15 November 2021.

“Phase 5: Closing.” PM4DH: Project Management for the Digital Humanities, 3 June 2016, scholarblogs.emory.edu/pm4dh/closing/.

PM4DH: Project Management for the Digital Humanities. “PM4DH: Project Management for the Digital Humanities.” scholarblogs.emory.edu/pm4dh/. Accessed 15 November 2021.

“Project Charters.” The Center for Digital Humanities at Princeton, cdh.princeton.edu/research/project-management/charters/. Accessed 20 Nov. 2022.

Project Closeout. Yale University Library Digital Scholarship Services. dhlab.yale.edu/assets/docs/Project-Close.pdf. Accessed Oct. 2021.

Radzikowska, Milena, and Stan Ruecker, editors. Design and the Digital Humanities. May 2022.

Reed, Ashley. “Managing an Established Digital Humanities Project: Principles and Practices from the Twentieth Year of the William Blake Archive.” Digital Humanities Quarterly vol. 8, no. 1, 2014, www.digitalhumanities.org//dhq/vol/8/1/000174/000174.html.

Roberts, Margaret et al. STM: Estimation of the Structural Topic Model. version 1.3.6, 18 Sep. 2020. CRAN.R-project.org/package=stm.

Rodgers, Stephanie. “Creating a Work Plan.” PM4DH: Project Management for the Digital Humanities, 3 June 2016, scholarblogs.emory.edu/pm4dh/creating-a-work-plan/.

Rodgers, Stephanie. “Defining a Project’s Scope.” PM4DH: Project Management for the Digital Humanities, 3 June 2016, scholarblogs.emory.edu/pm4dh/defining-a-projects-scope/.

Shenhar, Aaron, Dov Dvir. Reinventing Project Management. Harvard Business School Press, 2007.

Siemens, Lynne. “Project Management and the Digital Humanist” Doing Digital Humanities Practice, Training, Research. Edited by Constance Crompton, Richard J. Lane, and Ray Siemens. Routledge, 2015, pp. 343–357.

“Stolen Relations Awarded NEH Digital Humanities Advancement Grant.” Brown University Library News, 19 Aug. 2022. https://blogs.brown.edu/libnews/stolen-relations-neh-grant/.

Stolen Relations: Recovering Stories of Indigenous Enslavement in the Americas. indigenousslavery.org/. Accessed 15 November 2021.

Thompson, Derek. “The Biggest Problem With Remote Work.” The Atlantic, 11 July 2022, www.theatlantic.com/newsletters/archive/2022/07/remote-work-wfh-debate-management/670482/. Accessed 21 July 2022.

Yale DHLab, “Project Planning.” dhlab.yale.edu/guides/project-planning.html. Accessed 23 Nov. 2022.