Imagine launching a major feature only to have the servers crash under the load. The chaos, the angry users, the weekend of crunch - these are the consequences of underestimated risks.

You can’t really live a life without taking any risks. It is an unavoidable part of any project you start and yet it’s often underestimated. In the world of game production (or any other industry) ignoring risks can lead to delays, financial disasters or simply failure. However, risks that are managed correctly can be turned into opportunities, just like fear.

I dealt with many risks in my daily professional life intuitively, without a formal system for documenting them, qualifying and developing a response strategy. When you are dealing with weekly releases of live games, risks seem quite obvious but this approach may lead to overlooking some of the less obvious issues that might backfire later down the road. This article is a result of my exploration of how to identify, qualify and manage risks effectively. Here I will summarize actionable techniques and insights from both theory and personal experience. Hopefully, it will be useful for you too, my dear reader.

Risk Management and Why Does It Matter

It is impossible to avoid all the problems and risk management is not about that. It is about anticipating, mitigating and responding effectively when risks arise. To put it short (and save your focus for more important parts of this long article), good risk management aims to reduce uncertainty, help teams prepare for challenges, save resources by preventing avoidable setbacks and identify opportunities disguised as threats.

It’s about spotting potential threats and opportunities before they materialize.

For example, each December is full of risks and challenges for Penny & Flo team: everybody will be on Christmas vacation but the game still needs to receive updates weekly. Planning the workload, resources and scope of each release helps us to predict possible QA bottlenecks and operate the major features carefully. This preparation ensured that even with a tight timeline, the releases went live smoothly.

But how do you spot the variables that can derail even the best-laid plans?

How to Identify Risks

Some risks are obvious (no release = no revenue) while others require deeper investigation (tricky code dependency that will slow down the delivery of the feature and make it more risky due to a bigger client change).

But don’t fret, I’ll make sure no stone is left unturned, starting with the risk classification. They come in many forms but the main types include:

• Primary Risks - initial risks that can directly impact a project. Example: we are low on QA so we might not verify all the bugs in time for the release.
• Secondary Risks - a direct consequence of addressing primary risks. Example: you decide to allocate extra resources to the release, leaving another feature/project short-staffed.
• Residual Risks - risks that remain after all planned mitigation actions have been executed. Example: you assign a lot of junior testers to the release but some bugs will still slip through.

Name it to tame it - understanding the risk category will help to allocate resources effectively and plan the next steps. Here are some practical steps I took to spot risks and identify opportunities (sponsored by common sense 😅) and some of the well-known strategies that I haven’t used myself:

1. Historical Data and Case Studies
Look at similar projects within your organization or industry. For example, in Penny & Flo, we analyzed data from past live-ops rollouts for both Penny & Flo and Lily’s Garden to identify bottlenecks. Most of the bigger features have analysis data and retrospectives from the teams, plus we closely monitor publicly-available reports i.e. from GameRefinery.

2. Brainstorming and Reverse Brainstorming
I wrote about both here. Regular brainstorming is about generating a list of possible risks based on experience and project specifics, and reverse brainstorming flips the script by asking “How can we ensure we fail?” and the answers often wouldn’t otherwise come to light.

3. Workshops and Surveys
Workshops with stakeholders and surveys among team members can surface risks that a single person might overlook. These methods are especially useful for cross-functional teams and can be conducted either by someone within the team or by a person from another that specializes in qualitative analysis (in my case it’s a user research specialist).

4. Team Consultations (Delphi Method)
I’ve never tried it myself in exactly that way but still worth noting it. The Delphi Method involves gathering insights from experts in your team or network, taking into account diverse perspectives. Anonymity in responses is supposed to encourage honesty and creativity. Here you can read how this method was used in plastic surgery, for example.

5. SWOT Analysis
Strengths, Weaknesses, Opportunities, and Threats: A classic tool to assess internal and external risks. For example, a game with innovative mechanics and popular IP (strength) might also carry risks related to player onboarding and limiting the reach (weakness). It’s basically a more advanced form of a standard list with pros and cons, and its simplicity makes it a good use for almost any situation.

6. PESTLE Analysis
PESTLE stands for Political, Economic, Social, Technological, Legal and Environmental factors that are considered during this analysis. For instance, regulations on lootboxes in the EU might be a legal risk for a monetization strategy in those GEOs. The PESTLE format helps to keep in mind all of those factors instead of focusing on just one or a couple of them.

7. Risk Taxonomy
This involves creating a categorized list of potential risks (e.g., financial, technical, legal, operational). It serves as a checklist to ensure thorough evaluation throughout the project's lifecycle.

8. Assumption Analysis
Every project is built on assumptions about timelines, resources or player behavior. Try to stay aware of those assumptions and challenge them to identify risks within them.

How to Qualify Risks

