- Welcome to module 13, where we have an introduction to the Prince2 processes. We're going to take a look at the seven different processes and take a quick look through the Prince2 journey, the life cycle of a project, and then pause to reflect on how the processes are structured and how you would read the different chapters if you go to find out more. Now, in chapter 13 in the Prince2 manual, we have a diagram and we've just copied it here onto the slide. But as you can see, it's quite a large diagram of quite a lot of detail, and you probably won't be able to read it here on the screen. So I suggest that you go to chapter 13 and find figure 13.1, which indicates the Prince2 journey. So you can follow through this diagram with me, or you can just sort of sit back and watch, see what the journey involves and then go back and have a look at the diagram there. So, you choose how you want to handle this of course you can pause the video at any time. If you want to sort of look at the book and then look at my screen. So, this is a process map. And at the top you have corporate programme management and the customer who we're always referring to if we need some advice from, and we have within the project, we have our three levels, the delivering, managing, and directing levels. And so we are going to start off here actually, my language appropriate there with the starting up a project process. Now this is a pre-project activity or set of activities, and it's triggered by the project mandate. So corporate programme management or customer, they want this project or want someone to explore the possibility of viability of this project. So they'll give the project mandate out to probably the person who's going to be the executive and they might hand it on to the project manager. And so then the executive and project manager work together on this pre project preparation starting up project process. And they're really just doing some exploratory work here, trying to get some information together, to work out if there's a business case for this project. So you can see starting with project process fans, the managing and directing levels because the executive and the project manager involved in this one, and we all gathered together members of the board at this point. So the project manager's gonna speak to our senior user and senior supplier as well. So that straddles the two lines. Now at the end of the starting of a project process, the project manager will have written a project brief and also an initiation stage plan. And that now needs to be formally approved. So the project manager will give that to the board. Now, the project board here in Prince2 they operate in the directing a project process. And so you can see that up there in the directing level. The directing a project process is something that's entered into continually all the way through the life cycle of the project. We're always having to escalate things to the project board for them to approve or make decisions on. So you can see in the timeline, they're going through the lifecycle, they're going right the way across, and we just dip in and out and ask them to make decisions as appropriate. So they will read the project brief and the initiation stage plan. And if they like what they see, they will then authorise initiation and we can start our next process. And this is where the project manager has to initiate a project. So initiating a project process then, and they're very busy here. They are basically building the ped our project initiation documentation, setting out how we're going to approach risk and change and quality, et cetera. They're gonna write the project plan and our benefits management approach amongst other things. So there's a lot of documentation the project manager builds, and it has to go up to the board to be approved. So up it goes, and the board read everything they're given because this is the world of best practise, right? And it's best practise for everybody to read what they're given and the board certainly do. They've got a lot to read. They've got to read the whole head. I think of it as a filing cabinet of different documents that they've got to go through and approve, hopefully. Now, if they want to get advice from corporate anytime, you can see there's a connection there, they can always go up to corporate programme management or the customer and ask for advice and then filter it back to the project manager. But hopefully eventually they've read everything they happy and they are saying "right, great, "we authorise the project." But we can't start work yet because this project only has a project plan and we need to break up this project into manageable management stages. So for that, we need to stage plan for the first delivery stage. And so from directing a project process, we go to managing a stage boundary process. And again, this is a role for the, also an opportunity for the project manager to build information, gathering information, to prepare for the next management stage. So the managing a stage boundary process is information gathering exercise really. They will write a stage pump for the next stage they reflect on the stage that we've just about to finish, to see how that's gone. And they'll gather reports together to give up to the board and then ask permission to start our next management stage. And the board read everything they're given, which in this case stage plans and then stage reports. And if they're happy and they still think this project is viable and desirable and achievable then they'll say, "yep, okay, off you go, you can start stage two." So now we're in stage two, or as you can see at the top there, we are gonna go through this cycle a number of times, subsequent stages, as soon as the stage plan for that stage is approved by the board we can start that stage. And the project manager is now busy. They are controlling the stage. In the controlling stage process they're handing out work packages. They're keeping track of your work packages they're receiving completed work packages. They are escalating issues and exceptions as required. And they're trying to take corrective action to keep everything on track. So they are very, very busy, but they can always go up to the board for advice, if need be. They will be handing out work packages, negotiating the terms and conditions of those work packages with the team managers down there in the delivering level. So they, the team managers will be operating in the managing product delivery process and then the managing product delivery process. They are accepting the work package, delivering the work. And then eventually once it's been tested, delivering it back to the project manager. So the, all three levels actually are involved in the management stage. The team managers are making the products and testing them. They're reporting to the project manager and controlling stage. And then the project managers probably escalating or they will definitely escalate in their regular reports, but probably asking for advice from the board up in directing a project process. So all three processes are going to be used throughout most of the management stage. But near the end of that stage, the project managers starting to think about the next one. So they will enter into managing a stage boundary process and just like the managing a stage boundary process we looked at before, they are going to reflect on what has happened in this last stage we're about to finish and they're going to plan for the next one. So they're going to create an awful lot of documentation, like our stage plan and stage reports. And they're going to update the ped if necessary, and they're gonna give it all up to the board to read and of course the board read everything they're given, because they've got to make sure this project's still viable and desirable, so they will read these documents. And if they're happy, they will say, "yep. "Okay, of you go onto the next stage." And so we go through this cycle until we are approaching the final stage and the board will look at the stage plan for the final stage say, "yeah, okay we like it off you go." I mean, if they don't, you just go back into managing a stage manager process and improve it until they do. And if they really don't think the project is viable they will shut the project down prematurely, but let's assume for a moment we're approaching the final stage. The board have read everything they're given. So and they like the stage plan for the final stage. And I think it's still viable. So they give you the green light off you go. And we go into the final stage. The project manager does as they've done in every other stage, every other delivery stage, anyway. They need to control it and they are going to be working with the team managers in managing product delivery. So they're going to be the project manager is gonna be giving out work packages. The team manager is gonna get them finished eventually. And as we get near to the end of the project, the project manager now has to think about closure. And so there is a special process for that, the closing a project process, and here the project manager will organise the handover. So this project has been there to deliver products and a final product. And certain let's say, it's that project delivering a new car? Well, in the closing a project process, they formally hand over that new car to the customer. And we want that handover to go as smoothly as possible, but there might not be, everything complete. There might be some issues and outstanding risks, that we still need to tell the customer about because they will need to deal with them once this project is closed. So there may well be some following action recommendations that we negotiate in this closing a project process. It's actually usually quite a lot of documentation created in the closing a project process, not least the end project report. So there's plenty of information that we're going to send up to the board because the board, again, read everything they're given to make sure that closure was completed properly, that the customer has properly accepted the product and that we have met our objectives. And so if they are happy with that, then they will authorise closure and then that's it, we're done. The project is closed and we can all go home. So there you go. That's the life cycle of a principal project within the process map. But it might be easier if I look at this individually. So we do have modules where we examine the processes one by one. And on that note, it's good to think about how these are laid out in the manual. Each of those processes has its dedicated chapter and within each process, there are a number of recommended activities. And I've mentioned a few as I went through the previous slide. But within each activity, there are actions that Prince2 recommends. And so you have to be aware of the processes and the generally about the activities. But as you can see on the left there, the structure of the chapter is that they show the purpose of the process, the objectives, and the context means, how it connects to the other processes. And you they've got an asterisk next time, because you will need to know this for the Prince2 foundation exam. Having said that, I have noticed that they use language that has come from the activities. So I will take you on a little tour through the activities, but we don't need to worry too much about the order of these activities. You just need to note some of the language and generally understand what happens in each of these processes. The rest of it, the different outputs and the responsibilities and tailoring guidelines we'll leave for the practitioner part of the course. So they will be referred to eventually, but we don't need them for foundation, thankfully. Okay. So that's it. The introduction to processes is complete.