Pass PRINCE2 PRINCE2-Foundation Exam in First Attempt Guaranteed!

All PRINCE2 PRINCE2-Foundation certification exam dumps, study guide, training courses are Prepared by industry experts. PrepAway's ETE files povide the PRINCE2-Foundation PRINCE2 Foundation practice test questions and answers & exam dumps, study guide and training courses help you study and pass hassle-free!

Introduction to Themes

11. Theme No 5 Risk Part 2

You will need to know these for the exam. As you may recall, when we studied the theme "three qualities," I said that a project is a temporary organisation within the main organization, and you will need to adopt the overarching 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. In a similar way, your project will need to adopt the overarching risk management system of the organization.

Or in the case of a project, there may be a risk management system specifically for programme management, in which case your project will work within that. In a previous video, Risk Management Part One, we saw that before identifying risks, you need to define the project's risk management approach, which must at least 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 business justification of the project Prince 2's continued business justifies the principles, roles, and responsibilities for risk management. Prince Two are defined as roles and responsibilities. Principle 2, page 121, you will also need to understand the organization's attitude toward risk, i.e., how much risk are they willing to bear? This is often called the "risk appetite." It's important to know this because one organisation may consider the risk of losing $1 million as acceptable, while a smaller organisation may view losing $10 million as a disaster.

This information should be added to the risk management approach. Then we come to the risk budget. It might be appropriate to identify and set aside an explicit risk budget within the project's budget. This is a sum of money to fund specific management responses to the project's threats and opportunities, i.e., to cover the cost of any contingency plans should a risk materialize. Doing this can prevent the risk manager from becoming a runner at Ram. But please note that the risk budget is a reserved portion of the main project budget and not a separate stash of cash outside it.

As I mentioned in the last video, if your organisation, programme, or customer has a risk management procedure, then you need to use that. You can use your own or use a risk management procedure that is based on the management of risk. Before we begin the risk management procedure, we must first identify the project context, which may include customer quality expectations, the number of organisations involved in the relationship between them, the needs of the stakeholders involved in the project, and, most importantly, the complexity and scale of the project.

The delivery approach being used, what assumptions have been made about the organization's own environment, e.g., Legislative or government requirements; corporate policies, standard processes, and procedures; or whether the project is part of a programme or corporate portfolio Step one is to identify the risks. Risks can and should be identified by anyone at any time during the project, but in this exercise, a number of stakeholders will get together in some form of brainstorming meeting before the project begins.

This has the added benefit that it may be one of the few times when you have a number of key stakeholders together at one time, which can lead to improvements in the overall project. As you identify each risk, you will need to immediately record the details in the risk register. Typically, you will record the "risk calls," which are situations or events that may trigger a risk. For example, team members working outdoors in high temperatures might be a risk event. This is the possibility that AG team members will suffer from dehydration or heat stroke.

The risk effect is the impact on project objectives that could occur if the risk occurs, such as project delays and medical treatment costs. However, as mentioned, Princeton is not prescriptive, and so you may recall this in a different way, such as by writing it in a single sentence.

It's been my experience, however, that when people record risk details in a single sentence, it simply becomes confusing. Step Two: Part one is to assess the probability of the risk of carrying and the likely impact if it does occur. Most organisations employ a probability metric to chart the products of likelihood versus impact, similar to figure 10-3 on page one to figure 10-3 on page two. However, the usual colours are green for low, orange for medium, and red for high, rather than three shades of one color.

But I think that's just to fit in with the colour scheme of the principal guide. You can use it as a three by three matrix, a four by four matrix, a five by five matrix, or whatever size suits the particular risks you're working with. Step Two: Part two is to evaluate the risk exposure, which is the combined effect of all the risks, to make sure that the project is still within the organization's risk appetite.

And if not, it's back to the drawing board so that you can maintain the principle of continued business justification. Note that risk appetite and risk exposure are different. Risk appetite is the amount of risk that your organisation is willing to accept, whereas risk exposure is the amount of risk that the project requires them to accept.

By providing a definition of risk tolerance, you may be able to persuade someone to take a little more risk. Risk tolerance is the ability to tolerate levels of risk exposure that can be exceeded but, if exceeded, will result in some type of response, such as reporting the situation to senior management for action.

12. Theme No 5 Risk Part 3

Risk responses are the part of risk management that most people get wrong. And I believe that is because they rely on the everyday meanings of the words, or maybe words from the background, etc. But by now you know that Prince 2 has a special meaning for many words and phrases. If you're familiar with the Pinball, a guide to the Project Management Board of Knowledge by PMI, then much of this will be familiar to you. But beware—there are some important differences between pinball and prints too.

I have identified and assessed the risks. I've entered them into the risk log. So now I need to do something about them. Note that so far, really what we've been talking about are the threats or pure risks, the negative side of the risks, and the treatment options you can choose from or avoid. Note that 90% of our students get this one wrong.

