Student Feedback
PRINCE2-Practitioner: PRINCE2 Practitioner Certification Video Training Course Outline
Introduction
Projects, Project Manager and pr...
Introduction to Principles
Tailoring and Adopting PRINCE2
Introduction to Themes
Introduction to Processes
Recertification changes for PRIN...
The PRINCE2 Glossary
What are the changes for PRINCE2...
Introduction
PRINCE2-Practitioner: PRINCE2 Practitioner Certification Video Training Course Info
Gain in-depth knowledge for passing your exam with Exam-Labs PRINCE2-Practitioner: PRINCE2 Practitioner certification video training course. The most trusted and reliable name for studying and passing with VCE files which include PRINCE2 PRINCE2-Practitioner practice test questions and answers, study guide and exam practice test questions. Unlike any other PRINCE2-Practitioner: PRINCE2 Practitioner video training course for your certification exam.
Introduction to Principles
3. Principle 2 Learn from experience V2
Principal. Number two, learn from experience. All projects attract significant risks, and these risks must be carefully managed. Otherwise, the project will not deliver all of the benefits. Often, these risks come from a lack of knowledge or experience on the team because projects are temporary and usually involve staff doing different duties from what they're normally doing. As projects are managed by an organization, the lessons learned should be recorded routinely by everyone on the project. Notice the project manager. And so, when a new project is started, this collection of knowledge from previous projects should be examined. The process is called capturing lessons learned. And that one used to confuse me. So listen carefully. Capturing lessons learned doesn't mean recording new lessons; it means looking at the old lessons from previous projects to see how you can help this project. Let's capture lessons all around. These lessons exist only because people made an effort to record them. And so on your project, make sure that everyone records important lessons right throughout the project and makes sure that they're filed securely and are easily retrievable. Otherwise, there'll be no benefit to you at all. Otherwise, learning from experience or through the use of external resources, such as including subject matter experts on the team and sending staff and staff training courses, is preferable. These can be particularly useful if the project involves products that are new to the organization. and so there would be few lessons learned. Even if the project fails, and this is very important, the lessons must be recorded. In fact, they may even have valuable clues as to why the project failed. In fact, this is so important. I will end with an actual example of what happened to me. Some years ago, I was called in to take over a project in Australia, and the project was failing. I asked the team for the lessons learned, but they didn't have any. I asked them why they thought the project was failing. They couldn't tell me. And I asked questions like, "Have you got a feeling for something that might have influenced the project's feel?" And they were telling me things like the customer's project team is unfriendly. They complain about everything we do, and they complain about everything we send them. Then someone told me that the project had failed before. The project manager had left a couple of days ago, but I was able to get his contact details and give him a phone call. He didn't know why the project had failed when he managed it. I asked him a number of details about the project, but he didn't seem to understand what I was talking about. I asked him if he had any feelings as to why it might fail, and they said, "Well, the customer's team were very unfriendly." That didn't help. And they complained about everything that he did and everything that he sent them, which is remarkably similar to what I was hearing from the current project. Then he dropped the bombshell. He told me that the project had failed once before he had managed it. So that means this is actually the third attempt at the same project, not the second. There is a very appropriate old saying: If we do not learn from history, then we are doomed to repeat it. However, the project manager said that he actually used to keep handwritten notes of problems he faced on the project. Thank you. He said he had left the book in the store room when he left the company. So to cut a long story short, I had a search done in the storeroom, and I found a notebook inside a box of Christmas decorations. And I read it, and that gave me some clues. Then I had a meeting with the customer's project team, just to check that I was right. And it was because I realised that the previous two so-called project managers were not actually trained in project management, but the customer's project manager was trained.So they were, in effect, speaking two different languages. The customer was asking for standard project reports and information, but the project managers from my company had no idea what was being asked for. And they were sending them bullet-point lists of what they're doing, emails, and a couple of what they thought were useful diagrams. And they didn't even have a project schedule for checking where the project was at.So with these basic lessons learned from a failed project—from a notebook and a box of Christmas decorations—I was able to see the way to make a plan to rescue the project. And I quickly gained the respect of the customer project team because we were not speaking the same language. And I'm very pleased to say that the project was put back on and completed successfully.
4. Principle No 3 Defined Roles and Responsibilities
Principle number three defines roles and responsibilities. In today's organizations, resources such as time, money, and, of course, people are frequently in short supply. and so there is always a lot of pressure to do more. with less projects. You usually cross functional.What does that mean to an organization? Functions, which are often called silos, are operational areas such as the sales area, marketing, production, human resources, distribution, and so on. And your team will probably be made up of members drawn from various different functions around the organisation as well as maybe a few people from outside. Too often, you'll be moving these people away from the usual locations where they feel secure in terms of their workmates, whom I always talk with, and bringing them together with other people that maybe they don't know so well in a different environment. And the work that they do is different from the usual work. And the work that they expected to do may be so different that they feel insecure, and they may be afraid of failing. And also, they don't know who to talk to if they have a problem. Do they still talk to their usual line manager? Do they talk to the project manager? Do they talk to the project executive? All of these things can be very uncomfortable and stressful for both them and for you as a project manager. And in order to control the demand for these resources, you have to have a very clear picture of who does what on the project and what the lines of authority are. The best project can be ruined by team members not understanding their purpose or their responsibility or by not having effective lines of communication. Prince Two avoids much of his confusion by assigning dedicated project-based roles where the duties and responsibilities of each are clearly defined. Key roles include the executive to represent the business, a senior supplier to represent the specialists who will provide the expertise to create the products, and a senior user to represent the staff who will use the products and thereby realise the benefits. Other roles include produce manager, team manager, project support, project assurance, and others.
5. Principle No 4 Manage by stages
Principle number four, managed by stages A Pitch 2 project is divided into sequential sections known as management stages. And Prince Two defines a management stage as the section of a project that the project manager is managing on behalf of the project board at any one time. The project board will want to review the progress made thus far. the state of the project plan. the business case and the risks. and the next stage plan in order to decide whether to continue with the project. That's in Prince 2's guide. Page 23. In some organisations or bodies of workseem to go on and on forever. In fact, they're more like operations, and no one has a clear picture of where the project has gotten tight. In fact, sometimes no one is actually sure why the project was started or what it was intended to do. Prince Two gets around all these problems by dividing the project into logical stages. And the very first stage is called the initiation stage, and that makes sure that everything is documented, understood, agreed on, and authorised before the project even starts. And each project must consist of at least two stages. Please make a note of that, because thatcomes up in the examination quite a bit. It must have the initiation stage and one other management stage. Breaking the project into stages means that the project board gets to check the progress at the end of each stage and also decide if the project should continue. This is quite the reverse of a typical non-principal project, where there is an underlying assumption that, of course, the project will simply continue to the end on its own channels no matter what happens. The deciding factor for the project board hinges on whether or not the project is still likely to deliver the expected benefits. When the project board authorises the project to continue, they will also authorise the project manager to manage that stage. But the project manager is not given free rein to manage as they see fit. They are given tolerances that they have to keep within; otherwise, if a tolerance is forecast to be exceeded, they have to raise an exception report to the board. Managing by stages takes much of the burden off the project board, as they are generally required only at the end of each stage or to give ad hoc advice during the stage. The board should also consider whether they want to increase or decrease the degree of control they want over the project. And they do that simply by increasing or decreasing the number of stages, as we will cover in detail later.
6. Principle No 5 Manage by Exception
Principle number five, managed by exception each time, underlies every one of these principles. I think this is a really great principle. This is a fantastic idea, but this principal principle is particularly clever because, as I mentioned before, people are in very short supply in an organization, and that means that managers' and senior executives' time in particular is very valuable indeed. The manage by exception principle ensures that people are involved in a project only when it is essential for the success of the project. Corporate management selects a project board to control the project. The project board comprises managers to represent the interests of the three areas of the organization. I remember these by remembering the acronym. the business interest, which is represented by the executive. I will remind you that there can only be one executive on a project board because the executive, although advised by the rest of the board, is the single decision maker.So there can be only one you, the user interest, which is represented by the senior user or users, and the supplier interest, which is represented by the senior supplier or suppliers. When corporate management authorises the project board to manage a project, they set performance tolerances for six aspects of the project. These are very important. Please take the time to memorise them. They are cost, time, quality, scope, benefits, and risk. And each aspect will have an upper and lower tolerance limit set by corporate management. For example, they may say $1 million plus $200,000 or minus $100,000. For the project cost, They may say 215 days plus or minus 20 days for project time using the manage by exception principle. Corporate management leaves the board to manage the project under the guidance of the executive. Corporate management does not want to be disturbed during the project, and they've got much more important work to do. In fact, the only time they can be disturbed by the project board is when the project is forecast to exceed a lower or upper tolerance. When the tolerances are forecast to be exceeded, the project board will report to corporate management and ask for advice. If the tolerances are not exceeded, then the corporate management will not be disturbed. Okay, so now we have the project board managing the project within project tolerances. The project board, with the help of the project manager, will divide the project into a number of management stages, as we saw in principle number four, managed by stages. And at the beginning of each stage, the project board will set stage tolerances for that stage, then authorise the project manager to manage the stage. As I said before, corporate management will not be disturbed during the project unless project tolerances are forecast to be exceeded. Well, in exactly the same way, the project board will not be disturbed during the stage unless stage tolerances are forecast to be exceeded. If a stage tolerance is exceeded during the project management stage, then the project manager will report to the board and ask for advice. If the tolerances are not exceeded, then the project board will not be disturbed until the end of the stage. And that is so efficient. Think of a typical home-based principal project. What happens every week? A lot of senior managers have a project meeting and people report about things that worked, things that didn't work, and corrective actions taken, plus what holidays you're going to have and how the kids are doing in school. Do senior people need to be involved in all this trivia? No, of course not. It is largely a waste of time. But as we have seen, we have two levels of management now: corporate management and the project board managing by exception. But wait, there's more. During a management stage, the project manager will then determine which work packages or sub-deliverables are required to be created. During that stage, the project manager will assign those work packages to team managers. The project managers will also set tolerances for each work package, and they will set checkpoints as well, which we'll learn about later. So now we have corporate management who will not be disturbed during the project unless project tolerances are exceeded. The project board will not be disturbed during the stage unless stage tolerances are exceeded. And the project manager will not be disturbed during a work package unless work package tolerances are exceeded. I think that is so clever and an exceptionally efficient use of people's time. Let's have a look at a quick question on management by exception. Question. A management stage has an expected duration of 16 days, with a tolerance range of minus two days to plus four days. Because of a delay in a work package that is on the critical path, this stage is likely to be delayed by approximately three days. What should the project manager do? One, seek advice from corporate management on how to create an exceptional report. Three, make an entry in the risk register or do nothing because the stage is still within tolerance. If you don't know the correct answer, sometimes you can follow the advice of a fictional detective called Sherlock Holmes. He said, Once you eliminate the impossible, whatever remains, no matter how improbable, must be the truth. Okay, so let's apply his method to our list of suggested answers. In a Princeton project, a project manager should never contact corporate management about anything. Remember, a project board reports to them. So number one is wrong. Number two is wrong as well, because this stage is still within tolerance. Therefore, there's no exception to report. So that brings us down to three important, reasonable answers. However, when you think about it, although there's no exception, clearly something has gone wrong. And so the project manager can't just sit there and basically ignore it. which means number four is wrong too. And that brings us to number three. the only one left. Make an entry in the risk register as a correct answer. So even if you don't know the correct answer, all the other answers are wrong. But we still need to give it a final reasonable check. There is an issue causing the delay, and issues are connected with risks, and so it would seem reasonable to record the problem. And so, recording and keeping a risk register Again, that all seems to weigh up. So number three is our correct answer. This method can be useful for answering questions when you simply have no idea what the correct answer is. Look for answers that are clearly wrong and strike them out. If you can strike out two of them, then you'll have a 50% chance of getting the question right on a simple guess. If you can strike a trade, you've got it. You've got the right answer.
7. Principle No 6 Focus on Products
Principle number six focuses on products. One of the main dangers of managing a project is that everyone gets so focused on project management tools and techniques and charts and diagrams that they forget about the products. Yet without the products, you cannot deliver the benefits to the organization. It is a Princeton that ensures that the products remain the primary consideration throughout the project, and that every action taken must improve the ability to deliver the products. And that is why a product breakdown structure is used in the early part of planning. All of the outputs from the project collectively form the project scope, and when the activities required to deliver the scope are being estimated, they are determined by examining the necessary outputs. There are two types of products. As we can see from the principal guide on page 25, a product is an input or output, whether tangible or intangible, that can be described in advance, created, and tested print.In product management, there are two types of products: general products and specialist products.
8. Principle No 7 Tailor to suit the project
Principle number seven managed to suit the project. This Prince II principle of tailoring is arguably the most important principle because it is by tailoring that the Prince Two project remains universal or generic, which means it can be used in all types of projects in all industries, environments, cultures, and languages. However, it is vital to note that tailoring means adjusting the other 16 principles, not removing them, because unless the project is managed using all seven principles, it is simply not the principal project. As the principal guide says on page 26, PrinceTwo is tailored to suit the project environment, size, complexity, importance, team capability, and risk. And in page 27, the purpose of tailoring is to ensure that the project management method used is appropriate to the project, EIG. aligning the method with the business processes that may govern and support the project, such as human resources, finances, and procurement. Project controls are appropriate to the project scale, complexity, importance, team capability, and risk, e.g., the frequency and formality of the reports and reviews. The process is called tailoring because it is an analogy with how suitable clothing is adjusted by a tailored, fitted person. The tailor cuts off or adds pieces of cloth to legs and sleeves; they are likened or shortened, and so on. However, no item of clothing is removed. This is vitally important because, although you expect pieces of fabric to be missing, if the tailor returns the clothing to you with a principal piece of clothing missing, such as a jacket or trousers, clearly it is no longer a suit. Similarly, Prince 2 consists of seven principles, and while each principle must be tailored, if one is missing from your project, it is no longer a principal project because all seven principles are interconnected and interdependent. The goal of tailoring a principal project is to reduce the burden on the team as much as possible while still maintaining suitable governance and control so it can be tailored. According to the Princeton 2017 Guide, tailoring can be applied to processes, themes, roles, management products, and terminology. For example, on a small project, a project manager's role could be combined with project support and team manager roles, but they could not be combined with project assurance. For example, because of the obvious conflict of interest reasons, work packages could be emails and the project schedule could be a simple spreadsheet. On large projects, however, roles may be split, and the project identification documentation may be so large that creating that could be a separate project. All of the management products might have to be formally signed, and so on, as long as tailoring does not impact negatively on efficiency unless it's necessitated by government requirements or introduces conflicts of interest. Another common tailoring practise is to adapt the organization's existing project methodology to fit Prince 2. Another is to replace Prince 2 terminology with the organization's terminology. Sometimes this is done to help with buying within the organization. This is all perfectly okay. It's almost all seven principles that are used. And the key to tailoring is: if it already fits, stop tailoring. It's a project manager's responsibility to develop a tailored plan, working with key stakeholders and providing project assurance. This will then be submitted to the project board for their approval.
Pay a fraction of the cost to study with Exam-Labs PRINCE2-Practitioner: PRINCE2 Practitioner certification video training course. Passing the certification exams have never been easier. With the complete self-paced exam prep solution including PRINCE2-Practitioner: PRINCE2 Practitioner certification video training course, practice test questions and answers, exam practice test questions and study guide, you have nothing to worry about for your next certification exam.