Life as a Project Manager - Project 3 Post Mortem

Another deadline, another project wrapped up today. All in all I had fun making Tanty, though it could be much, much better, and I'm not too proud of it, it was still fun to participate in it. Primarily, I'd like to discuss how I felt as project manager, and how it relates to what I might want to do in the future. This project is now published and available on here.

As I've mentioned before, for the past few projects I've participated in I've been relegated to the Project Manager role. It's been a great opportunity for me to see what it's like to manage a small team of 5 people, I've toyed around with the idea of starting my own games studio, so I had a chance to evaluate how that might go if I were to start a studio in the future.

The Bad

The TL;DR of it is that I feel that being a project manager on the past few projects, I felt helpless, useless and like I was the reason that not enough work was being done. Feeling that perhaps if I had just pushed a little bit harder for more work, then maybe I could have gotten the work at a standard that I can approve of. However, I can't just blame myself, but I can't just blame my team, all I could really do is get better. The bright side of it is that I do feel that I've gotten better at managing a small team for a small project, I've just been doing it wrong, more or less.

The source of the problem is that I trusted in my team too much. I placed a lot of faith in my team to acknowledge what they have to do and get those things done before the given deadline (a milestone, a playtest etc.). However, I was also dumb, and didn't give them a detailed written outline in the game design document of what needed to be done before that time. Having the written instruction gives me something to point to if the person assigned doesn't get the task quite right or doesn't do it at all. For future projects, personal or group, I will ensure that all of the tasks are outlined in the game design document, or a similar centralised document for game mechanics and have the tasks on that document linked from the description of an assigned task in the group's HackNPlan, a really simple and useful scheduling tool for game development. Doing this, I can keep a close eye on who is actively looking at their tasks and adding to the document.

The biggest mistake I made was being complacent with the work that was getting done. I might have felt that a lot of work was being completed, but the reality was that I or one other member of the group can completed all of our tasks. Therefore I felt that there wasn't much need to rush the other members or push for that little bit more work to be done. I don't have any real power when it comes to choosing who is in my team or making them do work. I told myself that I would push them to do more work if they were lagging behind or not getting work done before deadlines. However, there comes a point when you just can't rely on those members of the team, and you also can't get other members to waste time helping them. It then becomes a case of working around your team and accepting that they don't want to get work done. Of course, in a professional environment, this kind of behaviour should never be present, it really does give perspective, separating those who want to become professional from those who don't. I plan on being more firm with future groups, even if it does mean feeling like I'm being irrational. In the end, it'd benefit everyone in the project to get work done, and more satisfying for everyone if the project makes real progress before a deadline.

In terms of the project, of the things I found to be difficult to work with was the initial concept of the game. At the beginning of this project, it was very clear that the game was uninspired, not innovating, and overall bland. It discouraged many of the team members as we attempted to pitch it and found that it just wasn't working for us. The fact that the concept was not iterated on very much after pitching made it rather difficult to find something positive to hold onto throughout the early stages of development. Quite simply, iterating on the game in those early stages of development, particularly if we know the project isn't up to scratch, is one of the most important things that could be done at that time. Ensuring that all plausible ideas are thrown at a wall and seeing what sticks is the best idea.

The Good

Of course there were things that I liked about this project. The fact that the project was intended to focus on player experience and working around restrictions. This project worked around the given restrictions quite well, despite being unfinished. I also felt that focusing on giving the player feedback via controller vibration and screen shake was extremely satisfying. It was interesting to see player's reactions to the screen shake and vibration. I'm not saying to always focus on player experience, but if you have a feature that you want to provoke a certain emotion, polishing it, ensuring it works, and watching it work is easily one of the most satisfying feelings in game development. The experience you want your players to have is important, what's more important is that it is focused on. When it comes to making games, you'll always want to add a feature here or there because you think it'll give it that touch that makes it just right. In the end, if it doesn't match with the experience that you want it shouldn't be in the game.

After trying to be a project manager for the past few projects, I can safely say that I want to do better as a project manager, especially as someone who is thinking of starting their own studio. Being a project manager this early on in my career, managing a small amount of people can give me life experience for the future. While the projects didn't go perfectly, I got a huge amount of experience just by doing, and that's just the way that I learn best.


Tylah Kapa