Introduction to Themes

6. Organisation Part 3

But one must be very careful not to trim below the minimum, otherwise you will cease to be a principal project. So what are the minimum requirements for the organisation theme? We find these on page 62 of the Principal Guide. The minimum requirements are that the project must define its organisation structure in roles. This must ensure that all of the responsibilities and Prince Two's role descriptions are fulfilled. Princeton's Defined Roles and Responsibilities Principledocuments the rules for delegating changeauthority responsibilities if required. define its approach to communicating and engaging with stakeholders. principally requires the two products be produced and maintained by the organization's team. In the context of the organisation, this provides a single source of reference on how the project is to be managed. The Pit sets out the project management team structure and roles. Communication Management Approach: This describes the means and frequency of communication to stakeholders, both internal and external to the project. Both of these products should be created using the 'Initiating a project' method. Please study Figure Seven-Three Prince Two's Project Management Team Roles in the Principalguide for roles, authorities, and responsibilities. The roles are essential, but that does not mean that a separate person will fill each role. Some roles may be combined and others may be filled by several people on large projects. The big exception to this is that there must only be one executive and one project manager. And a reminder that on the project board, the senior user and senior supplier advise the executive. But the executive is the final decision maker.The executive is appointed by corporate programme management or the customer. The executive is then responsible for selecting and appointing all the other members of the project management team. The existential role is a senior user who represents the people who will use the products to realise the benefits. This could be more than one person, but you will find that increasing the number of people on a board can greatly reduce efficiency and slow down the decision making.The senior supplier, who represents the expert who will actually create the products, is at the same level as the senior user. And in many cases, the specialists who create the products will be the same people who will maintain them. Once you're in production again, it is advisable to keep senior suppliers to a minimum. However, for both the senior user and senior supplier, some members may be warranted if the project represents different departments or different areas of specialism respectively. And so you need to get those extra few points in there. Now we come to project assurance. This is an extra responsibility of the project board. The members of the project board sometimes perform project assurance duties on smaller projects if they have the time and if they have the skills. But for larger project assurance, larger project assurance duties are usually delegated to others. But please note that the project manager cannot perform a project assurance role if that would be a conflict of interest. Then we have the change authority. As with Project Assurance, change authority is again a responsibility of the project board. The board may authorise requests for changes to all specifications directly on small projects. But in larger projects, change authority is usually delegated to others. However, and please remember this for the exam, the project board must decide if they will be the change authority or whether it will be delegated to team members and document the appropriate role descriptions before moving out of the project initiation stage. Please read chapter eleven for more information on this. Next is the project manager, and this one takes a little bit of extra study if you're ambitious too, because unlike some other methodologies, the project manager role carries a little less power. As with the nonprinting projects, the project manager is a single responsible person authorised to perform the DayToday project management. The project board authorises project management to the project manager one management stage at a time, and the project manager is given stage tolerances to manage within. If the tolerance is forecast to be exceeded, the project manager must report to the project board for advice. Under normal circumstances, where we're still within tolerances, the project manager will in turnmanage the team managers and project supportand liaison with project insurance. On small projects, the project manager may also perform the duties of the team managers and the project manager, but never project assurance, because that must always be independent of the project manager. Two important points to remember for the examare that the project manager was responsible for all the work in the principal processes except for directing a project process and appointing the executive and project manager, and the pre-projectprocesses of starting up the project. And the second point is that the project manager will most likely come from the same organisation as his commission in the project. I. E. The same one as a corporate project management or customer organization. For most of my career, I was provided by the supplier organization, and this type of relationship is discussed in sections seven, three, and four. Section 7218 covers the team managers. They report to the project manager and receive work from the project manager in the form of work packages. A very important note for the examination is that if the team manager works for a supplier organisation that is different from the commission organization, then the project manager may have to communicate with the team managers through the team manager's line manager. And as I've mentioned before, the positioning of team managers at the bottom of the project hierarchy does not imply a lower seniority. In fact, within the commission organisation, the team managers may be more senior than the project manager. Lastly, we come to project support, which is really an administrative function to assist the project manager, such as updating schedules and reports, document control, that sort of thing, and project support can also administer change control just the day to-day work. Please note that all of the above rules are required in a principal project team. But as I said before, one person may perform several roles. And I have mentioned too that the rules which can't be combined with section 72110 for a submarine. Be careful of confusing jobs with roles. For example, a team manager on your project might actually have the title "project manager." But that doesn't mean your project isn't important to project managers. It's just that person has the title "Project Manager." In the larger organization, the project manager is responsible for documenting the communication management approach for communications both internal and external to the project. Also, Pinstripe recommends reviewing the approach at each stage boundary. Please read and do your best to memorise table seven, one on page 68, for details of organisational responsibilities. This is one of the key tables to knowing you.

