Experienced game developer and manager Troy Dunniway, a veteran of studios like Microsoft, EA, Insomniac, and Ubisoft, discusses some of the major risks involved in transitioning from a small to large development team and how to identify and avoid them.
[Experienced game developer and manager Troy Dunniway, a veteran of studios like Microsoft, EA, Insomniac, and Ubisoft, discusses some of the major risks involved in transitioning from a small to large development team and how to identify and avoid them. This, the first part in a two-part series, covers four of the 10 risks outlined by Dunniway, and is designed to help you get a general feel for the inherent risks in a large-scale project.]
Project risks in production can take many forms, and be as simple as something which could lead to a bad product, or a canceled project, or even your company going out of business.
Risks in your projects can affect every department and aspect of your company, and are often very different from project to project, team to team, and company to company. It is important that you objectively analyze the risks in your projects and company to see where the problems are and deal with them early on -- before it is too late.
The game industry has been undergoing a lot of changes these last few years. If you are looking into starting your own game development company, expanding your existing small studio into something bigger, or move from developing smaller projects on "easier" platforms into a larger game production, it is important that you minimize as many risks as you can. It also provides some tips on how to avoid or minimize common risks found in larger scale game development.
This list represents a lot of usually very obvious and common sense advice for people who are just getting into games, breaking off on their own, or taking on larger projects for the first time. Some of these tips may also be helpful for established developers and producers who are looking to take on larger roles in their organizations.
However, as I've found throughout my 18-plus year career, common sense is sometimes overlooked when it comes to making games, and many people tend to leap before they look. Hopefully this advice will help you avoid the mistakes I have made, or seen others make, over and over again.
It is nearly impossible to account for all of the risks in a project. Risks can come from every aspect of your company -- process, team, project requirements, publishers and many other internal and external factors which may be out of your control.
There are no solid rules for what risks to look for in a project, as almost all of them will exist in every larger project. The best approach is to get your most senior people on the team (usually the leads) to periodically assess the risks the project is facing.
For example, I was recently talking to a developer about their problems, and told them to revert some code they changed in their source control system back to an old version, and they responded that they didn't use source control.
As a seasoned developer, I would never consider not using source control for my source code, let alone my assets -- but some developers still haven't even learned some of the simple rules and best practices that a full veteran team is used to and takes for granted.
In other words, when analyzing risks, you really need to be able to objectively look at your problems and analyze them, and also be smart enough to know when you need outside help.
The top 10 areas of risk areas in a project are:
1. Business Risks
2. Pre-Production Risks
3. Process Risks
4. Team Risks
5. Schedule and Project Management Risks
6. Design Risks
7. Art Risks
8. Outsourcing Risks
9. Technical Risks
10. Testing Risks
These aren't the only areas of risk in a project, but they most probably cover the most serious issues on most projects. However, this doesn't mean that there won't be a million other things you should also be on the lookout for as well.
If you are working on smaller games for handhelds, mobile, casual games, and other "easier" to develop for platforms, some of these risks may not be as big or problematic. Also, if you are doing sequels or other kinds of games which are very similar to what you have already done, then a lot of these risks may not occur -- but always be watchful.
As a small developer, you are often at constant risk, whether you realize it or not. Most small developers who only have a single project are usually at risk of having most of their money coming in from a single publisher for a single project.
Ten or more years ago, it was possible to find and sign a new project in a few days or weeks, as the process and requirements were much lower. Five to 10 years ago, it began to usually take three to six months to sign a new project (unless you were lucky or already a well known developer). Today, I hear that some teams negotiate for 12 to 18 or more months for new projects.
Publishers also used to pay for prototyping, as the costs for building a prototype could be $250,000 to $500,000 for a really good prototype for a major AAA console game.
However, costs have now doubled or tripled to build a prototype to the quality that most publishers would like to see, and now they don't want to pay for it either. This shoulders the heavy burden of building prototypes and funding them now on developers, which is risky and hard for most small companies to do.
Small developers must incur a lot more financial risk in today's game development market. They must deal with the burden of creating concepts for new projects, pitching new projects, developing prototypes, getting new projects signed, and hoping that their current project(s) don't suddenly get canceled.
If you are a small indie developer, you may be living from one milestone payment to another, or close to it, and probably won't have time to find a new publisher if your current project is canceled. If you own the rights to the game you are developing, and it is in reasonably good shape, you might have a chance of getting it signed quickly, but if you have to start over and find a new project, it could easily take four to eight months.
There is no easy answer on how to mitigate the risks of having your publisher cancel your project. The best advice is to be continually looking and negotiating for the next project or to try and ramp up a second team or project as soon as possible. The more diversified your income is, and the more additional funding sources you have, the more stable your company can be.
Also, while taking on a second project does have its own risks involved -- in that too much growth can be challenging for some teams -- there are many other benefits as well.
There are many costs associated with running a company, from the common space building overhead, to other non-production personnel who might be needed, like a receptionist, HR, accounting, management, audio departments, and much more. Having two projects allows a lot of these costs to be shared and helps the company significantly.
Also, look for other ways to diversify your business. You don't need to be locked into making "traditional" large scale retail console games anymore.
There are many new platforms and publishing options, online distribution, casual games, handhelds and other places to publish games more quickly and easily than you may realize. There are also many options to extend your games as well, so creating downloadable content, theme packs and other content can add a lot of extra income, while also extending the brand of your games.
The biggest risk related to pre-production is not having adequate (or any) pre-production at all. Some teams will jump right in and just start building the game, planning to adjust things as they go. The whole point of pre-production is to mitigate the creative risks of a project and build a plan which you know you can execute on and have proven is feasible.
Unfortunately it is very easy for a team to either work on the wrong stuff during pre-production, or to not work on things thoroughly enough, since the definition of pre-production is a little vague for most.
For example, teams have used all their pre-production time to test risky new game technologies and mechanics, but then failed to produce anything else. So, in this case, they succeeded in that they proved that their big new and hopefully cool feature sucked and wasn't worth doing, but on the other hand they chewed up 12 months and now have almost nothing to show for it -- and basically had to start over and prove that the new core idea was feasible.
Another common mistake is that people prototype a variety of features, but hack the code together. This code is usually meant to be redone, but now suddenly everyone assumes everything is "working" and that the game can be done much sooner than the team actually intended.
What you do in pre-production is just as important as how you do it.
Concept Development Risks
Many teams still don't properly understand pre-production and concept development. It is really hard to properly develop the concept for a new project while working on another project. Most teams don't have the resources to allow a dedicated team to concept a new project while trying to finish the old one. This actually is one of the biggest problems in game development today; as it means that many projects get off on the wrong foot and start down a bad path from day one.
In a perfect world, a team which is developing the concept for a new project should be relatively small and given the time to really get their ideas down and proven before turning on the big faucet of a full team.
What tends to happen is that a project will finish, and the team members are often burned out from crunching, but need to start working on the next project after a short break.
Often the worst thing you can do from day one is to give a team a hard ship date, team size, budget and project requirements. Unless you have something to go off of, this can all be speculation and just put a team into a box it can't escape from.
A large game could easily require three to six months of concept work before it is ready for a larger team start work on it. If a team has to roll over from one project to another, you have to be ready for the transition. The design team is therefore often under too much pressure from day one, and forced to cut corners and either not properly design parts of the game or move forward on stuff that they will inevitably have to redo later.
In other words, the problem with the conception and pre-production of projects is generally a staffing and scheduling problem. It can generally be avoided by either having a small dedicated concept team which can work on new ideas and have them ready for production when needed, or by restructuring your team to either allow for a more flexible team structure, so you aren't forced to jump into production prematurely.
If you utilize a lot of outsourced or in-sourced labor (especially artists), have some standardized technology which doesn't require a large engine programming team, and have a flexible design team which is able to wear a lot of hats, so your team may be able to adapt much more easily.
Prototype Risks
Along with the concept and pre-production phase risks, there are also a lot of risks associated with building a prototype -- and even more with not building one properly. Prototypes should exist to minimize risks in the project.
What development risks exist need to be proven in the prototype stage. The prototype should prove any risky design elements, new or risky technologies, any production pipelines or anything else which need to be proven before the full game production begins.
Just doing a prototype isn't mitigating enough risk for a project anymore. What you are prototyping needs to be carefully evaluating to minimize the most risks possible. You should evaluate what the project and team risks are and make sure those are addressed. From a design perspective, you need to prove any mechanics which have either a risk of not being fun or a risk of being to difficult to do for production reasons or other reasons.
By the time you finish your prototype, you need to make sure you are ready to go into production, and have a plan to deal with any remaining known risks in the project.
Simply stated, the development process of a game is the way in which the game will be developed. It is the steps which will be taken to ensure that nothing is forgotten, and that everything happens in the order it should. It will dictate things like how much documentation is created, how things are approved, how the team is structured, what the overall workflow will be, if you are using an agile development model, and so on.
It is also important to understand how having a good development process is also critical to avoiding risk. If you don't have a clear roadmap of where you want to go, and how to get there, you face a major risk. Having a very clear process includes not only documenting the individual features themselves, but the entire pipeline for how the game will get made, how decisions will be made and so on. Having a process requires you impose some standards, and taking a stand on how things need to run in order to get done on time and on budget.
The development process is also important to understand in relation to the requirements from a publisher, a licensor, or other external factors which may be involved in the project. There are often requirements from outsiders who have final say on things in the game, and it is important that you understand what they will need and when they will need it during the production of the game.
For example, we often don't schedule extra time to create a special E3 demo, or to create a demo that will be distributed to players before the game ships. We also often underestimate how many demos will need to be delivered to the publisher and how much time will be needed to wait for and address publisher feedback each month (or whatever interval). I have worked for publishers that have regular reviews, and at each review, your game could be killed if it looks bad or doesn't show progress.
I have worked on projects where approximately 20 percent of the total project resources and personnel were dedicated to just making demos -- which contributed very little to the overall game. It killed me to see this small dedicated demo team which just made demos to keep the project going. It was better to do that, however, than distracting the entire team for two or more weeks every few months to put together a demo for a review.
It is also important to understand when, where, and how your development process may be broken. Maybe you brought your development processes over from a larger company where you used to work, or maybe you used it on a previous project. Regardless of where the process came from, you also have to make sure that you aren't stubbornly sticking to it, if you realize it is broken and actually hurting the project.
There are no hard right and wrong answers to having a great process, but I have found that if the process isn't defined and refined, that this will be the biggest risk. I also have found that any process which is poorly documented and poorly followed is also a risk. So, in the end, you really need to understand your development model and process, or you will face major risks in many areas of the project.
One of the biggest risks for most small teams is team structure. Teams at large companies can easily reach over a hundred people, while really small iPhone or casual teams can be fewer than five people. Some teams have most everyone working on the project on staff at the developer, while others rely on people from other internal teams, external teams, outsourcing companies and consultants to help them.
No matter how you structure a team, there can be short- and long-term risks associated with your decision. Larger teams cost more money to maintain each month, and thus typically require more projects to keep them busy and cost effective. However, large internal teams can allow you to hire much better talent and increase the quality of your products.
Outside team members might be able to be chosen, or may be forced on you, so you need to evaluate the risks of using outside help, along with the benefits of possibly reduced costs and overhead to the project and company.
So, no matter how you decide to structure your team, you need to take a look at the risks associated with your team, both short and long term.
Staffing Risks
Hiring the wrong people, not being able to hire who you need, key people leaving, or other staffing problems can also lead to major risks in your project. Even though there is a lot of available talent out there right now, this doesn't mean finding qualified help is easy.
You may find dozens or hundreds of candidates who are qualified for some positions and only a few who are truly qualified for others. By the time you find the right people, get them hired, relocated and settled in, you may have spent months of time you didn't account for. Many teams fail to account for how hard, long, and costly hiring can be.
If you are pushing some people too hard, will they break? Losing key staff at any time can be costly or devastating to the project. You need to evaluate everyone on the project, and understand what would happen if they left or couldn't work anymore.
In some cases, you may need to require some team members to document certain processes, techniques or knowledge for others to learn from, or train up either a backup or possible replacement. You should avoid having any absolutely critical knowledge in a single person. This will also allow that person to go on vacation and not get completely slammed if something goes wrong.
So, to mitigate staffing risks, make sure you start hiring early, make sure your team is happy and not crunching (either at all or too hard), and that knowledge is documented and spread around to secondary people whenever possible.
Work for Hire Risks
Besides outsourcing, there is work for hire. This can be a general blanket for using anyone on a project which is outside your core team. This might include hiring outside designers, programmers, sound designers and much more.
The term "work for hire" is usually used in reference to hiring a full team, but could also be applied to using contractors. In some cases, an entire company may be hired to do some aspect of the project for you, whether it is a full port of the game to another platform, to doing an entire game mode (like multiplayer) for your team.
As with using any outside company, there are always inherent risks. Just like in outsourcing, you never know what the company is going to do. You need to vet the companies and people you work with and make sure they have a good reputation and won't leave you hanging or do poor work. It's important to understand what each team could do to the project if they fail.
Also, it's important to stay on top of the developers or contractors and make sure they are adequately making their deadlines. Some teams like to promise you their best team or people, and then can end up giving you different people, or putting the people which are supposed to be on your project also onto other projects, reducing their quality.
It's impossible to mitigate all risks associate with using outside help. The best thing you can do is make sure they are on very regular milestones, and that you constantly communicate with them, as well as visit them whenever possible.
In this first part of the article, the risks covered are more general and broad to the project and company. In Part II, I will talk more about specific risks which affect the different teams on the project during production. In Small Developers: Minimizing Risks in Large Productions - Part II, I will also go into more detail about how to avoid risks and how to not let them happen in the first place.
If you found this useful, and haven't read my first article on Globalizing Production for the Future, I would highly recommend giving it a read, as it also talks a lot about how to structure your team and projects to minimize the risks in large scale game productions.
---
Title photo by Toshiyuki Imai, used under Creative Commons license.
Read more about:
FeaturesYou May Also Like
.png?width=300&auto=webp&quality=80&disable=upscale)
