- Welcome to Module 14 where we look at the starting up a project process. We're going to be looking at the purpose of starting up a project process, the objectives for it, putting it in context, and also taking a look at the project brief which is one of our major outputs. So we'll look at the purpose first, and there are... Really there's just one main point to this. We've got to ensure that the prerequisites for initiating a project are in place, but we do that by asking a very important question, do we have a viable and worthwhile project? And we need to do the minimum necessary to decide. So do we have enough money, do we have enough time, do we have enough resources, do we really want this, are there going to be enough benefits? There's a lot that we've got the think about here, but we're really not going to waste too much time on it. We're going to do the minimum necessary. Now, depending on the complexity of this project, the minimum necessary may be quite a lot of work. So don't be too fooled by that phrase, but just remember it because this is an important keyword that I've noticed in our foundation and practitioner exams. Now, the objectives are to ensure that there is a business justification for this project. So we're going to have to create an outlined business case to present to the board, and they'll decide for us. We need to check that there's the right level of authority, and that someone can initiate our projects once we've given them this information. We need to know what we're going to produce, so in others words we need to know what's in scope, what's not in scope, so we need to define that. And we need to know how we're going to deliver this product, whatever it might be. Are we going to go in-house, out of house, off the shelf, bespoke? We need to know that before we initiate because it has big impacts on time, and cost, and risk. It's quite useful to appoint as many project team members as you can at this point, and we will certainly will need the board to be involved, so we'll appoint them at least even if we just write role descriptions for the other roles. And we will need to create an initiation stage plan so we know how much it's gonna cost to initiate, and how long it's going to take, and who needs to do what, and when, and where. And the idea here is as much as planning for a project we know is gonna happen, it's important to establish which projects will not be viable, so those poorly-conceived projects. We don't wanna waste time initiating a project if it's not a good idea. So really what we're trying to do here in the starting up a project process is to check that this is actually a good idea for a project, and that somebody might have had some hair-brained scheme and thought, "Oh, it's going to be great," but they haven't really thought it through. And so what we're going to be doing here in starting up a project process is working out whether or not we can afford it, whether or not we're going to get any benefits at all from it. And it's often as soon as you're given the mandates, sometimes you get a feeling for this, whether or not this is a project that's viable or not. But the people who give you the mandate are sometimes very emotionally attached to the idea of this project, so we need to try to be careful here and maybe spend a little bit more time than we would normally proving to them that this isn't actually a good idea. And do this now before we waste resources initiating. So it's good to bear that in mind, and that's why they say do the minimum necessary, but the minimum necessary might be quite a lot. To put this in context then, we receive the mandate from corporate, the programme, or the customer. That then triggers this process, starting up a project process, and the output of that then, one of them anyways, is the project brief. We also have an initiation stage plan, but the project brief then and the other documents will go to the board, and the board have then got to decide is this project worth initiating? Now, the activities involved are in Section 14.3. You've got this diagram in your book, and as you can see, there's quite a lot in it, text is a bit small. So feel free to go there and have a look for this diagram. I'm going to translate this into a more accessible version for the screen, but effectively also I'm going through is every single one of these activity boxes within the starting a project process, so here we go. The first activity triggered by receiving a project mandate is to appoint the executive and the project manager. Now, corporate will appoint the executive. The executive will probably then go out and find a project manager. And they will together go through what they've learn from previous lessons and create a lessons log so that we can store lessons for the future. And we might have learned important lessons from past projects, which suppliers we like to work with, which ones we definitely don't. Whether or not we need a team of people in project support or whether we can get by with just the project manager doing it. There'll be all sorts of lessons that we can learn. And we don't have to just rely on the executive and project manager. They can go out to get advice from other project managers, or even outside the organisation, online forums, even they count. But we'll gather those up so that we can learn from their mistakes and listen to their advice before we move forward. Then we can think about how big our project management team should be, and we need to design a structure, write role descriptions, and then appoint as many as we think relevant at this time. We're certainly going to need the rest of the project board, so we'll bringing on board a senior user and a senior supplier. The senior supplier may change, it might even be someone like head of procurement who will help us with procuring other suppliers as the project goes on. So we'll bring those people in, and so effectively what we're now discovering is who is going to help us achieve the goals of this project. So it's the who question here. Once we know who can help us, then we can work with them to prepare the outline business case, so that discussion of viability. And so we will then be answering the question why? Why do we need this project? What are the reasons, what benefits do we hope to get? But it's really why are we here, why are we going to do this? At the same time in this activity, but it's not clear from the activity title, we need to write the project product description. So this is why I'm sort of taking a closer look at these activities because they have these activity titles, but it doesn't always show you exactly what's going on, so I put little speech bubbles in there. And feel free to annotate your book actually with some of these items that I've put in the speech bubbles. So we prepare the outline business case and we answer the question why, why are we gonna do it, and then we add the project product description, and that answers the question what? What are we going to make, what's the project product? And we talked about the project product description when we thought about quality, and this will tell us what would be fit for purpose, and how it's going to be tested, and what would be acceptable at handover? So very important document there not to be forgotten. We think about that right in this pre-project preparation process, and so we need to know exactly what we're going to build before we initiate. So we know who, we know why, we know what. Now we need to select the project approach, and that is asking the question how? How are we doing to deliver this? Are we going to go in house? Are we going to outsource it? Is there something off the shelf we can buy, or do we need to go bespoke? So selecting the project approach is about delivery approaches and how we're going to build this project product. And with all that information that we've got, the who, the why, the what, the how, that can all go in the project brief. So the brief, and imagine this as a briefcase, it's a briefcase of a few bits of documentation. We might have spent quite a lot of time building it, but we now know who, why, what, and how. And so that will go up to the board eventually, but first we need to build an initiation stage plan. We need to plan that initiation stage, so that's the final activity here. How much is it going to cost? How long is it going to take? We decide that in our initiation stage plan, and we'll gather that up with the project brief and give it to the board. And now the board will decide whether or not we initiate. The last thing to think about here is just the project brief because it's worth just looking at the language that you use in relation to that. The project brief then, this collection of documents that tell us who, and why, and what, and how. And we'll provide a, as they say here, a full and firm foundation for the initiation of the project. I think of it just as a briefcase with a few documents in. And the guidance on this from PRINCE2 is that we should document what is known at this time, but don't spend too much time getting the details. Details can be added in the project initiation details, the PID, when we initiate. So there you go, that's the project brief, and an introduction to the activities of the starting up a project process.