7. Theme No 3 Quality, Part 1

Quality theme. The purpose of the quality theme is to define and implement the means by which the project will verify that the products are fit for purpose. That's the principal guide, on page 78. Fit for Purpose means that products meet business expectations and enable the desired benefits to be achieved. I've noticed that some study guides state that the desired benefits will be achieved after the project is completed. However, that is just part of the story of the exam. You'll be expected to know that while benefits are usually achieved sometime after the project has ended, products may be created throughout the project, so benefits may actually be achieved while the project is still being managed. The quality management team is based on the ISO, which is the International Organization for Standardization 9000 QMS Quality Management System series. This is a generic set of standards, which means that they do not relate to any specific products, services, or outputs, nor to any geographic location, and apply only to the processes for creating the products, services, or outputs. And this generic nature makes it ideal for working with quinto, which is a generic method. According to ISO 8400 and 296 quality management and quality assurance vocabulary standards, which is quite a mouthful. Quality is the totality of features and characteristics of a product or service that bears on its ability to satisfy stated or implied needs. According to the ISO 9010-2000 International Quality Standards and Guidelines for Quality Management Systems, quality is the degree to which an inherent existing characteristic meets requirements. And from the above, the totality of features and characteristics, or set of inherentexisting characteristics, refers to our project scope. The scope of the project is a list of all the products that the project will deliver. The glossary says, and I'll just remind you here, please read the glossary off and have a read two or three glossary items a day if you don't get the hang of it. The glossary says for a plan, the sum total of its products and the extent of its requirements. It is described by the product breakdown structure for the plan and associated product descriptions. The product breakdown structure, often referred to as aPBS, which is a hierarchical chart showing all the products and subproducts that make up the scope, applies the principal principle of focus on products. People tend to think in pictures, and so the PVs enable one to visualize, understand, and produce the entire scope. Let's stop and think about the word quality because the meaning of quality in quality management is different from its everyday meaning. For example, let's consider something that everyone is familiar with a cheeseburger.You decide to have a cheeseburger for lunch, and you have the choice of a four-dollar fast food cheeseburger or a $95 hamburger à la chic at the French restaurant. Which one do you think would be of higher quality? Using the everyday meaning of quality, you would be thinking in terms of grade, i.e., better or worse. For example, better quality meat, bigger portions, better presentations and so on. But in quality management, quality refers to conformance to specifications and not to the grid. But let's think about the four-dollar fast food cheeseburger. Again, they make patties or mass produced, they're stamped out like coins on a sheet, and so they'd be virtually identical in every way. The buns will be mass-produced and virtually identical too, and so will the square cheese slices. Then the burgers are cooked at a fixed temperature, cooked for a fixed time according to an aprinted specification, which the cooks have to follow. And so, if I were to buy a cheeseburger every day,it would be exactly the same product day after day. This means it conforms to the specification or scope, and that, by definition, the four-dollar burger is high quality. But in a French restaurant, however, there could be considerable variation because chefs tend to estimate rather than weigh or measure. And that is why when you order a meal at a restaurant and the person next to you orders the same meal, theirs is always twice the size of yours. And chefs tend to add a pinch of this and a spring of that to the mix, just as I feel on the day that a bunch of baked goods are in the restaurant and various sizes and weights add to their charm and their cost. And the cheese slices are handcuffed, and the chef might use a different type of cheese from day to day. And see, if you were to buy a burger from a French restaurant or a burger from Mao Chic every day, it could be a different one every day. This means it does not conform closely to specifications, and that's by definition, an expensive burger is low quality. As a result, a four-dollar fast-food cheeseburger can be of higher quality than a $95 fence restaurant cheeseburger. But this scenario highlights another important point about quality. Low quality is always a problem. Low grade may not be If I eat a four-dollar burger, it will be of much lower quality than the $95 one, or so I hope. But it is quick, easy, and cheap, so people know what they're getting and millions of people are perfectly happy with it. So the grade is not a problem. But if the four-dollar burger is smaller than advertised, or raw in the middle, or the cheese slice is missing, then the burger is low quality, and that is an issue. One final point. I said that the four-dollar burger conformed to specification. I did not say that it matches the store advertisement poster, as the two are clearly unrelated. As we have seen with the word quality, the meaning of some words and phrases in Prince Two can be different from their everyday meanings. And this can lead to significant misunderstandings. When using the Pinstripe guide, it is very important to get into the habit of reading the glossary, which starts on page 370, because not only will you find the meaning of lots of words that you don't understand, but you will also find the meaning of words that you think you understand. But Princeton has a different and special meaning for them, which may be different from my everyday meaning,such as we've just seen with the word quality,and different enough to make a difference in passing or failing a particular question on the exam. But sometimes you have to dig a bit deeper. For example, the word product in the glossary means an input or output, whether tangible or intangible, that can be described in advance, created and tested. Prince Two has two types of products: management products and specialist products. Our project will deliver specialist products for the business to use, and sometimes we think of a product as something you would build or buy in a store. And often, products are exactly that: tangible, physical goods. But it also said that products can be intangible. And so, to get a fuller picture of the products, take a look at quality and the glossary. Because quality deals with producing products that are fit for purpose, the degree to which a set of inherentcharacteristics of a product, service, process, person,organization, system, or resource fulfils requirements is called quality. We see then that a product can actually be a service, a process, a person, organization, system, or resource. Quality implementation on a project takes time, mary, and resources. However, a properly implemented quality system will save much more than the cost, maybe through reducing rework, but also through protecting reputation, gaining future sales and so on. You need enough quality, but not too much,because some people seem to make a career of designing and applying needless quality procedures. For example, when specifying product acceptance criteria, using terms such as will operate on any device, user-friendly, intuitive to operate, attractive, and smart are just asking for trouble. Avoid open-ended criteria and stage useattributes that can be measured.

