- welcome to module 16. We're going to be taking a look at the initiating a project process, and we will be looking at the purpose, objectives, context, and also quick look at the PID, the Project Initiation Documentation. So the purpose of the initiating a project process is to establish solid foundations for the project, and in this way, we now understand the work that needs to be done to complete the project product. So the language here is about solid foundations. Now, when we were in the starting up a project process, we were doing the minimum necessary and we were trying to get a firm foundations. We had a rough idea about what was going to happen. We know that could shift, but once we have finished the initiating a project process, we know exactly how things are going to be done. It's solid. We're gonna do a lot of work to come to that point. Here are the objectives, and firstly, we need to understand the reasons for the project, the benefits, and the risk that we've going to have to build on the business case in order to fully understand that. We need to agree the scope. We have already got a project product description written, but we're going to tweak that, and we're going to create a project plan to show how and when those products will be delivered and how much it would all cost. We also may need to update the role descriptions that you've written in starting up, and we're going to confirm decision making authority so that we know who is involved in our project decision-making, so that's one of our objectives there, the third one. Then we also need to think about building our approaches for risk, change, quality, and communication. So how are we going to deal with risk, and change, and quality, and communications around here? We need to create those strategies. We also need to think about how we're going to tailor Prince2, and our existing methodologies in the organisation to suit the project. Tailoring is very, very important to us within Prince2. So lots of objectives there, and also if you look at the activities in the context there, quite a few individual activities. Now, again, you'll find this in section 16.3 in the manual. So feel free to go and look at that, feel free to annotate it, I'll give you permission to write in the book. Some people need it. But in fact, there's a street value to Prince2 manuals that have been annotated properly. So feel free to annotate notes on these diagrams. I'm going to break it down into a hopefully more accessible and certainly visually layout. So if we take a look at the individual activities within the initiating a project process in turn, we start with the agree tailoring requirements activity. This is where we decide how we can tailor Prince2, to suit the needs of the project. So if you're in a very complex project, we might be adding extra management products and making that decision now to do that. So you have better control of the project. If it's a very small, quite simple project, then we'll be wanting to take more lightweight approach. So when we agree the tailoring requirements, we might say, "Oh, well, I have some of these reports verbal, we'll just use corporate strategies," etc, etc. So the agreed tailoring requirements is something we need to set up and decide in advance, before we continue through the rest of the activities within the process. The next three activities can all be done at the same time. There is not a particular requirement to do them in a particular order. Although actually thinking about risk, that might be the first one to look at because if the project is too risky and we find out now when we write our approach, well, maybe we should, prematurely close project right now. Well, we'll see. So think about preparing that risk management approach. So how are we going to approach our risk in the project? We also are going to think about how we're going to approach quality and write the quality management approach and the change control approach as well. Now, Prince 2 recommends for each of those approaches that we have registers. So at this point we will create the appropriate registers as well. So for the risk management approach, it's the risk register that we're creating, for the quality management approach, it's the quality register, and for the change control approach, we create the issue register. So we now all ready to deal with risks and quality tests and issues as they arise. With that done, and from those discussions, stakeholders become important. We need to communicate to our risk owners, and action is for example, we need to tell the chair of our quality review meetings that they are the chair and that they need to take action, etc. We need to tell people who are going to act as the change authority that they have responsibilities to carry out as well. So there's lots of communication required and that's just within the project team. Of course, we've got lots of external stakeholders as well, and we need to communicate with them. So this is why we have that fifth activity there to prepare the communication management approach. Now, quite strangely, in some ways there's no communication register required in Prince2 methodology, not even recommended or listed, but if you have a project where we need to record those communications, then you can easily tailor the methodology and have your own communications registers and that's tailoring. So we've got the approaches sorted out. Now we can start to plan the projects, and so the project manager will create a draught project plan and they will give that to the board. The project board I'm talking about here. Will have to then look at that draught project plan and they will have to decide what project controls they want to put in place. So they will be discussing with the project manager where the stage boundaries are going to be, how often they want their highlight reports, and they may even have some discussions with the project manager at this point to decide who exactly has responsibility to do what. So change authority as an example, how much money is the change authority authorised to spend in Mongo cumulatively? So the project board will need to be consulted in this set up project controls activity so that the project manager can record what the project board need to control the project properly. So then the project manager can take that information and finish off the project plan. Now that they know where the stage boundaries are, this will really help them decide how we're going to chunk up the various activities. So from there, they can make product descriptions for the various products they're creating and they will use the product based planning technique to help them write the project plan. So that will now mean that we've got a more or less perfect, hopefully that's all draught, but it hasn't yet been authorised, but we've got a much better idea of how much it's gonna cost and how long it's going to take. If the project manager is not happy, then now just work with the board to see if they can get more insight into how are we going to manage this project. So there's going to be a bit of liaising between those two. Eventually though, the project manager has got a project plan that they think is demonstrating a viable project. So they will then move to the next activity. That is to refine the business case. Because we know so much more now about the project. We know what the major risks are, we know what activities we are going to carry out, we know how long it's gonna take, we know how much it's gonna cost. So we can update the outline business case that we created in starting up a project. This will help us understand the viability and desirability of this project. We will weigh up again, the benefits we're hoping to get against this updated costs and risks, and these benefits we're really hoping that they don't outweigh these benefits. If that's the case, and the benefits are no longer high enough to outweigh the cost, and risk, and this benefit. Then clearly we're not going to get a good feeling about this project. We'll send up the documentation to the board and they would probably say, "Nope, let's not move forward with this project. We will shut it down now." But hopefully, having done all this work, we know that actually there are still significant benefits to be expected and bearable cost, and risk, and these benefits. I will be thinking, great, yeah, this project is still viable." So this is a really important step in the initiating a project process. At this time, having thought about our benefits, and confirmed what benefits we're hoping to get, we need to think about how those are going to be measured ongoing through the project if we can get them realised within the project, or beyond the projects, once the project is closed. We call this management product the benefits management approach, and in this benefits management approach, we will write down more benefits that are expected, who's going to be accountable for them? Who's going to measure them? When are they going to measure them? What resources do they need? So these two documents then are created in this one activity. I'm nearly done, because there is one more activity left and that is to gather all these major documents that we've created and to put them in the PID or Project Initiation Documentation. So we won't put in the registers because they're always dynamic and changing, but we are going to put in our approaches, our tailoring documents, our project plan, product descriptions, the project controls and the business case. All of those are going to go in the PID. I do think of it as a filing cabinet because it's a collection of important documents that will then have to be delivered up to the board and the board will read every single one of them and they'll individually become baseline, and if we want to change those documents in the future, we'll then have to go through formal change control. So assembling the PID is the final activity in the process. The purpose of the PID is to define the project then in order to form the basis of its management and an assessment of its overall success. It's effectively a contract between the project manager over there on the left and the project board. The PID lays out exactly how we're going to do things around here, how much it's gonna cost and how long it's going to take. That's an agreement then with both parties and there'll be expectations on behaviour as well here. So it's expected that maybe the project manager escalates an exception within 24 hours and that the board will make a decision with 48, for example. If that's what they have written down in one of the approaches, then that's how everyone should behave. So it's effectively is a contract between those two parties and the project board will have to read every single thing in the PID before they can authorise the projects. So that's why the PID is a very important document for us, and it's going to be updated when we need to, and at least at the end of every stage when we're in the stage boundary process. So there you go. That's the PID, and that completes our video on the initiating a project process.