Chris Stamp on making VIDEO GAMES
Managing big game projects is an unusually challenging occupation. A Games Producer requires knowledge of a lot of specialist subjects and deals with a wide range of people with different backgrounds and mindsets, and requires a correspondingly wide range of skills. The consequences of messing up are usually serious - games development companies tend to rely on a project to be a success to ensure that they live to fight another day. Games Publishers can afford a mix of big hits and abject failures, but games development companies aren't usually so fortunate (although the current trend towards cheap-to-build smartphone or Facebook based games is moving things back into less precarious territory).
I'll cover some of the key components of games project management here, but first some terminology. Is a Producer the same as a Project Manager? What is a Senior Producer? What is an Executive Producer? In the US, job titles mean a lot, people place great store in them and have definite expectations about what a role is. There, your job title greatly affects your career development. In the UK it is much more haphazard, and the same title can mean different things in different companies, and there are a wide range of structures. I've been a Producer, a Team Leader, a Project manager, a Senior Producer, an Executive Producer and a Senior Project Manager, and to be honest the job titles didn't define the roles half as much as the team size, the circumstances surrounding the project, and what other management roles existed on the project. However, a rough rule of thumb is that a Producer tends to be a leader and a figurehead (as well as a manager), while a Project Manager is more likely to focus on the mechanics of the project, such as scheduling and reporting.
I've broken the responsibilities of managing a game project into some individual topics: Project Planning, Development Processes, Scheduling and Tracking, Team Structures, Hiring, Outsource Management, Communication, Game Design, QA, Man-management, Team Culture, Post-mortems, MMOG Challenges, Risk Management, Reporting, Finances and Budgets and Managing Yourself. I've provided an overview of each, and identified some key factors to consider. Covering all that's involved in the job would require a whole book, of which there are plenty available of course, so you'll want to read some of those if my notes are of interest. There are no doubt more questions raised than answers provided here.
Project Planning
A project plan is the framework within which development activities will take place. The plan describes the phases the project goes through, how the transitions between the phases are defined, the milestones, and what the key activities are in each phase. As a project manager, defining the phases in a project plan is your first opportunity to make sure the project is tackled the right way. However, there is often one big external influence on this - the publisher (assuming you are working with one), or more specifically, whatever has been agreed with the publisher in terms of payment milestones. If your first payment milestone is already "delivery of level 1, three months in" then you have immediately lost all ability to plan the project foundations your way. If you want to control project planning, you, or someone representing your position, needs to be involved in negotiating the project structure with the publisher or customer right at the start.
On a big project you'll certainly want to start with a Pre-Production period, if you are using any new technology or any original ideas at all. Pre-Production gives you the opportunity to get to grips with unknown areas and build the tools that you'll need before you can start delivering, and make your game design solid. It's the chance to do the groundwork that will minimise mistakes and rework later when people are expecting your project to be churning out the levels and the game assets, and generally showing value-for-money and going forwards rather than sideways or backwards. In an ideal world, Pre-Production would take as long as it takes, and you wouldn't go into Production, with the large team sizes and expense that it involves, until the project was ready for it. Often however, Pre-Production is time-boxed ("you can have 3 months of Pre-Production"), in which case you can look at it as advance damage limitation, or try to tailor the ambition of the project to include only as many risky areas as you've been able to explore in the available Pre-Production time.
Production is the meat of the project, when the vision is turned into reality (albeit with plenty of rough edges). This is when your team size can shoot through the roof to fit your calculations of how many people are needed, so you had better know what you want everyone to do by this point. Your calculations are unlikely to have allowed for spending weeks trying to figure out what everyone should be doing exactly, or having people sitting idle because tools aren't ready for them or are broken. If you have the luxury of building the team up gradually, to allow you to smooth out any growing pains in a controlled manner, you should take it.
Post-Production is the bit after Production and before launch of the game, which is obvious enough. In practice this phase is as much about a change in mindset as anything else. Everyone has to stop tinkering and get the product ready to ship, and realise that it is going to happen, and sooner than it seems. During Production, the end of the project may have seemed a million miles away and there was always tomorrow to fix something, and always a reason why something couldn't quite be finished. In Post-Production all the reasons to defer things have to be overcome, bugs have to be fixed, assets have to be made shippable. On big, complex projects, this phase relies very heavily on project managers and producers, because it is impossible for the team to tackle everything that would ideally be tackled, objectivity is at a premium, and somebody needs to cut through all the noise and make sure that decisions are being taken on the myriad small tasks that either need to be done or not done, bugs that need to be fixed or deprioritised. Development teams have high hopes and high standards and this phase can be a challenging time as sacrifices need to be made, the 'ideal world' is no more, and the scramble to tie up the loose ends needs to take place in a (reasonably) controlled manner.
Development Processes
A development process is your set of guidelines for how the team go about their work - what rules they have to follow in order to operate as part of a coherent unit. There are lots of different 'standard' processes around, and even more names for them, but it's rare to find anybody who follows one exactly. Every project is different, every team is different and there are always exceptions to the rules. The expectations of the customers may affect how you do your work and may influence your development process, or you may have a group of developers who are highly-motivated by the idea of following one process, and will be more committed if they are able to. The best approach is to make yourself familiar with process ideas as a toolkit from which to select practices where the situation demands it, and adapt to specific situations.
In the games business just now, any discussion of development processes will include the word "Agile". It has many interpretations, so the phrase is of little value without discussing what the word means to the people using it, but it generally refers to working in relatively short phases, minimising process overheads by very frequent (e.g. daily) team meetings for communication, and trying to avoid defining too far in advance what each phase consists of so that the project can be exploratory and reactive. The sacrifice is loss of predictability, which can be a particular problem if the customer for the project is seeking more certainty.
In practice, almost everyone concludes that a balance between Agile methods and more traditional planning-based approaches is appropriate for their project.
Another key topic is documentation. What is the team expected to write down, and how much traceability is needed? Where is the definition of the project, to refer to when people have questions and memories start to diverge? Maybe it is in the head of one person who runs the project in all respects, whose word is final, and can spend their time communicating to everybody, or maybe it is in documentation of some kind - Word tomes, Wiki documentation, whatever. As for serious software documentation (technical specs etc) - personally, I like developers to be able to at least write down what it is they are trying to achieve in a particular task (the Requirements), and broadly how they are going to achieve it (the Specification, although terminology varies). It's amazing how often basic misconceptions are picked up that way. Documentation is one method of ensuring the appropriate thought processes takes place for creating structured software. Document-writing is a skill in itself however, and not everyone who can make great games can master document writing, so you need to establish a process that involves only a constructive level of documentation. And passing documents around should never be a replacement for actually speaking to each other.
Scheduling and Tracking
Scheduling and tracking (and the Estimation that goes into scheduling) is a huge topic. On a big project you're likely want to dedicate somebody to this. Common tools are Gantt charts (see Microsoft Project), spreadsheets, burndown charts (usually associated with 'Agile' development) and bug lists (bug tracking tools are often used for more general task tracking too).
Whatever tools you use, it is important to avoid the trap of believing that what the spreadsheets and graphs are telling you captures reality with any great accuracy. Schedules should be used to influence the future, and should be made as accurate as possible, but on any complex engineering project they very rarely work as a crystal ball. The factors that dictate when you'll be finished are usually the things that aren't yet on the schedule (changes in plan, major underestimations, previously unidentified work).
Schedules are very often based around milestones. If you use milestones, you need to bear in mind that the development team will probably forget all about the big picture of the project and focus their attention on the next milestone. So it's very important that it consists of work which actually complements the long terms goals. It sounds obvious, but getting this wrong means that the entire team is working on the wrong things for a period, and few projects have leeway to absorb this. For example, if your milestone is to create a demo around a certain feature, and you intend that this represents real progress towards the final product, you need to make sure that everyone understands that the demo is a means to an end so that people aren't doing work that is of little use longer-term, in an attempt to satisfy the limited short-term goal. Otherwise you can all-too-easily end up with an over-optimistic impression of progress and a subterranean store of big problems (a Technical Debt) for later.
Any scheduling system needs to cater for dependencies and allow visibility of the critical path. Dependencies are timing links between tasks - e.g. integration of vehicle art assets (3D models) can't take place until the import tool is written. Any schedule that doesn't cater for that dependency and assumes that the tasks can be done in parallel will be misleadingly optimistic. The critical path is the longest chain of dependent tasks required to finish the project (and is therefore also the shortest time in which the project can be completed). To give a trivial example - if you have tasks A B, C and D, all estimated at two weeks, where A, B and C can be done as soon as someone is available to so them, but D can't be started until A is finished (i.e. D is dependent on A), then the critical path is four weeks.
Team Structures
Your team structure heavily influences the working life of everyone on a project. It affects where the control lies in a project (is it producers or technical leads who hire and manage development staff?), dictates career progression, and influences the culture of the project and whether the games team is primarily focused on quality or schedule. There is no one right structure, and in any case a structure is only as good as the people within it, but it is worth considering how different life on a project can be according to who is giving the instructions and recognition, and therefore influencing everyone's behaviours.
One rule of thumb I use is that roughly every five engineers should have a full-time technical manager to make sure their work is following the right processes and successfully integrating together into the bigger picture. Be careful not to use all of your best engineers as managers - they probably won't enjoy it and you'll weaken the engineering skills base. People who enjoy communicating and managing, and can just about keep up with the hotshots, are a better choice of technical manager.
Hiring
Few projects or companies are set up so well that weak or distracted employees can be slotted into the system and still produce the desired results. In addition, few games companies devote much time to turning weak employees into strong ones. It's an industry that relies heavily on its talent, so hiring good people, who will be motivated to do what you need them to do, is crucial, and will influence the level of success possible for the company.
In my experience, employing someone whose character you weren't sure about in an interview almost never works out. Any character flaw or incompatibility detected in the hour or two that you spoke to someone in an interview will often turn into issues that you have to live with for months and years, and can do little to change. Prevention is better than cure.
There's a wealth of information freely available on the hiring processes of successful of companies - you might like to read up on how others do it before deciding on your own methods. Whatever process you use should be designed to make sure that you don't face-to-face interview candidates whom you discover in the first ten minutes are not going to be suitable. Aside from being a huge waste of time, it can be an awkward and depressing situation. Phone screening and advance tests are two ways to help prevent this.
Another thing to bear in mind is legislation. You should have a good HR team, to make sure that decisions you make as part of hiring are actually legal!
Outsource Management
Especially on large projects, the question of whether to outsource work will crop up. This involves paying another company to do work for you, often in a different country where manpower is cheaper. Although you can save some money on particular tasks this way, the real saving is in not having to maintain a team that is only employed intermittently. You may have periods on a project where 40 artists are needed, but for the majority of the time only 20 are required, so having a permanent staff of 40 is not sensible unless you have enough projects on the go at any one time that there is always a need somewhere and they can be moved around.
Outsourcing can therefore make a lot of sense if it can be made to work for you, but it isn't quite as simple as it sounds. You need to put some dedicated management in place to communicate constantly with the outsourcing company, who naturally rely on you to give them a clear definition of what you need. They also need you to provide prompt feedback on their work, and to feed them any required specifications, concept drawings or example assets in timely manner. Otherwise you are making it very difficult for them to be efficient and profitable, as you are forcing them to do rework or have idle staff. They will come to look at you as a less desirable customer and possibly put their best people on somebody else's project. The result will be a failure to get the results you needed, and you need to consider whether it was a failure on your part to manage the process effectively before blaming the outsourcing company.
Communication
Lack of communication is one of the most common complaints about management, which is unfortunate because successful communication between managers and staff is the lifeblood of a company. Retaining top talent relies on them understanding and appreciating what they are doing and why, and buying into the company's vision and ideals. A lot of the staff won't care that much, but the star players will.
But for a producer or project manager, it's not quite as easy as just sharing information on whatever happens to be going on. A lot of what is happening in managerial circles at any given moment is speculative or work-in-progress, and it would just be a constant distraction to be diverting people's attention to things that may or may not come to anything. In general, developers hate uncertainty as much as they hate being uninformed.
Managers aren't expected to keep changing their minds or not know things (managers aren't even expected to be quite human much of the time), so knowing what to communicate and when, and maintaining an informed but distraction-free environment when there is a lot of furious activity going on behind the scenes, is one of the tricks of being a good manager.
Encouraging communication amongst the team is always a good idea. Suppressing communication rarely works - if there are problems, the best approach is to tackle them rather than hide them. But if you have individuals who are genuine troublemakers (even if they don't appreciate that themselves), you need to tackle that promptly.
Game Design
As a producer or project manager, you may have a key role in game design management, or that may be somebody else's remit (e.g. a Creative Director). Whichever, your job is a lot easier if you fully appreciate the game design and feel enthusiastic about it, but can also take a step back and be objective about it, and look at things from the customer's viewpoint. If you have to err to one or the other I'd suggest prioritising the latter - it's all too easy to get too involved a game idea that you're excited about and fail to see that your players can care about different things from what the development team cares about. However at various times you are likely to be in a position of having to 'sell' the game concept to external parties, like the press, so you do need to be able to talk about the product enthusiastically and in detail. A balance between passion and objectivity is required.
QA
On a large project, QA (Quality Assurance, or testing) is vital if you are to ship a product of high quality. No matter how talented the developers, and how rigorously designed the software is, the development team can't catch all the problems on something as complex as a modern video game. In many organisations QA drives the closing stages of the project, taking control of what the team works on in the last few weeks in order to make the game ready to ship. As a Producer you'll want to make sure that QA activities are fully represented in your project planning, and that there is a top notch QA team (or equivalent outsource company) available when the time comes. When do you want to get QA involved? It's useful to have one key person in touch with the project right from the start, and you should get into the swing of building QA into your processes as soon as you can. The first big milestone or demonstration is a good time to properly introduce QA to the project, in preparation for a big increase in QA input nearer the end of Production.
Your QA team may or may not have an official input into the game design, but its always a good idea to seek out individual opinions and take them seriously. The QA staff are usually very keen gamers themselves, and have a perspective one-step removed from the development team.
Man-management
Games developers are a diverse bunch, and it can be a passionate and emotive business. There is no end to the number of surprising situations that crop up with individual people, and the number of unique personality traits you come across. You need to be able to deal with all manner of people and situations sympathetically, while doing what is right for the team and the company. You will also need a good HR team, to avoid accidentally opening your company up to legal action. Natural justice and legal justice can be very different!
Sooner or later you'll no doubt need to let people go if it isn't working out, for the benefit of all concerned. This is never fun, but you need to handle it professionally, sensitively and objectively, fully consult the HR team, and never allow yourself to get drawn into an acrimonious personal battle. As a manager, you probably have more to lose than anyone else if things get messy or out of hand. If you happen to be working in a different country, or with foreign staff in this country, be aware that there are significant legal and cultural differences in employment law.
Team Culture
There are as many different team cultures as there are teams, because people drive culture as much as any other factor. Everyone's behaviour affects it, but managers have a disproportionate influence.
What is culture exactly? It's the social and professional framework that a development team operates within - how they expect to be treated, what values they have and what codes of conduct are commonly accepted. It is the foundation for almost every activity that goes on, and as such a project is unlikely to be successful without a healthy team culture. Most of the things you need for a healthy development culture are the same as those you need for a healthy society - mutual respect, law and order, a meritocracy, at least some element of democracy, and opportunities for people to influence things and achieve their own goals.
Unfortunately, many games companies seem to have an embedded unhealthy culture, with rampant egos and a poor work-life balance leading to a high turnover of employees. You'll be lucky if you can make a significant impact in terms of improving an existing unhealthy culture (because it invariably has come from the top down), but by all means try. You are more likely to be able to establish a healthy culture with a 'blank slate' of some kind. Once you have a productive culture you should defend it at all costs - it's the secret to being able to actually enjoy a management role!
As you progress through the project, you may want to hold post-mortems (after each milestone for e.g.) to identify opportunities to make things run more smoothly in future - there's always room for improvement. Although a post-mortem naturally focuses on where things went wrong (as that's where the most potential for improvement usually is), it's important to avoid making people defensive or assigning 'blame'. If people become defensive they won't be honest or receptive, maybe even inclined to hope that things go wrong elsewhere on the project so that others take the flak, completely undermining teamwork. A constructive post-mortem will only be possible if you have a healthy team culture, and holding post-mortems may well expose team culture weaknesses. Post-mortems, like chainsaws, can be extremely useful, but handle with caution.
Note that missing minor milestone objectives may not always be a bad thing - it can be a sign that the milestones are challenging enough that they are getting the most from the team. If the team hits every milestone perfectly, maybe the milestones are not ambitious enough targets. Of course, if you rely on hitting milestones 100% to get payments from publishers, more cautious milestones may be appropriate, but you may want to include some private extra tasks for your team to provide a challenge (and exceed expectations) without risk to the payments.
MMOG Challenges
Massively Multiplayer Online Games are a different breed from traditional products, for many reasons. For example, it's almost impossible to test them properly in-house (unless you have thousands of QA staff) and the project never ends - just becomes 'live' (open to the public), which is an even more demanding time than the traditionally frantic run up to launch of a 'boxed-product' game. When you factor in all the additional skills and functions required to make an MMOG (online operations and hosting, web development, customer support and community management, billing, online security, customer retention) you have a monster of a project, and few succeed. If you get involved in one of these, you are taking on one of the most challenging project management roles the games business has to offer.
Risk Management
As a manager, you need to keep a close eye on what potential dangers and pitfalls lie ahead, and, of course, try to avoid them. You should keep a risk list of threats to your project's success. I tend to do this by evaluating how likely something is to go wrong ('likelihood'), and how big a problem it will be if it does go wrong ('magnitude'). Multiply the two together and you have rough risk index, which you can order them by. A big part of project management is reducing the 'likelihood' factor of your risks.
Reporting
You'll need to demonstrate the state and progress of your project to senior management, customers such as publishers, and the team itself (see communication). Nobody will want to see your Gantt charts or endless spreadsheets - you need an 'executive summary', something that encapsulates some meaningful metrics and communicates them fairly concisely and intuitively. It's a neat trick if you can do it, and worth investing time in to get right, as much for your own peace of mind as anyone else's. It's important not to get too dazzled by your own charts though, and be lulled into a false sense of security. What your charts show is only a snapshot, and things can change very quickly. Worst case, your charts can actively mislead you and everybody else because they don't take all of the factors into account. Another thing to watch is maintenance. If it takes you hours to update your chart it will become a major headache and will be error prone. If you can assign a technical person to help you create efficient and automatic reporting tools, processing your detailed data into something digestible at the push of a button, it is usually an excellent investment and pays for itself many times over in terms of improved decision-making.
Finances and Budgets
Your role as a project manager or producer may or may not involve some financial management. Either way it's useful for you to know the boundaries, and what leeway there is should things not go according to plan A. Depending on your level in the company, you may not know the full facts, but whatever you do know needs to be handled sensitively. Blurting out numbers in the pub, or using the prospect of financial meltdown to inspire your team to greater heights will probably result in your future management prospects being severely curtailed. Who knows, you may even have been given a little piece of information as a test, to see if you could handle the responsibility!
Financial management isn't rocket science, but if you are asked to do it you need to be diligent, understand what you are being asked for, and double check with the relevant people that you have got the right idea. Those numbers will come back to visit you sooner or later.
Managing Yourself
Project management in the games business is complex, demanding, and stressful. You will find out a lot about yourself, what you are good at and what you aren't. The hardest part of the role may be managing yourself, to make sure that you stay objective, constructive and someone that others can rely on. One thing to realise is that you can't be all things to all people, and accept that you will be making up for your weaknesses in some areas with strengths in others. Don't be intimidated by those around you with different skills - make use of them to complement your own. Take advantage of opportunities to attend training courses and find new ways of approaching things or thinking about things, compare your experiences with those of others facing similar challenges, and see for yourself that all managers are only human. When things go wrong, make sure you take some benefit from the experience and be confident that you have become a wiser manager as a result. Make sure you have the necessary assistants in place and train them to share the burden and eventually take over from you - it might be good for your ego to be the only person who can see the project through, but it isn't healthy for the team or the company, and, ultimately, yourself.
If you are involved in games project management, or hope to be in future - Good Luck!
I'll cover some of the key components of games project management here, but first some terminology. Is a Producer the same as a Project Manager? What is a Senior Producer? What is an Executive Producer? In the US, job titles mean a lot, people place great store in them and have definite expectations about what a role is. There, your job title greatly affects your career development. In the UK it is much more haphazard, and the same title can mean different things in different companies, and there are a wide range of structures. I've been a Producer, a Team Leader, a Project manager, a Senior Producer, an Executive Producer and a Senior Project Manager, and to be honest the job titles didn't define the roles half as much as the team size, the circumstances surrounding the project, and what other management roles existed on the project. However, a rough rule of thumb is that a Producer tends to be a leader and a figurehead (as well as a manager), while a Project Manager is more likely to focus on the mechanics of the project, such as scheduling and reporting.
I've broken the responsibilities of managing a game project into some individual topics: Project Planning, Development Processes, Scheduling and Tracking, Team Structures, Hiring, Outsource Management, Communication, Game Design, QA, Man-management, Team Culture, Post-mortems, MMOG Challenges, Risk Management, Reporting, Finances and Budgets and Managing Yourself. I've provided an overview of each, and identified some key factors to consider. Covering all that's involved in the job would require a whole book, of which there are plenty available of course, so you'll want to read some of those if my notes are of interest. There are no doubt more questions raised than answers provided here.
Project Planning
A project plan is the framework within which development activities will take place. The plan describes the phases the project goes through, how the transitions between the phases are defined, the milestones, and what the key activities are in each phase. As a project manager, defining the phases in a project plan is your first opportunity to make sure the project is tackled the right way. However, there is often one big external influence on this - the publisher (assuming you are working with one), or more specifically, whatever has been agreed with the publisher in terms of payment milestones. If your first payment milestone is already "delivery of level 1, three months in" then you have immediately lost all ability to plan the project foundations your way. If you want to control project planning, you, or someone representing your position, needs to be involved in negotiating the project structure with the publisher or customer right at the start.
On a big project you'll certainly want to start with a Pre-Production period, if you are using any new technology or any original ideas at all. Pre-Production gives you the opportunity to get to grips with unknown areas and build the tools that you'll need before you can start delivering, and make your game design solid. It's the chance to do the groundwork that will minimise mistakes and rework later when people are expecting your project to be churning out the levels and the game assets, and generally showing value-for-money and going forwards rather than sideways or backwards. In an ideal world, Pre-Production would take as long as it takes, and you wouldn't go into Production, with the large team sizes and expense that it involves, until the project was ready for it. Often however, Pre-Production is time-boxed ("you can have 3 months of Pre-Production"), in which case you can look at it as advance damage limitation, or try to tailor the ambition of the project to include only as many risky areas as you've been able to explore in the available Pre-Production time.
Production is the meat of the project, when the vision is turned into reality (albeit with plenty of rough edges). This is when your team size can shoot through the roof to fit your calculations of how many people are needed, so you had better know what you want everyone to do by this point. Your calculations are unlikely to have allowed for spending weeks trying to figure out what everyone should be doing exactly, or having people sitting idle because tools aren't ready for them or are broken. If you have the luxury of building the team up gradually, to allow you to smooth out any growing pains in a controlled manner, you should take it.
Post-Production is the bit after Production and before launch of the game, which is obvious enough. In practice this phase is as much about a change in mindset as anything else. Everyone has to stop tinkering and get the product ready to ship, and realise that it is going to happen, and sooner than it seems. During Production, the end of the project may have seemed a million miles away and there was always tomorrow to fix something, and always a reason why something couldn't quite be finished. In Post-Production all the reasons to defer things have to be overcome, bugs have to be fixed, assets have to be made shippable. On big, complex projects, this phase relies very heavily on project managers and producers, because it is impossible for the team to tackle everything that would ideally be tackled, objectivity is at a premium, and somebody needs to cut through all the noise and make sure that decisions are being taken on the myriad small tasks that either need to be done or not done, bugs that need to be fixed or deprioritised. Development teams have high hopes and high standards and this phase can be a challenging time as sacrifices need to be made, the 'ideal world' is no more, and the scramble to tie up the loose ends needs to take place in a (reasonably) controlled manner.
Development Processes
A development process is your set of guidelines for how the team go about their work - what rules they have to follow in order to operate as part of a coherent unit. There are lots of different 'standard' processes around, and even more names for them, but it's rare to find anybody who follows one exactly. Every project is different, every team is different and there are always exceptions to the rules. The expectations of the customers may affect how you do your work and may influence your development process, or you may have a group of developers who are highly-motivated by the idea of following one process, and will be more committed if they are able to. The best approach is to make yourself familiar with process ideas as a toolkit from which to select practices where the situation demands it, and adapt to specific situations.
In the games business just now, any discussion of development processes will include the word "Agile". It has many interpretations, so the phrase is of little value without discussing what the word means to the people using it, but it generally refers to working in relatively short phases, minimising process overheads by very frequent (e.g. daily) team meetings for communication, and trying to avoid defining too far in advance what each phase consists of so that the project can be exploratory and reactive. The sacrifice is loss of predictability, which can be a particular problem if the customer for the project is seeking more certainty.
In practice, almost everyone concludes that a balance between Agile methods and more traditional planning-based approaches is appropriate for their project.
Another key topic is documentation. What is the team expected to write down, and how much traceability is needed? Where is the definition of the project, to refer to when people have questions and memories start to diverge? Maybe it is in the head of one person who runs the project in all respects, whose word is final, and can spend their time communicating to everybody, or maybe it is in documentation of some kind - Word tomes, Wiki documentation, whatever. As for serious software documentation (technical specs etc) - personally, I like developers to be able to at least write down what it is they are trying to achieve in a particular task (the Requirements), and broadly how they are going to achieve it (the Specification, although terminology varies). It's amazing how often basic misconceptions are picked up that way. Documentation is one method of ensuring the appropriate thought processes takes place for creating structured software. Document-writing is a skill in itself however, and not everyone who can make great games can master document writing, so you need to establish a process that involves only a constructive level of documentation. And passing documents around should never be a replacement for actually speaking to each other.
Scheduling and Tracking
Scheduling and tracking (and the Estimation that goes into scheduling) is a huge topic. On a big project you're likely want to dedicate somebody to this. Common tools are Gantt charts (see Microsoft Project), spreadsheets, burndown charts (usually associated with 'Agile' development) and bug lists (bug tracking tools are often used for more general task tracking too).
Whatever tools you use, it is important to avoid the trap of believing that what the spreadsheets and graphs are telling you captures reality with any great accuracy. Schedules should be used to influence the future, and should be made as accurate as possible, but on any complex engineering project they very rarely work as a crystal ball. The factors that dictate when you'll be finished are usually the things that aren't yet on the schedule (changes in plan, major underestimations, previously unidentified work).
Schedules are very often based around milestones. If you use milestones, you need to bear in mind that the development team will probably forget all about the big picture of the project and focus their attention on the next milestone. So it's very important that it consists of work which actually complements the long terms goals. It sounds obvious, but getting this wrong means that the entire team is working on the wrong things for a period, and few projects have leeway to absorb this. For example, if your milestone is to create a demo around a certain feature, and you intend that this represents real progress towards the final product, you need to make sure that everyone understands that the demo is a means to an end so that people aren't doing work that is of little use longer-term, in an attempt to satisfy the limited short-term goal. Otherwise you can all-too-easily end up with an over-optimistic impression of progress and a subterranean store of big problems (a Technical Debt) for later.
Any scheduling system needs to cater for dependencies and allow visibility of the critical path. Dependencies are timing links between tasks - e.g. integration of vehicle art assets (3D models) can't take place until the import tool is written. Any schedule that doesn't cater for that dependency and assumes that the tasks can be done in parallel will be misleadingly optimistic. The critical path is the longest chain of dependent tasks required to finish the project (and is therefore also the shortest time in which the project can be completed). To give a trivial example - if you have tasks A B, C and D, all estimated at two weeks, where A, B and C can be done as soon as someone is available to so them, but D can't be started until A is finished (i.e. D is dependent on A), then the critical path is four weeks.
Team Structures
Your team structure heavily influences the working life of everyone on a project. It affects where the control lies in a project (is it producers or technical leads who hire and manage development staff?), dictates career progression, and influences the culture of the project and whether the games team is primarily focused on quality or schedule. There is no one right structure, and in any case a structure is only as good as the people within it, but it is worth considering how different life on a project can be according to who is giving the instructions and recognition, and therefore influencing everyone's behaviours.
One rule of thumb I use is that roughly every five engineers should have a full-time technical manager to make sure their work is following the right processes and successfully integrating together into the bigger picture. Be careful not to use all of your best engineers as managers - they probably won't enjoy it and you'll weaken the engineering skills base. People who enjoy communicating and managing, and can just about keep up with the hotshots, are a better choice of technical manager.
Hiring
Few projects or companies are set up so well that weak or distracted employees can be slotted into the system and still produce the desired results. In addition, few games companies devote much time to turning weak employees into strong ones. It's an industry that relies heavily on its talent, so hiring good people, who will be motivated to do what you need them to do, is crucial, and will influence the level of success possible for the company.
In my experience, employing someone whose character you weren't sure about in an interview almost never works out. Any character flaw or incompatibility detected in the hour or two that you spoke to someone in an interview will often turn into issues that you have to live with for months and years, and can do little to change. Prevention is better than cure.
There's a wealth of information freely available on the hiring processes of successful of companies - you might like to read up on how others do it before deciding on your own methods. Whatever process you use should be designed to make sure that you don't face-to-face interview candidates whom you discover in the first ten minutes are not going to be suitable. Aside from being a huge waste of time, it can be an awkward and depressing situation. Phone screening and advance tests are two ways to help prevent this.
Another thing to bear in mind is legislation. You should have a good HR team, to make sure that decisions you make as part of hiring are actually legal!
Outsource Management
Especially on large projects, the question of whether to outsource work will crop up. This involves paying another company to do work for you, often in a different country where manpower is cheaper. Although you can save some money on particular tasks this way, the real saving is in not having to maintain a team that is only employed intermittently. You may have periods on a project where 40 artists are needed, but for the majority of the time only 20 are required, so having a permanent staff of 40 is not sensible unless you have enough projects on the go at any one time that there is always a need somewhere and they can be moved around.
Outsourcing can therefore make a lot of sense if it can be made to work for you, but it isn't quite as simple as it sounds. You need to put some dedicated management in place to communicate constantly with the outsourcing company, who naturally rely on you to give them a clear definition of what you need. They also need you to provide prompt feedback on their work, and to feed them any required specifications, concept drawings or example assets in timely manner. Otherwise you are making it very difficult for them to be efficient and profitable, as you are forcing them to do rework or have idle staff. They will come to look at you as a less desirable customer and possibly put their best people on somebody else's project. The result will be a failure to get the results you needed, and you need to consider whether it was a failure on your part to manage the process effectively before blaming the outsourcing company.
Communication
Lack of communication is one of the most common complaints about management, which is unfortunate because successful communication between managers and staff is the lifeblood of a company. Retaining top talent relies on them understanding and appreciating what they are doing and why, and buying into the company's vision and ideals. A lot of the staff won't care that much, but the star players will.
But for a producer or project manager, it's not quite as easy as just sharing information on whatever happens to be going on. A lot of what is happening in managerial circles at any given moment is speculative or work-in-progress, and it would just be a constant distraction to be diverting people's attention to things that may or may not come to anything. In general, developers hate uncertainty as much as they hate being uninformed.
Managers aren't expected to keep changing their minds or not know things (managers aren't even expected to be quite human much of the time), so knowing what to communicate and when, and maintaining an informed but distraction-free environment when there is a lot of furious activity going on behind the scenes, is one of the tricks of being a good manager.
Encouraging communication amongst the team is always a good idea. Suppressing communication rarely works - if there are problems, the best approach is to tackle them rather than hide them. But if you have individuals who are genuine troublemakers (even if they don't appreciate that themselves), you need to tackle that promptly.
Game Design
As a producer or project manager, you may have a key role in game design management, or that may be somebody else's remit (e.g. a Creative Director). Whichever, your job is a lot easier if you fully appreciate the game design and feel enthusiastic about it, but can also take a step back and be objective about it, and look at things from the customer's viewpoint. If you have to err to one or the other I'd suggest prioritising the latter - it's all too easy to get too involved a game idea that you're excited about and fail to see that your players can care about different things from what the development team cares about. However at various times you are likely to be in a position of having to 'sell' the game concept to external parties, like the press, so you do need to be able to talk about the product enthusiastically and in detail. A balance between passion and objectivity is required.
QA
On a large project, QA (Quality Assurance, or testing) is vital if you are to ship a product of high quality. No matter how talented the developers, and how rigorously designed the software is, the development team can't catch all the problems on something as complex as a modern video game. In many organisations QA drives the closing stages of the project, taking control of what the team works on in the last few weeks in order to make the game ready to ship. As a Producer you'll want to make sure that QA activities are fully represented in your project planning, and that there is a top notch QA team (or equivalent outsource company) available when the time comes. When do you want to get QA involved? It's useful to have one key person in touch with the project right from the start, and you should get into the swing of building QA into your processes as soon as you can. The first big milestone or demonstration is a good time to properly introduce QA to the project, in preparation for a big increase in QA input nearer the end of Production.
Your QA team may or may not have an official input into the game design, but its always a good idea to seek out individual opinions and take them seriously. The QA staff are usually very keen gamers themselves, and have a perspective one-step removed from the development team.
Man-management
Games developers are a diverse bunch, and it can be a passionate and emotive business. There is no end to the number of surprising situations that crop up with individual people, and the number of unique personality traits you come across. You need to be able to deal with all manner of people and situations sympathetically, while doing what is right for the team and the company. You will also need a good HR team, to avoid accidentally opening your company up to legal action. Natural justice and legal justice can be very different!
Sooner or later you'll no doubt need to let people go if it isn't working out, for the benefit of all concerned. This is never fun, but you need to handle it professionally, sensitively and objectively, fully consult the HR team, and never allow yourself to get drawn into an acrimonious personal battle. As a manager, you probably have more to lose than anyone else if things get messy or out of hand. If you happen to be working in a different country, or with foreign staff in this country, be aware that there are significant legal and cultural differences in employment law.
Team Culture
There are as many different team cultures as there are teams, because people drive culture as much as any other factor. Everyone's behaviour affects it, but managers have a disproportionate influence.
What is culture exactly? It's the social and professional framework that a development team operates within - how they expect to be treated, what values they have and what codes of conduct are commonly accepted. It is the foundation for almost every activity that goes on, and as such a project is unlikely to be successful without a healthy team culture. Most of the things you need for a healthy development culture are the same as those you need for a healthy society - mutual respect, law and order, a meritocracy, at least some element of democracy, and opportunities for people to influence things and achieve their own goals.
Unfortunately, many games companies seem to have an embedded unhealthy culture, with rampant egos and a poor work-life balance leading to a high turnover of employees. You'll be lucky if you can make a significant impact in terms of improving an existing unhealthy culture (because it invariably has come from the top down), but by all means try. You are more likely to be able to establish a healthy culture with a 'blank slate' of some kind. Once you have a productive culture you should defend it at all costs - it's the secret to being able to actually enjoy a management role!
Post-Mortems
As you progress through the project, you may want to hold post-mortems (after each milestone for e.g.) to identify opportunities to make things run more smoothly in future - there's always room for improvement. Although a post-mortem naturally focuses on where things went wrong (as that's where the most potential for improvement usually is), it's important to avoid making people defensive or assigning 'blame'. If people become defensive they won't be honest or receptive, maybe even inclined to hope that things go wrong elsewhere on the project so that others take the flak, completely undermining teamwork. A constructive post-mortem will only be possible if you have a healthy team culture, and holding post-mortems may well expose team culture weaknesses. Post-mortems, like chainsaws, can be extremely useful, but handle with caution.
Note that missing minor milestone objectives may not always be a bad thing - it can be a sign that the milestones are challenging enough that they are getting the most from the team. If the team hits every milestone perfectly, maybe the milestones are not ambitious enough targets. Of course, if you rely on hitting milestones 100% to get payments from publishers, more cautious milestones may be appropriate, but you may want to include some private extra tasks for your team to provide a challenge (and exceed expectations) without risk to the payments.
MMOG Challenges
Massively Multiplayer Online Games are a different breed from traditional products, for many reasons. For example, it's almost impossible to test them properly in-house (unless you have thousands of QA staff) and the project never ends - just becomes 'live' (open to the public), which is an even more demanding time than the traditionally frantic run up to launch of a 'boxed-product' game. When you factor in all the additional skills and functions required to make an MMOG (online operations and hosting, web development, customer support and community management, billing, online security, customer retention) you have a monster of a project, and few succeed. If you get involved in one of these, you are taking on one of the most challenging project management roles the games business has to offer.
Risk Management
As a manager, you need to keep a close eye on what potential dangers and pitfalls lie ahead, and, of course, try to avoid them. You should keep a risk list of threats to your project's success. I tend to do this by evaluating how likely something is to go wrong ('likelihood'), and how big a problem it will be if it does go wrong ('magnitude'). Multiply the two together and you have rough risk index, which you can order them by. A big part of project management is reducing the 'likelihood' factor of your risks.
Reporting
You'll need to demonstrate the state and progress of your project to senior management, customers such as publishers, and the team itself (see communication). Nobody will want to see your Gantt charts or endless spreadsheets - you need an 'executive summary', something that encapsulates some meaningful metrics and communicates them fairly concisely and intuitively. It's a neat trick if you can do it, and worth investing time in to get right, as much for your own peace of mind as anyone else's. It's important not to get too dazzled by your own charts though, and be lulled into a false sense of security. What your charts show is only a snapshot, and things can change very quickly. Worst case, your charts can actively mislead you and everybody else because they don't take all of the factors into account. Another thing to watch is maintenance. If it takes you hours to update your chart it will become a major headache and will be error prone. If you can assign a technical person to help you create efficient and automatic reporting tools, processing your detailed data into something digestible at the push of a button, it is usually an excellent investment and pays for itself many times over in terms of improved decision-making.
Finances and Budgets
Your role as a project manager or producer may or may not involve some financial management. Either way it's useful for you to know the boundaries, and what leeway there is should things not go according to plan A. Depending on your level in the company, you may not know the full facts, but whatever you do know needs to be handled sensitively. Blurting out numbers in the pub, or using the prospect of financial meltdown to inspire your team to greater heights will probably result in your future management prospects being severely curtailed. Who knows, you may even have been given a little piece of information as a test, to see if you could handle the responsibility!
Financial management isn't rocket science, but if you are asked to do it you need to be diligent, understand what you are being asked for, and double check with the relevant people that you have got the right idea. Those numbers will come back to visit you sooner or later.
Managing Yourself
Project management in the games business is complex, demanding, and stressful. You will find out a lot about yourself, what you are good at and what you aren't. The hardest part of the role may be managing yourself, to make sure that you stay objective, constructive and someone that others can rely on. One thing to realise is that you can't be all things to all people, and accept that you will be making up for your weaknesses in some areas with strengths in others. Don't be intimidated by those around you with different skills - make use of them to complement your own. Take advantage of opportunities to attend training courses and find new ways of approaching things or thinking about things, compare your experiences with those of others facing similar challenges, and see for yourself that all managers are only human. When things go wrong, make sure you take some benefit from the experience and be confident that you have become a wiser manager as a result. Make sure you have the necessary assistants in place and train them to share the burden and eventually take over from you - it might be good for your ego to be the only person who can see the project through, but it isn't healthy for the team or the company, and, ultimately, yourself.
If you are involved in games project management, or hope to be in future - Good Luck!
Managing Game Projects