8. Theme No 3 Quality, Part 2

And fit for purpose in this definition reminds us that products are actually made to be used, and it's only by using the products that the benefits can be achieved. I also talked about higher quality means of conformance to scope rather than implying agrade, and I reinforced the importance of checking the meaning of words and phrases. In the Princeton glossary, I've just mentioned the scopeand, so we can have a look at the theglossary to see what it says about it. The scope for a plan is the sum total of the products and the extent of the requirements. It is described by the product breakdown structure for the plan and associated product descriptions. By defining the scope, it is normal to include scope tolerances. Again, we check this in the glossary scopetolerance the permissible deviation and the plan scope that is allowed before the deviation needs to be escalated to the next level of management. The scope tolerance is documented in the respective plan in the form of a note or reference to the product breakdown structure for that plan. C tolerance The quality management system (QMS) is a comprehensive set of quality standards, procedures, and responsibilities for an organisation or entire entity, site, business unit, and so on. Sites and business units are permanent or ongoing organisations within that organization, as opposed to projects, which are temporary organisations within that organization. But all of these will need to adopt the overarching QMS quality management system of the main organization. In the case of a project, there may be a quality management system, especially for programme management, in which case your project will work within that. Two terms that confuse many people are "quality assurance" and "quality control." In everyday language, they're often used interchangeably, and yet they're quite different. For example, if you work in information technology, you'll often hear people, such as programmers, saying they're que in their work, which is short for performing quality assurance when they're testing it. But testing is something which is part of quality control, not quality assurance. The difference is that quality assurance is a management function. It's concerned with putting plans in place to ensure that products will be made better fit for purpose. But quality control is largely concerned with checking to see if the products have been made correctly. Therefore, if someone is carrying out any form of testing, they are in fact carrying out quality control, not quality assurance. So any form of testing aimed at measuring is quality control. The actual quality management techniques to be used are outside the scope of the principal method. The principal requires systematic activities to explicitly agree on the customer's quality expectations and acceptance criteria for the product Determine the project's products. eitherlevel at which the project intends to extract The project products and product descriptions include the quality criteria to which they will be assessed, the quality method to be used in designing, developing, and improving them, and the quality responsibilities for those involved. Implement and track the quality metrics employed throughout the project. Note that the first three points are covered by quality planning, and the fourth one by quality control, is that one involves checking whether the customer's quality expectations will be captured in the project product descriptions. And that brings us to the customer's acceptance criteria. Acceptance criteria is defined as a prioritised list of criteria that the project product must meet before the customer will accept it. measurable definitions of the attributes required for the set of products to be acceptable to key stakeholders. But what does acceptance criteria actually mean? When I'm managing a project, I find it quite difficult to get users to finally signoff on products, and the reason for that is that they are afraid of missing problems during the testing procedure and then formally accepting the product that has faults which will be discovered later, and they should be worried about getting into trouble. For them to overcome that, you need to make it really easy for the customer. The process of checking the end products is called UserAcceptance Testing, and the best way to perform this, I find, is to take the scope of the product and make a step-by-step test plan. The plan should describe a test that is as simple as possible. Push a button, turn a key, then describe, with as many pictures as possible, exactly what should happen. A web page appears which looks just like this picture, and if the test is successful,users should mark it with a tick. Otherwise, nothing would actually happen. So it can be fixed. If at the end of a full test sequence,all of the boxes have been ticked as complete,then the user can sign formal acceptance. This removes much of the fear of rejection. We know that we must tailor each theme to avoid needless bureaucracy and the load on the team. However, one of the minimum requirements for quality, as stated on pages 82 and 81 of thePrincipal Guide, is that a project define its quality management approach. This approach must minimally cover the project's approach to quality control. The Project's Approach to Project Assurance The management of quality is communicated throughout the project lifecycle. The roles and responsibilities for quality management prints to be used The DefinedRoles and Responsibilities principle specifies exclusive quality criteria for products in product descriptions that revolve around their product focus. maintain records to provide evidence that quality activities have been carried out and summarise those activities that are planned or have taken place in some form of quality. Register specify the customer's quality expectations and prioritised acceptance criteria for the project in the project product description. Appendix A, Section A 00:21: use lessons to inform quality planning, the definition of quality expectations and quality criteria Two's Principle of Learning from Experience Two products are produced and maintained by Prince Two. A Quality Management Approach A quality management approach describes how quality will be managed on the project. This includes the specific processes, procedures, techniques, standards, and responsibilities to be applied. The Quality Register is used to summarise all the quality management activities that are planned or have taken place and provides information for the end stage reports and the end project reports. Refer to Appendix A, Sections 822 and 823 for more details about the suggested contact for these management products, and just a reminder that the outline descriptions of all products can be found in Appendix.

