Module A5: Project Documentation Checklist

Module Status: Drafting in Progress | Ready for Testing | Tested
Current Module Downloads: Module A5 Activity Worksheet and Excel Worksheet

Effective Sustainability Plans Require Effective Project Documentation

If your team has already created a sustainability plan for your project, whether by means of having run the Socio-Technical Sustainability Roadmap before or by other methods, you are well on your way to seeing your work persist for as long as you want it to. This module focuses on making sure that your sustainability plans, as well as your general project activities, are well-documented. Effective project documentation is the foundation for any sustainability plan as it allows for past decisions to be communicated to future project team members without relying solely on interpersonal or institutional memory.

If your team has not yet created a clearly documented sustainability plan for your project, the Socio-Technical Sustainability Roadmap should set you on your way. You may have noticed that each module asks you to create some form of written documentation. Some teams may prefer paper-based documentation, while others may prefer digitally-stored documentation, but either way, creating a recordkeeping system for your project is the backbone of your sustainable success.

If this is not your first time through the Roadmap, and you have already set up a system for project documentation, please use the time allotted for this module as your opportunity to consolidate any past documentation that may have gotten away from you and to assess the effectiveness of your recordkeeping system for your team.

Reliable Sites of Project Documentation

Knowledge production and dissemination, particularly within the context of team-based digital scholarship, necessitates the coordination of a complex communication network. In a collaborative, interdisciplinary space, data is gathered and research is conducted in a variety of environments, but meaningful information is best ultimately stored in a reliable, shared location.

Within the specific context of the Visual Media Workshop at the University of Pittsburgh, we have been proactively working on a communal and consistent system for storing the documentation that emerges in the process of conducting our collaborative research. Although each researcher has their own data-collection and drafting processes, the team is making a concerted effort to apply a common strategy to its communal research documentation by using the concept of “reliable sites.” Reliable sites of project documentation designate those locations that we agree are communally-kept and community-essential, and they are therefore watched over by us all. We all also commit to keeping these locations filled with timely, reliable, and accurate information. In our practice, we have found that there are a few keys to maintaining effective “reliable sites,” and we offer ours below.

Keep the Number of Locations Small

The fewer places there are to find a document, the more likely it is that the document will be found. Conversely, the fewer places there are to store a document, the more likely it will be stored in the appropriate location that is accessible to all.

In some environments, you may be using a cloud storage infrastructure such as Box or Dropbox, in others you may be using a local nework drive to share information. In yet others, Google Drive will be used as the location to store documents. In any or all such situations, we would like you to consider that the issue is not where you store your information, but in how many different locations you store the information. We highly recommend consolidating your reliable sites of project documentation into the smallest number of places possible. These will then become your go-to places to look for and to store the work that needs to persist over the long-term.

Keep the Folders Simple

One way to think about beginning a plan for effective, communal project documentation is to consider implementing a simple, but consistent, file folder structure for your digital documentation. Humanities projects are as variable as they are numerous, and so it is not likely that there is a one-size-fits-all approach that can be made to work for every team. That said, the following division of documentation has worked well for a number of projects here in the Visual Media Workshop, and we offer it to you as a possible model. We not only encourage you to adapt and adjust as needed, we know that such changes will be almost necessary.

In our process, we have found that keeping the number of top-level folders low is utterly key. Each double-click is both a decision and a commitment, and to encourage good recordkeeping behavior, it should always be as clear as possible which folder will contain the information sought and, conversely, in which folder the information is best stored. Records managers call these “big buckets,” and they are designed to capture large-scale project concepts rather than finely-tuned ideas that can rarely, if ever, reflect all of the highly personal understandings of a project.

The following set of four top-level folders has proven quite useful in our lab-based, team-focused work:

1. Articles-Books-Links

It may be easiest for humanists to think of this folder as the location for the secondary source information salient to your work. Distinct from the data (primary source material) used by the project, this folder could, on some projects, be conflated with its “Bibliography,” and on others with its “Library.” In the main, because this folder is shared by numerous people, we have found that subfolders in the Articles-Books-Links folder work best when associated either with the main intellectual themes of your project or with the work of individual researchers on your team. Zotero is a commonly-used online platform that works a bit like this folder, and it can certainly be used for this purpose.

2. Data

This folder contains the actual data used to power the digital project. This information could take any form, and might also simply be copies of the data being used on a separate web platform. Alternatively, it could contain past drafts and iterations of the data. Be sure to label this information as accurately as you can at every step of the way. You may think you’ll remember why this or that particular spreadsheet was created, but without descriptive metadata, that decision-making process will almost certainly be lost to the sands of time.

Organizing your data is a large and critically important component of the sustainability of your project. The published work of professional data stewards and data curators can be your guide, but if you happen to be able to work directly with one of these information professionals, they can offer you unbelievably salient advice about the best ways to store your data in order to keep it accessible and usable for the foreseeable future—even after you might feel that you are finished with it yourself!

3. Process Documentation

This folder contains all of the administrative documentation for your project. You may have, for example, correspondence with your web host or memos traded with your department chair. This is also the location you might consider storing any project management information that you might choose to export from a project management platform, such as Asana, or an inter-team chat platform such as Slack (see below for more on these technologies). This folder would also be an ideal site to store the documentation created during the Socio-Technical Sustainability Roadmap.

