Scholars' Lab Blog //(Digest #4) On managing projects, not people
Blog //(Digest #4) On managing projects, not people

This digest comes a bit late, because in the interim I have been going through a mild project management crisis.  Now that the crisis is past, I see the experience as the perfect opportunity for a post.

I mentioned in my last post that the nature of our project—and thus our team—is changing.  Development has a working game up and running.  They now are adding features and troubleshooting bugs in the program.  Design has given the identity pitches and is moving forward with our new identity: Ivanhoe, designed in such a way as to emphasize the web-like network of moves which our game will inspire.  (Watch for more posts on the design plans from Francesca and Zach.)

Eliza is learning SASS, which—very roughly speaking—lets her make her design life easier by building templates of CSS.  These will enable her to not have to enter every little bit of CSS for complex but commonly used formatting.  Zach is becoming more familiar with CSS, and the two of them will start applying the design plan to our website and theme within the  week.

Francesca is refining design on our logo and will be transitioning to writing web content this week.  Francesca has reflected before on the nature of our tool as a game (see, for instance, “Are we gaming or just simulating?” and an earlier post on gamification), and I think she is the perfect person to write web content on Ivanhoe for this reason.  She will be writing a brief history of the Ivanhoe Game, so anyone who wishes to see what our game has grown out of may do so.

That leaves me.  For a while, I was heavily focused on what everyone was working on.  I knew that my job was to keep up with that and make sure that everything got done.  This quickly became problematic, however.  Development’s understanding of coding tasks far outstripped my own.  They have also been very organized and have had very little need of managing outside of their own team.  Design also established a system of meeting, dividing up tasks—each member taking a separate design plan for the identity pitch—and plunged into the design.  This left me feeling a bit bewildered.  I felt that I had little to do but blog on what everyone else was doing.

This particular circumstance is essentially a good thing; a project manager needs the team members to take initiative and plan their own parts of the project.  Once that’s going smoothly, however, a new style of project management is called for.  I was not prepared for this, and in my frustration, I fear I may have teetered on the brink of MICROMANAGEMENT.  This was the very demon I had striven to avoid in my Praxis involvement, and in a climactic meeting with my team, I discovered that I may have begun this downward spiral.  I didn’t want people to feel like I was looming.  But how to do my job?

This is where a project manager needs to remember that she is managing a project, not people—a confusing point, as people are responsible for everything that gets done on a project.  Still, with some coaching from Bethany and Purdom, and after putting inquiries to my teammates as to how I could best be helpful, I emerged from my confusion with a very good idea of what my role would involve in the latter half of this semester.

I figure primarily in the role of Support now.  I am responsible for publicity—blogging and looking for opportunities to get the word out about Ivanhoe.  I am also the primary steward of The Timeline (all caps because it’s so important).  This quite simply means knowing what our deadlines are and keeping people aware of them so they can plan their own work accordingly.  I am also involved in testing Ivanhoe—a very fun job where I enter games on our Heroku testing site and then tell Development what’s broken.  I create a new issue on GitHub for each bug, give it a big red “Bug” label, and go look for more.  It’s satisfying in the way that taking a red pen to an essay is satisfying.  And I know that when it’s all done, our game will be the better for it.

GitIssues

Lastly, my job is to maintain our vision for Ivanhoe.  This means keeping people on track if they start wanting to add features which veer from our essential goals.  This part of my job is a bit amorphous and abstract at this point, but for all that, it is inspiring.  I look forward to seeing where Ivanhoe will go, and to gaining greater project management experience and insight as the semester progresses.