9. Theme No 4 Plans

The where and how, by whom and estimating the when and how much definition of a plan is a detailed proposal for doing or achieving something which specifies the what, why, how and by whom it will be achieved. In Princeton, there are only the following types of plans: project plan, stageplan, team plan, and exception. Plan plans provide the backbone of the management information required for any project. Without a plan, there can be no control. Many people think of a plan as just being a chart showing time scales. Two takes both a more comprehensive and a more flexible view of plans. A principal plan must describe not only the time scales but also what will be delivered, how and by whom. Permanent planned projects cause frustration, waste, and rework. It is therefore essential to allocate sufficient time for planning to take place. A plan enables the project team to understand what products need to be delivered and the risks, both opportunities and threats. Any issues with the definition of scope within which people, specialist equipment, and resources are needed when activities and events should happen, whether targets for time, cost, quality,scope, benefits, and risk are available. A plan provides a baseline against which progress can be measured and is the basis for securing support for the project, agreeing on the scope, and gaining commitment to provide the required resources. In the early days of project management, the belief was that a project could be planned in detail right from the very start. So a scope statement would be written in detail and then it would be set in concrete. And the project manager, by Maidensfer or Foul,would directly deliver the scope as close to the original deadline as was humanly possible or as close as inhumanly possible. Because project managers were seen as monsters who bullied people and didn't listen to the client. But the problem with that approach is that projects tend to be a learning experience for all concerned, especially the customer. And the customer would be disappointed as a product that they had described and even signed off on gradually took shape but was not at all what they had envisioned. But the only reason they had skipped it in detail at the start of the project and signed off was because they were effectively bullied into it. But not only is a project a learning experience, but in many ways, it is like a research project. It is only as the product develops that the customer begins to realise what they want. That is why Prince Two breaks a project into stages. Then you can work within your planning horizon, which means you can work only as far as you can see ahead. Clearly, this is efficient because if you try to plan beyond your planning horizon, you will simply have to redo the work later. As well as having detailed plans for each stage, two also require high-level plans to keep you heading in the right direction. Both the high-level plan and detailed plans need to be maintained in parallel. On page 95 of the Principal Guide, the two levels of a project plan for the project as a whole. This will usually be high-level planning, providing indicative time skills, milestones, cost and resource requirements based on estimates. A detailed plan for the current management stage aligned with the overall project plan time skills must be produced before the start of that stage and must not extend beyond the planning horizon. principally uses product-based planning. As you can see with the focus on products, the products are identified and described before the activities and resources to produce them have been defined as usual. The generic nature of the principle means that it is not prescriptive when it comes to specific details of reports. However, chapter Nine Three of the Principal Guide provides guidance for effective planning, and chapter Nine Four suggests techniques for prioritisation estimation and scheduling. Figure Nine shows how PrinceTwo's plans relate to each other. Appendix A Prince Two guide is where you will find a single product for all plans. The initiation stage plan is shown on its own because it exists before the project plan is created. In fact, it's created before we even know whether or not we're going to initiate a project. Then, once the project has been initiated,you can see a clear hierarchy. The subsequent stage plans are derived from the project plan, then the team plans to derive from the stage plans. If the stage is forecast to exceed the tolerances, then a project manager will be required to produce an exception plan, which in most cases is a revised stage plan. But in extreme circumstances, the project manager may be asked to develop an exception plan for the entire project project.Please take time to study Chapter nine because it has many examples of reports and techniques which you may be able to use in your own projects and may well appear in the exam.