In the Pinbock guide, this treatment is the same. Avoid means removing the risk completely, usually by taking away the cause of the threat. This is usually achieved by removing part of the scope. Very important. If you apply this treatment and it still occurs, you have not avoided it. It has to be zero percent. For example, your project is to build three explosive manufacturing plants in the United States.

Location One and Location Two have been assessed as very safe locations. Location Three, however, is to be built in California, which is the unofficial earthquake capital of the US. No matter how you plan, the risk of an explosion remains high. So you avoid the risk by deciding not to build a plant in California. And therefore, with no plant, you have zero risk. The next treatment type is reduction. This means doing something to reduce the probability and/or impact of the risk. For example, the explosive that you're manufacturing will explode. If not, you can reduce the probability by having efficient air conditioning.

And you can reduce the impact by having many small machines producing small amounts of explosives rather than one large machine producing large quantities. The next step is to prepare contingency plans. This means preparing a plan to use in the event that a risk occurs but not taking any action until it does. According to the Pinball Guide, mitigating treatment is a combination of reducing and planning for contingencies. The risk transfer comes next. This is one that 60% of my students get wrong. That means attempting to give the risk to someone else. The most usual methods are outsourcing and insurance.

The reason I said "attempt" is that, say, for example, you're building an office as part of a project and the office is destroyed by fire. The insurance company will hopefully pay for the damage. But now you have to rebuild the office, and that could hold up your project. The trick to transferring is that the entity you transfer to must be outside the commissioning organization. Where my students usually get it wrong is when they say our team does not have the necessary skills for a major task. So we will transfer this risk to a more experienced team, or we can transfer this risk by employing an expert.

Both of these are wrong because an organisation is responsible for the work of all of its employees, so they still own these risks. The only way to transfer risk is to completely remove it from your organization. Next is sharing. The risk does not appear in the pinball guide except for opportunities, but it is where multiple parties share the risk.

And lastly, we have accepted risk. This is also true of the Pinball Guide. 90% of our students get this one wrong. Basically, when accepting the risk, you simply acknowledge that it can happen and record in a risk register that you're not going to take any further action until it does. Please note that you don't try to make up any other actions at the time, because it means that you're actually taking a reduced strategy.

And you can't make plans if the risk occurs because you'd be reusing a prepared contingent plan strategy. You simply record it, leave it, and walk away, and if the risk does happen, then and only then will you create a plan, which is usually called a workaround plan.

A workaround plan can't be made up in advance. Please review Table 10: Three Risk Responses on Page 123 of the Pins Two Guide, and you will see how the treatments are applied to opportunities in a very similar manner. But please remember to use the right amount of treatment—which is proportional to the risk and the amount at stake—so that you get value for your money. There's no point in spending $1,000 on a treatment that will only save you $10 if the risk occurs. And as mentioned earlier, you can never avoid all risks on a project. For example, occasionally one of my students will suggest we can avoid all risks in the project by outsourcing the whole thing. Firstly, this is a chance for treatment, not one to avoid. And secondly, if you could outsource the whole project, it would cost a lot more than doing it yourself, unless you've got your business case totally wrong. It is critical to ensure that the owner and executor are identified and agreed upon.

Trisk risk Owner: a named individual who is responsible for the management, monitoring, and control of all aspects of a particular risk assigned to them, including the implementation of the selected responses to address the threats or maximise the opportunities.

Risk Action A person assigned to carry out a risk response action or to serve as a bridge for back-and-forth communication should be constantly engaged. The communication step ensures that information related to the threats and opportunities faced by the project is communicated both within the project and externally to stakeholders. Risks are communicated as part of the following management products: checkpoint reports, highlight reports, end-stage reports, project reports, and exceptional reports. And please revise these reports to find out what they are and when they're used.

13. Theme No 6 Change Part 1

Any potential and approved changes to the project Baselines for projects always change. They are a learning experience, so there is a planning horizon to consider, i.e., you can see only so far ahead. However, as shown in Table 11-1 and on Page 138, there may be other reasons for changes. Look at what Prince 2 calls "changes and issues," which is confusing at times.

As it says in the principal manual, Prince Two uses the term "issue" to denote any relevant event that has occurred that was not planned and requires management action. Issues could also be raised at any time during the project by anyone with an interest in the project or site camps. Tipple eleven One identifies three types of issues. request for change Offspecification "Off specification" refers to something that was supposed to be delivered but was not, or was delivered but did not meet specification. For example, the scope might have specified brass fittings, but the fittings provided are just brass-plated arm problem or concern.This is anything that requires action from the project manager.

Once the issues have been identified and recorded, you will then need to follow a common systematic approach for Disneyworthy. Issue and change control is an activity that is performed throughout the project. Without it, the project will not deliver the benefits. When a change is to be made, it always needs to be considered against the baseline, which is like a snapshot of the current state of all management and specialist products. The paint, the project briefing, the business case, and all sorts of ways of controlling changes to the baseline products But if a name is given to the process of preventing unauthorised change, Prince 2 calls these things that need to be controlled and baselined.

