A general chat around risk management for those involved in making video games. This is an introduction to the topic and is aimed at game producers.
If you prefer the podcast version, you can find that here:
https://www.game-production.com/podcast/episode/4a84cfa5/11-risk-management-for-game-producers
Part 2 goes into more detail on actual risk and issue examples.
https://www.youtube.com/watch?v=1d9CSoy_z3w
Part 3 is a walkthrough of generating a Risk and Issue Log that you can download and use/abuse at your leisure.
https://www.youtube.com/watch?v=PljB6IBZW2w&t=421s
I mentioned some other articles on risk management for gaming. Here they are:
https://www.gamasutra.com/view/feature/131309/risk_management_with_development_.php
https://www.gamasutra.com/view/feature/191523/managing_risk_in_video_game_.php
Here is the complete transcript.
Risk Management for Game Producers
Main Speaker: Hello, it's Liam Wickham back to talk to you about game production. Now, today, I want to talk about risk and I know that's something that's quite boring. And when you talk about raid logs, risk management, issue management, and things like that to gain producers or anyone in the games industry, 95% of them go, yeah, whatever we don't care, just get on with it. Games are hard. How are you going to measure risk in the games industry in a way that makes any sense and is useful? I'm really, I kind of agree with them to an extent because of this, when you make a game, especially a big game with lots of people, but when you make a game of any kind, you're exploring. You're out there to discover. You're out there to go. Can we find the fun? To use that terrible term. Or when do we know that this game is viable? What do we have to do to make this game profitable? How is this game going to be released, launched, marketed, et cetera, in a way that's going to make us all rich or at least in a way that's going to make us all feel very happy to let go of our baby? These things happen over months and years with a couple of people or many hundreds of people across different departments. It's a huge project, but it's handled quite differently across different areas of the games industry.
And really, I want to pull you back to the idea of risk being the first thing that you should know about and feel is extremely important to making any game, even before you start making it. Why is that? Well, because risks determine whether you should even start the game or not. Risks should help you to scope the game. They should help you to restrict what you do. They should help you to restrict in a way that helps you to focus down on what you need to discover first. Now, traditional risk management in which you have raid logs, which are risks, assumptions, issues, and dependencies, they were brought about by traditional project management. So we have in the UK Prince2, which is the government standard project management training and standards. And we have in the U.S. PMI PMBOK, which is project management, book of knowledge, which is a very lengthy time. Now, these things don't tell you how to manage a project of any size. What they do is by chapter, they just list out things like what is risk management? What does a raid log look like and what should go in it? And they do that for their different project management chapters. But they don't actually teach you how to do it. Because of course they can't, they're generic. They can't say that for this specific project, you should do it this way or that way.
They're generic training, generic standards. And you're supposed to adapt those standards much like making a game in which you may be, have a bunch of veterans working for you who have experience in different games and you hope that they will bring that experience to you. And that, that being their standards, they will then customize it towards what you need. That's great, that works. However, nobody really talks about it. If you do some searching for risks in the game industry, you'll find that risk in game production produces about two or three results. There's very little... there's one study that's been done academically. And there's... I think two Gamasutra articles about it, which are actually pretty good. And they're from quite a long time ago, 2013, I think in 2001. So, not so lot has happened -- risks and issues. Let's think about what they are. A risk is something that hasn't happened yet. An issue is something that has happened. So keep that in mind. So a risk -- something that hasn't happened. Now, I've worked outside of the games industry for many years, as well as inside it. I can tell you now that handling risks really confuses people. When we look at the games, industry risks, being something that haven't happened, yet, issues being something that have happened already, these risks and issues can be categorized quite clearly for a game. They tend to fall into broad categories.
So, let's take one for example, which is staffing. So that's a really obvious one in the games industry. Do you have enough people? Probably not. Do you have the right people? Almost certainly not. Have they got the right skill sets and experience that you really, really need? Probably not. So there are some risks right there, right? So, because in six months’ time down the line, when you're looking at this risk that you brought up now about, well, we don't have this particular program with a particular skill set that we need. We want to be say on pierce five, and we don't have anybody with any experience of even baseball they're all coming from Microsoft. What are we going to do it? If you have that situation at six months down the line, you say, I raised this risk and we have been working on this risk to mitigate it -- mitigation, being to do something about -- for six months now. And as a result, we were able to handle that risk. We were able to go to senior management, find somebody, bring them in this risk has now been mitigated. We can close this risk off. And you think hooray, but what often happens is that people simply go [inaudible] we're in a right mess. No, one's talking to anyone else. Yeah, it's typical for this place. We need these programmers. Everyone knows about it, but no one's doing anything about it.
That's your fault, if you're a producer, you're supposed to do something about it. And the easiest way to deal with long term risks and issues is to get yourself a risk and issue log; is just to get yourself an Excel spreadsheet or whatever you like. Start listing these things and start taking people through them. What I used to do when I was executive producer, at Sumo Digital, we would have a leadership team meeting. And I would put up that risks and issues and I would make the team leads, go through their own ones that they owned, that I had assigned to them and say what have you done about this? Okay, let's talk about it. And I didn't do that as a punishment. I did it because it was a chance for them to shine. It's a chance for them to be motivated to go, okay. So each time I come to this leadership meeting, rather than us just sitting around going, yeah, whatever, I've got something to talk about. I can talk about the progress I've made. And I might not sound very much like a, yay, we're a game it's all great and fun. It's not great and fun to make a game. It's a really serious business. And there are horrendous risks that you are probably already aware of or that you should be, or that you will be. And to come to a team of people who are taking it seriously and who will say to you, right. Every week we go over our major risks and issues and we see what progress has been made and we discuss what to do about it. And as we come near the trigger points of when we think these things are going to become real, we are through our leads and through their lead, taking it to senior management above them to deal with. And so we are totally transparent about our risks and issues and that transparency is so important. Because there's a tendency to just moan and bitch, and to not write things down and report them upwards.
And if you don't do that, it's your fault. You are accountable. It is your responsibility to log these things. And it can be very simple to do that in a future lesson -- Because there's going to be a lesson. In a future lesson I'll actually go through and create a risk and issue log. And I'll do it with a hypothetical scenario of a game. And I'll break it down into categories and I'll show you how to put it together -- how I've done it in the past, how to put it together, the philosophy around it, how you think about it and what you do with it in terms of a process, it is something which is quite complicated.
So why is it complicated? It's because making a game is complicated. Why is making a game complicated? Or you should know if you're in the games industry, you have got multiple teams, you've got multiple people and problems. You've got multiple hardware, software, coding, design, art, et cetera, issues everywhere. Why? Because it's life, that's what life's like when you throw a bunch of people together and you say to them, let's create something brilliant. Okay. Show me your plan. Well, I don't have a plan. We're making a game. Okay. What game? Well, our design lead and our director of art they've put their heads together and they've come up with this brilliant idea and they sold it to senior management who've decided to fund it for a concept. So, we got five or six people who are going to get together and they're going to really put some work behind this thing for a few weeks.
And in like two months’ time, we're going to have just rough demo, just proof of concepts that's what we're going to do. Okay. Great. Eight weeks go by, yeah, we need a little bit more time. We underestimated how long it would say, but now it's looking great in another three or four hours. And by the way, one of the reasons it's delayed is we didn't get the people we needed. We didn't get those artists that we really wanted. Well, they're busy working on something else we couldn't get them. And the person we had, they didn't really know what they were doing. It's kind of slowed us down. Anyway, give us a few more weeks -- a few more weeks go by. Yeah, we're ready now. Here you go.
Now it's not quite what we said it was going to be at the beginning. Because we realized halfway through, there was a much better idea. All right. What's much better idea? Here it is. Okay. So can you sell a much better idea? Have you got any data to prove it's a much better idea in terms of gamers the end audience? Well, it doesn't matter about the end audience because it's a great idea and there's people on YouTube and they're going on about so much to make this game. And also there's another game out and it's quite similar and it's really popular. Oh, okay. Right. So do you know what kind of team you'll need? Oh, yeah, of course. Because our producers put together a plan of attack of what it looks like to get into pre-production and beyond. So we already know this is going to be a, it's not like a triple layer. It's going to be pretty big, but it's going to be great. Right? How many people do you need? Well, we probably need this many and that many and this many. Okay.
So great, we can't put the whole studio on this then, so we're going to have to split the studio, so some of them working on this game and some of them working on another game. Yeah. But they're coming for you from working on something else soon this whole bunch of people. So we can use some of them. I know they're already assigned. I'll shut up. I'm sure you wish I had already, because what I'm describing is very normal. It's extremely normal for especially big studios who are working on multiple games. And they tend to share people. People come free from something and move on to something else. People want to work with their mates. The only person who's got this particular expertise is being pulled between different jobs. And that's just people. And then there's needing to get the hardware in, needing to get the licenses, getting the budget approved in the first place. And so on and so forth. And I'm not going to go on and on and on and on any more about that. I'm just saying what I'm talking about here, this conversation I'm having with you as if I'm talking about somebody who's been asked, what this game's like. I'm talking about risks and issues. And as a producer, you should be writing those things down and assigning the ownership of those things. The people who are talking about them or to whoever, but ultimately you're accountable for chasing them. And it depends upon the level of production seniority, but even as an associate producer, who's just joined, has got one team under them.
There's a whole bundle of risks and issues because you can't just look at your own team. You have to look above and you have to look around and you have to look at things like dependencies. A dependency is where you are dependent upon someone else, or they are dependent upon you to get something done. And if you use something like JIRA, where you're moving things along on your good old Kanban board, and they're going across. This usually column called blocked, and it's become quite normal when I've worked around different studios now that blocked appears. And if you talk about it, it's people who've said, oh well, I can't work on that right now because Mr. Joe blogs over there hasn't finished his work until he's finished what he's doing, I can't work on this anymore. So it's blocked. Or it'll be something like the art department had been working on the further art development on particular game level, and the designers will come along and say, oh, we've made some major changes to that level on Friday. And we forgot to tell you so you're going to have to redo the art. So all that work you've been doing for the last three or four days actually not just for the last three or four days, but sorry, last two weeks, going to have to dump that and start again. Because we fundamentally changed this level. Right.
That's not the same as a long-term large-scale risk and issue. That's on the ground production support needed that's on the ground leadership needed. That's still an issue, right? It's an issue because it's happening. And you need to deal with it. And you need to log it. Why do you need to log it? And what do I mean by logging? I mean, get your Excel spreadsheet open, write down that this happened, write down what it was, fill those rows in. And then at the end of that, fill in what you did about it, because then you can learn and others can learn and you've got an accountability trail should you need one, if you really work in that kind of place, but really it fits into what everyone should be doing, which is continuous improvement. It's about continually developing yourself and your teams. So you want to be able to go, let's have a mini post-mortem or let's -- that's a bit of a [tossy] term for this, but you know what I mean? Let's look back at what happened there. Right, so how can we do that better? How can we fix that? Let's talk to the people in the teams. Let's talk to my colleagues, my mentors, let's talk to the people around me. How have they done this in the past? A lot of people work in lots of different companies and then come and work with you.
What were their experience in others? What did they do? How did they avoid the problem where art and design are head to head banging heads, time gets wasted, work gets wasted people get upset. But how has that been dealt with somewhere else? Let's learn because look, an issue just happened and we've tried to resolve it. Well, we've wasted a lot of time. And for me as a producer to show that I'm taking that seriously, I want to lock that issue. And then I want to try and learn from it. I want to arrange a little chat. I want to go and have a little chat with a few people or they're having a cigarette around the back and go, this thing happened, you guys, you're really experienced. How have you dealt with this before? What should we know about this? How should we do this differently? Be humble, right. I am. I go around saying, I don't know what to do here. Can I have some help? Right? And I've been like an exec producer, a deaf director, whatever. It doesn't mean, anything. It just means that you've been around. And it means that you've got a whole wealth of experience in your head where you try and help others. But the real trick is to be this humble servant leader. Who's not so much trying to order people around and tell them what to do, but it's taking the issues that have happened and saying, right, well, let's all learn from this. What can we do? Go on the internet and have a look, come to game-production.com and have a look. Just ask questions, talk to people, just learn.
Now back to the point, risks and issues, issue logging, and trying to do something about issues. They're in your face. They're short term firefighting. The bigger longer term tend to be the risks in which you go. For example, the PS5 is coming out soon and we need to get our game on the PS5. Okay. Do we have the deaf kids? Have we sorted out the licenses? Have we talked to SonyExDev there for example, or whoever ask. Have we got the budget? Have we got the right people who will actually be able to spend some time, not just doing work on our game, but spend some time disappearing off to learn about PS5 to get these deaf kids in, to try and learn about what they can do to try and talk to the right people in the right places to determine what the differences are between the PS4 and the PS5. To look at how the technology is going to change. To look at, if we can still use those plugins from Unity over there, or are they going to be outdated? Maybe we want to do something really clever with a silk scarf. Is it going to work on PS5? Are we going to showcase something really special? Are we going to be able to pull it off or do we need a little team assigned to that? Pulling back to risks, that's a risk that conversation I've just described to you, which by the way, is pretty real. That sort of conversation that's a risk because you can then go, right. Okay. I tell you what I do. I'm going to raise this as a risk with the leadership team. I'm going to note this down. I'm going to say, we need these people to do this thing here. And the impact of that on the rest of the game [inaudible 19:55] will be, they will not be available to work on those things there. So those things we needed them to do, we're going to need some other help or we're going to delay, or you need to rethink it's a risk because it hasn't happened, but it's going to be an issue.
Should we not do anything about this? If we just carry on regardless and ignore it, we'll crash into it. A risk says, pull it back, raise it up, make a note of it. And then you have to do something to communicate it. You can't just have -- you can't just hide these things. And if you note them down again, you can't just keep that on your hard drive. You can't just shove it in on Excel somewhere and forget about it. It has to become part of a routine where you are communicating these risks where you are going through these risks and issues. Now, one way that I have made this work is to raise it to the level of the leadership team and say, every leadership team meeting, you will go through your risks and issues or major ones, the top ones. And you will talk through each of the people we'll talk through the ones they own and they'll say, okay, I've actually done some things about this. I've chased this one. This is still in my head. I'm still thinking about this. I know it. We know it. We are aware, it's transparent and transparency is so important. Never be afraid of saying there were problems. Because people want to help specially in the games industry, you've got a whole bunch of people, especially the engineers, the coders who are just built to solve problems. Let them help you solve problems. Don't be proud to be humble. Be modest.
I never walk into a place and say why I've got all the answers. That's my job is to have all the answers you're in safe hands now. My job is not to do that. My job is to go in as a producer and say, okay, I've got experience and I've got knowledge and I've got learning and I've got training. And if I combine all those things, I can give you a foundation of security and safety in which you can operate and within which you can operate. And when you operate within the boundaries of my support, you could feel that you're going to be doing the right work at the right time in the right order. And it's not all going to go down the toilet. It will sometimes, but we will minimize that. We will minimize the risks. We will mitigate the issues. We will reduce the dependencies on each other. And the only way to do that is transparency is to talk to each other. But there's no point having, as they call corridor conversations, there's no point having corridor conversations. Or chatting to somebody about a problem and then just walking off. You've got to write it down and you've got to store it somewhere where everybody can see it. Now, of course, there are some sensitive issues and there were some things that you probably just want to store so only the leadership team, especially if it's about people. You got be careful, right, fine store it somewhere sensitive where only the leadership team can see it. But there are some things that should be splashed all over the walls that should come up every time you have your stand ups, if that's what you're doing or your Kanban's dailies or whatever.
And this can happen remotely as well, is that you should be able to go there as a producer and say, all right. So we're trying to find the fun factor. We're two weeks late. It doesn't look like this particular feature is going to be much fun. We need to do something about this. This is an issue because every day that goes by, we're heading to a brick wall where other teams are dependent upon us. And until you guys saw this out, everyone's waiting and we're going to be late in other areas. And you should be working on something else anyway. Now you can't just sit there and say those sorts of things, and then just leave it. You need to follow through and you need to log it. And logging it, writing these things down, writing down what you're doing, writing down your actions, writing down what you are going to do to solve a risk or an issue and close them down. That's gold, man. That's gold. Because when you do that, people will respect you. They will know you're in charge of the destiny of the team. You're not trying to dictate. You're listening. You're transparent. You're communicating, you're going off and talking to others. You're bringing back that experience and you're giving it freely. The leadership team are backing you up, every week they're going through the major risks and issues. You can bring it to them. Even a junior producer, easily talk to your producer, talk to your [inaudible 24:54] whatever you've got. Talk to your product manager, whatever you've got, raise these issues. Just say, I need you to talk some more about this one. No, one's doing anything about it, but until you write it down until you communicate it clearly until you have it in a place where it needs to be, no one can really trust you because they're just thinking, well, we talk a lot just a general introduction to risks in the games industry.
And we haven't even gone into any specifics, but I wanted to give you that overview, that flow of getting it into your head, that philosophy of thinking to yourself, I need to earn people's trust. They need to be able to expect from me that I will listen to them properly. And I will love what they're saying, and I will chase it up. And I will push for my team and my teams. I will push for them. I will fight for them. Once you can show that. And once you can show a couple of quick wins and successes, you will have people on your side helping you. And the rest and issues that you're logging and that you're raising and that you're pushing. They will receive a momentum that you won't have experienced before, because that's what happens when people trust you and have faith in you. That's the position you need to get to. And now in the next one of these, we will go into more detail about some of the common risks and issues that you're going to face. But for now, have a little think, leave some comments. I hope that wasn't too rambling, but it's the philosophy I want to get across to you. It's that mindset of, you know what, it's not a tossy boring, stupid thing to do to write down risks and issues. We'll touch dependencies in a different place because dependencies are a whole new kettle of fish. And they will become a bane of your life if you don't deal with them properly. Thank you very much.