ID:107050
 
Keywords: game_management
Project management is a pretty tiring job, if you want to actually do it right. But just what DOES a project manager do?

Essentially, a project manager is a facilitator. Your job as a project manager is first and foremost to make sure everything is going to plan, and the project (the game you are making etc) is progressing happily. In games development, your big resource (and so big thing to manage) is your people.

Here's an important fact to get you started, which a lot of people seem to overlook when managing games development on BYOND: Your people want to do well. They honest to goodness do! People like working on projects that are going somewhere, to feel their work will be part of a bigger success, so they want the game to succeed.

With that in mind, your job most probably doesn't involve a lot of shouting at people or strong-arming them into doing things. If you find yourself doing that, something has gone badly wrong and you better review what you're shouting about.

So the question is, what DO you do? Find out what's holding them back. It might be some confusion on the system they are trying to implement, they may be worrying about how complex it'll be, they may be waiting on some art to get things going, or work from another programmer. Who knows, it may even be some rubbish school homework they need to do, or their girlfriend is upset with them about something.

Then your job is to remove those problems for them. Worried about how complex a system will be? Simplify the task for them. Waiting on art? Chase the artist for a status update, re-assign the programmer onto something else if you can. It's all pretty straight-forward problem-solving if you think about it.

Essentially, that really is all a project manager does, solves team and planning problems. An interesting thing emerges though, that is worth bearing in mind for attitude purposes. You decide the way forward, but you're not actually in charge. You spend most of your time solving issues for the team regarding how things are ordered, how much they need to do currently, keeping them re-assured and moving. Or basically, you serve your team, just like the programmer serves the artist's role sometimes and vice versa to progress.

Once you get that attitude covered, it's all just estimates and listening to your team members. Part two of this set of articles will cover estimation, and three will cover team communication. We will wrap things up with a part four, covering case studies of actual projects and how their project managers handled things.

I hope this gets you thinking about your team, thank you for reading.