APM ChPP - Competence 6. Risk and Issue Management

[Music] Hello, welcome back to another parallel project training podcast. I'm still here with John and Carmen. Hello. Hello. Hi. Right, we're on to competence 6. So competence 6 is the first competence where you don't have a choice. You have to do this one. Have to do it. Yeah. Yeah. I mean, yeah. The others are managed. You have to do pairs, one of the pair, but you have no choice with risk and issue management. So you've got no choice but to listen to this podcast? Yes. Well, that's very good. Yeah, there are options. Okay, risk and issue management. Let's start with the elephant in the room, risks and issues. Difference. Risk is something that might happen an issue is something that has risks, demand, proactive activity, issues, demand, reactive activity. So the interesting thing about these competence is that you see that there is a criteria with seven, seven different criteria. Some of them relate to risk more closely. Some of them relate to issues more closely. So the choice here is particularly important, especially considering the work constraints. Because if we start in order, if we start with the first one, continually identify risks within a project. So this is just about risks. It's about how did you identify a list of things that potentially may impact your project? Did you do brainstorming? Did your organization had prompt lists? So this one, if you read it, is just concerning risks. So there's a couple of ways of breaking these up really. You can decide to focus on risks and there's four that relate to risks and there's four that relate to issues. So you could choose to just focus on risks. Or issues. I mean, one point six has implemented responses to risks and issues. So one point six is the one that relates to both. But I think the point is that people get stuck because they don't know the difference fundamentally between the two. So they'll talk about, we've never worked with that client before, as being a risk. It's not its fact. It's an issue. There's no doubt there's no uncertainty. It's true. The question is, what are you going to do about it? So the fact that you've got an issue causes a risk in that situation. So here, one of the scuba errors in these for people that are writing these, they write down risks as if they were issues. And that happens in the project overviews as well. Or vice versa, they write an issue which is actually a risk or a risk is actually an issue. And there are some assessors who will particularly pick up on that. And you can argue that that's a bit pedantic and silly and awkward and unnecessary, but it happens. Beyond that, when you get into the technical knowledge areas, if you don't know the difference, that can easily catch you out. So it's not a bad idea to just be aware of all of that and not box yourself into a corner. And as Carmen says, identify risks, PP1.1. Most people are about to do that. PP1.2 created a risk register with the potential impact and suitable responses. I mean, that's bread and butter for most project managers. Assess the probability that it's an impact of risks and plan those responses. Again, most people don't do that. So 1.1, 1.2, 1.3, relatively straightforward. And all of a sudden you bump into issues and you go, oh no, now what's going to happen? But you could pick up on 1.6. You see, implementing responses to risks and deal with that. And then also adding a bit about issues, how you responded to issues. Generally, and then add a bit about lessons learned. That'll be to fork criteria 250 words. So you don't, by no means need to, what I observe when we're looking at people that write these, they start at the top and work their way down. And there's absolutely no need to necessarily do that. You can do the first one in the last three. You can do them in different orders if it makes more sense to you. You don't have to follow this specific structure. The only rule is make sure you know which one you are doing when you're doing it. But when you get into issues, so number 1.4, capture and recorded issues, I should say captured actually, captured and recorded issues, how they were resolved and their implications to inform planning for future projects. So this is about lessons learned. It's a wholly focused on knowledge management. So when something went wrong, what did you do? How did you solve it? And can you provide an implication to inform, how did you make sure that didn't occur again on another project? So how would that differ from 1.6, which is implemented responses to risks and issues including escalations and recorded lessons learned? It doesn't, which is why I said they're quite a lot of overlap. So you've got the implemented responses to risk and issues the first bit, but the last bit, 1.6 is risks and issues, 1.4 is only issues. So you could hypothetically write an answer to 1.6 and you'd more than likely fit 1.4 as well. A lot of it, yeah. I see the emphasis as well in 1.2 is about documenting recording, whereas 1.6 is about implementing the response and tracking effective implementation of that response. If you look at 1.4, it focuses on making sure we log it somewhere, what the issue was, how it was resolving, because that's going to have an implication for future projects. In 1.5, it's about the planning. So we plan a response and 1.6 is about how did you actually ensure that that plan was implemented? So you almost break it that down into the different high-level steps. It's particularly difficult, because risks and issues are combined in the same heading. Ideally, in the old days, in the old body, inologies and competence frameworks, they have a separate risk management and issue management to several things. That's right, yeah. But now they've conflated the two in the competence framework and the way you deal with them is differently. From a whole philosophical point of view, risks are you've got to be future-looking, you've got to pre-empt them and stop them happening. Issues, you've got to be ready for them and react to them and deal with them when they have. And the whole language is different. And whilst this is a lot better than it used to be in version 1 of CHPP, it's still a bit contrived because it's following the competence framework and the way that's put together, I suspect. Yeah, but the way John presented it is, is really clear. Risk are more proactive and the language follows. Identifying risk, recording issues. You don't identify issues. The issues have happened, but you must record it. So I agree with John. I think the way the criteria has been updated is making that differentiation much clearer. You see arguably, you can, the other question that people get, and this is a really good example of bringing this point out, is how much of an example do I use? What role does examples have to play in here? And if you think about the project overview, the project overview is the situation here, you're talking about the task and the activities and what was what I have to do and what did I do? So sometimes you need to introduce a little bit of an example, and you can let the example drive the answer. The example mustn't become the answer. So given the little case study of how you dealt with one risk, there's not going to answer all of those points, but it can help to underpin it and breathe some life into it, because what you've got to try and do is convince the assessor that you really did this and you didn't just use CHATGPT to generate your answer. So you've actually got to got to breathe some salience and some personality into it to make it sound real. And so you could introduce an example of a little risk, that matured into an issue and then you could explain what you did about it, and you probably deal with most of that with some careful wording, and that would probably be good enough. Yeah, you could identify one risk and then follow it through all of those PPs. Pp 1.7 transferred and/or formally closed and resolved risks at the end of a project or phase. Yeah, back to the definition of the risk is something that may happen, but it may not. So some of those risks that we anticipated to identify may not have manifested, or perhaps the proactive response that we put in place to try to avoid it or reduce that probability has actually worked and is not longer a risk. So I think this criteria transfer or formally closed and resolved risk at the end of the project is about how did you track that, and you may do that to release some of your contingencies, for example, or maybe for other reasons, lessons learned perhaps for future projects. How do you transfer numbers old risk? Well, let's say you've built something and you're aware that there's a danger that it might go wrong. Yeah. That's a good question, but I mean, you know, see, if in building a route way, you've determined that maybe there's a risk that those trees will grow and obscure a signal, you might want to pass that onto the operator. There's nothing you can do about it. You've done your project exactly as it was supposed to be. Any idea where you're adept with it while you're doing it but it might be that on you know final handover they're risk appears on the operators risk log and then they have to deal with it, right? Now, that means that you're not to blame if something goes wrong, God forbid, but it also means that they're aware. So there's a piece in there about identifying who it is or where it is. You're actually transferring that risk to rather than just leaving it there to register. I mean, implies you're going to give it to somebody else and that somebody else is the operator. And it also says the other thing that's important in here is about phase because not everybody finishes a project. So here you would pass risks from one phase to another. So we didn't we didn't manage to finish all of the uninterrupted power supplies for the servers. They're all working, but there's a risk that if one of them fails. This phase has finished. Now you're going on to the next phase. You need to deal with that. So you need to build that into your budgets because we did all we could. We didn't manage to get it fixed so over to you kind of thing. But the project still going. It's just another phase. Maybe it's a different project manager. And just saying that we left it on the risk log and so it's now someone else's responsibility probably isn't the right. It's a bit lying, isn't it? Yeah. Yeah. And when something goes horribly wrong, when you go, well, I did tell you, it's not going to hold much water, is it? One of the things I'm going to point out here is that when people 1.3 assess the probabilities and impacts, right? Now a lot of people are used to quantitative risk assessment, but some people aren't. And a lot of people use qualitative. And what I mean by that is qualitative is, oh, that's quite likely. I'll give that a 4. Oh, if that goes wrong, that's going to be a 5, right? Well, that's sort of semi qualitative. You're giving a number to a subjective judgment. Quantitative risk assessment is about objective judgment. So it's where you have a definitive number that you derive through some algorithmic or mathematical derivation. It doesn't really matter here, but it will in TKs. So when you go and I'm just flagging it now because we're not going to get a chance to do this podcast for TKs, but when you get into TKs, you will notice that they talk about qualitative and quantitative. And I've seen people, as people, application, unpicked the interview just because they didn't know the difference. So you've been warned. It doesn't matter for this particularly. Although you could argue that, you know, in here, you could show how you did a quantitative risk assessment to deal with Pp1.3. So it's equally acceptable. It's just one of those rules of thumb is if you're not completely comfortable with something. Don't start talking about it. It might still come up in interview, but you can't do anything about that. But what you can avoid is he's painting yourself into a corner. Because if the assessor sees, "Oh, you did quantitative risk assessment." That's really interesting. Can we talk about that? And you go, "Oh, I didn't really." So I'm going to go well. Good. So we've deprived the listener of a 45 minute argument between Paul and John about risk and issue management, which is probably to there. Well, I mean, we'll do those on demand, I think there's plenty of them out there in the other side. There are. If Pp1's a listen to Pp1. Oh, the E-Fuck. Yeah. Yeah. Good. I think we've covered all of them. Yeah, yeah. I'm looking towards my cup of tea. Good. Right. Thank you. Thank you. [Music]