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 Nine, Part Three. We are finishing off the Plans theme. We are going to be looking at product-based planning. Product-based planning is a technique that is recommended by PRINCE2 to help you with the planning process. It's all about identifying products that we need to make in our plan. And they recommend four steps in the product-based planning, and the first one is that we start with our project product descriptions, so we need to write it down. What is the project product going to be? What quality is required? We're going to go to the customer and ask them what their customer quality expectations are, and then we're going to pin them down to measurable acceptance criteria. So we've for that project product description ready telling us what the quality is, and how it's gonna be tested, and who's going to approve it, and all of that ready. So we'll only need to do that once, Then we will for each project plan or stage plan that we need to make, we need to go through the next steps. So step one, we have our project product description. Step two, we need to make a product breakdown structure. So we're going to think about the products that need to be created in that plan. And this is a bit of a brainstorm. Could be a mind map actually that we produce. It could have a workshop where we get people to put Post-In notes up on the wall and to brainstorm what products need to be created or obtained to help create the products in the plan. So I'm gonna show you an example of this in a moment, but that's stage two or step two in the product-based planning technique. Step three is to think about the products then that we have to make and write product descriptions for them. So we need to write maybe many, maybe hundred of product descriptions depending on how complex the plan is and how many products we need to create. We will certainly need to make, for the project plan, product descriptions for the major products, the main component parts. Then last step, we need to think about the sequence of events, so which products need to be made first so that we make other products later, and what products are the last products that need to be made? So we need to have a flow diagram explaining what products need to be made in what order. And that clearly will then help us finalise a plan. So those are our four steps. A project product description which we will only need to create once for the project plan, and then making a breakdown structure, product descriptions, and flow diagrams for every other plan that we make, as well as the project plan. I'd like to show you some examples of the product breakdown structure and the product flow diagram. Don't get too bogged down with these because they're not going to be heavily examined in the foundation exam, but they are just useful to show you. You will need to know the different steps in the process, the four steps that we showed on the previous slide. You won't be asked in depth about what goes into a diagram. However, there are some useful tips that I would like to get across at this point. So we want to create a product breakdown structure and it may look a bit like this one. I have taken this out of the Appendix D in the PRINCE2 Manual, so if you have a look at the back of the book, find Appendix D, you'll see this diagram, Figure D.2. Now, this is a conference, and it's a breakdown structure of all the products that are in scope for that project. And you will see at the top there, we have the project product which is the conference, and they clearly have had some kind of brainstorm, potentially this is what we've got after putting Post-In notes on the wall or something similar. We have group headings. Who knows who came up with those, they're just probably what seemed convenient at the time. You may well have grouped this differently. And we are showing then the internal products, the products that are within scope for this project. So these are the products that we will need to make. These will be work packages, and each of these products will need a product description. We also display external products, the products that we are using to make our products, our internal products. So external products are those that already exist or are being made or created by groups outside of our projects, they are out of our control. But we need them because we are using them to make our products. So these are usually displayed, if you're drawing a breakdown structure like this, in a circle or a lozenge shape. And it's really useful if you're going to have this kind of activity to get a number of people in the room with you to help you. I always found it very useful bringing the longest-serving member of IT support because they knew things just in their heads that no one else knew, and they would say, "Oh my gosh, you don't need to make that. "I've got something like that in a cupboard over there." Or, "Don't forget to work on this system "because don't you know there's been a change?" And we go, "Oh, right, okay," and adapt our breakdown structure accordingly. So it's a really useful technique if you're going to use it. The flow diagram is where we reorganise all these products into the sequence of events, and what we have here is the same project, it's the same conference but rearranged. We got the same products in there. Look at the bottom, this is our project product, the conference, so that will be the final thing. Finished everything, ta-da, here's our conference, let's go. Hope you get a free lunch, yeah. Let's have a look at some of the items within this flow diagram. We looked at some internal products on the breakdown structure, here they are again up there in the flow diagram. You can see we've also got the same products, but the same numbering, and we have a sequence of events implied here with those particular products. Some of these products can be made in a series like this. Some of them in parallel, but we need to have an idea about which products come first and that's what this flow diagram is all about. Now, the external products that I pointed out, I've also pointed out here. So I pointed them out of the breakdown structure, and here they are in the flow diagram. They often trigger things for us, so they're often the starting point. So we can't really do very much about our materials for this project until we get the previous materials. And we really can't start booking venues and speakers until we know what the subject is and the date. So those external products often trigger or allow us to create our internal products. So this again is a very useful activity to carry out. And if you are in a room with a wall full of Post-It notes, you just rearrange the Post-It notes. And I recommend you take photos if you're doing this so that you can go back to things if you liked a different order, or certainly if you leave the room for a day and come back, you don't want the cleaners knocking things off the walls, so photos are always good things to do at this point. So I actually think that this product-based planning technique is quite useful, and if we go back to that slide that I showed you before, these four steps then, we write that project product description, and we create that breakdown structure, and the fourth step at the bottom, the flow diagram. They've suggested we write product descriptions in the middle, but in fact in reality, it's a little bit more flexible than that, and even the PRINCE2 Manual will accept that. So you might do this in a slightly different order, that's fine, as long as for a foundation exam, you remember that there are four parts to the product-based planning technique and what they are. Now, one thing to note about this product-based planning technique is that we are just identifying products. There was nothing in the breakdown structure, nothing in the flow diagram to tell us how long it was going to take, or how much it was going to cost, or what was resources we needed exactly. These are not plans that we've made here, these are just brainstorms, and flow diagrams, and product descriptions that will help us write the plan. And if I take you even further back to the very first slide that we looked at in Part One, if you think about our planning approach, the product-based planning technique is really only looking at step two here, defining and analysing the products. So what we're doing here is identifying the products, what's in scope, what's not in scope? And then we can identify the activities, and prepare estimates, and put it in a nice, pretty schedule, And then you document it properly with headers and footers in a nice binder. So product-based planning is just to help us with step two to identify what's in scope, what's not in scope, what sort of products do we need to create? And so there you go, that's the Plans theme complete. Thank you for your time.
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.