- Welcome to Module 11 Part Three. We're still going through the change thing. And here, in this part we're going to be looking at the change control procedure. Now the change control procedure is one that's recommended by PRINCE2, and we will be recording this procedure if we're going to use it in our change control approach. And it looks like this. First of all we capture an issue, and the issue might be coming phone call, email, project manager might just be bumping into someone in the corridor on the way to get coffee, you know how it is. "How was your day?" "Oh it's fine except that we just got "three people go sick," you know that kind of thing. And you go, "Oh hang on," that's an issue. So with the project manager will catch the issue in all sorts of different ways and then they have got to decide what to do with it. The first thing actually is to determine the issue type, and we of course got three types of issue. They will be thinking, "Oh, is this a request for change, "is it another specification, or is it just "a problem or concern, any other category?" And they will be. You can imagine having a conversation with someone in the corridor. They will even in the corridor in that chat with that person that bumped into be thinking about how severe or important that issue is. And if it is quite serious, it needs to be dealt with formally, they will then log that issue when they get back to their desk, and it'll put that in the issue register, if it needs to be death with formally. And you notice there at the bottom of this diagram here, they could be recording this in the day, a log of it's gonna be dealt with formally, and certainly that's where your emails would be if it's coming by email, this is issue, then the project manager just replies with a response. Then that's it, dealt with, it's completely saved in the daily log but if the project manager wants to deal with this formally, they might move it to the issue register. So we've captured it, we worked to how serious it is and we've logged it in the appropriate register. The next step, and we can still be doing this bit actually in the corridors, we're talking with our team member or project team member, is to assess, we need to assess the impact of this issue on our project and we're specifically going to think about the business case here. So does it affect the viability of our project? Or our stage in any way? And we're going to having reflected on that think about have we changed our ideas on how severe or how important it is? Now you'll notice in this diagram there's actually an arrow up where we can request advice to the next level up of management so that's our Project Board or the Change Authority, if it's a request for change, and the advice could be, well just pick up the phone and call them, but we might also create an issue report. Now an issue report is a report where we basically report the issue to the appropriate level and ask them for their advice, and we could send that issue report up to the Board or the Change Authority as it's indicated here, but we could also send it out to project assurance, or even outside of the project to online forums and all sorts of things, keeping our confidentiality agreements, or keeping within our confidentiality agreements. So the issue report might go to a number of people, but we have just shown it here, Project Board and Change Authority. And so advice will be requested and then hopefully received, and the project manager will then decide what to do about this issue. I say "decide" because they're not actually gonna make the decision, they're just going to propose different solutions. They're going to look at different options to solve this issue, evaluate them and then recommend their suggested way forward. So they might well be using the advice they've got from the Board or the Change Authority when they came up with these options and evaluated them. They then have to make the decision of which of those options to choose if they can, if it's within their authority to do so, but if it's not in their authority to make that decision, if they have to escalate it, they will do so now. So if they know what they would like to do, so in the propose step thing, know what their recommended action would be, but to do so means that we overspend or overrun in terms of time, in other words we breach a stage or project tolerance, then the project manager can't make that decision, and they have to escalate it. And so this is where we send up an exception report to the appropriate level in the next level above us, Change Authority/Project Board. This is going to be the Project Board that will get this. They will get the exception report, even if it's a project tolerance breach, they won't be able to make a decision if it's a project tolerance breech. They can only make decisions if it's a staged tolerance breach, but they will receive in nonetheless. Project manager will send it up to them because we never skip a level. The project manager will never go straight to corporate. They will go through the appropriate chain of command so if they need a decision, and it's it for a staged tolerance breach, they will send up the exception report to the Board, and then the Board will make a decision. The Board will decide to tell the project manager and then the project manager can implement that corrective action and then update the records and plans accordingly. Now if it had been a staged tolerance breach, that'll be fine, the Board will make that decision, project manager implements it. If it had been a project tolerance breach, then the project manager would have not been able to decide. Again, given the exception report to the Board, and then the Board couldn't decide, they don't have authority to deal with a project level exception, they have to escalate it to corporate. Corporate makes the decision, tells the Board, the Board tell the project manager, and then we go to the implement step. The project manager carries out whatever corporate agreed. So we can go through these steps, these five steps in the change control procedure regardless of what type of issue or the severity of it, we do the same steps every time. So for example, if we bumped into someone in the corridor on our way to make the coffee and they said, "Ah, we got a problem here, there is no coffee." You're thinking, "Hm, I just captured an issue here. "It's not actually that serious, "that's not a very serious issue." The issue type is really not a request for change, or no specification, it's just a problem or concern, then we probably won't log this in the issue register, but this will stay in the daily log if it makes it that far actually, this issue is very small. The project manager in conversation is probably assessing immediately, it's not gonna have a massive impact on the business case, not that serious and they won't need to ask for advice from anyone on that, and they just think to themselves and move onto the next step. "Hm, I wonder how I should sort this. "I propose that I go out in my lunch hour. "Oh, I could wait until after work and buy coffee." And they think about those two options, they evaluate it for a minute and think, "Hang on, I might have some complaints "if I leave it too late, "so I'll recommend to myself that I'll go in my lunch hour." So that's what they decide. In the decide step they say, "Yeah, that's the best choice. "I'm gonna go get coffee in my lunch hour," and then they implement it. When it comes to their lunch break, off they go and buy coffee. So the same steps, but this is obviously a very informal issue and this would only stay in the daily log, it wouldn't be formally recorded. If we had a bigger issue, so someone puts in the request for change, the project manager might catch this via email and say, "Hm, yes this one needs to be dealt with formally." They'll put that in the issue register, and of course it depends on the request as how severe that is, but when we go to the assess step, this will might need some advice, so this is where they might send up that issue report up to the Board to get their feelings on it, and then get some feedback and that'll help them propose whether or not the Change Authority accepts, rejects or defers their decision about that change request, and then with that information, with a recommended decision, they will go to the decide step. Now if it's within their limits to make a decision on that change request, then the project manager may be able to make that decision, but if not, this is something for the Change Authority, they will escalate it to the Change Authority and the Change Authority makes a decision and then informs the project manager. The project manager can then implement that decision, take the corrective action and update the records and plans accordingly. So it's worth some remembering these different steps. Certainly they seem to like this foundation level exams, and even in practitioner, sometimes they ask you, "Which step a particular activity belongs?" So something to read through and you can find out more in Chapter 11. And so that's it for this part. We're just been through the change control procedure, and so hopefully you're a bit happy with that, and we'll continue with part four shortly.