Starting and Maintaining Your Own Game Project: Part 2
A while back, I posted part one of two on starting and maintaining your own game project, so now the time has come for part two! Part one was all about starting up a project, but part two is more about the maintenance side of things. This post will focus on ways of setting up and organizing a schedule, communicating with your team, keeping your team motivated, and tips for dealing with common problems I’ve come across during my work on Delirium. If you missed part one, you can find it here: Project Planning and Team Recruitment.
Meetings and Scheduling
Once you have assembled a capable team and completed all of your project planning, it should be time for your first meeting. The first meeting is the toughest; it’s all about explaining the specifics of the project and what exactly they’ll be doing, without scaring them off. For my first meeting for Delirium, we held it in one of the classrooms at the school, so I could use the projector. I put together a slideshow that had a lot of specific information, and I elaborated on things throughout. To be honest, though, I don’t think the meeting went as well as it could have. If I had the chance to redo that first meeting, I would have ditched the slideshow, gathered all the new recruits around a large table, and simply talked to them about the project. I think that this would have been much more effective, since, well, let’s face it, slideshows are usually pretty boring. Plus, anything you can do to break the ice between everyone is great; after all, these people are supposed to be working together, so let them get to know you and the rest of the team. Team dynamic is very important, so try to bring it out during that first meeting. Of course, you still need to talk about the specifics of the project, but this way, everyone should feel more comfortable, especially if they have any questions. It’s also important to get contact information from everyone during this first meeting. I actually relied too heavily on those online applications I did, and not everyone filled out all the contact information properly. Be sure to get phone numbers, emails (we each have a school email and a gmail), Skype accounts, and anything else you might be using. If people have multiple emails, ask which one they want everything sent to. Once you have all of their contact information, you can start adding them onto email lists and your project management tools.
While the first meeting might be the most difficult, it’s certainly no small task to schedule additional meetings. I asked all of my team to send me a copy of their school and/or work schedules, which I then used to determine what days and times were available to the most members. Finding meeting times that work for everyone is a challenge, but you should be able to find at least one or two days that work with everyone. For Delirium, the biggest problem we had with scheduling had to do with the fact that we had distance students on the team, and they happened to be in a different time zone than the rest of us. If some members aren’t able to make it to your meetings, then take some one-on-one time with them to make sure they stay in the loop. We also published notes from each of our meetings on Assembla, which is the project management tool we use. The key is to make sure that as many members as possible can make it to your meetings, and in case anyone can’t make it, be sure to keep them up to date on what’s going on.
Speaking of meetings, it’s definitely not okay to just have one meeting a week. Originally, we started off with having two meetings a week: one for updates on the project and to check up on our progress, and another to do planning and actual work. As it turned out, this wasn’t enough, so we decided to set up another meeting specifically to work on the game, along with a separate lead meeting to make sure it didn’t interfere with any other meetings. This change was reflected in the actual game, and by setting aside a specific time to do nothing but work, we were able to produce better quality assets in a reduced time frame. Furthermore, it also helped improve the team dynamic, motivation, and communication, as it is easier to talk to your leads in person than it is through email. The number of meetings you have for your team is totally up to you, but I recommend having at least two to three, with one being a work session and another for a lead meeting. Also, it is important that everyone on your team knows what days, what times, and where you meet. We have all of this information on Assembla, so all team members can easily access it, and I usually send out reminders through a group email. If a meeting gets cancelled, be sure to let everyone know at least two hours before the meeting, if not sooner.
Communication is, by far, the biggest challenge you will face as a project manager, producer, or lead. This is why it is so important to get your team’s contact information early on, and make sure that you have the most up to date information. We keep a list of everyone’s contact information on Assembla, which allows each team member to update their own information if it has changed. As for communication methods, we utilize email (mostly gmail) and Skype for anything that isn’t in a meeting. I send out weekly updates on the progress of the current build, and I usually send an email for things like reminders, sprint retrospective surveys, questions/answers, and anything else that the team as a whole needs to hear about. I don’t recommend sending out too many group emails, as your team might get tired of them and not even read them. For group emails, try to keep things short, simple, and, if you can, exciting. It’s also important to always remind your team of how great they’re doing, and you never want to come across as rude or demanding. If you have to tell someone something important, try to do it in person if you can, since emails, no matter how nicely written, are never a substitute for hearing it with your own ears.
Despite how well you may be communicating with your team, they might not always respond to you. Not everyone has great communication skills, but let them know when they join your project that you are treating this as professional environment, and that communication is critical to the game’s success. If you need to get an answer out of someone, try talking to them in person instead of through an email. This way, you can get the answer you need in a timely manner, and either of you can ask additional questions if there are any. If you do have to send an email, though, be sure to ask for exactly what you need to know (don’t be skimpy on details!), and specifically tell them that you need a response from them. On occasion, I’ve found that some members don’t respond back if they don’t think they have to, so if you want a response, just let them know. Furthermore, if there’s time sensitive information, put something like “important” in the subject line, and tell them when you need a response by.
On every project, though, there are always “problem children.” I’ve found that, on Delirium, these people were the ones who never, or rarely, communicated. I’ve had a few members simply disappear off the grid; we weren’t sure what they were doing, or if they were even on the project anymore. Of course, people get busy, so try your best to get in touch with them and find out what’s going on. If their schedule is a bit too crowded, try minimizing their workload and making sure that they check in at least once a week with their lead. Do your best to work with them to resolve the issue; you might even find that they simply didn’t know that they weren’t communicating properly. Sometimes, lack of communication can be resolved fairly easily, but other times, it gets to be a serious problem. If you’ve tried working with someone, but they still aren’t communicating, it’s probably best to set up a meeting with them, in person if possible, and explain why their lack of communication is hurting the team. If you have a producer on the team, I’d recommend having them attend the meeting, as well as that member’s lead. Clearly explaining why they need to communicate with everyone will usually resolve the issue, but not always. If they still aren’t communicating or doing their share of work, you might have to let them go (depending on other circumstances, too, of course). It’s an unfortunate thing to do, but if they aren’t contributing and keeping involved, they are only going to bring the team down with them.
In order to properly maintain your project, you need to know what is working and what isn’t. It sounds simple enough, but most of your team isn’t going to just tell you outright. On Delirium, I set up sprint retrospective surveys, which I would send out to the team at the end of a sprint or milestone. Each survey had the following information, which was used to help me figure out what could be improved upon:
- Name: If a member is having a problem that is specific to them, you need to know who it is in order to remedy it.
- How well do you feel this sprint went overall?: They simply had to pick the answer that they agreed with most; answers were poor, adequate, good, and excellent. This gives you a good overview on their opinion.
- How did you feel about the amount of work assigned to you?: This question is similar to the last, with the answer options being not enough work, just the right amount, and too much work. This lets you know how they felt about their workload, and can help you to adjust everyone’s workload for the next sprint.
- Rate yourself on how well you did on the following: Each member is able to rate themselves on their communication skills, logged hours, and completed work. This gives you an idea of how well they personally think they are doing. It can also tell you who isn’t doing work, as they will either say it or try to lie (you can check this against your own records and project management tool).
- Rate your lead on how well they did on the following (Leads, rate your team): This question is the same as above, but instead of rating themselves, they are now rating their lead (or team if they are a lead). This can give you good information on if your leads are doing their jobs correctly, and can also sometimes reveal if a member does not like their lead (as they will rate them poorly, despite the lead’s best efforts). If the lead fills it out, you can get an idea of problems and/or successes they might be having when dealing with their team.
- Rate the entire team on how well they did on the following: Again, this question is the same as the above two, but gives insight on the individual’s views of the rest of the team. It can tell you if they want to see more or less communication, and how they feel about the overall work that the team is completing.
- What went well during the last sprint?: Unlike the other questions, this and the following ones require the member to write something. This question is important to understand what they think is going well, which you can bring up at your next meeting and praise the team for their efforts. It’s imperative to highlight the positive aspects of the project, and not just the negative ones.
- What could be improved upon from the last sprint?: This question is basically the opposite of the previous, and lets you know what you and the team as a whole can work on for next time. Plus, you might find some good suggestions for improvement here! I’ve also found that if a team member is having a specific problem, this is usually the spot they put it, and it tends to have the longest answer.
- Problems/Issues? Additional comments, questions, or suggestions?: This last question is usually left blank, but I have seen a few answers here, such as suggestions for improvement, comments about problem members/leads, and even problems the person had with the actual game. If it is filled out, be sure to carefully read it and follow up with the member to learn more, and, if there’s a problem, work on solving it.
Team feedback is extremely important, and I’ve found that having these relatively short surveys at the end of each sprint helps to find and eliminate problems. More importantly, if you find any problems or suggestions, you need to take the initiative towards resolving them. If your team takes the time to fill out a survey that doesn’t change anything, they aren’t going to waste their time doing them anymore. The purpose of the survey is to get information that your team might not otherwise state, and use that information to better both the team and the project.
After the first few weeks or maybe months, your team is probably going to start losing motivation. It happens to the best of us, but it certainly doesn’t mean it’s the end for your project. There are a lot of little things that you can do to keep members motivated, including workshops, overall and individual praise for team members, bringing in snacks to a meeting every once in a while, letting them actually play the game, having small parties/celebrations when a milestone is completed, and just letting them know how great they are. Both the art lead and tech lead on Delirium have hosted workshops to teach their team some cool new skills, and afterwards, those members were ready to put those new skills to work. I’ve made cupcakes and cookies for the team several times, and after big milestones, I usually cancel a meeting and let them take the day to relax. Praise, too, is always important, and everyone likes to hear that they’re doing good work. Even if they aren’t doing the best, let them know that they’re still doing well and that you appreciate their hard work. Sometimes, constructive criticism can also be a good motivator, especially for artists and designers, since they are usually looking for ways to improve their work. Just be careful not to be too critical, and always point out the things they did well first. Another thing you can do to both improve team dynamic and boost motivation is to get the team together in a non-work environment. Try to just hang out with your team and keep from talking about work; get to know your team, and ask them how things are going. Remember: making games might be a lot of hard work, but that doesn’t mean it isn’t fun, too.
As a final note, I think it’s important to bring up how to maintain both communication and motivation over breaks. I only started up the Delirium project in September, 2011, so this winter break was the first real time apart the team has had from each other. If you’re working on a student project, there is no way of getting around winter break (or summer, if your school doesn’t go year round). What we did was have a meeting before the break started, and I let everyone know that all of the leads will be open for communication if anyone wants to do any work, and that there would be work in the backlog that a member could work on if they wanted to. We made it clear that we weren’t going to interfere with anyone’s break home, but for those who wanted to continue working, they still could. When we returned for the spring semester, not much work had been done, but some is always better than none. If you want your team to keep working over the holiday break, you need be very clear that you do, give them specific assignments (nothing too big), and check in with them via email or Skype every week or two. Either way, when your team returns from break, make sure they are still able to stay with the team, and get them back in the swing of things as soon as possible. If you let them sit around for too long, they probably aren’t going to want to do much work, so set your first sprint up and let everyone know that it’s time to get back to work.
Thanks for reading, and I hope that this has been informative! If you have any questions about this or the first part, feel free to ask me!