Free Practice Questions for PMI PMI-RMP Exam

Each project is unique, even when similar to previous projects, and therefore, it requires a tailored risk strategy. A specific risk strategy for a project ensures that the risks are managed in alignment with the organization’s risk appetite while considering the unique aspects of the project. The risk strategy will identify the specific risk thresholds for the project, which may differ from other projects due to variations in scope, stakeholders, or external conditions.

PMI emphasizes the importance of aligning the risk management strategy with the organizational risk appetite. This alignment ensures that the project’s approach to risk is consistent with the organization's broader risk management framework and that it reflects the unique risk profile of the project​​.

According to the PMBOK Guide, one of the tools and techniques for the implement risk responses process is root cause analysis. Root cause analysis is a technique that focuses on identifying the fundamental reason for the occurrence of a problem or a risk. By conducting a root cause analysis, the risk owner can determine why the implemented measures were only partially successful and what caused the new unforeseen risk to emerge. This can help the risk owner to identify and implement more effective risk responses, as well as to update the risk register and the risk report with the new information1 . References: PMBOK Guide, 6th edition, pages 452-453, 474-4751; PMI-RMP Exam Content Outline, 2015, page 8.

The project charter is the first resource the project manager should reference to determine the risk tolerance and risk attitudes of the project’s key stakeholders, as it contains information such as the project purpose, objectives, success criteria, high-level risks, and key stakeholder list. The project charter is an output of the Develop Project Charter process, which is part of the Initiating process group. The project charter provides the project manager with the authority to apply organizational resources to project activities and establishes a partnership between the performing organization and the requesting organization. References: PMBOK Guide, 6th edition, page 81-82.

Enterprise environmental factors (EEFs) provide information about the organization's culture, risk tolerance, and risk attitudes, which can help the project manager determine the risk tolerance and risk attitudes of the project's key stakeholders. (Reference: PMBOK Guide, 6th Edition, p. 39)

According to the PMBOK® Guide, a scope change request is a formal proposal to modify any project document, deliverable, or baseline. It is an output of the Perform Integrated Change Control process, which is the process of reviewing all change requests, approving changes, and managing changes to the deliverables, organizational process assets, project documents, and the project management plan. A scope change request may introduce new risks or affect existing risks on the project, which may impact the project objectives, such as scope, schedule, cost, and quality.

The risk manager should support the project manager with the scope change request by evaluating any new risks that are introduced due to the change in scope. This is because the risk manager is responsible for planning, implementing, and monitoring the risk management activities on the project, as well as communicating and reporting the risk information to the project manager and other stakeholders. The risk manager should use the appropriate risk identification and analysis techniques, such as brainstorming, interviews, checklists, SWOT analysis, cause and effect diagrams, probability and impact assessment, etc., to identify and evaluate the new risks that may arise from the scope change. The risk manager should also document the new risks in the risk register, which is a project document that contains the details of all identified individual project risks and other relevant information.

The other options are not valid for what the risk manager should do to support the project manager with the scope change request:

Update the risk management plan to reflect the scope change: This is not a valid option because the risk management plan is a component of the project management plan, which describes how risk management activities will be structured and performed on the project. It is an output of the Plan Risk Management process, which is the process of defining how to conduct risk management activities for a project. The risk management plan should not be updated to reflect the scope change, but rather to reflect any changes in the risk management approach, methodology, roles and responsibilities, budget, timing, risk categories, definitions, reporting formats, etc. The risk management plan should be updated only when there is a change in the risk management process, not in the project scope.

Reassess the identified risks that impact the project scope: This is not a valid option because reassessing the identified risks that impact the project scope is part of the Monitor Risks process, which is the process of implementing risk response plans, tracking identified risks, monitoring residual risks, identifying new risks, and evaluating risk process effectiveness throughout the project. The risk manager should not reassess the identified risks that impact the project scope before evaluating any new risks that are introduced due to the change in scope. The risk manager should first identify and analyze the new risks, and then reassess the existing risks to determine if they are still valid, relevant, and prioritized.

Update the risk register to identify, analyze, and plan a response for any new risk: This is not a valid option because updating the risk register to identify, analyze, and plan a response for any new risk is a combination of several risk management processes, such as Identify Risks, Perform Qualitative Risk Analysis, Perform Quantitative Risk Analysis, and Plan Risk Responses. The risk manager should not update the risk register to identify, analyze, and plan a response for any new risk in one step, but rather follow the sequential and iterative risk management processes to ensure a comprehensive and consistent risk management approach. The risk manager should also coordinate and communicate with the project manager and other stakeholders when updating the risk register, as well as obtain their approval and input.

PMBOK® Guide1, Risk Management Professional (PMI-RMP)® Cert Guide1

At the risk strategy and planning stage, the risk manager’s primary responsibility is to define the risk management processes and tools to be used for the project. This is foundational and comes before identifying individual risks or updating communication plans.

"The first step in risk management planning is to define how to conduct risk management activities, including processes, tools, and techniques that will be used on the project."

— PMBOK® Guide, 6th Edition, Section 11.1 (Plan Risk Management)

ISO 31000 similarly emphasizes that the establishment of the risk management context, processes, and tools is critical at the planning stage, especially for projects involving multiple stakeholders and locations.

