Posted on September 17, 2026
Project Management Doesn’t Need Frameworks: It Needs Structure
When discussing the definition of digital history in his 2021 book Technology and the Historian, Adam Crymble found himself skeptical of the utility of continued confabulation over the precise definition of the term “digital humanities,” writing, “Digital history does not need definitions. It needs histories.”1Crymble, Adam, Technology and the Historian: Transformations in the Digital Age (University of Illinois Press, 2021; online edn, Illinois Scholarship Online, 23 Sept. 2021), https://doi.org/10.5622/illinois/9780252043710.001.0001, accessed 12 Aug. 2026, 161. After our discussion and exercises in Clio Wired this week, and with the benefit of a background in software development, I find myself in a similar position with regards to the continued advancement of frameworks of project management and communication: what we need isn’t frameworks, but tools and structures. In slightly Marxist terms, praxis over theory.
I suppose I should start by refining what I mean in the difference between a structure and a framework, which are pretty similar terms. By framework, I’m talking about a theoretical framework, a high level conceptual idea of a way to conceive of project mangement; the same way it is used in Edin Tabak’s 2017 paper “A Hybrid Model for Managing DH Projects.”2Tabak, Edin. “A Hybrid Model for Managing DH Projects.” Digital Humanities Quarterly 11, no. 1 (2017). https://doi.org/10.63744/rme2max8ep42. In contrast, a structure is a specific plan for managing a specific project. For example: we have standup on Tuesdays and Thursdays; we store documentation in an Atlassian wiki; our files are named [subject]-[author]-[date].[file], etc..
For a little background on where I’m coming from, I have worked for four years in software development and engineering. I gained most of my experience working on a development team engineering cybersecurity software for Verizon. This team’s structure spared me the worst of the agile/scrum environments in what my developer lead called “Agile-lite”. But I also work with other teams who are working under a much more stringent interpretation of the agile/scrum framework – and, to what I imagine is no surprise to anyone who has ever worked under one of these frameworks, my team was far more efficient, even while being one of the largest teams on the project and at my company.
The real difference maker here was not the difference between frameworks but in the details of the implementation of a structure. My teams have historically not adhered well to exactly what is perscribed by Scrum – we’ve often had no dedicated project managers, standup only as needed, planning around releases rather than sprints. The reason the team succeeded in this looser adoption of a framework was by making up for it with strong structure, an understanding of who and where information could be found, what needed to be done and when. Our team centered on mutual trust to be able to get things done and was based around quickly access to information and remove roadblocks, in order to reduce time spent planning and increase spent time in development. In addition to an active Slack with well-divided channels to divide out topics of communication, one example of this structure at work was in our daily standups. The main check we made in these meetings was for “issues or blockers,” that is, any problems you ran into or things that would prevent you from finishing your tickets, and if one was present we would work to remove it then and there.
![STOP DOING AGILE
SOFTWARE WAS NOT SUPPOSED TO BE SISYPHEAN
YEARS OF PROGRAMS yet NO REAL-WORLD USE FOUND for a DAILY STANDUP
Wanted to add features anyway for a laugh? We had a tool for that: It was called "WATERFALL"
"Yes please give me UNFINISHED software. Please let me work INFINITY hours"- Statements dreamed up by the utterly Deranged
LOOK at what Programmers have been demanding your Respect for all this time, with all the keyboards & mice we built for them
(This is REAL PROGRAMMING, done by REAL Programmers):
[Three diagram images, each captioned with "?????", "???????", and "????????????????" respectively]
"Hello I would like ⭕ features please"
They have played us for absolute fools](https://madelynharrington.net/wp-content/uploads/2026/09/babe-its-4-pm-time-to-roll-the-boulder-back-up-the-hill-v0-6fVbLL78u_Ka2fb-Gx6qVuOU6pt1xvtK42myoDOr4GM.webp)
I’ve also seen a number of other projects, both ones I have been on and ones I have witnessed from the outside, fail organizationally, with consequences ranging from companies folding, to delays, to simply excess stress on developers. As exemplified by our exercise on implementing an imaginary application for a Digital Humanities Advancement Grant, there is a wide array of different aspects that must be managed within a project, and keeping them all together is no small task.4National Endowment for Humanities, “Digital Humanities Advancement Grants Notice of Funding Opportunity” (2024) https://www.neh.gov/sites/default/files/inline-files/20240111-HAA%20Digital%20Humanities%20Advancement%20Grants%202024%20%281%29.pdf. I appreciate where Tabak is coming from when he attempts to iterate on frameworks for both communication and project management, as many of these failures do often come down to failures in communication. But to his point, because DH projects involve non-linear workflows and diverse stakeholders, the need for a reliable, localized structure is even more pressing than in standard software dev, and I struggle to see how Tabak’s proposed framework is more useful in addressing this problem than encouraging teams to use better tools and providing them with structural practices.
It can certainly be helpful for scholarship to construe projects in the abstract; even in writing this, I’m feeling the problem that it’s hard to extrapolate a lesson from structure out to a wider lesson. But in my experience every team is different, and improving project management comes down to knowing your team, both collectively and individually; knowing your stack; and knowing your problem. It’s something no framework can replicate, because it comes down to being able to adapt to the needs of your project and the individuals on your team, something Tabak touches on when he delves into what makes DH projects unique from digital projects writ large.
I was reminded of this while working with my group in planning the first stage of our final project. Though we had a productive discussion on the benefits of the frameworks of project management and communication discussed in the readings, once we began to discuss the project, it was fully anchored in what tools and communication styles were beneficial for us, rather than anything based in theory. All in all, I’m very excited to get started on this project, and to see how we can manage our project as the semester goes on!
Maddie, sharing your experience working with software and providing that context really added to my understanding of these readings. I appreciate that you did not just analyze the readings but provided practical advice for group management based on your understanding of the readings and professional experience!
It is always interesting in hearing others’ experiences. I have lived in the policy/research world where the prevailing view has always been that subject matter experts can be taught to code but coders aren’t SMEs. The result, for better or worse, was that formal project management was never emphasized. If the project was large enough we hired contractors with the right skill set.