4. Sites of Production

This folder has proved to be, hands-down, one of the best innovations of this recordkeeping system for the collaborative work of the VMW. It basically correlates to the notion of “creative outputs” as covered in Module A1. As noted there, larger-scale digital projects are often faceted and usually have more than one, single manifestation. Digital humanities project teams are expected to present results at conferences, create different types of articles and books, produce exhibitions, and other such project deliverables. In this folder, you might therefore consider making a subfolder for each. Examples might include, “NEH ODH Grant 2020,” “DHQ Submission,” or “AHA 2019 Presentation.” Within these folders can then be found all of the bespoke or custom-created work needed for these particular instantiations of your work.

Back Up Your Reliable Sites

Often, when participants first hear the phrase “reliable sites of project documentation,” they assume we mean technologically reliable, and we do! Including your reliable sites of project documentation as part of your back-up plan is part of the work of Module C2: Access & Backing Up Your Work. However, to reiterate, a truly reliable site is one that is known to, actively used by, and accessible to all appropriate team members. The more intelligent, focused attention a site has, the more reliable it becomes.

Drafts and Working Documents

As you think through how to store your project documentation, you might find that you have preferences about where to store your records based on where you are in the drafting process. For example, here in the VMW, we use Box as our reliable site to store final, definitive project records, but we prefer Google Docs to draft and work on documents collaboratively while drafting. In this situation, we have policy to transfer our documents out of Google Docs and into Box once they reach their distributable form. Otherwise put, we do not consider Google Docs to be a site of reliable project documentation, only Box.

While it might be ideal for us to begin using the collaborative Microsoft Online features that now come coupled with our service on Box, the project team does not like the affordances of this workflow. In cases such as these, your recordkeeping processes will always need to strike a balance between finding a consistent way to document the team’s work and striving to minimize its impact on the way the team wants to work. Recordkeeping failures are often tied to asking the recordkeepers—that is, the whole team in this context—to perform inconvenient or burdensome activities.

Project Management Information and Interpersonal Communication

Project management platforms, such as Asana, provide an excellent venue for assigning tasks and tracking active projects. Here in the Visual Media Workshop, we do not consider the information created and stored in Asana as a reliable site of project documentation. If we want to maintain a record of what is going on in that platform, we will export that information, date it in the filename, and add it to the “Project Documentation > Asana Exports” folder. And, to be frank, we rarely do!

However, you could certainly feel free to deem Asana to be a reliable site of project documentation for your project. The trade-off here rests between multiplying the number of places you go to look for information, and keeping the information stored in the precise systems that produced it. Either way you go will be fine, if the decision is made mindfully. Simply make sure that your choice aligns with the preferences of the team, and also consider that, while you can more-or-less control the persistence of the data that is stored on your shared server, you cannot control if and when Asana goes offline, shuts down, or is sold to a new company with different priorities than before.

Slack, to an increasing degree, provides a chat environment that is both efficient and effective for brief, but nonetheless significant, exchanges of information amongst project teams and even entire intellectual communities. Just as with Asana, we do not consider Slack to be a reliable site of project documentation in the VMW. If you will, we treat it a bit like we used to use the phone, back in the day. If decisions are made, they are documented outside of Slack and stored accordingly. You can feel free to decide otherwise keeping in mind the caveats above.

Marking Copies of Record

Because drafting and documentation processes vary so widely across project teams, and it is also often the case that “future you” will want to know less about the drafting process than the final documention process, you may find it helpful to design a way to denote proactively which documents and/or folders contain information documenting bonafide decisions that the team has made on the content, context, and/or structure of your project.

Email

Please do not forget to consider that giant morass of communally inaccessible records that can be your personal and professional email accounts. If your team is in the habit of making major decisions over email, it would behoove you to create a reliable site of project documentation for this information. It is even possible to create a team email account to which final decisions are sent and to which all appropriate members of a team have access. If you do this, please note that you are creating another reliable site of project documentation and it should be cared for accordingly.

If you choose to keep record copies of your email interchanges outside of an email system, do make sure that, wherever the emails end up, the names and email addresses of all senders and addressees are maintained, as well as all dates, and all attachments. As a heads-up, it can be relatively difficult to do this by printing to paper/PDF due to the variability in the types of attachments you might be receiving via this mode of communication.

Additional Resources

Cervantes, Gina. “To Bucket or Not to Bucket…” The Texas Record, October 17, 2017. https://www.tsl.texas.gov/slrm/blog/2017/10/to-bucket-or-not-to-bucket/.

Gilliland, Anne, and Sue McKemmish. “Archival and Recordkeeping Research: Past, Present and Future.” In Research Methods: Information Management, Systems, and Contexts, 2nd edition, edited by Kirsty Williamson and Graeme Johanson, 79-122. Prahan: Tilde University Press, 2017.

“Keeping Records.” Jisc. Last updated October 1, 2012. https://www.jisc.ac.uk/guides/project-management/keeping-records.

(Module last updated December 2018)

Previous Module: Module A4: What are the project's sustainability priorities? Continue on to Section B
Back to Section A Overview