Project Management, Part 1: Managing your team news

One of the most common sentences you'll read on ModDB comment threads is "please don't let it die". Many mod projects suffer the same fate of vanishing before hitting their first public release. In our own project lifespan, we got into a similar situation and TNE only survived due to a good portion of luck. There are many reasons for a project to fail. Especially when it comes to larger mods, there is usually a lot of dynamism what concerns the team lineup. People come and go, turn inactive for a while, have more important things in real-life that obviously come first. And even though you're not bound to commercial pressure, this is exactly what makes modding more complicated to manage than an Indie game.
When we first started, we stabbed in the dark and just went on producing assets without a clear plan. Over the years, we started implementing a series of project management methods and tools that helped us a lot. We developed some of those on our own and learned others from industry professionals, such as Christopher Schmitz, the Head of Production at Ubisoft Blue Byte. In our first developer diary on production, I want to talk a little about the most important component of any mod: your team.

But first, what is project management all about actually? The very core is: ensuring that a project is delivered in time, budget and quality. Each of these factors influences the others and the task of a project manager is to find the right balance in order to make the project a success.

While the factors quality and quantity are rather self-explanatory, I would like to point out why time and budget are in fact relevant to mod projects as well. First of all, even if you work on a non-profit project, you still require a budget. Many people mistake this for money, but it's actually all about the amount of work you can put into your project. In the end, the factor budget comes down to your team members again, which leads us to time.

Motivation

Sure, mod projects are even popular among professional game designers, programmers and artists alike: you don't have budget-related time constraints as in a commercial production. Thus, you can simply be creative and realize some cool ideas without any pressure. For very compact teams with über-skilled people like Flavien Brebion, this can work out really well. Most of the time though, ambitious mod projects (including the ones that transition to indie) will work on lesser resources and thus require more time before substantial progress can be seen - or played. In these situations, it is very difficult to maintain motivation over longer periods of time. Thus, scope management can become rather important.

The vision

If you're the one who launched a mod project, you probably have a pretty good vision of what the entire thing is going to be. But let's say a 3D artist joins the team, does some props here and there, how is he going to understand or share that vision? How is he gonna stay motivated if the goal is not clear? Mod descriptions in their respective profiles are usually rather vague, verbalized in a marketing style and thus, not very useful for team management purposes.
A written vision statement should always be available to your team members. It's not so much about particular features of your project, but rather the overall goal. Just to be clear: "fun gameplay" is no useful goal, as it is imprecise and leads you to all sorts of associations. You should rather ask yourself:

• What is it that's supposed to cause the fun?
• Who do I want to reach?
• What sets my project apart from others?

A vision paper that answers these questions does not only help new team members, it can also raise the quality of your mod. Once you start being more precise about your goals, you often end up finding out that the overall concept doesn't turn out to be that unique at all and at the same time triggers some more thoughts. To sum it up: Be SMART about your goals. A handy buzzword for the most important properties to remember:

• Specific
• Measurable
• Attainable
• Relevant
• Time-constrained

I've made the experience with several student projects that tried to be the next World of Warcraft. Usually, the motivation was gone even before pre-production started. Even if your team shares your vision in its entirety - if the goal seems unattainable, it's just a matter of time until the entire project crashes. It's good to have a cool vision for something large. But if you really want to go for it, make sure that you set intermediate goals (milestones) that are attainable. There's nothing more motivating than seeing a spare time work coming together as planned.

Work structure

There is more to motivation than seeing a goal, though. Each individual has his or her own reasons to work on a mod. For fun, for personal mastery, for the feeling of achievement, for a portfolio...there are plenty of reasons. If you want to keep these people going, try to understand their motivations and implement them into your mod's work structure. At Invision Games, we started off with a very classic approach derived from the professional industry: a straight hierarchy with the experienced leads laying down the game design and strategy. It's a suitable model to stay within a planned timeframe, since actual producers can pull people back that waste the team's time on things that aren't even planned for the next milestone. It's a way to avoid feature creep in case the producers have some experience.
There is just one major downside: In a spare time project, it is unlikely that people stay motivated if they have to work on stuff they don't like. It even drains the creativity of professionals at work, so obviously the effect is stronger when you're not getting paid for it.
So even if your team's producer assigns tasks in a way that may be best for the project in theory, he might feel like a tyrant to the rest of the team at some point. That is one of the reasons why teams fall apart. When we ran into a similar situation, we knew that we had to change the work model. So over the years, we changed to a meritocratic approach to development by involving everyone in the creative process. We ended up having no more dedicated game designers, but actually having all the team working out the game design. Might sound inefficient for an oldschool producer but for us, it worked out very well. We introduced weekly meetings on our Teamspeak server where the whole team would gather, discuss progress, lay down plans for the next iteration and move on to a weekly playtest afterwards.

To us, this approach had various benefits: First of all, it created an iterative workflow that didn't exist before. Even if just one person on the team had time to work on the mod that week, you'd still notice changes even in a weekly period. And seeing progress done by others usually motivated the other members to put some efforts in on their own. Without actually noticing it at first, we had implemented an iterative work structure that is most common in the industry. Running through the cycle of planning, realizing, evaluating and correcting frequently, we could establish a solid quality for our groundwork before proceeding with other features.

While we were concerned at first that involving everyone in the game design could cause inconsistencies, quite the opposite happened. We naturally developed a meritocracy where new or inexperienced team members would trust in the arguments of the senior staff, but would never hesitate to throw in their own ideas. With this approach, we're most of the time able to get to a decision without actually having to vote. If we can't get to an agreement through discussion, things that are not too time-consuming simply go into playtesting and voting really becomes a last resort.

Of course, less popular tasks still have to be done, but people are actually doing them in a self-determined fashion since they have an impact on the creative direction. That way, everyone pushes even harder towards a common goal.
To come to an end, there's another hint I'd like to share with you. Over the years we had about 60 people contributing several gigabytes of material and countless work hours to Star Wars: The New Era. If a team grows that strong, you need to have a clear overview over the skill set of each individual. It's not just about the producers having an overview, but the entire team size and skill set should always be transparent to everyone. If a level designer needs props or materials, he should know who to ask. And remember: it's not about simply assigning tasks, but asking the right people whether they're interested.

Of course, it's always interesting for us what approaches other teams take. If you have an interesting story to share, just post in the comments! In the next production feature, we'll focus on scope management: how to organize and document SMART project goals and keep track of complex feature sets and overall progress.