The course is part of this learning path
The course focuses on the components of the method and how they help to structure project delivery. Delegates should note that evening work will be assigned which is not expected to exceed two hours per night.
Specific course content will include:
- The structure of the method and the guide will be introduced before we discuss the context within which a PRINCE2 project operates.
- The seven PRINCE2 principles provide the framework for managing the project and are built on good practice developed from successful and failed projects.
- Themes and Processes
The seven PRINCE2 themes are aspects of the project that must be continually addressed and integrated as the project journeys through its life cycle.
- Business Case
The seven PRINCE2 processes encompass the chronological activities that are required to direct, manage and deliver the project successfully. The activities include pre-project, initiation and delivery, and end with project closure.
- Starting up a Project
- Directing a Project
- Initiating a Project
- Controlling a Stage
- Managing Product Delivery
- Managing a Stage Boundary
- Closing a Project
PRINCE2® is a [registered] trade mark of AXELOS Limited, used under permission of AXELOS Limited. All rights reserved.
The Swirl logo™ is a trade mark of AXELOS Limited, used under permission of AXELOS Limited. All rights reserved
- Welcome to module six part two. And this is the final part of the business case theme. Here we're going to be looking at, the requirements PRINCE2, regarding the business case, and also the important management products within it. Now we have a number of requirements for PRINCE2, and there are firstly, that we need to maintain our business justification, so we've got to create it first, and keep it up to date. This is usually written down in a business case, or it might be given a slightly different name, if you're tailoring it, and it clearly links to our principle of continued business justification. We need to review it and update it, at regular intervals, or when required. So if there was an issue, and we look at that issue, we think "Oh that actually might affect the business case," then we will reflect on the business case, and think about whether it needs updating. Otherwise we have our stage boundaries, so if you can say they're roughly at a regular interval, let's say that's our opportunity to update the business case at regular intervals, although not all stages will be the same length, but there is a mechanism then to pause and reflect, on the business case and update it. And within our business case, we're going to, want to demonstrate we're going to get benefits, and also here going to, in our requirements there, we need to define actions to ensure these outcomes are achieved. So if the outcome is increase sales, or reduce costs, we need to think about, whether or not those things are possible, within this project, and that will support our business case, or if we think we can't, then it might cause our project to be closed, because we no longer have a desirable, viable, or achievable business case. And finally, we need to think about the roles for the business case. This links to our principles there, clearly the role of having defined roles and responsibilities, so that principle there. So we need to define roles for the business case, and not just for the business case, for managing benefits once the project has closed. In fact, it may be possible, that we're going to get benefits during the life of the project, and so we need to give responsibilities to certain individuals for making sure those benefits are measured. But once the project has closed, you know, we've been running the project, we may have got benefits all the way through, once the project is closed, the project team has gone home, they've moved on maybe to another project. Someone is left behind, the organisation is left behind, and someone in that organisation is going to have to measure those benefits, and make sure, that we've met our strategic objectives. So we're going to be thinking about that also, in our business case. The important management products then, we've got two. We have the business case, but we also need to create, and document, if it's a complex project, a benefits management approach. So let's have a look at these in turn. Firstly we'll look at the business case, and we've got the number here on the slide, it says A.2 for business case. And that is because, you will find information about the business case in appendix A. And appendix A is right at the back of the PRINCE2 manual, and it's all in alphabetical order. So whenever you see the A, dot and a number, what this one means is, A.2, the business case is the second management product that is explored in appendix A. So if you want to find out more, and look at the purpose and the contents for business case, you can go to appendix A, and read more. So that's up to you. For foundation, we really just need to know the purpose of the documents, and you know, roughly what goes in it. But reading appendix A is always a useful thing if you have any extra time. So let's have a look at the business case in A.2, in appendix A. And if we look at the quote here, this is a really good one just to get the key words in, it contains "The business justification for undertaking a project, based on the estimated costs of the development against the anticipated benefits." So we've kind of got a scale going on here, we want to know what the benefits are going to be, and we need to weigh them up against cost, but also we've got to think about those dis-benefits and risks. And hopefully, we're going to come up with a business case which demonstrates there are more benefits than costs and risk and dis-benefits. So all of that is recorded in your business case. Now the second document that we think about, is the benefits measurement approach. And of course being further along to the front of the alphabet, there it's A.1. So if you wanted to find out more, you go and have a look there. But if we take a look at it, sort of very high level, just the purpose, which is what we need for foundation, this is where we define the benefits management actions, and benefits reviews that will take place. Either during the project and most usually, once the project has closed. So, what benefits we are going to measure, who's going to measure them, what resources do they need, when are they going to do it? Those are the kind of things that will go in the benefits management approach. So we've got the business case, which is more about the justification for the project, but we also have the benefits management approach, which is thinking about mainly when the project is closed. You know, who has got to do what, in order to prove that this project was a success, and that we actually achieved the benefits that we hoped to achieve. And so, that completes the business case theme, and this is the end of this module.
About the Author
A hard working, self-motivated and dedicated IT Consultant with extensive experience and a proven track record in the areas of Management, Networking, Communications and Security. A capable organiser, quick to grasp and make good use of new ideas and concepts. Reliable and conscientious in all work aspects. Possesses exceptional interpersonal skills and utilises communicative abilities to build, develop and maintain effective relationships. A motivational and inspirational manager, who enjoys being part of a successful and productive team, and thrives in highly pressurised and challenging working environments.