10. Theme No 5 Risk Part 1

But first we must answer the question, what is a risk? The Prince Two guide defines risk as an uncertain event or set of events that, should they occur,will have an effect on the achievement of objectives. A risk is measured by a combination of the probability of a perceived threat or opportunity occurring and the magnitude of its impact on objectives. Business as usual is routine and relatively predictable. There are risks, of course, in everyday work. But because of the regularity of process work, many of the risks have been foreseen or encountered before, and so there are already management strategies in place for most things that can happen. Projects, on the other hand, usually involve an organisation taking on familiar steps with staff performing unfamiliar duties. And so there's a distinct element of uncertainty. It is unacceptable to simply wait for risks to occur as if everything is beyond our control. Think of the everyday situation, for example. On an overcast day, there is a risk of rain but you really want to go for a walk. You could simply go out and accept the risk that you make it wet. Or you could take an umbrella to reduce the likelihood of getting wet. And even if it's not 100% effective, especially on a windy day, it will reduce the impact of the rain on you. If you don't want to carry an umbrella, you could plan a route where there are many places that you can shelter from time to time. Or you may just avoid the risk completely by staying indoors. When people in an organisation talk about risk, almost 100%of the time, what they're actually talking about are negativerisks or threats to things they are trying to avoid. And so it may seem that they're unaware of positive risks. The truth is that they are aware, it's just that they call them opportunities instead. I think it is because almost everyone thinks of disasters when they hear the word risk. So therefore, if it's positive, they have to have another word for it. In this video, when I mention risk, I mean threats. Unless I tell you otherwise. The next question to answer is: what is at risk? But now you should be able to remember the six variables on any project, whatever they are. That's correct. It would be really nice if there were seven, because there are seven principles,seven themes, and seven processes. But we just have six. So six to work with. And just in case you couldn't remember what they are but you should do, they are cost, time, quality, scope, benefits, and risk. And so, any project objectives related to these are at risk. Now we need to think about what we are going to do to manage risk on the project. And once again, we look to the principal guide for a definition of risk management. It is the systematic application of principles, approaches, and processes to the task of identifying and assessing risks, planning and implementing risk responses, and communicating risk management activities to stakeholders as we see. This is mainly a four-step process. One is to identify the risks. This means trying to think of all the things that could go wrong to assess risks. Now that you know what could go wrong, you want to try and estimate how likely they are to happen and, if so, their impact on the achievement of objectives and how much damage they will cause if they happen. Number three, plan risk responses, which means deciding what you're going to do to reduce the likelihood that the risks will occur and reduce the impact if they do happen. Four implement risk responses. And please note that this is not a one-off activity. You need to repeat these cycles a number of times throughout your project and throughout the process. You need to make sure your stakeholders are kept in the loop about the risks and issues. It's important to note that while you can do a lot to reduce the risks in your project and a lot to reduce the impact, you can never remove all risks. Prince Two's Requirements for Risk Management As usual,we need to know what Prince Two expects as a minimum from a risk management system. We find it in section ten, two on page 121. To be followed by Prince Two, a project must, at a minimum, define its risk managementapproach, which must minimally cover how risks are identified and assessed, how risk management responses are planned and implemented, and how the management of risk is communicated throughout the project lifecycle. assessing whether identified risks might have a material impact on the businessjustification of the project, which is Princeton's continued business justification principle. Roles and Responsibilities for Risk Management Principals Responsibilities and Roles In principle, they intend some form of risk register to record and identify risks and decisions relating to their analysis, management, and review. Ensure that project risks are identified, assessed,managed and reviewed throughout the project lifecycle. Use lessons to learn to identify and manage information risks. Princeton is learning from experience. Princeton requires the products to be produced and maintained. The Risk Management Approach describes how risk will be managed on the project. This includes the specific processes, procedures, techniques, standards, and responsibilities to be applied. This provides a record of identified risks related to the project, including their status and history, and is useful to capture and maintain information on all the identified threats and opportunities related to the project. Both of these products should be created during the initialising of a project process. The risk management approach should be reviewed and possibly updated at the end of each management stage. The risk management approach will define how and when the risk register is reviewed and updated. Appendix A, sections 824 and 825, provides product descriptions and suggested content for these products. Print Two recommends an approach to risk management based on the management of risk. Guidance for practitioners Office of Government Commerce, 2010. But please note that while it's important to read the book, And you should understand that you do not need to know this book for the exam. Everything that you need to know for the exam and risk management is contained in the principle guide and on the scores.

ExamSnap's PRINCE2 PRINCE2-Foundation Practice Test Questions and Exam Dumps, study guide, and video training course are complicated in premium bundle. The Exam Updated are monitored by Industry Leading IT Trainers with over 15 years of experience, PRINCE2 PRINCE2-Foundation Exam Dumps and Practice Test Questions cover all the Exam Objectives to make sure you pass your exam easily.