Risk management has been a big part of my work for a long time now. I’ve taught courses on it, published a book about it and spent a great deal of time thinking about how it can help people making games. What interests me most isn’t the register itself, although we do need somewhere to put it all. It’s what happens once we start paying attention to the risks we’ve identified.
Making a game involves committing time and money while a lot of important things are still uncertain. The core mechanic might look wonderful in a prototype, but we don’t yet know whether it will hold a player’s interest for a full game. The technology might be capable of delivering the vision, provided we can get it working on the platforms we have promised to support. Our plan might depend on people and funding being available when we need them.
We have to make decisions anyway. Waiting until we have removed every uncertainty would be a rather effective way of ensuring that we never finish a game! What we can do is look at which risks matter, decide how we want to respond and keep checking whether that response is still appropriate as the game develops.
A register is a starting point
A risk register gives us somewhere to record what might happen, how likely we think it is and what the impact might be. That is useful. It helps people share an understanding of the situation, and a heatmap can draw attention to things that need a discussion.
But let’s imagine a risk sitting in the red area of that heatmap. It has been red for the last three reviews. Is someone doing something to reduce it? Have we agreed to accept it, or has it simply stayed red because nobody has had time to look at it properly? Those are rather different situations, even though the heatmap might look exactly the same.
To manage the risk, we need to know who is responsible, what response has been agreed and what evidence will tell us whether it is working. Then we need to come back to it. If the situation changes, the assessment and response may need to change too.
That takes time, of course, and the people involved are busy making a game. A process that depends on someone remembering every action and reconstructing decisions from old meeting notes is going to be difficult to keep going. We need the register and the conversations around it to help people do their jobs, rather than become another thing to update for a meeting.
Following a risk through a game
Let’s take a fictional example. A team has a promising prototype for a central mechanic. The early sessions are fun, the team is enthusiastic and there is a plan to build a substantial amount of content around it.
There is also an assumption: that the mechanic will remain engaging across a much longer game. Perhaps that is true. But if it hasn’t been tested beyond short sessions, the team has a reason to examine it before committing too much of the game to that design.
The risk might be that players lose interest over longer sessions, leading to major design changes after substantial content has already been built. The consequence isn’t just that somebody has to update a document. It could affect scope, budget, timing or the experience the game is trying to offer.
A possible response is to run longer playtests before the team commits to the full content plan. Someone needs to arrange the test, agree what it is intended to tell us and make sure the results are reviewed by the people who can decide what happens next.
Let’s say the results are mixed. Some players enjoy the mechanic for much longer, while others lose interest. The team might want another test, or it might identify a part of the design that needs changing. It could also decide that the remaining uncertainty is acceptable for now. What it shouldn’t do is quietly treat the original assumption as proven because the result was not a complete disaster.
A small indie team may have to make that call with the people in the room and the time available. A larger game may need the feature team, game leadership and a funding decision to come together. Neither situation calls for an enormous committee by default, but both need somebody to make the decision and understand what is being accepted.
Risk is not the same thing as an issue
This distinction is easy to lose when we are busy. A risk describes something uncertain that could happen. An issue describes a situation that already exists or an event that has happened.
In our fictional example, the possibility that players won’t stay engaged is a risk. If a playtest has been cancelled because the testing equipment has failed, that failure is an issue. The cancelled test may affect how well we understand the risk, but the two things are not interchangeable.
The distinction matters because the response is different. For a risk, we might try to reduce the likelihood or impact, or prepare a contingency if it happens. For an issue, we are dealing with a situation that already exists. If everything goes into the same list under the same name, it can be surprisingly difficult to tell what we are trying to prevent and what we are trying to resolve.
Assumptions and dependencies matter too. They can affect a risk without automatically being risks themselves. If a team assumes that longer playtests will confirm its early results, we need to know whether that belief is supported. If the test depends on access to participants or equipment, we need to know whether those are available.
Different levels need different decisions
The person working with a feature team needs enough detail to organise the playtest and understand what comes back. Someone responsible for the whole game may need to consider what the result means for the plan, the teams involved and the next commitment.
A studio leader might need to consider funding, competing priorities or whether to support a change of direction. Those questions are connected, but they aren’t identical. Copying the same risk entry into three reports doesn’t automatically give each person what they need.
This is why I talk about project, programme and portfolio perspectives in my teaching. A team needs to understand its own work, while someone looking across the game needs to consider how teams and decisions affect each other. At studio level, the concern may be how much funding or capacity is tied up across several commitments.
An indie founder may need to look at all three perspectives personally. In a larger studio, the information may have to travel between different people. Simply handing each of them the same list isn’t necessarily enough; each needs to understand the part of the situation they can actually influence.
Making the process part of production
You can manage risk with a spreadsheet and regular conversations. Plenty of teams do, and if your process is working well, you should understand what makes it work before deciding that you need to change it.
The difficulty is keeping the process useful as production changes. A response that seemed sensible three months ago might no longer be sufficient. Equally, the team may have done excellent work to reduce the risk, but nobody has revisited the assessment, so leadership is still looking at the old picture. In both cases, the review needs to consider what has changed and what evidence supports a different judgement.
That doesn’t mean discussing every risk in every meeting. It means establishing a rhythm that suits the work and gives the important uncertainties attention while decisions can still make a difference.
It also means accepting that good risk management does not eliminate uncertainty. Games are creative products, and some worthwhile decisions involve taking risks. The aim is to understand what you are taking on, make an informed choice and avoid discovering too late that a crucial assumption was never examined.
Bringing the method into a system
I’ve explored these ideas in my book, Risk Management for Video Game Professionals, and teach them through Game Production Academy. In particular, my course Implementing a Risk Management System for Game Studios is about putting a working risk-management system in place, with ownership, reviews and decisions connected to production.
That studio course led directly to the Studio Risk Intelligence System, or SRIS. I wanted to take the method I teach and build a system to help people put it into practice and keep it going as their production changes.
SRIS is designed to help people maintain a working picture of risks, related issues, assumptions and dependencies, along with the actions and decisions that follow. It is intended to support the different questions people need to answer at project, programme and portfolio level, without replacing the tools teams use to manage their work.
One part I’m particularly excited about is the optional AI assistant, the Studio Brain. It is designed to bring knowledge and advice from my book, courses and experience into the context of a studio’s own risks. The aim is to help spot patterns and suggest ways to respond, rather than give a generic answer detached from the work you are doing.
The Brain can suggest; people still need to assess its advice, decide what to do and confirm what goes on the record. It’s an early product, and I want to test how useful that combination really is in practice.
A pilot, and an invitation to try something now
I’m looking for a small number of producers and studios willing to help test SRIS through a controlled pilot once external access is ready. You might be working in an indie studio, or looking after several teams within a larger one. The pilot can focus on the part of production you are responsible for; it doesn’t have to cover the entire studio.
The current offer for selected studios is a 12-week pilot with no fee, a separate private site, initial setup and weekly time with me. In return, I’m looking for repeated use and candid feedback. Access and use of studio data depend on readiness checks and signed data terms.
If you would like to learn more or register your interest, you can find the details on the SRIS page.
And if you aren’t looking for a new tool, try this before your next review. Pick one risk that has been on your register for a while and look at the response alongside it. Is there an owner, and do you know what evidence would tell you whether the response is working?
If the answer isn’t clear, take it to the people involved and find out what has changed since the risk was last discussed. You may discover that the original concern is being handled well, that the plan needs help or that the team is waiting for a decision. Any of those would be useful to know.
For more on the method, you can also explore the Game Production Academy courses.
