It's New Project Season at the Stanford Literary Lab and one of the students from my 2024 #DHRPG Project Management class is running her first project. It occurred to me that for all we talked about managing projects in that class, I could have done a better job getting down to the concrete specifics of how you would actually run a project meeting.
Most of my projects are me and maybe 1-2 other people, so how I run my project meetings is usually a lot less formal than this. For larger projects (like the Data-Sitters Club), we get to something that looks a little more like this, but it's more casual because we're all friends and have been doing this a while now. But as a starting point for folks bringing together a group of people who don't necessarily have an existing relationship, to take on a new DH project, this is how I'd go about approaching it.
Why Have a Meeting?
As much as it’s a joke, there are several legitimate reasons why you might hold a meeting, especially for a DH project where the participants don’t regularly see each other.
- Meetings are for getting unstuck: Some people are comfortable with something like a project Slack channel / WhatsApp group / etc for asking questions asynchronously and solving problems that way. Other people aren’t. Knowing there’s a regular time and place when they can ask questions about the things they’re stuck on makes it easier for work to continue at a reasonable pace, because there’s a cadence for addressing questions and ambiguities.
- Meetings are for making decisions: Depending on the structure of the project, one person may be in a decision-making role, or there may be more of a collaborative team / consensus culture. Even if there’s a clear decision-maker, it can be helpful to get input and feedback from the team, including in cases where the decision is made and can’t be changed. (In these cases, it gives people a chance to vent, express reservations, and potential issues that could arise from the decision.) Decisions are easy to put off, so having a meeting where part of the agenda is making a clear determination what the path forward is can be helpful to get to collective clarity on important issues.
- Meetings give people a deadline: Usually, everyone doing a DH project is also doing ten other things. The thing they’ll work on is whatever is most on fire at the moment. It’s easy to let DH project work go if nobody’s holding you accountable for it. A meeting provides a deadline for when you’ll be embarrassed if you show up and have done nothing.
- Meetings remind people (hopefully!) why they like each other and the project is cool: Slogging through this kind of work can be lonely! Having people to geek out with about some of the niche things about the project data that would take too much time to explain to a partner or friends. Hopefully the people on the project like each other (more or less) and it’s a nice opportunity to catch up. If you let this go a little too far, your project will turn into a social club, which is a nice thing, but isn’t going to get you the project results you need. But don’t overlook the “people like spending time with people” aspect of meetings.
A meeting takes preparation
At least a few days before the meeting, take stock of where the project is at. If this isn’t the first meeting, what were the things everyone agreed they’d do by the next meeting? If it is the first meeting, what are the big questions about the shape of the project that need to be hammered out to be able to actually move forward?
Write these things down as an agenda, and send it out to the team, asking for input on any other agenda items.
First project meeting topics
- What’s the scope of the project data? (Roughly how many things, from what time range, what languages, etc) – this can be a dicey one because often people have their pet thing that they would like to include in the project. If that pet thing might derail the bigger project, take a disproportionate amount of time or resources, or otherwise steer things in a weird direction, you may need to say no or define it out of scope for “the first phase of the project”. (If the person is still super into it after you’ve done some work, you can check back in with them to see if they’re still interested and have time to commit to it.)
- What are we roughly aiming at for an output? - Is this something that’s going to be a set of conference talks, a paper (and for what kind of journals), a data set you release in some form, a tool you build and maintain, a website with information? Getting on the same page with people from the start about this saves a lot of anguish later.
- What’s the timeline, and who has how much time? - Summer DH conference deadlines are usually in early November to January. Will you be able to get far enough to submit at least a proposal for an exploratory project (i.e. can you do some quick experiments on a limited but not absurd data set, enough to submit a promissory note for the work you’ll do between now and then)? When do you imagine you’ll be in a position to give a Lab talk about this? When do you expect you’ll be writing the paper / building the tool / etc? You don’t need a firm timeline, and whatever you come up with will change, but you want to get broadly on the same page here so one person doesn’t expect to be writing a paper before winter break, and another person was thinking that would be next summer. Make sure people’s availability aligns with their agreement on the timeline, or else re-evaluate the timeline.
- Who’s committing to do what next steps? - Not everybody is available to take on something after every meeting, but other team members should be volunteering to do some work on the regular. Otherwise, you don’t have a project team, just an advisory board.
Follow-up meeting topics
- Project task status: What happened with the things people agreed to do? Are they done? If not, why not? Were there problems that the group can help solve (e.g. trying to resolve tricky taxonomy questions)? Are there resources (software licenses, computing cluster accounts) that people are missing?
- Project timeline: If people ran out of time on tasks, it’s worth checking in on whether the person foresees the next week/etc. Being meaningfully different, or if someone else should take on the task, or the project should re-evaluate the timeline. (This happens all the time and is no big deal.)
- Big issues: It may take several meetings for these to arise, but are there any intractable or big issues for the project that you keep running up against, where it might make sense to re-evaluate some of your initial plans or decisions? Spend time talking them through, but also see what you can do to nudge this towards making some kind of decision. (A decision can include punting the topic to next meeting to decide, but don’t let it just drop.)
- Next steps: What is everyone committing to do next time?
During the meeting
Have a shared Google Doc where you can paste in each week’s agenda and keep notes on it. The person leading the meeting should ideally also not be taking notes. Also ideally, notetaking responsibility should be shared around within the group. It’s a good skill for people to practice, and not just make the same person do it every time even if they volunteer. The person leading the meeting can review the notes and stick in comments or other additions if major things were missed.
After the meeting
Get organized. After your first meeting, you should:
- Make sure there’s a project folder for your project materials
- Have a Google Doc for your running agendas / meeting notes
- Have a Google Doc that explains where your data lives, and how that’s structured (e.g. describe basics of folder structure and anything else someone new to the project would need to get onboarded)
Over time, you’ll probably add folders for presentations, conference proposals, etc. but you can get to those as you go.