By Corey Schmidt
Transitioning from being a project manager to a program manager presents unique challenges, especially in the context of archives and archival description. In 2020, I was the project manager leading a migration from Archivists’ Toolkit, our archival management system, to ArchivesSpace. After successfully migrating two libraries and five repositories, my colleagues expressed a desire not just to keep the software updated, but to keep track of how we were doing archival description and what we could do to keep our data in good shape for the next migration. It was one thing to build and develop scripts, workflows, and documentation to move to a new system, but another thing to make it sustainable for the future. As I transitioned into this new role, I learned a few key takeaways. First, make sure you create understandable documentation about technical processes, such as updating software, installing plugins/addons, and running scripts against the system. Second, automate what you can to make keeping track of archival description and content easier for you and those making the content. Third, participate in a community of practice by sharing your knowledge with others and asking for help. All these lessons made me see the humanity in our processes by mitigating stress and anxiety, automating tasks to remove burdens, and helping others to foster a caring community.
When creating documentation, you are actively building against future stress and anxiety for yourself and others when dealing with tasks irregularly. While managing our data migration process, I kept a working journal to track things that worked and things that didn’t, people to reach out to, and an assortment of resources to consult when I came across them. This journal turned into a gold mine of ideas and eventually a formal report of how the migration went, summarizing the good and the bad, which allowed us to review and improve on this process when moving into the long-term maintenance phase. Since I built custom Python applications and scripts to manage our data workflow from ArchivesSpace to our finding aid website (https://github.com/uga-libraries/aspace_scripts, https://github.com/uga-libraries/ASpace_Batch_Export-Cleanup-Upload), I implemented docstrings in my code, issue tracking in GitHub, and recording processes in Microsoft Teams. This helped me understand where my scripts encountered issues, what fixes I implemented, and why I built things the way I did. This allowed me to reference this documentation when building new scripts and editing existing ones. I heavily utilized GitHub’s Wiki pages to include information useful for our users and future code maintainers, such as a user manual (https://github.com/uga-libraries/ASpace_Batch_Export-Cleanup-Upload/wiki/User-Manual) and code structure page (https://github.com/uga-libraries/ASpace_Batch_Export-Cleanup-Upload/wiki/Code-Structure). All of this ensures that my future self and others after me can “download my brain” to pick up where I left off.
Another contribution to my future well-being was creating an automated data auditor (https://github.com/uga-libraries/aspace_scripts/blob/main/ASpace_Data_Audit.py) of our ArchivesSpace instance, helping alleviate the stress of re-learning how to run a once-a-year series of checks against our data. The data auditor originated from many of the data cleanup processes I developed during the migration process. Additionally, I led conversations with my colleagues about what common archival description and data errors they wanted to see in a yearly report. We determined that the data auditor needed to check our archival description for things such as repetitive or unwieldy controlled vocabulary lists (we had over 200 extent types before the migration); duplicate subjects and agents; bad URLs found in our digital objects, notes, and other fields; inconsistencies in archival object levels (think series on the same level as files, items, and subseries); phantom containers; and many others. From this, I created a list of requirements to make the data auditor as useful and easy to work with as possible. It needed to run automatically once a year, generate an Excel spreadsheet with data that could be filtered by repository, and highlight known issues that grab our attention. Built on Python and using ArchivesSpace’s API and MySQL database, the script generates the spreadsheet and emails it to our users to review and begin fixing any errors caught. I actively worked with our local system administrator to co-develop the script to work in a secure environment on our servers, where data is exported, parsed, and wiped once the process is done, and email us if any issues arise. This reinforced for me the importance of good communication and organization inherent in project and program management. I needed to work with archivists and system administrators to find solutions that would meet both groups’ requirements. Thanks to project management, I do not need to re-learn the details of our data audit process, and our archivists and system administrators can feel at ease knowing this process was built alongside them every step of the way.
With my immediate colleagues, an integral part of our ongoing maintenance of the system and our archival description is having a community of practitioners, in the form of the ArchivesSpace community, to rely upon when we need advice and expertise from others in the field. When I first became project manager, I hit the ground running, attending conferences, workshops, and presentations in the ArchivesSpace community, taking full advantage of listservs and Slack channels to ask questions of experts in the field. That time was vital to gain trust in the community and build connections with people who could offer help on everything from learning how the ArchivesSpace API works to different approaches to evaluating our description and processing practices. To share what I was learning and give back to the community, I began to give my own presentations, documentation, and advice to others through the listserv and elsewhere. Helping others through technical or non-technical issues fostered a sense of community and shared experiences that typically is not considered when working with software. When you are not as actively engaged in a project or system after implementing it, there’s a sense of trust and relief knowing you’ve built a network of users willing to help when you need it and vice versa.
Project management and program maintenance center around human interaction. We plan projects, write documentation, build scripts and software, and create a network of fellow users and experts to enable ourselves and others to achieve things we could not do on our own. So often, the jargon and technical processes of project management and archival description lose this sense of cooperation and humanity. By building documentation for the future, automating tasks for the present, and fostering a community of support, we ensure our own well-being as project/program managers and help others achieve the same.
Corey Schmidt is the Project Management Librarian/Archivist at the University of Georgia Libraries. He graduated from the University of Michigan School of Information with a Masters in Information in 2019 and from Truman State University with a Bachelor of Arts in History in 2016. In his spare time, he enjoys gaming, improv’ing, baking, and enjoying the outdoors when bugs do not consume him.
Descriptive Notes 