- Welcome to Module 11, Part One. Here we are discussing the change theme. And we're gonna start with looking at the purpose of the change theme and the different types of issue. The purpose of the change theme is to identify, assess, and control any potential and approved changes to the baseline. Now that's quite a big statement there and some of you might not actually come across that with baselining your day-to-day business life. So let's have a look at the definition of baseline and it tells us in the PRINCE2 manual that the baseline is a reference level, or reference levels, against which an entity is monitored and controlled. So yeah, that's helpful, isn't it? I think of baseline as something that has been approved. So it might help to think of a baseline as an approved product or something that's been agreed. A reference level, then. If we've agreed it, it's baselined, it's not going to change. And so anything we do will be compared against this baselined, or agreed, product. A good example would be our project plan. Once we make our project plan, we will pass it up to the project board, the project board will hopefully approve it, they'll agree it, and so we now have project plan version one. The project manager hands out work packages and manages the stage accordingly, and we will keep going to try and deliver what was in the baseline plan, the agreed plan. So if we want to change the plan, that could be quite serious. We basically want to change the agreement, change the baseline. So that's just one example of something that is baselined in PRINCE2 with our project plan. And there are quite a few management products that we baseline, and also when we make our specialist products. When we've made, let's say, we're making that car. When we've made the engine and we test it and they put their thumbs up and say, "Yes, it's passed the test, it's approved." We're not going to change that engine unless we go through formal change control. So the change theme is about controlling our products and making sure that we do not have uncontrolled change. We're not trying to prevent change around here. In fact, any exam questions that you come across that suggest that we might be trying to prevent change in PRINCE2, oh dear no, that's not going to be the right answer. We are trying to just make sure the right changes are made so that we can not have that situation where people just changing documents and products left, right, and centre. That would be our worst nightmare pretty much in a PRINCE2 project. So, the purpose of the change theme is to identify, assess, and control any potential and approved changes to the baseline. And people, if they want to ask for a change, we will treat that as an issue. And so let's have a look at that. An issue, according to PRINCE2, is any relevant event that has happened, wasn't planned, and requires management action. And so quite a lot of issues arise in the project manager's life. You know, all those e-mails and phone calls you take. A lot of those weren't expected, and you have to spend your very important and scarce management time dealing with those. Those are issues. And they can take the forms of questions, requests for change to anything that's baselined, but really anything that requires your time, that you didn't expect, is an issue. And there are three types of issue category that we use. We will collect these issues in an issue register and the project manager will decide are they a request for change, an off-specification, or a problem or concern. And I'll just look at these just to clarify what PRINCE2 means by those words. A request for change is a proposal for a change to a baseline. So basically, if somebody wants to change something that has already been approved or agreed. So changing our project plan, we were on version one, do we want to make that change and move to version two. So we need to consider that request for change. That's an issue. We also have our off-specifications and that's defined as something that should be provided, but is not. So, let's say we had an agreed product description and an agreed work package. We've given that to a team manager and they've got to make the car engine. And they've completed the engine, or nearly completed it, and they suddenly realise that there's something they can't finish. Maybe they've got a problem with a supplier. Maybe it's supposed to meet certain quality criteria, but it keeps failing the test. But in some way is not including everything that it should. So we know what should go in the engine. We have a product description for it that tells exactly what should go in it and how it's gonna be tested. But maybe we have not provided something in there, maybe it's not fit for purpose. So an off-specification could be considered a faulty product. We know what should have been in it, but there's not everything we want in it so it's missing something, it's off-specification. The third category is the problem or concern and according to PRINCE2 this is any other issue that the project manager needs to resolve or escalate. And the clue there in the language is any other issue. So if it's not a request for change or an off-specification, then we have to categorise it as a problem or concern, even if it's not necessarily a problem or negative thing. So watch out for that, that's slightly misleading in the title there. The project manager will then put the issue in an issue register, categorise it, and then decide what to do from there, but they have only got these three categories. And it's quite important to understand the difference, particularly between request for change and off-specification, so we do provide an exercise where you can test your knowledge on that. But don't forget, a request for change is where we are trying to change, or want to change, something that has already been agreed. And if it's an off-specification, we're either holding our hand up saying we can't do it, problem with supplier or something's faulty, we just can't make it pass the test. Or it might be, and this is what you don't really want, the customer spotting a fault and they're saying, "You should have made this car blue! "Look it, we've agreed this, "it's in our product description, but you've made it red, "and that is not right. You should have made it blue, but you've made it red. That would be an off-specification. But just, you know, an e-mail saying, "Oh, we're going to give everyone the afternoon off, "because, you know, it's such hot weather. "We want to give everyone time to enjoy it." Well, that's actually good news that you want to distribute. Everybody's gonna be really happy that. But the project manager has to communicate it, so this is an issue for them and actually might cause some concerns if we've got deadlines approaching. But it's on the first glance good news, "Oh, everyone's going to get the afternoon off." It's not necessarily, obviously going to fit in the problem or concern category, but it's not a request for change, it's not an off-specification, so it has to be a problem or concern. So hopefully that clarifies the three different issue types and that brings us to the end of Part One.