- Welcome to Module Nine, Part Two. We are continuing the plans theme. And here we're going to take a look at the planning approach that PRINCE2 recommends. We're going to examine the difference between the management stages and delivery steps. And we're also going to take a look at the requirements of PRINCE2. The planning approach, as recommended by PRINCE2, has got several steps, you can see, taking it from the top. First of all, we need to have some kind of design for plan, and I'm sure a lot of you take existing plans, you know, fall savers and kind of rework them for the plan that you're just about to make. So there is probably a template somewhere in your organisation that you're using for the plans. So we have some kind of design existing there. Then you have to think about what you need to do in this plan that we're writing. So what products need to be created? And you need to define and analyse that. We're gonna be looking at that later with the product-based planning technique. The third step then is to, once we've got the products listed, we identify the activities to make those products, and think about the dependencies on those. From there, we can make estimates, how much it's gonna cost, how long is it gonna take, what resources do we need, et cetera, et cetera. And then we can make a schedule. And finally, we take that schedule and put it in our design plan template and add our assumptions and other documentations such as, you know, assumptions and things like that. So then we're documenting the plan. So there we have all the different steps. And all the way through this, we've been thinking about risks. You can see that in the red text there, we've been analysing risks to our plan. So that's the planning approach that PRINCE2 recommends. And we will do this every time, go through this every time we make a plan, whether it's a project plan, stage plan, or those optional team plans. In PRINCE2, we have management stages. We've talked a little bit about those. And we also have delivery steps. And we need to really explain the difference between those two. Now let's have a look at management stages first. They are "The section of the project "that the project manager is managing on behalf "of the Project Board at any one time," so PRINCE tells us. There is only one management stage at a time. We have our initiation stage, and then at least one delivery stage. So there's a minimum of two management stages in every PRINCE2 project. But depending on the complexity and timescales of your project, if your project is running for several months or maybe years, you're going to have many more management stages required to help manage that project. So there are at least two management stages in the PRINCE2 project. You cannot have stage one and stage two running at the same time. They must be one after the other, because at the end of every management stage, we pause and reflect and decide, or the Board does, whether or not this project's still desirable, viable and achievable. Basically we decide whether we should carry on. So we have finished one management stage. We pause and reflect and decide whether we should carry on to the next management stage, and so on and so on until we get to the end of the project. So that's what we mean by management stage. And that's very different from a delivery step. A delivery step is, "A step within the delivery approach." And you might know these as work streams. You might know them as technical stages if you've come from a previous version of PRINCE2. Here in the 2017 edition, we call them delivery steps. And these are maybe your designers designing, your developers developing, your builders building. They are effectively going to be now, different work packages for us that the project manager has to manage. So they will be included in a management stage as work packages or activities to complete, and they can often overlap. So we can have our designers designing, our builders building at the same time. So delivery sets can overlap, but they can also span more than one management stage. So we could have designers designing throughout the life of the project, particularly if you're in IT, and you're using sprints and agile delivery. So those delivery steps can span more than one management stage. And there can be more than one of them at a time. It might be easier to show you this in a diagram. And so let's have a look at what I've got here. This is adapted from a diagram in Chapter Nine. So you can maybe go and have a look there and see it's very similar. I don't really know what this project is going to be delivering, but we've got a number of delivery steps here. We are going to be specifying something, designing something, building it, training people to use it or make it, a lot of training there, so I'm really not sure what this could be. But at the end, the final delivery step is commissioning the product, whatever it might be. So we have five delivery steps in this project, and you can see some of them overlap. So we've got a specifying and designing at the same time, designing, building, and training there, the end there, at the same time. Some of them start at different times, some them finish together. But the delivery steps then represent the activities that we're going to carry out over the life of this project. So it's quite high level here. Now imagine that this is what the project managers put together. This is their draught project plan. Maybe be on the back of a napkin. And when they get a spare moment to think about this project, it's explaining what's going to happen over the delivery stages. But we don't really know yet what the, where the stage boundaries are going to be. And that's not the project manager's decision. They might recommend where they want the stage boundaries to be for each management stage. But it's actually the Project Board that decides this. So let's imagine the project managers got this on the back of a napkin and they've taken it to the Project Board and said, "This is what I think we need to do in this project. "Where do you want your stage boundaries?" And the Project Board would say, "Okay, well, this is where we want them." And the stage one will always be the initiation stage. And it's where we create our PID, our project initiation documentation. But that specifying delivery step and the beginning of designing, that's gonna be stage two. So when we finished the specification, that will be a stage boundary point. The Board want to look at that and decide whether or not we move on to stage three. So we won't begin the training until we're happy with that specification. And you can see in stage three, then we've got the designing delivery step, and the training delivery step. And at the end of stage three, they've decided to finish stage three before we get the builders in. Now we know that's a very big expense. We don't want to start building something and then abandon it. So we'll pause and reflect and decide whether or not we still want this project before we get the builders in. So stage four, we've got three delivery steps. We've got the designers finishing things off, the builders starting, training is being completed. And then when all of that is finished, the Board have decided that's a very good time to reflect and examine project viability. We'll check whether what we bought built was a... We'll check whether what we built was any good before we commission it, so that's stage five. And we then have management stages, one after another because they cannot overlap, but we had delivery steps, which do. They can have several delivery steps at the same time, like we've got in stage four. And some of those delivery steps span several management stages. So designing for example, spans several management stages. So hopefully that's clarified the difference there between our management stages and delivery steps. But if we take this one step further, what does this mean for the project manager? And actually, will they be happy with the stage boundaries that the Project Board have requested because they might not be, and this would be fine if this project was maybe one year, stage two to stage five, we could maybe, if our planning horizon is sort of two to three months, we can cope with that, that's good. But if we thought that this project was going to be five years, this would not be enough. We'd need more stage boundaries, more management stages. So the length and number of management stages are going to be influenced by your planning horizon, also by the delivery steps, which really very much influenced how the Board decided it here. If you're in a programme, the programme might also specify certain stage boundaries too, and risk. If this project is really risky, we're going to need tighter control. We're going to need more stage boundaries. So this would be fine if we're in a fairly stable environment and this project's not going to be more than about a year, and we're not part of a programme, we'll probably keep it like that. But you've got to bear in mind those influences on our management stages. And the project manager will then, once the Board have put these stage boundaries in, they might say to the Project Board, "Thank you very much." And they'll go back to their office and they will start then making the final version of their project plan. And it might look a little bit like this. So you'll see a difference in the language, particularly in the start at stage two. We did have the delivery set of specifying, but we don't focus on activities in PRINCE2. We focus on products, so we can't deal with specifying. We need to know what the end result of that is. What's the final product from that delivery step? And they've called it the specification here. Now we know what we're going to have delivered by that delivery step, now we can make a product description for it. So we'll need to create a product description for the specification. And if you look at the designing step, because we have stage boundaries splitting up, we need to decide what they're going to deliver at the end of each of those stages. And in stage two, we decided that's the overall design. So that's the right product description for that. In stage three, they've decided that we're producing the detailed design. So let's have a product description for that. In stage four, we're going to finish off the peripherals. So we need a product description for the peripheral design. So the delivery steps are split up across the management stages, and we need a product description for each of those outputs in each management stage. So you can see this carries on through the other delivery steps. You know, got the built facility, the training service, the trained staff, and the commissioned facility. Once you start switching it from focusing on activities, to focusing on products, which is our PRINCE2 principle, you can see now very clearly how easy it is now to actually write product descriptions for the major products. So there you go. Management stages and delivery steps and how that might help the project manager in their planning cycle. PRINCE2 has a number of requirements regarding the plans theme. So let's take a look at those. The first one is that the plans must clearly enable a business case realisation. So if we can't actually write a plan that allows us to, or demonstrates that we can make these products within the time and cost constraints we were given, then we need to rethink the viability of this project. They also insist that we have at least two management stages and that's that initiation stage where we spend some time planning the rest of it. So the initiation stage is one stage. And then if this is a fairly simple project and a very short timeline, we might only need one further delivery stage. So we've got the initiation stage, plus at least one delivery stage. But if you've got a longer project or it's very complex or quite risky, we're gonna have to break it down into more management stages. So, at least two, minimum of two. We also are told that we must have a project plan and stage plans for every management stage. And also we must have exception plans where if there is a major exception and we're asked to create a replacement plan for the stage of the project as required. So we must have that mechanism for making exception plans. We will learn lessons about planning. Maybe we might always overestimate or underestimate our costs and times, and as we go through the project, we'll start noticing that, and we should learn from that, and we'll then improve the plans in the future. So we use our lessons to inform our planning. We also have to make clear who is responsible for writing our plans and for monitoring and controlling them. So we must define our planning roles and responsibilities. And also we must use the product-based planning approach. I haven't talked about that yet, but that will be the content in the next video in part three. So that sums up the requirements for PRINCE2. And so that's it for me for now. I'll see you in the next video.