Apr 23, 2019
Poor risk management is a common issue behind the three most significant problems facing the industry: crunching, projects going over budget and projects skipping deadlines. However, the use of formal risk management practices seems to divide the industry, with some producers even arguing that risk management does not apply to game development.
In this article, I will explain what risk management is really all about, why it is always necessary, and how to adapt it to your game project.
What is Risk Management?
Risk management is the process of identifying potential risks, planning responses to said risks, and monitoring for their occurrence.
For the purposes of this article let’s define risk as an event that may or may not occur in the future. Furthermore, we can divide risks into known risks (likely or expected risks, ex: level design takes significantly longer than planned) and unknown risks (completely unexpected or random, ex: an earthquake damages the team’s offices).
There is not a lot you can do for unexpected risks, except being conservative with spending and planning to ensure there is room in the schedule and funds in the account to deal with the unexpected. However, there is a lot of things you can do to prepare for expected risks, and as a producer, it would be negligent not to do so.
All risks have a likelihood of happening and a potential impact associated to it – you can think of most unexpected risks as risks with an incredibly small expected probability of occurring. Thus, it’s necessary to prioritize risks in both dimensions: a risk with high impact but a low chance is less scary than a medium impact and high probability risk.
Your objective as a producer when approaching risk management is not to eliminate all risks, an impossible goal, but to minimize the overall effect risk items might have in the project. There are five main strategies to deal with threats:
- Escalate: Only available to developers that are part of a larger company, it involves asking a higher authority to take on the risk. An example might be a software license for the whole company that is about to expire, and you ask higher management to negotiate a renewal. Escalated risks are not monitored after the agreed escalation party has accepted ownership of the risk.
- Avoid: Is when the project team takes actions to eliminate the chance a risk materializes at all. The most common risk avoidance measure is to control the scope – a difficult feature to implement that is not core to the game? Leave it for the sequel. Another good way to eliminate the risk is by prototyping – not sure of a technology? Do a quick prototype and see if it makes sense to include it in the plan.
- Transfer: Is when the risk ownership is shifted to a third party. This is the concept behind insurance, you pay so someone else carries the risk. Some applications of transfer in game development are: transferring to the publisher marketing responsibilities and outsource the code of multiplayer networking code to another studio.
- Mitigate: Is when actions are taken to reduce the probability and/or impact of a risk. A good example is the use of constant demo releases and playtesting to make less likely that the final release is not fun/polished enough for the target audience. Mitigate and Avoid are similar, but the difference is the extent to which you can be sure to reduce the threat, partially (mitigate) or entirely (avoid).
- Accept: Sometimes there is not a lot you can do to affect a particular risk, you have to accept as a fact that the risk might happen. However, acceptance can be active or passive. Active acceptance is to allocate extra time and money to ensure the team can react/recover from said risk (Contingency reserves in project management terms). Passive acceptance is the decision to take no proactive action, except for some monitoring. Acceptance is sometimes the best course of action, especially for risks with a very low likelihood of happening or where the cost of acting might be more expensive than the expected effect of the risk.
Why Risk Management is necessary for any project?
Unforeseen events and wildly optimistic scenario planning, are the main reason for the game industry’s notorious fame for projects going over budget, skipping deadlines and as a result crunching.
Making games is hard, no question about it, but it shouldn’t be as painful as it has been. Proper risk management would have avoided a great deal of horror post-mortem stories. Through adequate risk identification and management, the team can tackle unknowns head-on; prototype, test and understand what is worth including in the game and what is best avoided.
The reason risk management is skipped is usually ignorance or misunderstanding of what risk avoidance is and – more worryingly – a mistaken belief that risks are all part of game development and its consequences such as crunching are to be embraced like the price to work in games. I believe the latter is increasingly less common, but the first is still a common concern.
Uninformed producers tend to associate risk management to a) “formal” project management for large contractors using waterfall or b) an ultra risk-averse practice whose objective is to eliminate all potential threats.
An example of such a negative view is this comment from the research paper Risk Management in Video Game Development Projects:
“This notion of risk management is coming at it from, “How are we going to handle risks?” is kind of coming at it from the wrong angle, because the only way to handle risk is either to cut scope or to just not have a product. And when you’re dealing with physical media, when you’re dealing with console developers, you can’t cut scope. There’s a floor to the point of cutting scope, and so you can have a viable game that will pass their certification standards, with Nintendo or Microsoft, or Playstation or whatnot. So I always laugh when someone says, “Well, what’s your risk assessment?” Well, my risk assessment is, I have a game or not, and here’s what I need to have those things. –A02”
(Schmalz, Finn & Taylor, pg4332, 2014)
Thankfully the research’s participant view stands in contrast with what I have heard and seen from other, more informed producers. The industry has been incrementally incorporating and adapting methodologies and frameworks from the software and entertainment industry as well as creating its own strategies through better risk recordkeeping and more discussion among producers and developers.
It is no coincidence that the incidence of crunch has been diminishing at the same time that the bigger studios are embracing agile practices and formal risk management.
In addition to all of this, if you are looking to work with a producer, a well thought out risk management plan can be a big plus. The effort put into the risk plan signals to potential investors and partners that you are serious, have done your work and are prepared to complete the game with minimum fuss.
How to perform good risk management
The first thing to sound risk management is to not go crazy. After all, do you really need a full day session identifying and planning risk management and monitoring strategies for a 48hour game jam?
For the rest of the article, I will assume the project is a relatively short 3-6 months of development game undertaken by a is a small core development team with limited resources. Larger teams on bigger projects will go through the same process but should dedicate more time to it, as well as make sure that all is correctly documented for later reference.
Preparation for risk planning
Be mindful that some team members might not fully understand what the purpose and objective of risk management are, and you should try to explain what is a risk and what is the objective of the risk planning meeting (identify risks and agree on a risk management strategy per every risk).
Do some research and include lessons learned from past projects that share a similarity to yours – if you are a new developer or new to a specific genre/technology head out to Gamasutra.com and check around for postmortems that touch your particular use case.
Finally, create a prompt list – that is a predetermined list of risk categories that are common for your project/industry. I created the one below by using the top9 risk factors detected by the research paper cited above, four risk factors for contractors and a catch-all category for risks beyond your team’s control (ex: new laws and regulations that might impact your game). This list can help you think about common risks and give some structure to the upcoming brainstorm session.
Identify risks
This step should start immediately after the team has selected game concept, theme, core and reach mechanics and tech and art stack. The idea is to gather the development team and brainstorm any potential setback that the team and project might encounter.
There are two main ways to conduct your brainstorm session:
- Traditional: Explain the objectives again and open up the discussion. The idea is to just get as many potential risk suggestions from the team. Don’t question any opinion, just write them down and get the flow of ideas going. If your team’s discussions tend to be dominated by a few strong personalities make sure to ask people to take a few minutes to write on their own any risks that come to their mind before starting the discussion, this will reduce the impact of group thinking.
- Premortem: Gather everyone and say: “Imagine that we are a year into the future. We tried to develop the game. The outcome was a disaster. Please take 5 to 10 minutes to write a brief history of that disaster. Afterward, write down every risk factor and continue as a traditional brainstorm session.
The premortem is a way to overcome our natural optimism – our mind is excited about the new game to be developed and has a hard time visualizing anything going against the plan, given that we put effort into producing what we think is a reasonable and achievable plan. However, the premortem changes that by forcing us to visualize what failure looks like and create a coherent narrative for it. Therefore, the premortem is usually more effective than traditional brainstorming, but it has the downside that it can feel corny or dramatic.
Its time to start wrapping up the brainstorm session when the flow of ideas is starting to slow down, at this point start consolidating (eliminate duplicates or join similar risks) and categorizing the risks. After the risk list is as complete as it will be it is time to rank the risks. Have everyone write down the probability and potential impact on a scale of 1-5 and average both scores for each risk. Finally, multiply the averaged probability and impact scores for every risk and use this value to prioritize risks.
Define a risk response
As a rule of thumb, if a risk is potentially catastrophic its best to avoid or transfer, while low probability risks can be accepted – Remember to set aside extra budget proportional to every accepted risk just in case. If an accepted risk does not materialize, you can reinvest the funds later in marketing the game or use it as seed fund for the next game.
After the type of risk response is defined, it is essential to assign who will own the risk response. The risk owner is responsible for coming up with a high-level plan (one or two phrases) to approach the risk and a contingency plan if the worst happens. It is also possible to come up with the approach and contingency plan as a group, in this case, the owner is only responsible for the execution of the plan.
The best course of action at this point will depend on your team’s disposition and individual personalities. If your team is full of people who like to verbalize their thoughts and the energy levels are high, keep the momentum going; if not, agree on a deadline and leave it up to the risk owners to work on it on their own.
The risk response and contingency should look something like this:
| Category | Risk Description | Response Type | Response Details | Contingency Plan |
|---|---|---|---|---|
| Fun Factor | IP and concept is not interesting enough to the potential user | Avoid | Conduct a Facebook ads test to determine relative interest in the concept and IP to modify our model | Discuss findings with IP owner and analyze if project is financially feasible in its current format or it will require a pivot |
| Fun Factor | Unclear monetization potential | Avoid | Build out monetization table and use industry standard assumptions to form LTV hypothesis | Discuss findings with IP owner and analyze if project is financially feasible in its current format or it will require a pivot |
| Development Strategy | Control scheme is new and unproven | Mitigate | Build a quick throw away prototype that demonstrates the control scheme, compare with existing market emulation targets | Enhance tutorial to teach the nuances of the control scheme to new players |
Finally write everything (the risk, probability, expected impact, response and contingency plan) in a document to be able to reference it and keep an eye on it. This document is usually known as the risk register.
Take action
After risk planning is complete is time to follow through with concrete actions. Prioritize high risk (mix of probability and impact) actions that will allow you to close (avoid) or mitigate risks.
The necessity to be proactive attacking known risks, in particular, “known unknowns,” is one of the things that Bernard Yee (Executive Producer at Oculus VR) stressed out in our conversation:
Bernard: Well, the known unknowns are really pretty straightforward, because you tackle them right away. Those are things that you try to front-load. Any known risk, you want to tackle it first. We’re working on a particular feature for VR right now. One of the implementation features seems pretty risky, because we weren’t sure all the knock-on effects. You want to get the system up and running so you can start playing it first, and there’s where you can make a better evaluation.
Bernard: I think the unknown unknowns, you just have to kind of brace for, because by definition, you don’t know them. But the known unknowns are things like we know this feature has a lot of potential effect, knock-on effects. Why don’t we prototype it and start using it? Put it through a user research session of 10 to 15 users and see what they do? Start getting a feel for how much work it is, and have a contingency. Like, “Yeah, that feature, it’s cool, but to really make it polished and great, it’s going to take us a lot of time. Let’s just do the simpler, less ambitious version.”
Not all risk management strategies can be front-loaded, it is the producer’s responsibility – alongside the assigned risk owner – to regularly monitor for those risks. The faster you can detect if a risk is materializing or changing (increased likelihood for example) the better prepared you will be to face it.
Conclusion
The objective of risk management is not to eradicate risk, but to identify the project’s weak spot and be prepared to face them head-on.
Risk management is definitely not the sexiest of topics in game development; many of its prescriptions to risks, such as using iterations and prototyping are increasingly common practices in the industry and should not take anyone by surprise. However, by taking the time to purposely think about risks and responses the development team increases the odds that they will deliver a good game on time and makes the team a more attractive investment for publishers.
1 Schmalz, Marc & Finn, Aimee & Taylor, Hazel. (2014). Risk Management in Video Game Development Projects. Proceedings of the Annual Hawaii International Conference on System Sciences. 4325-4334. 10.1109/HICSS.2014.534.
