The assigned topic this week, Project and Data Management, was one I expected to be rather boring. I won’t say the assigned readings were riveting, but I found some interesting information. The article I found most interesting was Griffin and Hayler’s 2018 article, Collaboration in Digital Humanities Research, from Digital Humanities Quarterly. The article suggests that, since communication is an unavoidable necessity in Digital Humanities work, all forms of communication should be studied and understood. Hayler and Griffin identify human-to-human, human-to-machine (or material), and machine-to-machine as three areas of communication. Every DH project will use some, if not all, of these forms of communication, and the borders between the categories are rather fluid. The article covers the importance of language and terminology. Communication between and within their collaboration categories needs clear language, and participants need to be aware of the meanings and biases inherent or inferred from the language they use. The article also stresses being cognisant of all collaboration, even if there is not another person involved. DH is a multidisciplinary endeavor, and forgetting the ways you collaborate affects the products and process. I found the article to be well-written. It was a good reminder that humans are a tool-using species, and being aware of our tools and how we discuss them is important. I also found many sources from this article that I believe will be beneficial to my research.
I found the other article, Tabak’s 2016 article for Digital Humanities Quarterly, A Hybrid Model for Managing DH Projects, to be quite the opposite of Griffin and Hayler. Despite noting multiple times that he did not want his article to be seen as a strict ruleset, the hierarchical structures, rulesets, and repeated cycles were incredibly rigid. He takes methods that work from other disciplines, suggests that he adds “humanities” into it, and creates a method more removed from how humans and human collaboration work. His suggested methods feel clinical. During class, my small group actually looked at his academic career and found that he mostly studies computer science and writes theory on social science. It was not immediately clear from his career that he actually has any practical, working experience with DH projects. This lack of experience seems evident in his ideal structures.
Both readings were interesting conversation topics in class, though the provided video by Dr. Otis was the best explanation of the basic structures of project and data management. My takeaway, ultimately, is that Project Management is a macroscale to a microscale Data Management. Both are important, and both will be needed for most projects. The most important thing in any multi-person project is clear, direct communication, with agreed-upon structures for data management, and software to use. Humans are human, and being aware of your team’s strengths and weaknesses is key to balancing your capabilities. Not everyone can do everything, and not everyone has to. A lot of the parts and processes of project and data management were familiar to me, which is why I had expected this week’s class to be rather dry. I was glad to find that the readings fostered interesting discussions, and that I was able to find some interesting sources to look into more. Dr. Otis made a very good point that anything can be a project, and referencing my own patterns against the methods discussed and suggested in class has been a helpful exercise. Having a good guide to project management should be helpful this semester.