|
[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.
An Overview of Risks
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.
|
Printer-Friendly Version
I did want to hear more about the process of risk assessment. In the Prototype section, for example, you mention that is a point of assessment, but also there was a mention of regularly getting leads together to communicate emerging risks. Noting how important it is to identify risks early, what strategies help to do that without making that process "too regular", where the lead's eyes glaze over. What are some key things to keep an eye on that give clues to emerging risks?
Also, it may be pertinent to point out additional risks in team and staffing, that is The Human Factor; how teams gel or do not gel. In our studies of Great Groups, there are techniques to help maintain efficiency, innovation and productivity once a Great Group is formed, but it seems a critical part of that is picking the right team members in the first place; picking members that will gel.
Great job, Troy. I can't wait for the next part.
Why make a big team?
Outsource.
Be modular.
Develop a roster of talent and outsourcers, and live in that community.
Ramp up production only when you need it.
Hand pick your talent and outsourcers for the technical and aesthetic needs of each individual project (instead of always recycling whatever talent/platforms you have from project to project, oblivious of whether they are the best people/technologies for the project).
Now not only do you have a more flexible, less burn intensive studio, but you have a system that frees talent from being imprisoned by whatever IPs are housed in one company.
PS: The "Globalizing Production For The Future" link is broken.
One of biggest oversights a lot of project managers and managers in general make is that they solely focus on avoiding or mitigating threats and fail to identify opportunities where project / business performance can be improved with regard to schedule, quality, and other criteria. For these opportunities new activities in the project should be taken to enable them (increase the probability of it occurring) or enhance them (increase its value to the project / organization).
I applaud the author for raising risk identification as a subject of discussion on this industry website. This article would be accurate by replacing the word "risk" with "threats." Furthermore, I would like to see the author do a follow up explaining the types of opportunities that may arise out of the various risk categories identified in the article. This would give professionals in the industry a more comprehensive view of project risk management that can further optimize the value of their software projects.
@Richard: in my previous company we used Risks and Opportunities, not so much the word Threat. Maybe wrongly so. The important thing is that you look at both, and agree on the language to use. In my experience it's much harder to look at opportunities... maybe because we spend so much energy trying to mitigate against risks.
@Glenn: "glazing over" is sadly too common. Two things to consider. One: as a leader, set the example. If you give it the attention and energy it deserves, e.g. refresh the risk matrix regularly with your team, insist on accurate description of risks, etc. you will signal "this stuff matters" and create the right dynamic. Two: risks are only worth something if you have a mitigation plan behind it. Give each responsible person a clear, unambiguous, achievable, time-boxed mitigating action. And review these actions as per your agreed plan. This will help make risk mitigation a central part of your production, and not a "tick the box for upper management" time-waster.