Configuration item records contain information about the states and statuses of configuration items. See Appendix A, Section Eighteen, for an outline description. All the configuration item record definitions configuration item Record a record that describes the status, version, and variant of a configuration item and any details of important relationships between them. Page two of the guide, on page 139, is the next definition, which is very important. Many exam questions have stated that it will change control and obtain a project baseline. Project Status Account: a report on the status of products The required products can be specified by an identifier or the part of a project in which they were developed.

14. Theme No 6 Change Part 2

But at the same time, we must ensure that we still have a project that is compliant with prints too. And just to stick with the obvious, I hope we don't want to tailor down to the absolute minimum every time, because one reason is that it can actually take extra time and money to do that, but by tailoring to the absolute bare bones, we can also recite on some quite beneficial aspects of the principal framework. It's just that we need to draw a line in the sand and not cross it so that the Prince II project can continue. And so, in relation to the Prince Two Chains theme, a project must at minimum define its change control approach. This approach must minimally cover how issues are identified and managed.

Assessing whether identified issues might have a material impact on the business justification of the project Prince Two's continued business justification, principles, roles, and responsibilities for change control Prince Two's principles define roles and responsibilities, including a defined change authority. Define how product baselines are created, maintained, and controlled. Maintain some form of issue register to record identified issues and decisions relating to their analytical analysis, management, and review. Ensure that project issues are captured, examined, managed, and reviewed throughout the project lifecycle.

Use lessons to inform issue identification and management as principals learn from experience. Principle Two requires the following products to be manufactured and maintained. The register records and keeps track of all issues that have been formally managed. Approach to Change Control Specifies how and who will control and protect the project's products. The project's controls for issues and changes will be identified and established during the initiating a project process, then reviewed and, if necessary, updated toward the end of each management stage by managing a stage boundary process. That's the Prince 2 guide. Page 140, please.

Study table eleven for two responsibilities relevant to the change theme on page 141. Because you'll find it in the examination, they frequently ask questions about, basically, who is responsible for this and so on. Change Budget: the customer and supplier must decide to create a change budget to avoid numerous requests for small payments from the budget. They may also decide to place a limit on the amount that can be drawn for a single change to avoid one of two large changes. Changes deplete the entire budget. It can also help catch large changes that are trying to fly under the radar as small changes by breaking them down into many small pieces.

15. Theme No 6 Change Part 3

But rather to check that they're genuinely necessary and, if they are, to get them approved and implemented in a controlled manner. As we have seen with the other themes, as a project is a temporary organisation within the main organization, you will need to adopt the overarching procedure of the main organization, in this case, a change control procedure. In the case of a project, there may be a change control procedure, especially for programme management, in which case you'll work within that. I note for the exam that the questions often assume that you're following the Prince II-recommended procedure.

Please revise Figure 11.1 for the issue and change control procedure, which is the following step: capturing issues. To begin, when an issue is being captured, the project manager will conduct an initial analysis before deciding on the next steps. It may be that the issue is simple or of very low severity and can be dealt with informally and recorded in the daily log. Many, if not most, will probably fall within this category. The project manager will then deal with those that require formal action and enter them into the issues database, which will be assigned a unique identifier. The purpose of distinguishing between issues that can be managed formally and those that need to be managed formally is to ensure decisions are made at an appropriate level within the project management team. Avoid the project board being inundated with too many issues and therefore not having the time available to deal with the key issues affecting the project; reduce the administrative burden on the project management team; and deal with the day-to-day issues that may arise.

Issues being managed formally should be entered in the issue register and given a unique identifier. The daily law can be used to record issues being managed informally, and that's from the principle guide page 143zip. This is done by means of an impact analysis, but the project manager should be confident that issues can't be dealt with informally because of the time, cost, and effort of the analysis. The impact analysis should consider the impact that the issue has had or will have on the project's performance targets in terms of time, cost, and quality scope, including whether there are any other products that are within the project scope that will also be impacted by this issue.

The project business case should also consider the impact and benefits of any other dependent products produced by the project (the risk management profile, i.e. the impact on the overall risk exposure of the project, and please remember that there are three areas that can be impacted and must be considered during an issue, i.e. The bus, which I've mentioned before, is a business user and supplier. Step three involves proposing corrective actions in a similar way to how her options for the entire project are considered, and the one chosen then represents the best value for money.

A number of options for corrective action should be proposed to enable a selection. Step Five: deciding on corrective actions Select the corrective action that represents the best value for money, taking into consideration the time, cost, and risk of implementing it, and please be aware of a corrective action that may cause the project to exceed a stage tolerance. Because the project manager will then need to seek advice from the project board, please study Table 11.3: Project Board Decisions on Page 146.

Step Six: Implementing Corrective Actions: The project manager will either take the necessary corrective action, which might include updating effective products, work packages, plans, and registers, or create an exception plan for approval by the project board. In both cases, the project manager will update the issues, register the decision, and inform all interested parties—in principle.

PRINCE2 PRINCE2-Foundation practice test questions and answers, training course, study guide are uploaded in ETE Files format by real users. Study and Pass PRINCE2-Foundation PRINCE2 Foundation certification exam dumps & practice test questions and answers are to help students.