The risk manager should first check the risk register for proper risk classification, probability, and impact (C), as these are essential components of an effective risk management process. Next, the risk manager should ensure that the risk origin, triggering events, and ownership are identified (D), as this information helps in assigning responsibilities and taking appropriate actions for each risk. References to these steps can be found in the Project Management Institute's (PMI) A Guide to the Project Management Body of Knowledge (PMBOK Guide), Sixth Edition.

 The risk manager should check for risk classification and that probability and impact are identified, as these are essential elements of a risk register. Risk classification helps to group risks into categories based on their sources, types, or impacts, which can facilitate risk analysis and response planning. Probability and impact are the two dimensions of risk assessment, which help to measure the likelihood and severity of a risk event, and to prioritize risks based on their significance. The risk manager should also check to ensure that risk origin, triggering event, and ownership is identified, as these are also important components of a risk register. Risk origin refers to the root cause or source of a risk, which can help to understand the nature and characteristics of a risk, and to devise effective risk responses. Triggering event is a specific occurrence or condition that indicates that a risk event has occurred or is about to occur, which can help to monitor and control risks. Ownership is the assignment of a risk to a person or a group who is responsible for managing the risk, which can help to ensure accountability and communication. The risk manager should not check to ensure that the risk is supported by a Monte Carlo simul-ation, as this is not a mandatory or universal requirement for a risk register. Monte Carlo simul-ation is a quantitative risk analysis technique that uses computer-generated random scenarios to model the possible outcomes of a project, based on the probability distributions of the input variables. While this technique can provide useful information about the overall project risk exposure and the probability of achieving project objectives, it is not a necessary or sufficient condition for an effective risk register. The risk manager should not check to ensure that the risks are gathered using Delphi technique, as this is also not a compulsory or exclusive requirement for a risk register. Delphi technique is a qualitative risk identification technique that uses a panel of experts to anonymously provide their opinions on potential risks, which are then aggregated and refined through a series of rounds until a consensus is reached. While this technique can help to elicit expert judgment and reduce bias, it is not the only or the best way to identify risks. The risk manager should not check to ensure the risk meeting agenda and supporting documents are distributed, as this is not a relevant or appropriate action for analyzing the effectiveness of a risk register. The risk meeting agenda and supporting documents are part of the risk management plan, which describes how the project team will conduct risk management activities, such as identifying, analyzing, responding, and monitoring risks. The risk meeting agenda and supporting documents are useful for planning and conducting risk meetings, but they are not part of the risk register, which is the output of the risk identification process and the input for the risk analysis and response processes. References: PMI. (2017). A Guide to the Project Management Body of Knowledge (PMBOK® Guide) – Sixth Edition. Chapter 11: Project Risk Management, pp. 395-454. 5

The first element the risk owner should look for in the response plan is to verify that due dates for the actions have been identified. This ensures that risk mitigation actions are timely and can be effectively monitored.

 After identifying the risks and assigning risk owners, the next step is to develop risk response plans that describe how to address each risk. The first element that the risk owner should look for in the response plan is the due date for the actions that are required to implement the response. The due date is important because it helps to prioritize the risk response activities, monitor the progress of the risk response, and ensure that the response is executed in a timely manner. The due date also helps to align the risk response with the project schedule and avoid any delays or conflicts. The other elements, such as the probability of a secondary risk, the impact on the quality of the components, and the relationship with the critical path, are also relevant for the risk response plan, but they are not the first element that the risk owner should look for. References: PMI, 2017. A Guide to the Project Management Body of Knowledge (PMBOK® Guide) – Sixth Edition. Newtown Square, PA: Project Management Institute, Inc., pp. 407-4081

In situations where available time and funds are insufficient to address all identified risks, it's imperative to prioritize risks based on their potential impact on the project. Focusing on high-impact risks ensures that the most critical threats to project success are managed effectively within the constraints. This approach involves conducting a thorough risk assessment to categorize risks by their severity and likelihood, allowing the project team to allocate resources strategically. By concentrating on high-impact risks, the team can develop contingency plans that safeguard the project's primary objectives, even if lower-impact risks cannot be fully mitigated due to resource limitations.

PMI Risk Management Study Guide References:

The PMI-RMP Exam Preparation Study Guide emphasizes the importance of prioritizing risks, stating that "project teams often face constraints in resources, making it essential to focus on risks that pose the greatest threat to project objectives."

The risk registry is a document that records the identified risks, their characteristics, their status, and their responses. It is a key input for risk management and a source of information for project stakeholders. The risk manager should review the risk registry first to understand the current state of the project risks, especially the ones related to the client’s vendor, and to evaluate the effectiveness of the risk responses implemented so far. Enhancing risk identification, reviewing the contingency reserves, and creating a risk response plan are possible actions that the risk manager may take after reviewing the risk registry, but they are not the first thing to do. References: PMI Risk Management Professional (PMI-RMP)® Exam Content Outline1, PMI Practice Standard for Project Risk Management2, Risk Management Professional (PMI-RMP)® Cert Guide3

In projects where team members are spread across multiple time zones and have not worked together before, fostering collaboration is critical. Developing a start-up workshop, where team members can meet (either virtually or physically if colocation is possible), helps in building relationships, aligning on project goals, and understanding roles. This approach can mitigate communication challenges and improve team cohesion, which are essential for effective risk management and overall project success. PMI emphasizes the importance of early team alignment and relationship-building in the risk management process​.