 Hi, everyone. I'm Ashley Champaign. I'm the head of Digital Scholarship Project Planning at our Center for Digital Scholarship at the Brown University Library, and I'm so pleased to be with you for this C&I project briefing series. I'm going to share my screen. Today I'm going to talk with you about flexible project planning for digital scholarship centers, a framework for managing multiple projects of varying technical complexity. This is what we'll do. I'll give an overview of a digital scholarship center. This is based on Brown University Center, but also in my research over the past couple years of other digital scholarship centers and how they work with project planning. I'll then give an overview of some unique challenges for digital scholarship centers and project planning, and then offer a framework for how to handle those challenges. And then I'll offer two specific examples applying the framework, one of which is a customized project, and the other one is using off-the-shelf tools. And then finally I'll share with you our closing closeout document, which we finish after we finish any project. And this is something we just finished a couple months ago in our CDS. Digital scholarship centers often assist with a variety of digital projects that require different methodologies and skill sets. You can see the list of workshops and methodologies that our CDS works on here. This talk focuses on a framework for how to flexibly adapt project planning documents around the experience of a given team and the technical and theoretical skills a project requires. What I want to present is this framework for how to think about the skills and resources a university has and how to create a project planning framework that will work for you and your university. So this framework, of course, comes out of our CDS at Brown. And while there are a variety of helpful articles that really helped me think through project planning, I'll mention Ashley Reed's Managing and Established Digital Humanities Project, Sharon Miohn's Project Management for Humanists, and the conference panel at the Digital Humanities 2018 conference, Project Management for Digital Humanities. This talk instead focuses on digital scholarship centers and the wide array of projects these centers often take on, manage, and partner with in developing projects from conception to final product. So in digital scholarship, planning for a project that involves methods the specialists are deeply knowledgeable about requires a different approach from a project that involves substantial experimentation and learning along the way. Digital scholarship work more often falls into the latter category of experimentation. And so that has to be taken to account in project planning. And so I propose a way for digital scholarship centers to plan projects based on the knowledge their staff have and the knowledge their staff want to have. Many digital scholarship and digital humanities centers offer a range of services, which requires the specialists who work in the centers to have a breadth of knowledge on digital approaches rather than a deep knowledge. So our CVS, for example, has seven specialists in different areas, data visualization, data management, GIS mapping, text mining, web design, and digital publishing. Our center is the central hub for digital scholarship across the university. And we work with faculty projects across disciplines. What this means is that often staff at our digital scholarship centers focus on a breadth of knowledge rather than a deep knowledge. So here I list an example of a text mining specialist. That's me at Brown. This is actually a true story. So here the text mining specialist works across disciplines. The different disciplines use different methods. So I came to Brown knowing mallet, a Java based package that is seen as the kind of gold standard for humanists. And I met sociologists who use STM in our package. So I learned that. But also digital scholarship staff need to deeply know the theoretical aspects of digital scholarship work. They need to think about why to choose certain technology over others. What are the ethics of the work? They often need to know how to train undergrads in the field and teach workshops as well. As these teams work together to experiment with and apply different technologies to produce original research, learning new technologies and theoretical framings is often the significant part of the process. So these are some of the unique challenges and opportunities in project planning for digital scholarship centers. It is easier to produce timelines when deliverables with deliverables when a team is deeply knowledgeable about the technologies the project is using. For example, a team that has used Omeka, an open source web publishing platform for dozens of projects in the past will probably be able to accurately explain how long it will take them to assist with a project using Omeka. It is much harder to chart timelines when a significant part of the process will be made up of learning. How can someone who has never worked with a given technology accurately estimate how long a given project will take? Even if the staff member has significant experience with a given technology, that person may be directing a team of undergrads who may require more of the staff member's time than expected. Rather than rely on individuals to explain how long a given task will take, which is nearly always difficult to do, this talk proposes a framework for estimating project timelines and writing project charters based on how the team understands the necessary technologies and methodologies relevant to a given project. So I use Project at RCDS as examples of how others centers might use this framework. One way to go about understanding how much flexibility to put in a project timeline and other documentation is to chart out what level of expertise the staff will need to have and what level of expertise they have now. This visualization demonstrates on the x-axis a variety of skills that a digital scholarship center may have staff support. So text analysis, web platforms, data viz, front end development, other programming needs. On the y-axis there are numbers up to five. There are also two stacked bars that indicate the technical and theoretical skills a team may have. The colors within each category indicate the current skill set of the team which may or may not be exactly what the project requires. Loosely, we may say that the numbers on the y-axis are as follows. Zero might be no knowledge. Five might be a multi-year experience rewriting, expanding and using the code or software and original contributions to the theoretical impact of a given methodology. By using these broad categories I am making the point that even experts in a given technical methodologies often do not know everything there is to know about them. There is always something new to learn and it is important for project planning to understand what level of expertise the staff have and what level they need to have for a project. In addition, it's important to understand up front that a given project will require staff to learn more about the given technology so that you can decide if it's a project you want to take on. Learning is helpful long-term at the center in theory as you can take on similar projects in the future and create more accurate project planning timelines. While the majority of the projects at RCDS consist of using official tools like Omeka or Makoto, we also take on a few projects that for good reason require custom coding. A current example of this is stolen relations, recovering stories of an indigenous enslavement in the Americas, a community-based project led by Linford Fisher. Stolen relations is a collaborative effort to build a database of enslaved indigenous people in order to promote greater understanding of the historical circumstances of indigenous enslavement and the ongoing trauma of settler colonialism. The archival documents that we are collecting, transcribing and documenting on enslavement indicate indigenous presence or ancestry and they require specific fields in the back end of the MySQL database. On the front end, the project displays data alongside accompanying decolonizing contextual information. For this important project, we are working with 13 tribal nations in the New England area and we need to build a custom framework to address the feedback we continue to learn from our community partners. Our 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 but also because our staff are eager to learn the technologies and because we've never done a project like this before and no project like this exists, our knowledge of the relevant technologies was relatively low. How long would it take to explore relevant JavaScript libraries? How much troubleshooting would we need to do? These types of questions are hard to answer and it is important to support staff in learning new technologies. In order to do this, we adjusted our project planning structure for these customized projects, especially in how we create timelines. While our CDS did not have a project planning system five years ago, the chart here demonstrates how we could incorporate the framework to identify where our skill and experience level is compared to what the project needs. The majority of the skills we needed for the project included those on the right hand side of the chart. Frontend design, frontend development, MySQL and Python, we're experts in Python but there's a significant amount of learning we need to do to develop the project. While not every project requires a deep level of expertise of all the necessary technologies for project stone relations does, so if we had our project planning process ready at the 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 technological skills and theoretical knowledge. Compare this to a project that we did last summer in OMECA. We've worked with OMECA before, we knew the fields the metadata spreadsheet needed. It was much easier to predict a timeline because our technical and theoretical skills were what the project needed. Creating accurate timelines is difficult and of course even more so when a project requires learning along the way as in the case of stone relations. While project managers can often predict how long given tasks will take on a project that uses familiar tools, we sometimes do not know enough to even list the tasks required for highly customized projects such as stone relations. One way to manage this is to map out a timeline that focuses on the coming months worth of work rather than the full project timeline. We decided this was best for us. While it is ideal to have an overarching timeline for the project and to think towards the project's end of life as much as possible, we found it helpful to chunk our work month by month in order to determine the workflow for that period of time. Our timelines for customized projects or as we call them signature projects are therefore quite specific. For example, in a given month we might list what JavaScript library we're researching or what part of the project's input form we're investigating. Focusing on a month by month timeline gives flexibility to our staff to learn as they go. In addition, it allows us to make more accurate timelines in real time as we know which phase of work we're in and how far we have to go. It's not our goal to share a fixed end date for work in a project that requires significant learning. It's rather our goal to be transparent that we will need to learn throughout the process and so we can only provide estimates of our time frames. However, by tracking the individual tasks specifically throughout a project lifecycle, we can prepare a fairly accurate estimate of when we can expect to finish specific tasks for the project. Compare this month by month approach for a signature project with that of a project that uses OMECA. We knew exactly how long the project would take beyond the month timeline and so we were able to map it out over the course of several months. There are many excellent examples of project charter templates for digital scholarship that would accompany the timelines so I won't say much more about that here. An adjustment that we made to our project charter is to provide clarity about how we expect and anticipate needing to learn along the way if that is indeed the case. So the Brown CDS adopted a project charter document based on existing templates and processes from the Princeton Center for Digital Humanities and the Emory Center for Digital Scholarship. They are a model every CDS or CDH should consult to learn about project planning. While this talk focuses on managing uncertainty and project planning based on a team's familiarity and experience with given technologies for the project, 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 or more broadly people may not be able to devote the time to a project that they originally expected. A classic way to handle this is to overestimate. To tell the client, the faculty member that you can get a task done in two months when you can get it 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. We need to build trust to work together in the best way we can and building trust comes from speaking and writing honestly about the possibilities, limitations, and uncertainties that are inherent in working with a team. And in addition to the project charter, so then we have templates to write an addendum if the faculty member wants to change the original plan. And the project manager maintains close communication and offers regular updates. We handle uncertainty by building relationships based on trust and transparency. The closeout document, which is also one of the closing points of this talk, is a foundational component to our work process for every project. On the slide here, I list ours. It's short. That's because we only want the most essential information in this document when we finish a project. This document explains the work the team has accomplished. Regardless of whether the project included technologies we were familiar and confident with or everything went to plan or not, we create this document at the end of the project that details the essential information that our CDS needs to know and our future staff at the CDS need to know. This is not a new approach. Of course, there are ample examples of excellent closeout reports at other institutions. We were inspired by Emory's digital scholarship closeout document, and the Yale DH lab also has a great project closeout document on their website. In addition, the Indians project out of University of Victoria is an excellent project that explores how to design and develop projects for digital longevity. In our closeout, we list any specific aspects of the project that remain unfinished. The technical debt the project required of any necessary information to access the project, for example, passwords. We list dependencies and a preservation plan. And by technical debt, I mean any of the decisions we made on the project that produced work for us later. For example, by hard coding rather than writing a function that doesn't need to be directly edited. We consider the closeout document, the message in the bottle to our future selves and others who come after us. We keep all of these documents in our shared Google Drive on our server. One central aspect of the framework I propose is trust. It's important to build community with trust and transparency. At RCDS, we trust staff by building a month-by-month flexible timeline of the work we need to do. We trust and want to give staff the flexibility to list what they want to do and learn in a given month in order to build towards the overarching project goal. In turn, we also build trust with the faculty member by producing honest estimates in our timelines, documenting our work, and transparently explaining how we work on projects. Project planning has always been important, but as work has shifted due to the coronavirus pandemic, team members now increasingly work in hybrid or remote contexts, and thus there's an even greater need to communicate across teams and individuals. So this framework offers a way for digital scholarship centers to assess the needs of new projects or existing projects and determine the level of expertise the staff has in relation to what the project needs. In turn, it also provides digital scholarship centers the opportunity to consider whether it makes sense for them to take on a project that requires a significant amount of staff time to learn a given methodology or if they would do better to specialize in certain areas. Thank you for having me. It's been a pleasure.