Part 2 goes into more detail on actual risk and issue examples.
I have based the categories on the only current academic research I could find on the topic. You can read that in full here: https://www.researchgate.net/publicat...
Topics covered in Part 2 include:
02:39 High level risks
06:19 Staffing risks
12:32 Schedule & Budget Risks
19:20 Inadequate specs (I decided to skip talking about Design specs here as that deserves its own section some other time)
24:37 Fun Factor
33:46 Change management
38:20 Expectations of third parties such as publishers
40:40 Summary
Part 1, a more general introduction around risk management in the game industry, can be found here: https://youtu.be/Mh_WsEYr8WY
Part 3 is a walkthrough of generating a Risk and Issue Log that you can download and use/abuse at your leisure.
Here is the complete transcript.
Risk & Management Issues Examples for Games Pro
Main Speaker: We covered in part one of risk management, a whole lot of waffling from me about your general approach and philosophy. In this one, I want to talk a little bit more about some examples of risks and issues. And then I hope that we can kind of branch off as I tend to and talk about the whole bunch of things around that.
What I'm hoping is that at the end of this section, we can then go onto some screen work, right? I show you some actual work being done in which, I put together and some risks and some issues and you can see me working through it and thinking through it and I'll talk through what my thinking is and I'll simulate, I was going to say stimulate. I'll simulate some conversations which I've had to say, Oh, well I talked to this person, that person, they said this, they said that and that's what we're going to do about it. Just to show you the thought process and to reinforce the whole process around risks and issues and how best to handle them. You'll forgive me. I look at my notes a few times. Before we do that, you should note. I'm coming at you as someone who's been working outside of the games industry for quite a while on who's got coffee, cheers. Project management, risk management, et cetera. Which is part of our project management? This isn't something that in the other industries that use risk management that people have got, right? This is hard. There's a reason that you've got a job. You're not employed because you're good at smiling at people and having a laugh. You're employed because this is difficult and people deserve your help. They deserve being respected by you enough that you want to fix their problems and I hope that's, an adequate boost to your motivation to actually study risk management a little bit closer and think about it a little bit more. Let’s look at high-level risks.
A high-level risk is one that probably has come down to you from on high. Your bosses may have said to you something like, well as part of our development strategy for this game. We need you to come in a year faster or you really need to be ready for E3 which will require you to throw aside everything you're working on and commit the entire team to make a trailer of a game that probably doesn't exist in reality. Or maybe his gameplay footage, in which case you need to have the gameplay ready for that footage to be recorded. For example, or it might be something far more fundamental such as the end of an 18-month period, you will lose half of your team.
So, say half of the design team. You need to be able to finish the work they're doing in time and you need to be able to move them off in time. Why is that? It's because we have another project, we have another game or whatever it is. It might be something more fundamental, such as if we don't get this game out on time, we're going to go bust or whatever. Or for us to get bonuses from the publisher. These milestone deadlines are immovable and that's that and you can argue they're impossible. Okay. You still need to make it happen. Now that kind of a high risk still needs to be recorded. You still need to say this is a risk. We can bring it up at leadership team meetings and we can discuss what we're going to do about it.
At the very least, just by recording it and having it there and making it visible, no one can say that it was a surprise and you'll find that sometimes in leadership meetings that you're not going to go over the same thing every week. You're going to pick on specific things where you're making some progress, but you still need to be aware of them. You still need to think about it and talk about it. So, these high-level risks, they are your strategic risks. They're the ones which you can chuck in an Excel spreadsheet and work through, but they tend to be more long-term, something coming along in a year, three months, three years. Depends on the game. It depends on what you're making. If you're making a mobile game, it could be that there's a big change coming to say the way that a particular games platform is going to market your game or a way of a big change to user acquisition that you need to know about it.
It depends. If it's a small ND you, you may be, I mean you might find it difficult to have strategic risks if you're only a tiny ND, but still, you're going to have them and they're probably going to be really real. Like we will run out of money or the publisher will want this milestone really good vertical slice and if we don't deliver it, they'll shut us down. So, I think it's interesting that the bigger the studios at the huge, or they are the less urgent, some of these bigger risks look because you're part of something huge. But that's not really true because they're still going to happen. Just like everyone's going to die one day, they're still going to happen and you don't want your little baby game to die. you need to take them seriously.
Staffing. So staffing is always an issue because people come and go and that's actually fine. It's fine that people move around the games industry or leave it and come back like I did. It's fine. They gain experience. Some people don't fit. Some people do. Some people just want to change, but let's say you’re head of design leaves, you're screwed. What are you going to do? You need to find a replacement. People will say we'll promote the person who was under them and you'll say, well, I'm not sure they're ready. Well, people aren't always ready. You need to chuck them in there before they're ready so they can prove themselves. True. Yes, okay, we can try that problem solved, but if we move them up, who's going to be the deputy then? Well, maybe we don't need one and so on and so forth. You need to have those conversations to be sure but really you need to be thinking, let's look at the structure.
Let's look at the team structure, the team dynamic. Let's talk to the head of the design. What do they think should happen? How are we going to keep going with the minimum disruption? How long have I got until they leave? What are we going to do with this information? How are we going to communicate it? What are we going to say to the team members? Maybe it's a secret for a while. Maybe it isn't. How do we handle this? But really while you are kind-hearted enough to think about that and while you are also thinking about the morale of your team and how you're going to finish the things that only your head of design with knew anything about, et cetera, why you're thinking about that sort of thing, you should be thinking about why in three months’ time, how's that? How does it going to look? How will this fundamentally change anything else? Who else do I need to talk to? Do I need to talk to the head of art? Do I need to talk to QA? Do I need to go and find out what state things are in which they've told me they had designed, told me the States, but I'm not quite sure? I'm really convinced you need to go and investigate. You need to go make yourself comfortable that you can answer questions that will come from others. Because when an important person in the team leaves, it leaves a gap of knowledge and it leaves for the good ones. It will leave a whole bunch of momentum, motivation, support that they've been offering to others, especially with senior people. You need to be mindful of all of that. And people will be scared when important people leave. It's a risk. Now, if they're definitely leaving, it becomes an issue. They're leaving. May make it an issue, not a risk. If you've heard that somebody might leave, put it in as a risk. See if you can save them. If you want to save them from leaving, sometimes you don't. Right? They don't fit. It's good for them to make a move somewhere else. But staffing is a big issue. Now that's just an individual. I've had situations where we've been working on games and I've suddenly been told here 10 artists that you need to find jobs for a because we need to pay them. Give them some work to do. Okay.
What kind of artists are they? Oh, I don't know. Go and find out. Right. Okay. What we really need our environment artists are, yeah, I think the concept, right? Okay. That's another risk, right? Or an issue in this case that large groups of people can appear or disappear and staffing you need to think about very carefully. Staffing's a really difficult issue because as a risk or an issue. You need to justify that you need the people and sometimes you don't and you need to justify that you need specified skill sets in a person at a specific level of expertise or experience or both. You may need a very specific AI programmer. You might need somebody who says incredible at. I don’t know unreal. You might need a technical artist. Tech artists have specific skillsets. What kind do you need? You might need a concept artist at the beginning, short term and then you might need to get rid of them, right? Where it is obvious and known and simply part of making a game. And it's part of the game delivery life cycle. You have to raise it as a risk or an issue. It's where it comes out of the boundaries. It's where it becomes something that's stepped over and you go, oh hang on, that doesn't feel right. Something's, going to happen here. Well, I need to fix that. That's when you need to raise risks and issues. So, with staffing, typical examples, I've given you some. People catching wind that somebody's really unhappy and is going to leave and they, one of your key personnel. You could raise it as a risk, an issue. You might just want to go and have a chat with them first and find out what's really going on. But at some point people will walk up to you and say, Oh, please don't tell anybody about this. It's secret. I'm going to leave next week and they happen to be an incredibly important person on your team. You're going to tell someone else. You're not going to keep it as a secret.
Obviously, there were times when it really is obvious that you could not possibly tell anyone else. But if it's just armed, be unhappy and I'm definitely going to leave ever got another job, you have a responsibility to tell some people in confidence because otherwise, they can't do anything about it. You have to, you are accountable. You have to, as a producer, you cannot just keep something a secret because someone's asked you to sometimes, make a judgment call. Because in six months’ time if things have gone up, shit Creek because that person's left and you know very well. But if you'd said something, you could have at least a swayed some of that pain schedule, budget management. It depends upon the level that you're at but let's go over budget management first. What's a budget now? Believe it or not, a budget. It's just an estimate, a budget. It's just a finger in the air, stab in the dark. We reckon we probably need this many people and we think we need them to be these people. And you'll find that a budget normally for people will have names of people. It might just have skillset types, categories of people. It depends but the budget against those people will take into account their location, whether they're a contractor or permanent or freelance or whatever you have in your country, where you're working, it will have how much they are and add it all up and that will be your budget for people.
But your budget will also have, depending upon your level of seniority, you might be exposed to things like CAPEX, OPEX, operating costs and capital expenditure, and all this sort of stuff. You might have to take into account hardware costs and licenses. And if a member of staff walks up to you and says, I need this license for this cool thing and we can do some amazing stuff, and you go, Oh, go and get it, then. Oh, the way, how much is it? It's 10,000 a month. Yay! Well, that could be the cost of a person. And often you'll find that you're in this zero-sum world as they say, in which you're trading off things and you could be trading off people and there's no real winner. The more that you want to give, the more you have to give back somewhere else and that's life but it's a risk if you have a budget which has one would hope, an upper ceiling of how much you're able to spend and that money if you're accountable for it or even a portion of it if it looks like you're going to go over or under, you need to raise that. Back to risk and Issues specifically about the schedule and budget management. The most common one is not unfortunately that you'll be given too much money. It tends to be that the most common one is that you're suddenly told you don’t have that money anymore and that you need to get rid of some people. And then you raise that as a risk and you talk to the senior staff and you make your decisions, but that's an example and cutting corners and cutting money as life. That's what happens. Schedule.
So, schedule and risks, I mean they go together, right? That they're pretty much hand in hand with each other. A schedule. What is the schedule? It's supposed to be a list of work to do in a certain order. And if you were to extrapolate outwards, you'd find yourself with a roadmap and your roadmap would be a work of fiction as you stare into the crystal ball of the future and say, what do we think a roadmap might look like? What do we think we're achieving in terms of our vision being broken down into our features and our, you know, the different pillars of the game. What are we going to look at here? And in six months’ time will we have achieved a minimum viable product, a proof of concept in six months’ time we'll be in production where we have shipped if we're going to ship, what will we look like? Now a roadmap, whether people like it or not is a work of fiction because it presumes that estimates that have been made about work are correct and that you know everything, that you have 100% presence and knowledge about the future, which you do not.
So, a roadmap should always be sold as a fluid piece of fiction in which you're aiming at these things. Whereas your schedule is your schedule of work. It's what are the people in my team doing? What is my team doing? Are we making this game in a certain way? Great. How's that going? What's the list of work? Has that been broken down properly? Have people thought about that if somebody else over there is doing that work, it might hold up the people over there is the dependency? But the schedule and where it comes into risks is, well it's based upon what you're trying to make and you might not know what you're trying to make. This is game development. After all, there's a fun factor. There's a great potential that you might go down the wrong rabbit hole. You might spend too long on a proof of concept for a feature, which is terrible because you just can't get it to work. You might have to throw away an entire game level, which you thought was going to be the best level ever because you can't make it work. Why can't you make it work? I don't care. The fact is some really, really good people have been trying. You have to say the schedules food bar, we cannot now produce that feature or that level of whatever it is we're delayed elsewhere. We're going to have to rethink, it's going to push us back. We're going to have to suddenly think what all these people are going to be doing with their time when they were expecting to be, say arcing, a level that doesn't exist.
So, it's an issue. It's happening. You don't have to raise a risk to say it might happen. Unless it becomes really likely if there's a big piece of work going on, and I've definitely raised this as a risk before where there's a proof of concept for a specific feature or a specific really major piece of a level that you, sorry a major level that you, you're kind of resting your hopes on. Maybe it's a particular type that you really need in the game to fulfill certain criteria. You raise that as a risk. You say this has to work and if it doesn't work, we need a plan “B”. And you should start talking about a plan “B”. So, schedule risks, budget risks they are part of life, they are high level, but they're part of life and you need to get used to the fact that they require a great deal of your time and effort and stress levels. I've got no hair, that's pretty much because of budget and schedule. So, the next one, inadequate specification. If you're working on a game, you realize that it's funny too to think that you're going to get the adequate specification of what games going to be. And it's different in some cases, right? With smaller mobile games and with smaller Indies where you know exactly what, say you're cloning or you know exactly what you need to produce. It's very much, a time box piece of work where you can just say, right, this is what we're doing. Let's get out there. That's fine. You can probably get an adequate specification for that. In terms of scope and in terms of the specific type of game, the specific work that the specific checkboxes you need to take, you know, but normally for a larger game with more people, you're going on an adventure, you're exploring and when you're exploring you're not going to get the adequate specification for everything.
What you are going to get though with good teams is you're going to get things like the head of engineering or the code leader, whatever you call them, the principal programmer, well whoever. That person there is probably going to give you a whole bunch of advice on what you can expect. Your say tech spec limits are. So, they’re going to say, well, we're looking at launching on this console here and on PC and we're looking therefore this stuff you want to do over here. That's really amazing. Yes, you can do that that stuff over there. Forget it. You're never going to be able to pull that off if you want to get you if you're going to want to hit 60 frames per second, just no chance. So, you can start building up that picture if you can inform people on where you're going to put a game in the first place. You know, there's a big difference between certain platforms is a big difference between what people can or can't use and they should know that from the start otherwise, you got no game. But in some cases, tech specs, particularly with light, the next-gen consoles that are appearing a lot of that's going to be trial and error, and you're going to hypothesize.
Also, technical specifications, when you are trying to estimate how much load on a, say a computer on a gaming PC, your game's going to be in the end. You're guessing you're. I mean, you can base it up on a lot of experience and there are definitely ways of measuring load, et cetera. But when you keep piling in artwork and piling in all this great stuff you want to do and piling in more and more well, you know, piling in that could end up being a big issue, because you could end up going, Oh, well, we shoved so much into this level. If it's a level that you're designing a, it doesn't really run anymore. It runs such a crappy frame rate that we've realized there's an entire bunch of features that we're just not going to be able to support. There's an issue right there and when you see it coming, there's a risk. It’s worth actually raising forms of specifications as risks early on. Because then it encourages you to keep thinking about them and discussing them to get people in a room and talk through or when do we think we're going to know more. Really in concept, you might find that there's not much you can do. You kind of, you're not interested. By the time you're trying to exit pre-production if that's what you happen to have, those are the phases that you're going through. You really should have a much clearer idea because you don't want people hacking out huge amounts of content for your game and then telling them oh, sorry you think you could reduce the polygon count. So, there’s that kind of specification. There are loads of other kinds of specifications though.
There are things I just mentioned art, but there are things like the star guides and the templates and you know, the guidance you're going to get. If you're a new artist starting somewhere and you'll be, you're told, right, Hey, here you go. Here's what you need to know about the art here. And some of that stuff is going to change some of that stuff. You're just going to have to be talking about it and you're going to have to be aware that as you get on with the game and as people get more and more ambitious, and as people work harder and harder, the day could come that the tech artist walks up to you and says that plugin, that we've been using over there as disappearing next month, it’s not being supported anymore, we can't use it, or oh, you know that bloke who was using that thing over there. You know that well and how it's fundamental to part of the game, we just realized we don't have a commercial license for it and it's, it's going to be a million. Can we afford it? Stuff like that it's going to happen. Right? The best thing is you can raise it as an issue. You can log it. You can look at the impact, right? Write it down, be communicative, be transparent. The dreaded fun factor. It’s the bane of my life. The fun factor. Have you found the fun yet? Yes, but is it fun? You but guys, we're looking at this demo of this level and none of us really think it’s fun do we?
So, what are you going to do to make it fun? It's the whole walking up to the art director and saying you could do a thing a bit bluer, couldn't it? You need to be careful with the fun factor. I say it's the bane of my life. I'm semi-serious. Why is it the bane of a producer's life? It's because it illustrates that making a game is a journey into chaos and no project methodology handles chaos because chaos is a transitory state where you try and pull the order from it and you can't do that with project management. Project management says, we need to make this thing and to make it we'll do this.
Now, some people will be throwing plates at me because they'll say, agile project management. There's no such thing like agile project management, there are no projects in agile, agile doesn't deal with finite projects, agile deals with products, agile deals with quite different things. The term agile project management is a misnomer. So anyway, that's important because when you look at the fund factor, what you're really looking at is an admission that we are allowing a whole bunch of adults to play around for a long time in order to discover something brilliant by working together. And that brilliance takes the forms of these amazing games that go out and it's a miracle and it's wonderful. It's like an incredible painting. That's painted by a dozen artists or 200 artists, it's incredible that it can ever work. But it works, but it's not very ordered. Now we need to, as producers support that chaos, but also have boxes around the chaos. It can't go on forever. People can't be allowed to just play in their toy box forever. The sandbox will event actually be closed along with the studio if you don't get something out. Agile, lean those kinds of methodologies in the form of lean startup in the form of agile scrum for example. These describe ways of handling very chaotic projects.
So, say chaotic software development or should I say complex. So agile scrum is for complex work. Lean software development is for more ordered software development but still can handle things being ticked up. These days when you work as a producer, I pretty much guarantee you're a scrum master, right? You've probably got qualifications as a scrum master. You probably don't as a product owner and you probably were given a basic foundation course in agile but your team probably wasn't but are now expected to be agile. Why? It's because, well. Why they expected to be agile? It's because agile product development works on iterative and incremental cycles. Iterative in that, it says we will very quickly see if something works and we will put it in front of the customer. Let's say you're using scrum. Let's say your scrum team every two weeks, put something in front of the customer. You will always try and have a working product every two weeks that say, and by doing that, you can't go too badly off the line because you're your customer. Who’s probably the person paying you, can say, well that's not what I wanted. You've made a bike. I wanted a scooter. What the hell? But you can get to these problems quickly, right? There's a cycle. There's an increment. Let's say it's for two weeks, let's say its three weeks. Those are a whole mass of workaround agile methodology and philosophy that says, by doing things this way, you're actually just embracing a very old-fashioned concept. It's not that new, to be honest, it's the old-fashioned concept of learning, right? If you are a self-learner and you've ever done courses in cognitive learning, you'll know that this cycle of looking at something, thinking about it, adapting, changing it a little bit, trying again, that cycle of learning, which says, let's try it out.
Let's see if it's the right idea or not. That's basically what agile took and works around. It goes, there is a cycle and lean does the same. There's a cycle of product development that says let's keep it short so that we don't go way over there for years and then bring out something which is crap because that's stupid. That's a waterfall. That's the idea that you plan everything in advance and then because you know exactly what you're doing and then you bring it out in the future and it's great. It's a catastrophic failure, but you still see it in-game development. Because what you get is the teams are told, be agile, be scrum, reiterative, be incremental, discover fun, fast, fail fast, blah, blah. But at the top level, the big wigs are all still saying, oh yeah but where’ our designed documents. I want you to plan everything out to the not degree. If you don't plan everything out, then the coders won't know what's to code and the artists won't know what an art. So, hey designers, why is that a design document? Where what is haven't you written it all up? Now, I'm not saying you shouldn't, I'm saying you need to be mindful of the agile philosophy that says, working software over documentation. We favor working software over documentation. It doesn't say don't do any. It says, keep it balanced so that you can actually show something, rather than show documents.
Now I've been in places where documentation has ground, all kinds of leadership and development to a halt. Agile is one way to avoid, over documenting. Why is that a problem? Because if you document everything at the beginning and you're making a game in which you're trying to discover things and find the fun you haven't embraced the chaos, you've tried to put order in the chaos too quickly. It's important to put some order in, and it's important to have a concept and it's important to have design art people, et cetera. Working together with their coders, working together with QA, working together with everybody else in audio and going right, this is the general idea of what we're doing, but we're still discovering an agile and lean they support discovering. You can have a discovery phase. You can actually discover things and you're not scared of change; you embrace it. You say it's fine. We have this concept. You know where we're at now, we’re at here. And it was still within technical limitations. It was still within a bunch of specifications. This is still a risk and issue because you can highlight these things.
You can say it's all very well finding the fun but our risk is if we don't get this particular thing here to the state of fun, I'm being slightly facetious when I say it like that, but you know what I mean? Then we're going to fail in other areas. And this really is very sensible because you are going to have milestones. You're going to have deadlines and you need to be able to draw the short focused view. That is many agile teams. And you need to be able to say, there's a bigger world. And in the bigger world, we need a vertical slice ready next month. How you doing? Are you not ready? You're still trying to find the fun or we're screwed, aren't we? That's a risk? That's an issue. Whatever. Now, by raising a risk and saying, we have three months to deliver this thing, it forces you and the people around you at a leadership level to keep that in mind to keep thinking about it, to keep pressing and pushing and motivating and driving and directing so people in charge need to direct. They need to say try this or that it didn't work. Shelve it, try something else. It helps you to do that. Change management in the games industry I've never, ever worked anywhere, which has had changed management. I have worked outside of the games industry, where there have been huge amounts of governance in places like the pharmaceutical industry and the local governments and the foreign offices in the UK, which have had changed management.
What is change management? It's a part of project management. Change management says you can't just change things. You need to go through a process. We need to monitor the change. We need to assess the change. We need to evaluate the change. We need a chance to have a think about this change that you wanted to make, because this change could fundamentally alter a whole bunch of things. It could have a spill on effect. There are change managers out there. Change management, not just about change to something you're working on but it could be that what you're delivering changes the way people think, work, it could make their job invalid. You know, outside of the games industry, it could be that you're working on improving processes. And as a result, 10 people over there will lose their jobs because they won't need them anymore because we're automating things and you need change management in place to say, well what's our change plan? How are we going to communicate that? People just change things and they don't tell each other. So really for you, it's just about communication again and transparency it comes back to that again. We're going to change a level. We're going to change this bit of the game. We're going to change how high this thing here can jump with these controls. How are you? Well, did you know if you change that we have to remake the whole game? Its things like that, right?
It's where something changes and you need to do something about it to communicate across or something's about to change and you need to go, Oh God, or it's changed and you need to roll it back. You will find QA is your massive ally here because they'll spot those changes first. And the number of times that someone quite innocently changes a thing and doesn't understand the impact is extraordinary. For example, your lighting person. She sat there eight o'clock at night, she's waiting to light a scene and she goes, Oh, thank God I can finally light the scene is everything's been checked in. She comes in the next day. And the first thing that happened was somebody logged in, checked in a new change, 8, 9 in the morning. She comes in at 10 o'clock. She has to do the lighting again. Is that change management? Kind of. It's managing the change. It's about communication. It's about respect. It's about teaching people. What they kind of can't do. It's about educating them on what happens when they make changes like that. It's not official change management. If you did a project management course and learned about change management, it might help a little bit. But it’s more about being flexible, respectful, and communicating when things change.
We use things like whiteboards, where we would write up something that had changed so that people could see it. If we were co-located or we would communicate it via producers going to their daily stand-ups and noting that stuff had happened or they would over here and then it would be reported around, then we decide what to do about it. But again, we're in chaos. We are in a chaos that we've invited upon ourselves and we need to be mindful of that. Things will change and people will annoy each other but they're not doing it deliberately. They're doing it because making a game's really hard and it's your job to smooth those edges over and to just calmly decide, okay, well what should we do? Yes, you're right. We've made our main character jump much higher and we need to remake the whole game from scratch and we've got a month to go, probably need to roll that back. Don't you think? You don't need to put in change management not at this point, right? It could be at the very end when you're charging through QA, you're trying to fix things you whole blah-blah-blah. Or when you're locking down because you've got a milestone, it could be that you want some form of change management then, and it could be as simple as that, it could be perforce locked down.
Tell us if you want to put anything, any changes in that's fine, right? That's a different thing, but you don't need to raise that as a risk or an issue. Expectations.
If you're working with partners, publishers, let's say other companies, you need to raise risks and issues around them and what they bring to you and they will expect you to have risks and issues raised in order that they can have faith in you and trust that, for example. A publisher paying you money is putting that money in the right place. If you've got a big publisher paying you a whole bunch of cash and they're expecting monthly milestones or they're expecting a vertical slice by certain point, or they're expecting games who published on a certain date or for you to be ready with the marketing team and you're not going to be, they sure as hell want to know in advance. You keep risks and issues, and you document them. You can show them, Hey, last month we went through this risk here. And you remember, I told you these things, here's the action we've taken. Here's what we've done. It's gone. We're back on track. Or it's now become an issue. We were not able to resolve this. We're talking to you now because here's the impact. Here's what that means. This is why you need risks and issues logged and this is why you need to be transparent.
Publishers, partners, insource, outsource. They have expectations. They need to know that you're going to be ready to give them work. They need to know that that work's not going to suddenly change because you weren't ready really. You just thought you'd throw something at them and it’s all wasted actually just to get them something to do. Yes. You need to avoid those sort of things. You need to plan ahead? If you're not ready, you need to tell them it's not a perfect world. Is it? They might only be available for a certain specified amount of time. If they say an outsourcer and they're going to make you some great videos for some trailers and you're not ready on time, but they're not available. What are you going to do? Well for start, you're going to raise it as a possible risk once you see it coming because then it's not a surprise and it's a very lean methodology to wait until you've got enough information to gather as much information as you can before you need you need to make that decision, get yourself as much information as you can.
So, we've covered some sort of basics here. Next time I want to actually run through a radar with you and talk through in more detail and I will carry on rambling as I do, but I hope this is at least interesting and useful. Thank you.
[Outro]
Comments