- Welcome to module three, part two. And in this module we're finishing off our discussions on the PRINCE2 principles. So there are seven principles, and we're going to look at the purpose of each of those in turn. The first principle is continued business justification. Your project must have a good reason for being, and we must make sure that we write a business case down, and eventually get that approved. There's got to be a good reason to start the project. And we will keep that business case maintained, so that there's a good reason to keep the project going and recorded. If we come across any major issues, or there is any major concerns, the project manager will then examine how that issue will affect the business case. So the business case is a very important product for us, and we will always keep an eye on that business case to ensure that we have continued business justification. So we are going to, right at the start, we'll keep it updated, we'll be constantly referring to it, and when it's being updated, we'll have to send it up to the project board for them to approve it. And in this way we're revalidating the reason for being in our project. So that's continued business justification. The second principle is to learn from experience. We are constantly learning from experience around here. And in fact, before we even start the project, we're going to go and talk to our colleagues, maybe go online to forums, maybe delve into lessons databases, if you have them in your organisation, and we're going to gather lessons that will affect our project, hopefully in a positive way. So there might be suppliers that we would like to deal with because they worked with us in the past. There might be a sort of methodology, lessons to learn, so maybe we'll do this in three stages, not two. There are all sorts of lessons that we can collect, and we will learn from those at the start of the project, but we'll keep adding to that lessons log as we continue the project. And at the end, when we close the project, we're going to gather those lessons up and we're going to share them, so that other projects can benefit from our learnings. So this is a really important one for us. And if you have a lessons log in your organisation or methodology to use lessons and learn from them in the future, then, this indicates that you've got quite a high maturity level when it comes to projects in your organisation. But it's not easy to do well because, of course, people need to read the lessons before they can implement the lessons in their projects. So this is a very important principle for PRINCE2. Don't forget it. It's everybody's responsibility to contribute to this, and we're thinking about continuous improvement really here. So that's learn from experience, let's look at the next one. And here we have defined roles and responsibilities. Now, I think it kind of makes sense really. Everybody needs to know what they're responsible for doing, don't they? Otherwise we have meetings where everyone kind of looks at each other and go, "Who's gonna do that? "I don't know." But we need to have those roles and responsibilities defined, so we will record those roles, and have a project management team structure. And it might be useful, depending on the scale and complexity of the project, to actually write down role descriptions so that everybody understands what they've got to do. As well as that, we need to make sure that in our project management team, we have the correct representatives. We need representatives from our key stakeholders, our business, our users, and our suppliers. The business representative, also known as the sponsor or executive within PRINCE2, is going to make sure that we meet the objectives that we have been given by a corporate programme or the customer, and they're going to keep an eye on us to ensure that we get value for money with whatever we are producing in our project. The user representative is going to be making sure that we create a product which is fit for purpose, a quality product that is going to allow them to achieve the benefits that they want from this project. So they're going to be very focused on benefits. And so the users are people who will use the final product, but also potentially those that will support it and maintain it ongoing. The supplier representative, also known as the senior supplier, is bringing their skills and resources and knowledge, technical knowledge, to the party. We need to get their advice on what is technically possible within the constraints for time and cost and resources. So we need to have all three interests, we've got the business representative keeping an eye on things to make sure we don't go out of control cost wise, time wise, etcetera. The user, who wants, clearly, an excellent product, which will give them brilliant benefits, whatever they need to move the business forward. And then the suppliers, who can give us decent advice about what we should or shouldn't be doing, or can can't do within the project. So there you go. Those are the key stakeholders that we need to include. And let's have a look on the next one, manage by stages. And this is something that we're going to think about very early on in the initiation of our project. We're going to have a high level project plan, that's going to explain to everybody what's going to be delivered over the life of the project, and what's gonna be delivered when we close, but often this is a long period of time, so we might be six months, a year, maybe multiple years on track, it's very very difficult to write a detailed project plan that shows clearly what we're going to do. We cannot book a meeting in three years time and be confident that the agenda is going to be the same, and that the people are still there to invite. So, we will need to break down this project into manageable chunks, or management stages. So, in the PRINCE2 project, there will be always at least two stages. There's our first stage, where we're going to initiate the project, and then there'll be later management stages and the number will depend on what we've got to deliver, what our planning horizon is, where we want to make major decisions. And so, we will at least have one of those. So there's going to be a minimum of two stages in the project. The initiation stage, when we set it up, and then one delivery stage. But if we've got a long project, we're going to have to break it up into more than that. So this is what they mean by managed by stages. And for each stage, then the board are giving responsibility to the project manager to manage that stage. So they will approve of stage plans, when the project manager arises and sends them up, they'll say, "Yeah, I like that plan, off you go." And then the project manager has authority to run that stage. Near the end they'll plan the next one, show the plan to the board, who will go, "Yeah, I like that plan, off you go." And the project manager then starts the next stage. So the project manager is running each management stage on behalf of the board. And so that is the manage by stages principle. Managing by exception is a very powerful mechanism that we can use to use management time in the most efficient way. The project board will give targets to the project manager. And they have actually probably be given the targets from the corporate or programme level above them. So for example, corporate might say, "Oh, we want you to finish this project in six months, "and you've got a million pounds." So the project board say, "Thank you very much." And then they will give out those targets, spread across the stages to our project manager, and those targets will be for cost, time, quality, scope, risk and benefits. Those are the six aspects of project performance. And that's fine, but if, let's say, we thought the project was going to last six months and corporate told us we could spend a million pounds. What happens if we overrun by one day? What happens if we forecast to overspend by five grand? What are we going to do then? Do we stop, do we have a meeting, do we ask permission to overspend by that little amount? If we were going to do that every time we're forecast to overrun by a day or a few pounds, we would be constantly in meetings, and this is not a very efficient way to spend our time, clearly. So what we're going to do instead is manage by exception, we will set tolerances for all of these aspects. Instead of it saying, "Well, we've got to spend "a million, we're going to give you "a million pounds to spend." Instead of giving you that, we'll say, "That's your target, but we will allow you "to maybe overspend by 10%, that'll be okay." We would love it if you can understand by 20%. So that would be your tolerance. So the cost target, the cost objective is a million pounds, but the tolerance is an overspend by 10%, or an underspend by 20%. We know what they prefer, it prefers to underspend, but obviously that doesn't often happen. What's more likely to happen is that the project manager looks at the stage progress, realises we're going to overspend. If they think we're going to overspend by 5%, they'll go, "Okay, that's all right. "I'll tell the board in the next reports, "but we don't need to stop and have a meeting, "because they have allowed me to overspend by 10%. "So we're okay." Now, what we would have to do is escalate if the project manager forecasts an overspend 15%. Then they look at the tolerances, they go, "You've only got permission to overspend by 10%. "We're in trouble now." Let's escalate this as an exception, raise it to the board, the board can then escalate that to corporate and corporate can tell us whether or not we're actually allowed to spend that extra money, or whether or not they want us to take some other corrective action. So we will give regular progress reports up to the board and they will escalate those up as required, as necessary. But we only really need to pause and have big discussions if we forecast to breach our tolerances. So this is a very time efficient way of spending your management time, as long as everybody, of course, is reading their regular reports, and they do, because this is PRINCE2 and it's best practise, and everybody is following best practise. So it's best to imagine in PRINCE2 that we're operating in this best practise world, where everybody reads everything they're given, and we only really need a meeting or discussion If we have a major issue to discuss. So that's managing by exception. Focus on products is the next principle, and a lot of us have come from project backgrounds where we're very much focused on doing things, carrying out activities, where we've got designers designing, developers developing, builders building. Now, those are activities, and we need to plan for that, we need to know when they're going to start those activities and how long they're gonna take, and how much we're gonna pay them, but we're really interested in what they're going to deliver at the end of that. What's the product? So what are they designing? What are they developing? What are they building? What are they doing? So what are they producing? What are the products? So this might take a little mental shift from those of us who are very focused on the Gantt charts and what we're doing, but we want to know what the outputs are at the end of those activities, because then we can describe them, and we can put quality expectations on them, and we can even say how those products are gonna be tested, who's gonna test them, et cetera, et cetera. So we will focus on products here in PRINCE2. so it's worth bearing in mind that there are two different types of products in PRINCE2. You have management products and you have specialist products. Now, if you are in a project to create a car, the management product would be the project plan to make the car, the stage plans that we're going to create for each stage, when we do forecasts that are going to overrun by 15% and we're gonna breach our cost tolerance, there's the escalation report that we send up, that's a management product. However, we are going to make a car, and that is our specialist product. In fact, all component parts of the car are also specialist products. So the design for the car is a specialist product, the windscreen, the headlights, the upholstered seats. Those are all products, and those products make up the final product, which is the car. So those are the specialist products, and those are then very important to the final output, and will be very specific to an individual project. So clearly PRINCE2 will tell you and be quite confident about what management products you need, but they have no idea what specialist products you're going to need, because it will clearly depend on the project. The final principle in PRINCE2 is to tailor to suit the project, and, in many ways, this is one of the most important ones we have. A lot of people leave a PRINCE2 Foundation course, go back to work and say, "All right, I know how to run a project, "we do it like this." And they wave the big book around and try and get everybody in the organisation to use everything in it from every single tiny report to every single heading with every report, and it becomes very unwieldy in that situation. Now, some projects might need that, they might need everything that we recommend in the manual, and that might be because the project is very big, very complex, it's very important. And we might have a very capable team and lots of templates already set up, where doing all of this work is actually fairly straightforward. We might also need a lot more of the methodology to be used, more of the recommendations followed if it's a very risky project, because you want a lot more tracking, and you want a lot more control. But if you're in a very simple project with maybe only one delivery stage, and it's not that important, then you can take a more lightweight approach, let's say, to PRINCE2. So you really need to think about that when you are initiating your project. Do we need all the management products that they recommend or can we get away with maybe replacing that report with a verbal report? Maybe we'll just have a catch up by the coffee machine on Wednesday at three instead of having a written report. That is really up to you to decide, and that's really an art, and the more experienced you are at running projects and thinking about how you can tailor it to PRINCE2, the better you get. Test and measure really is the key here. But however you tailor that methodology, you've got to document it, and we do have the PID, our project initiation documentation, and that's where you write down how you have tailored the methodology. And you can tailor the themes, you can tailor the processes and the life cycle. You can tailor the names of all the management products to suit the language you're already using in your organisation, in fact, I recommend you do that, but you cannot mess with these principles. These seven principles I've just gone through, they must remain. So you can tailor everything else, but you don't tailor the principles. And so that's it, that's our seven principles. And that's the end of the lecture.