- Welcome to Module 20. We're nearly at the end of the processes, this is closing a project process. And we're going to be looking at the purpose and objectives of the process and putting it in context, looking at the activities. Now the purpose of the closing of project process is to provide a fixed point at which acceptance for the product is confirmed, and we have a handover meeting then and get acceptance from the customer. However, it doesn't always end in that positive way. It might be that we close prematurely, so another purpose is to provide a fixed point where we establish that the project has nothing more to contribute. Now our objectives are to verify that user acceptance of our project's products in the handover, and we also will not close the project until we are really clear that the host site is able to support the products we've made, so we're not just going to leave them with a bright new, shiny thing that they don't know how to use. Now that would not be good, so part of our objectives there is to make sure they're ready to support whatever we've delivered. We are also going to reflect on how the project has done. Have we met our targets? Have we stayed within our tolerances? You know, have we achieved the goals that the original PID set out, although it might've evolved over time, of course. We'll assess any benefits that could have been realised over the life of the project, and not all projects have a situation where benefits will be realised during the life of the project. Most projects will have a situation where benefits are realised after the project is closed, so we'll measure the benefits that we can and update our benefits management approach to make sure that the people using these products can measure benefits once we've closed. And then finally, we aren't just going to hide all the risks and issues that haven't been finished yet, we're not going to just keep 'em to ourselves. We would need to share them with the customer or user that's going to be using the project's products, so we'll ensure that those open risks and issues are going to be addressed with follow-on action recommendations. So it's not just a case of just handing it over, here you go, we're off. We have to really do this in a responsible way, so there are these set activities, which we're going to follow in the closing of project process. The diagram in the Prince Two Manual in Section 20.3 is displayed on the slide in front of you, and as ever, as we've been looking through these processes, this isn't that easy to read, so I'm going to take you through them activity by activity and feel free to annotate your book accordingly. The activity is triggered because we're near the end of the final management stage, and we know that we need to hand over the product before we can close. The first activity in the process is to prepare planned closure. We know we're going to have to have a handover where we pass the product to the customer or the end user, and we do not want that to be embarrassing or chaotic. We want it to be very organised and planned, so we have this activity to prepare planned closure. In this activity, we will update the project plan with the actual figures. We know how much it's cost and how long it's taken. And more importantly, have we got any money left? We also will check the project product description because in the project product description were acceptance criteria, a list of things that the product had to contain or deliver before the customer would accept it. So the project manager will check through the acceptance criteria and ensure that we have met all of them. Once they are convinced that we're ready to hand over then we moved to the next activity and that is the handover meeting. We're going to hand over products, that's our activity. And so we're going to, and it's usually a physical meeting for this one, where we have a customer sitting there ready to take responsibility for this new product. And amongst the documents that we're going to update, we are going to update the benefits management approach for one. We are also going to agree what we're going to do about those open issues and risks and create follow-on action recommendations. So if we have created a new office building and most of it's finished, we're handing it over to the customer, but we're just telling them, "By the way, there's a few tiles "that are missing in a bathroom." We're not going to stop project closure on the back of that, but that is an issue that needs resolving. so we'll create a follow-on action recommendation where it's agreed, who is going to fix those tiles, and when, you know who's gonna pay for it. And this is why it's useful to know if there's any project budget left, so we can agree to pay for things we can afford to. We really are here to get the acceptance record. So yes, all the rest of it is very nice, and hopefully we'll have some nice chocolate biscuits at least at this handover meeting, but we've updated the benefits management approach or benefits review approach. We've agreed the follow-on action recommendations, and then they sign on the dotted line, yep, they take responsibility for it. From here, we have the acceptance record and that's what we've been working for. This what this project's been all about this day, this moment, where they give us that formal acceptance for the final product. And it'd be tempting to just stop now, but we've got things to do. So the next activity is to pause and reflect on how the project went, so the activity is to evaluate the project, and this is where the project manager creates the end project report. So they'll think about how the project went. Did it go according to plan? Did we meet our objectives? If not, why not? This will be interesting reading for the project board later. The last activity is to recommend project closure. When we recommend project closure, There's actually a lot more going on here than the title suggests not least we're going to close down our logs and registers. We're going to archive documentation that is no longer needed, and we're also going to create, you ready for this, the draught project closure notification, little bit wordy for maybe quite a short document. The project board don't make anything except decisions, but when they authorise project closure, they will send out, and probably this is going to be an email to everybody involved in the project saying, "Thank you very much for your help, everybody. "We're just about to close the project, "if you haven't invoiced us now, "the cost centre is going to close soon, "so you better do it quick." So it's a thank you very much, don't forget to bill us kind of message. And we call that the project closure notification. Now the board don't write that, the project manager does, and they do that here in this activity, the recommend project closure activity. So they make the draught project closure notification as well as closing all the logs and registers. So now, actually we've got quite a few documents, we've got our acceptance record, the follow-on action recommendations, we've got a project report, which probably included a lessons report as well, we've got the draught project closure notification that's quite a lot for the board to read. So yeah, why not, let's fire it up, send it up to the board. They have to read everything in it, and when they are happy that everything has been closed properly, then they will authorise project closure, and we can all go home or at least onto the next project. So that's what we do if it's a planned closure, but as some of you probably know, not every project closes in a planned way. Sometimes we close prematurely, and we have an activity here in the closing, a project process just for that. Now we will be told to close prematurely by the board in their directing of project process, and that notification will come down to the project manager and they then start this activity. And there might be a number of reasons why you might have closed prematurely, and it's not necessarily because the project has failed. It might just be that you've already got a lot of benefits, and to go on to the later stages is just too much cost and risk, et cetera, and we've already got sufficient benefit and to carry on would just outweigh the benefits, so we actually might be in a more successful situation than lots of people might think. And in fact, part of preparing premature closure is to consider whether or not you need to ramp up your communication activities to communicate to the rest of your stakeholders that actually this is good news. We're closing for good reasons, and it's not really a failure at all. However, sometimes premature closure happens, things outside of your control. I trained a lady who worked in a catering company, and one of their projects was to cater a massive event hosted by a famous singer. Unfortunately, just before that event, the famous singer sadly died, and so that project was closed. The event was cancelled. What do you do? In the prepare premature closure activity, the project team get together and they consider, is there anything that can be salvaged? And in that situation, there were things like menu plans, they hadn't cooked anything yet thankfully, but they certainly had things that the customer wanted to keep for future events with other singers and artists. So in the premature closure activity, the team consider what additional work needs to be carried out to salvage, whatever can be salvaged, so that they can hand it over to the customer. So you can see there the speech bubble, we may need to create additional work estimates at this point. So we salvage what we can salvage. We hand that over to the customer then we go to evaluate the project, recommend project closure, and you can see it's just as if it from there really as if it was a regular closure. But if there was nothing to hand over, we go straight to evaluate the project then recommend closure and then that goes up to the board, and they decide whether we should actually close or not. So there are two ways in to the closing of project processes, either the planned closure entry or the premature closure entry, but again, there's only one way out. And so that's it, that's the closing of project process and all the activities within it. And it's just worth bearing in mind, and just reminding you now that for the foundation exam, it's really just the purpose and objectives and general context that you need to know, plus a general understanding of what is roughly going on here. It's good to know some of these key terms and products that haven't been mentioned before like the follow-on action recommendations, and these are additional work estimates. So that's why it's been worth going through these things, but don't worry too much about remembering every little step and what order they go in, you won't need to know that for foundation. So I hope you found these process modules useful. That brings us to the end of the closing of project process and close now all of the processes.