Submit a change request.

Explanation:
The project manager has discovered that a necessary piece of work was omitted during planning. This is not a simple oversight; it is a scope change that has been identified late and is already impacting the project's critical path.
The proper, formal mechanism for addressing any change to the project baselines (scope, schedule, cost) is the Perform Integrated Change Control process.
Submitting a change request is the first and most critical step. This formally documents the newly discovered deliverable, its impact on the critical path, and any proposed solutions (which could include options B or C).
The Change Control Board (CCB) or the appropriate authority will then review the request and decide whether to approve, reject, or defer it. Only after approval can the project manager legally update the project's official plans and baselines.
This process ensures that the change is properly evaluated, its impacts are understood by all stakeholders, and the project's integrity is maintained.

Analysis of Other Options:
B. Add additional resources to the project.
Incorrect. This is a potential solution that might be part of the change request, but it is not the first action. The project manager cannot unilaterally add resources (which costs money and may not even be possible) without formal approval. Furthermore, adding resources does not always shorten the schedule (Brooks' Law) and does not address the fundamental issue of the missing deliverable not being in the official scope.

C. Update the scope of work.
Incorrect. This is an output or a result of an approved change request, not the initial action. Updating the scope of work (and the WBS, schedule, etc.) without going through the formal change control process is unauthorized and undermines the project's governance. The project manager must first get approval for the change before updating the official documents.

D. Review the risk management plan.
Incorrect. While a valuable activity, the risk has already occurred—it is now an issue. The risk management plan outlines how to handle unknown-unknowns, but this is a known problem that requires immediate corrective action. Reviewing the plan does not address the immediate need to formally incorporate the missing deliverable into the project.

Reference:
PMBOK Guide, 7th Edition - Process: Perform Integrated Change Control. This is the definitive process for handling changes. All requests for changes, including those that result from corrective or preventive actions, are processed, reviewed, and approved through this process.
Knowledge Area:
Project Integration Management. The entire scenario is a classic example of why integrated change control is vital. A change in scope (Scope Management) directly causes a change in the schedule (Schedule Management), and both must be managed holistically through a single, integrated process.

Explanation:
In a hybrid framework, the project manager must blend the flexibility of Agile with the structured governance of predictive methodologies. A new compliance requirement that "has to be delivered before any other requirements" is a high-impact, mandatory change.

Collaboration is Key:
The project manager cannot act unilaterally. They must immediately collaborate with a subject matter expert (the compliance team member) to fully understand the requirement's scope, urgency, and impact.
Prioritization is Central:
The core of the response is to prioritize. In an Agile context, this means working with the Product Owner (or fulfilling that role) to immediately reprioritize the backlog. This new requirement must be moved to the very top, as it is a blocker for all other work.
Proactive and Integrated:
This approach is proactive, involves the right experts, and uses the established hybrid process (backlog prioritization) to address a critical, unplanned work item. It respects the urgency of the compliance need without bypassing proper project controls.

nalysis of Other Options:
A. Ask the team to include the compliance requirement in the current sprint and deliver it.
Incorrect.While this seems to address the urgency, it violates the core Agile principle that the Development Team owns the Sprint Backlog. The project manager should not unilaterally "ask" the team to add a major new requirement to an ongoing sprint, as this disrupts their commitment and plan. The proper process is to prioritize it and then let the team plan its delivery in the next (or current, if they agree to re-plan) sprint.

B. Add the new compliance requirement to the backlog as the technical team does not have any capacity.
Incorrect. This acknowledges the constraint but fails to address the critical urgency ("has to be delivered before any other requirements"). Simply adding it to the backlog without immediate reprioritization would lead to a compliance failure. The lack of capacity is a problem to be solved, not a reason to delay the necessary planning and prioritization.

C. Include the compliance lead in the stakeholders list and wait for the next status meeting.
Incorrect. This is a passive and risky approach. A mandatory compliance requirement is an urgent issue, not a routine update. Waiting for a scheduled meeting could result in a significant project delay or violation. The project manager must act immediately to assess the situation.

Reference:
Hybrid Framework Principles:
This approach demonstrates a hybrid mindset by using an Agile mechanism (backlog prioritization) to handle a disruptive change, while employing project management leadership to facilitate the necessary collaboration and risk mitigation.
Agile Practice Guide:
Emphasizes the need for a prioritized backlog and the role of the Product Owner (or equivalent) in managing it. A compliance requirement of this nature would be the highest priority item.

PMBOK Guide, 7th Edition - Principle:
Navigate Complexity:
The project manager is navigating the complexity of a disruptive change by engaging experts and adapting plans.
Optimize Risk Responses:
Addressing a compliance issue is a direct risk response, treating it as a threat that must be mitigated immediately.

Explanation:
When a project includes unclear or evolving requirements, a hybrid approach is ideal because it combines the predictive structure of traditional project management with the flexibility and adaptability of Agile.

The project manager should therefore:
Decompose the unclear requirements into smaller, manageable components, and
Prioritize these requirements to deliver value iteratively, refining details as the project progresses.
This allows for continuous feedback and adaptation while maintaining alignment with overall project objectives.

Why the other options are not correct:
A. Wait for the requirements to be more clear before any further action is taken:
This delays progress and contradicts the adaptive principles of hybrid and Agile delivery.

B. Ignore the unclear requirements and focus on the delivery plan:
Ignoring unclear requirements risks scope gaps and stakeholder dissatisfaction.

C. Escalate the issue of unclear requirements to the management team and wait for final authorization:
Escalation is unnecessary; managing evolving requirements is the project manager’s responsibility within a hybrid framework.

References:
PMBOK Guide, 7th Edition, Principle 5 – Focus on Value: encourages adapting planning as requirements evolve.
PMI Agile Practice Guide, Section 3.3 – Hybrid models: recommends iterative elaboration for projects with partially defined requirements.

Explanation:
The communications management plan defines who receives what information, when, and how. It ensures that sensitive content like budget details is shared appropriately based on stakeholder roles, authority, and confidentiality. In this scenario, the project manager presented budget information in front of an external client representative without confirming whether that was appropriate — leading the CEO to abruptly end the meeting.

Option A is correct because reviewing the communications management plan would have clarified:
Whether budget details were authorized for external sharing
Which stakeholders should be present for specific topics
The appropriate format a
nd timing for sharing sensitive information
This aligns with the PMBOK® Guide – Sixth Edition, Section 10.1: Plan Communications Management, and the PMBOK® Guide – Seventh Edition, under the Stakeholder and Communication Domains, which emphasize tailoring communication based on stakeholder needs and organizational boundaries.

❌ Why the other options are incorrect:
B. Reviewed the cost management plan with internal participants and CEO prior to inviting an external client representative to the meeting
The cost management plan governs budgeting and cost control, not stakeholder communication protocols. Reviewing it wouldn’t prevent the breach of communication boundaries.

C. Performed a root cause analysis with the external client representative and documented the findings in the lessons learned register
This is a post-incident activity, not a preventive measure. It’s useful after the fact but doesn’t help avoid the situation in the first place.

D. Sent the presentation slides to internal participants first and then to the external client representative prior to the meeting
This assumes the content is appropriate for external sharing. Without consulting the communications management plan, this action could still violate stakeholder boundaries.

🔗 References:
PMBOK® Guide – Sixth Edition Section 10.1: Plan Communications Management
Section 13.2: Plan Stakeholder Engagement
PMBOK® Guide – Seventh Edition
Stakeholder Domain: Tailor Communication Based on Stakeholder Needs Principle: Stewardship and Respect for Boundaries

Explanation:
The core problem is that the project failed to comply with a product functionality, likely due to insufficient detail or understanding in the initial, predictive plan. The project manager needs a technique to accelerate planning and delivery in this predictive context.
Rolling Wave Planning is a technique where the work to be accomplished in the near term is planned in detail, while the work in the future is planned at a higher level (work packages). This is an iterative form of planning perfectly suited for a predictive project where details are emerging.
In this case, after discovering the functionality gap in the second iteration, the project manager can use rolling wave planning to plan the next waves of work in greater detail, incorporating the lessons learned to ensure the missing functionality is correctly addressed in the upcoming deliverables. This allows for course correction and more accurate, detailed planning for the immediate next steps, thereby accelerating the path to a correct deliverable.

Analysis of Other Options:
A. Impact mapping
Incorrect. Impact mapping is a strategic, goal-oriented technique used for why we are building something, not for accelerating the detailed planning of a deliverable. It's excellent for ensuring alignment at the start of a project but is less about accelerating execution after a functionality gap has been identified in an ongoing project.

C. Collective code ownership
Incorrect.
This is an Agile software development practice where every team member can change any piece of code. While it can improve team velocity and knowledge sharing, it addresses the how of development (coding practices), not the planning and scope definition issue that caused the functionality failure. The problem is rooted in the "predominantly predictive" planning approach, not the code ownership model.

D. Scrum of Scrums
Incorrect. This is a scaling technique used when multiple Scrum teams are working on the same product. It is a meeting for coordinating between teams. The scenario describes a single "project team" and a problem with initial planning and scope, not a coordination issue between multiple teams.

Reference:
PMBOK Guide, 7th Edition:
Rolling wave planning is explicitly defined as a technique in the "Schedule Management" knowledge area. It is described as an iterative planning technique where the work to be accomplished in the near term is planned in detail at a low level of the WBS, while work further in the future is planned for WBS components at higher levels.
Hybrid Approach:
This answer best fits the hybrid context. The project has a predictive backbone, but the discovery of the functionality gap shows the need for a more adaptive, iterative planning technique. Rolling wave planning is the predictive/adaptive hybrid technique that addresses this exact need.

📘 Explanation:
When errors are discovered in deliverables after project completion, the project manager must document and track them appropriately to ensure resolution and accountability.

A. Issue log
is correct because the invoice errors are actual problems that occurred during or after execution. The issue log is used to record, monitor, and manage such problems until they are resolved. According to the PMBOK® Guide – Sixth Edition, the issue log is updated whenever new issues are identified.

D. Change log
is also correct because resolving invoice errors may require corrective actions or formal changes to the deliverables. Any approved changes—such as reissuing invoices or modifying the invoicing system—must be documented in the change log. This ensures traceability and governance over what was altered post-implementation.

❌ Why the other options are incorrect:
B. Risk register:
Risk refers to uncertain future events, not actual errors. Since the invoice issues have already occurred, they belong in the issue log, not the risk register.

C. Stakeholder register:
This document tracks stakeholder information and engagement strategies. It’s not relevant to documenting invoice errors.

E. Backlog register:
This applies to Agile environments where work is planned in sprints. Since the project is completed and invoicing errors are not new features or enhancements, they don’t belong in the backlog.

🔗References:
PMBOK® Guide – Sixth Edition
Section 4.3: Direct and Manage Project Work – Issue Log
Section 4.6: Perform Integrated Change Control – Change Log

Explanation:

• According to the PMBOK Guide, a change request is a formal proposal to modify any document, deliverable, or baseline of a project. Change requests can be initiated by any stakeholder, including the project team, and should be processed through the perform integrated change control process.
• In this scenario, the project team has identified a potential risk that could affect the quality and schedule of the next iteration of the project. The team has also proposed a solution to mitigate the risk by buying new equipment. This solution would require an increase in the project budget, which is a baseline that needs to be approved by the project sponsor or customer.
• Therefore, the project manager should submit a change request to increase the budget and buy new equipment, and follow the change control procedures to obtain the necessary approval and authorization. This would ensure that the project scope, schedule, and quality are not compromised, and that the project stakeholders are aware of and agree with the proposed change.

The other options are not appropriate because:

• Checking the project budget to verify if there is enough contingency reserve (option A) is not sufficient to address the issue. Contingency reserves are funds set aside to cover known risks that may or may not occur during the project. Even if there is enough contingency reserve, the project manager still needs to submit a change request to use it and update the project baseline.
• Reviewing the cost management plan to determine how to address this issue (option B) is also not sufficient to address the issue. The cost management plan is a component of the project management plan that describes how the project costs will be planned, estimated, budgeted, managed, and controlled. It does not provide specific guidance on how to deal with changes that affect the project budget. The project manager still needs to follow the change control procedures and submit a change request.
• Telling the team members that more equipment is not part of the project’s scope (option C) is not a constructive or collaborative way to deal with the issue. The project manager should not ignore or dismiss the team’s input and recommendations, especially if they are based on valid and relevant information. The project manager should respect the team’s expertise and experience, and work with them to find the best solution for the project.

References:
[PMBOK Guide] - A Guide to the Project Management Body of Knowledge (PMBOK® Guide) – Seventh Edition, Project Management Institute, Inc., 2021.

Explanation:
The question is very specific: the project is in the implementation phase and the goal is to ensure compliance during the execution phase.
"Continually survey the quality of the deliverable" is a description of the process of Manage Quality (sometimes called Quality Assurance). This is an executing process.
The purpose of Manage Quality is to audit quality requirements and the results from quality control measurements to ensure that appropriate quality standards and operational definitions are used. It is the process of "checking the checks" to ensure the project is on track to meet quality standards and that processes are being followed correctly. This is a proactive, ongoing activity during execution.
In a hybrid approach for a large hydropower plant, this would involve regular audits, process checklists, and reviewing the results of frequent tests and inspections (which would be the Control Quality activities) to ensure overall compliance.

Analysis of Other Options:
A. Analyze the quality requirements.
Incorrect. This is part of the Plan Quality Management process, which is a planning activity. It should have been completed before the project entered the execution phase. While analysis might be revisited, the primary work of defining and analyzing requirements is a planning function.

B. Plan quality management
Incorrect. This is definitively a planning process. The question states the project is already in the implementation/execution phase. The time for planning quality management is past. You cannot "plan" quality management to "ensure" compliance during execution; you must use the plan you already have.

D. Set up quality policies and procedures
Incorrect. This is also a foundational activity that belongs to the Plan Quality Management process. Setting up policies and procedures creates the quality management plan, which is a planning output. During execution, the team should be following these already-established policies and procedures, not setting them up.

Reference:
PMBOK Guide, 7th Edition - Process Groups:

Plan Quality Management (Planning):
The process of identifying quality requirements and/or standards for the project and its deliverables and documenting how the project will demonstrate compliance.

Manage Quality (Executing):
The process of translating the quality management plan into executable quality activities that incorporate the organization's quality policies into the project. It focuses on process and proactive assurance.

Hybrid Context:
For a large hydropower plant, the predictive elements require rigorous, planned quality audits (Manage Quality) to ensure compliance with strict engineering and safety standards, while the adaptive elements might involve frequent testing and review cycles. "Continually survey" captures this ongoing, active effort during execution.

Mitigate the risk by developing alternative plans to make the solution ready and available without full integration capabilities

Explanation:
According to the PMBOK Guide, 6th edition, risk mitigation is one of the strategies for responding to positive or negative risks. It involves reducing the probability or impact of a risk to an acceptable level. In this case, the project manager should mitigate the risk of the partner’s system being unavailable by developing alternative plans to deliver the solution without relying on the full integration. This will help the project achieve its objectives and satisfy the customer’s needs. The other options are not the best choices because they either do not address the risk, transfer the risk to the partner, or accept the risk without taking any action.

References:
PMBOK Guide, 6th edition, page 4361
Free PMP Practice Exam Questions - 120 Sample Test Questions, Question 692

Review the requirements traceability matrix with the concerned stakeholder.

Explanation:

According to the Professional in Business Analysis (PMI-PBA)® Guide, a requirements traceability matrix is a table that links requirements to their origin and tracks them throughout the project life cycle. A requirements traceability matrix helps to ensure that all requirements are addressed by the project deliverables, and that any changes to the requirements are reflected in the project scope, schedule, cost, quality, and risk. In this scenario, the project manager should review the requirements traceability matrix with the concerned stakeholder to verify if the requirement in question is indeed missing or not. This would help to clarify the source, scope, and status of the requirement, and to identify any gaps, inconsistencies, or conflicts between the requirements and the deliverables. This would also help to avoid any misunderstandings, miscommunications, or assumptions that could lead to stakeholder dissatisfaction or project failure. Checking the approved list of requirements, working with the stakeholder to improve the acceptance criteria, or discussing additional requirements are actions that should be taken after the review of the requirements traceability matrix, not before. These actions do not address the root cause of the situation, which is the possible discrepancy between the requirements and the deliverables. 

References: (Professional in Business Analysis Reference Materials source and documents)

• Professional in Business Analysis (PMI-PBA)® Guide, Chapter 4, Section 4.3.1.3
• A Guide to the Project Management Body of Knowledge (PMBOK® Guide) – Seventh Edition, Chapter 5, Section 5.2.2.3
• The Standard for Project Management – Seventh Edition, Chapter 3, Section 3.2.2.3

Hold a meeting with the project team project sponsor and the client to agree to the further work required to close the project and add to lessons learned

Explanation:
According to the PMBOK Guide, project closure is the process of finalizing all activities across all of the project management process groups to formally complete the project or phase1. Project closure involves verifying that all the project deliverables have been completed and accepted by the customer or sponsor, confirming that all the contractual obligations have been met, documenting the project performance and lessons learned, releasing the project resources, and archiving the project records2.

In this question, the project manager is faced with a problem that the client will not agree to closure, claiming that the project team has not performed the code inspections mandated in the development contract. The project team has performed the code inspections, however the records are not complete. This indicates that there is a discrepancy between the contractual requirements and the project documentation, which can lead to disputes, claims, or litigation. The project manager should approach this problem by holding a meeting with the project team, project sponsor, and the client to agree to the further work required to close the project and add to lessons learned. This way, the project manager can facilitate a constructive dialogue among the key stakeholders, clarify the expectations and obligations of each party, negotiate a mutually acceptable solution, and document the agreed actions and outcomes. This will also help to maintain the relationship with the client, ensure customer satisfaction, and capture the lessons learned for future projects.

The other options are not the best actions to take to solve this problem. Seeking expert legal advice on the interpretation of the clauses in the contract is a possible option, but it should be done after trying to resolve the issue amicably with the client and the sponsor. Seeking legal advice may also escalate the conflict and damage the trust and goodwill with the client. Closing the project and handing over the deliverables to the client is not advisable, as it may violate the contract terms and expose the project to legal risks. Holding a lessons learned workshop with the project team and project sponsor to avoid contractual compliance issues arising in future projects is a good practice, but it does not address the current issue with the client and the project closure.

References:

1. PMBOK Guide, 6th edition, p. 123
2. PMBOK Guide, 6th edition, p. 125

Coach the product owner on how to create a product backlog

Explanation:
The project manager should coach the product owner on how to create a product backlog, as this is a key artifact in Scrum and Kanban methodologies. The product backlog is a prioritized list of features, user stories, or requirements that the product owner wants to deliver in the project. The product backlog is dynamic and evolving, and it reflects the value and vision of the product. The product owner is responsible for creating, maintaining, and refining the product backlog, as well as communicating it to the development team and the stakeholders1. The project manager can assist the product owner by providing guidance, feedback, and tools on how to create a product backlog that is clear, concise, and aligned with the project goals and scope. The project manager can also help the product owner to use agile techniques, such as user story mapping, story splitting, and backlog grooming, to break down the functionalities into manageable and testable chunks, and to prioritize them based on value, risk, and dependencies2.

The other options, encouraging the team to subdivide the project tasks, creating a work breakdown structure (WBS), or discussing the product owner’s responsibilities within the project team, are not the best ways to assist the product owner. Encouraging the team to subdivide the project tasks may help the team to plan and execute the work, but it does not address the product owner’s confusion on how to start delivering the functionalities. Creating a WBS may help the project manager to define and organize the project deliverables, but it is not a suitable artifact for agile methodologies, as it is static and rigid, and does not reflect the changing needs and expectations of the customers and stakeholders3. Discussing the product owner’s responsibilities within the project team may help the product owner to understand their role and expectations, but it does not provide practical guidance on how to create a product backlog.

References: 1 A Guide to the Project Management Body of Knowledge (PMBOK® Guide) – Sixth Edition, Chapter 5.4.2.2 2 Agile Practice Guide, Chapter 3.2.2 3 What is a Work Breakdown Structure (WBS)? - Project Management Institute