Now, with risks on our radar, the next step is to qualify them, assess the likelihood and impact of each risk and prioritize where to focus our efforts. To qualify risks, we typically evaluate two main factors: Probability of occurring (aka Likelihood) and Impact. Combining these gives a sense of the risk’s overall significance. For example, an 80% probability of missing a typo in Korean localization is less urgent than a 20% likelihood of not getting UI for the feature in time.

To qualify risks, these techniques can be used:

1. Risk Matrix
   A visual tool that plots risks on a grid of likelihood versus impact. This helps prioritize risks into categories like:

• Low priority (monitor only)
• Medium priority (manage proactively)
• High priority (requires immediate action)
  For example, in game production a potential delay in visual assets might be a medium priority if buffer time is built into the schedule but a high priority if the delay impacts a critical launch (like a Christmas sale, for instance🎄).

2. Risk Scoring and Ranking
Assign numerical values to probability and impact, then assign risk scores based on the formula “Risk Score = Probability x Impact”. This can be combined with the previous point, visualizing the score inside the matrix.

Side Note: the same formula works for Expected Monetary Value if the Impact has a monetary equivalent. I.e., 50% probability of losing $20,000 has a -$10,000 expected monetary value as it’s a negative outcome. Combining several negative and positive outcomes will give an overall EMV of the project risks which is useful to determine the strategy.

3. SWIFT Analysis (Structured What-If Technique)
While SWOT is and advanced form of “Pros vs. Cons”, this is and advanced form of “what will happen if X occurs?” questions. For example, “What if our server goes down during Christmas week?” leads to identifying backup strategies.

4. Monte Carlo Simulation
I’ve never used it myself and it sounds pretty complex, but I see a bunch of software tools that can do it for you, in case this method appeals to you. It is supposed to be great for complex projects as the simulation uses algorithms to model multiple scenarios and estimate the probability of different outcomes.

Here are some practical tips for risk qualification from my own experience:

• Consider secondary and residual risks: Try to think about the consequences of your risk response strategy and look out for those risks later in the project. Make sure you monitor the outcome closely.
• Involve the Team: Risk qualification is a coop mission. Engage your team to get diverse perspectives, especially when the risk lies in a specific area of expertise.
• Document Everything: Keep a ‘risk register’ and update it with the results of your qualification process.
• Focus on the Big Picture: Don’t get buried in details and keep the overall project goal in mind to avoid wasting time.

Risk Response Strategies

Once risks are identified and qualified, the real work begins: addressing them. Risk response strategies focus on minimizing the impact of negative risks while maximizing opportunities.

The Four Strategies for Negative Risks (aka Threats)

1. Avoid: eliminate the risk entirely by changing the project plan. This might involve removing a risky feature, adjusting a deadline or altering a contract with a third party, i.e. if a specific SDK is prone to causing crashes and ANRs, switching to a more reliable alternative can avoid the associated risks.
2. Transfer: shift the risk to a third party. The most common example is purchasing insurance against some negative outcome, i.e. car crash so the risk will be bared by the insurance company and not by you.
3. Mitigate: Reduce the probability or impact of a risk (or both) through preventive measures. For example, implementing automated testing along with manual QA can mitigate the risk of bugs slipping through.
4. Accept: Acknowledge the risk and prepare to deal with it if it occurs. This strategy often involves contingency planning such as allocating a buffer in the schedule for unexpected delays (or in budget for unexpected expenses).

The Four Strategies for Positive Risks (aka Opportunities)

1. Exploit: Take direct action to ensure the opportunity occurs.
2. Share: Partner with another party to maximize the benefits of an opportunity. The most common examples are publishing and co-development.
3. Enhance: Increase the likelihood or impact of an opportunity. This could involve additional UA efforts for a game that’s showing good KPIs.
4. Accept: Same as the risk acceptance, acknowledge the opportunity and prepare to take advantage if it arises.

Practical Integration

Once you’ve selected your approach and tools, incorporate them into regular workflows. Allocate time for historical data analysis and brainstorming in the team’s schedule, document your findings on Confluence or Notion, use tracking tools like Jira or monday.com to track identified risks and response strategies, continuously assess risk probabilities. Risk management isn’t just a one-time activity but a continuous process that evolves alongside your project.

NB: Just as with management techniques, working on live games taught me to avoid a one-size-fits-all approach in risk management too. The risk response strategy should match the risk’s nature and project goals, and those are always different, at least slightly.

Don’t wait for a crisis to think about risks. Regularly set aside time to review and update your risk assessments. Even for a completed project, you can conduct a retrospective to identify what could have gone wrong and what risks were avoided. Encourage open conversations about risks without pointing fingers: when team members feel safe flagging potential problems, you can address them proactively. Every project offers lessons on what went well and what didn’t and documenting the insights can guide future projects.

By making risk management an integral part of your workflow, you empower your team to tackle challenges with confidence and ensure the projects stay on track. Continuing my favorite ship crew analogy, a ship is safest in the harbor but that’s not what ships are built for. And with solid risk management practices, you can steer your ship through the stormiest seas 🌊