We migrated this website to a new platform, and are working to correct formatting errors in older blog posts as a result. If you encounter an error, please send an email to scholarslab@virginia.edu. Thanks!

At our final official Praxis meeting, I shared an overview of my experience as project manager with the rest of the team, and I thought I would share some of those same reflections in a short series of blog posts. This first post reflects on some of the more technical and organizational aspects of project management.

Early on, I read Sharon Leon’s piece about project management, and these reflections follow much of her conversation. As Leon discusses, the PM is responsible for the delegation of roles and tasks, the allocation of resources, establishing a work plan and a time line, and developing a method for tracking progress and the completion of tasks. In addition, the PM needs to be able to articulate the vision and goals of the project, distinguishing between primary deliverables and those that are secondary.

Rather than deciding on a set of goals and then assigning people to different roles, in the case of Praxis, these processes happened in tandem. As each of us gravitated toward certain roles, it became more clear which deliverables would become prioritized and which would be secondary. To help keep myself focused, I drafted a very general project vision statement and, at Bethany’s suggestion, collected statements from the other Praxisers about their goals for the semester.

This left me with the job of laying out the calendar and work plan for the semester. As I blogged about earlier, this was a really daunting task for me given that I am still new to the DH world and did not have the skills to conceptualize how all the pieces fit together. From that process, however, I have learned that PMs do not need to know every detail of how the project will go from the outset. Rather than feel uncomfortable with my lack of knowledge, I started to see how I was surrounded by a team of knowledgeable consultants who could assist me in figuring out the relevant information needed to coordinate different aspects of our project.

When it came to the calendar, I basically just worked backward. I started by establishing our launch date. Then, in conversation with Wayne and Bethany, I worked to figure out the approximate dates when each task needed completion. Leon and others recommend that PMs work with team members to establish deadlines and goals rather than just dictating them. While this is a good idea (and something which I plan to try again in my next PM gig), it didn’t work so well for Praxis—mostly due to the fact that all of us were novices and not really sure how much time various tasks required. I did, however, collect information from everyone with regard to their commitments over the semester. I wanted to know when people would be leaving for the summer, when they would be out of town for a significant period, and if there were other commitments that might take time away from Praxis. That information helped me to set up the calendar and to know when people were most and least available throughout the last few months.

Although we did not have to worry about financial resources or the allocation of equipment or software, I want to say something briefly about time and space. One of our most important resources has been the graduate lounge. Often our best work happened when we were in that shared spaced for a good chunk of time. Although the design team had regular weekly meetings, the rest of us were rarely in the lounge collectively. Rather, we came in one by one when our schedules allowed. As the semester quieted down, we found more time to be in the lounge collectively. I am happily in awe of the amount of work and progress that we accomplished in the last three weeks of Praxis. Had I known how valuable that shared time and space would be, I would have done more to institute habits of collective work meetings early

To keep track of progress, we used the issues tracker in github. Deciding what counted as a task or a milestone was also difficult initially. Personally, I found that it helps to have the project broken down into small enough parts that you can actually track progress from week to week. If tasks are too large, there is little to check off of the “to do” list until the project approaches completion. In the end, each of our core deliverables became a milestone to which a list of issues (or tasks) were attached. I will have more to say about the articulation of tasks in my next post.