Submit a change request.

Explanation:

The project manager should submit a change request to update the scope of work, the schedule, and the budget to accommodate the missing deliverable. A change request is a formal proposal to modify any aspect of the project, such as the scope, schedule, cost, quality, resources, or risks. A change request must be documented, reviewed, approved, and communicated by following the change control process. The change control process is part of the perform integrated change control process, which is one of the processes in the project integration management knowledge area. By submitting a change request, the project manager can ensure that the missing deliverable is properly identified, analyzed, and integrated into the project plan, and that the impact on the project objectives and constraints is minimized. The other options are not correct. Adding additional resources to the project may not solve the problem of the missing deliverable, and it may also introduce new risks, costs, and communication issues. Updating the scope of work without submitting a change request may lead to scope creep, which is the uncontrolled expansion of the project scope without proper authorization and approval.

Reviewing the risk management plan may help to identify and mitigate any potential risks related to the missing deliverable, but it does not address the root cause of the problem or the impact on the project plan.

References: PMBOK Guide, 6th edition, Chapter 4.6, 5.6, How to Manage Change Requests on a Project- PMI

Collaborate with the compliance team member to review and prioritize the requirement’s delivery

Explanation:

The project manager should collaborate with the compliance team member to review and prioritize the requirement’s delivery, as this is a way to manage the change request and ensure that the project meets the compliance standards and expectations. The project manager should also communicate the impact of the change on the project scope, schedule, cost, and quality to the project sponsor and other stakeholders, and obtain their approval and support. The project manager should not ask the team to include the compliance requirement in the current sprint and deliver it (choice A), as this would disrupt the sprint planning and execution, and create scope creep and quality issues. The project manager should not add the new compliance requirement to the backlog as the technical team does not have any capacity (choice B), as this would delay the delivery of the compliance requirement and expose the project to legal and regulatory risks. The project manager should not include the compliance lead in the stakeholders list and wait for the next status meeting (choice C), as this would not address the urgency and importance of the compliance requirement, and it would not involve the compliance lead in the decision-making and problem-solving process. 

References:

• PMBOK Guide, 6th edition, page 115: “A change request is a formal proposal to modify any document, deliverable, or baseline.”
• PMBOK Guide, 6th edition, page 119: “The project manager should review all change requests, assess their impact on the project, and either approve them or submit them to the change control board (CCB) or other decision-making authority for approval or rejection.”
• PMBOK Guide, 6th edition, page 120: “The project manager should communicate the approved change requests to the project team and other stakeholders, and update the project management plan and other project documents accordingly.”
• PMBOK Guide, 6th edition, page 39: “Compliance requirements are the set of standards or regulations that the project must adhere to, such as health, safety, security, performance, environmental, or quality standards.”

Break down the requirements and prioritize the requirements into iterative work packages

Explanation:

A hybrid approach combines predictive and adaptive elements to deliver projects. In a hybrid approach, the project manager can break down the requirements into smaller and manageable chunks, and prioritize them based on their value and risk. This way, the project manager can deliver the most important and uncertain requirements first, and get feedback from the stakeholders and customers. This feedback can help clarify the unclear requirements and improve the quality of the project deliverables. The project manager can also adjust the delivery plan based on the changing requirements and environment. A hybrid approach is suitable for projects that have some degree of uncertainty and complexity, and that need to respond to changing customer needs and expectations. 

References:

• A Guide to the Project Management Body of Knowledge (PMBOK Guide) – Seventh Edition, Chapter 2: Value Delivery System, Section 2.3: Delivery Approaches, pp. 31-35
• Project Management Professional (PMP) Handbook, Section 2.2: PMP Exam Content Outline, Domain II: Process, Task 1: Plan and manage project scope, pp. 14-15
• Hybrid Project Management: What It Is & How to Implement It, by Simplilearn, published on February 10, 2020

Reviewed the communications management plan before inviting an external client representative to the meeting

Explanation

The communications management plan is a component of the project management plan that describes how project communications will be planned, structured, implemented, and monitored for effectiveness. It also defines the communication requirements, methods, and channels for different stakeholders, as well as the confidentiality and security levels of the information to be shared. The project manager should have reviewed the communications management plan before inviting an external client representative to the meeting, to ensure that the information presented was appropriate and authorized for external disclosure. The project manager should also have obtained the approval of the project sponsor and the CEO before sharing any sensitive or confidential information with the external client representative. By not reviewing the communications management plan, the project manager may have violated the communication policies and protocols of the organization, and potentially compromised the project’s budget, scope, quality, or schedule. This could have caused the CEO to end the meeting abruptly, to avoid further disclosure of information that could harm the project or the organization. The other options are not the best choices because they do not address the root cause of the situation, which is the lack of review of the communications management plan. Reviewing the cost management plan with internal participants and CEO prior to inviting an external client representative to the meeting (option B) may be a good practice, but it does not ensure that the information shared with the external client representative is appropriate and authorized. Performing a root cause analysis with the external client representative and documenting the findings in the lessons learned register (option C) may be useful after the situation has occurred, but it does not prevent the situation from happening in the first place. Sending the presentation slides to internal participants first and then to the external client representative prior to the meeting (option D) may also be a good practice, but it does not guarantee that the information in the slides is suitable and approved for external communication.

References:

Project Management Professional (PMP) Reference Materials:
A Guide to the Project Management Body of Knowledge (PMBOK Guide), Sixth Edition, Chapter 10: Project Communications Management, pp. 361-411
Project Communication Management According to the PMBOK

Professional in Business Analysis (PBA) Reference Materials:
Business Analysis for Practitioners: A Practice Guide, Chapter 4: Planning Business Analysis Work, pp. 59-60
Effective Project Communication Plan Template: TeamGantt

Rolling wave planning

Explanation:

Rolling wave planning is a project planning technique that allows the project manager to plan and execute the project in short iterations, based on the available information and the level of detail required12. Rolling wave planning is suitable for projects that have a high degree of uncertainty, complexity, or change, such as a component development project13. Rolling wave planning can help the project manager to accelerate the deliverable by enabling the following benefits123:

• It reduces the risk of rework and waste by allowing the project manager to adjust the plan as more information becomes available or as the requirements change.
• It increases the flexibility and responsiveness of the project team by allowing them to focus on the most important and urgent tasks in each iteration, rather than following a rigid and detailed plan.
• It improves the quality and customer satisfaction of the deliverable by allowing the project manager to incorporate feedback and lessons learned from each iteration into the next one, and by delivering incremental value to the customer.
• It enhances the collaboration and communication among the project team and stakeholders by involving them in the planning and execution of each iteration, and by providing frequent and transparent updates on the project progress and status.

The other options are not the best techniques to accelerate the deliverable in this scenario. Impact mapping (A) is a strategic planning technique that helps the project manager to align the project deliverables with the organizational goals and the customer needs, by identifying the actors, impacts, and deliverables involved45. However, impact mapping does not address the issue of how to plan and execute the project in a fast and adaptive way, especially when the project has failed to comply with a product functionality. Collective code ownership © is a software development practice that encourages the entire team to share the responsibility and the authority to modify any code file as necessary, to improve the quality, the performance, and the functionality of the software product67. However, collective code ownership does not address the issue of how to plan and execute the project in a fast and adaptive way, especially when the project has a predominantly predictive approach. Scrum of Scrums (D) is a scaling technique that helps multiple Scrum teams to coordinate and collaborate on complex and interdependent projects, by having representatives from each team meet regularly to report on their progress, their impediments, and their dependencies89. However, Scrum of Scrums does not address the issue of how to plan and execute the project in a fast and adaptive way, especially when the project has a predominantly predictive approach.

References:
https://www.teamgantt.com/waterfall-agile-guide/hybrid-approach https://www.float.com/resources/hybrid-project-management/ https://en.wikipedia.org/wiki/Rolling-wave_planning

Issue log

Change log

Explanation:
According to the PMBOK® Guide, the issue log is a project document that records and tracks the issues that arise during a project and how they are resolved1. The change log is a project document that records all the changes that occur during a project, including their status, description, and impact2. The project manager should update these two documents as soon as possible to reflect the invoices with errors and the actions taken to correct them. The risk register is a project document that identifies and analyzes the project risks and their responses3, but it does not record the issues that have already occurred. The stakeholder register is a project document that identifies and classifies the project stakeholders and their requirements4, but it does not record the issues or changes that affect them. The backlog register is not a standard project document, but it may be used in agile projects to list the product features or user stories that need to be delivered, but it does not record the issues or changes that affect the product quality. 

References:

1. PMBOK® Guide, page 123;
2. PMBOK® Guide, page 122;
3. PMBOK® Guide, page 436;
4. PMBOK® Guide, page 513; : Agile Practice Guide, page 77

Submit a change request to increase the budget and buy new equipment

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.

Continually survey the quality of the deliverable

Explanation:
This answer is based on the PMI Guide to Business Analysis, which is one of the reference materials for the PMI-PBA exam1. According to the guide, quality is the degree to which a set of inherent characteristics fulfill requirements2. Quality requirements are the criteria that define the acceptable level of performance, reliability, usability, and other attributes of the project deliverables2. In a hybrid approach, which combines predictive and adaptive methods, the project manager should continually survey the quality of the deliverable to ensure that it meets the quality requirements and the stakeholder expectations2. This can be done by using various quality management tools and techniques, such as inspections, audits, reviews, testing, feedback, and metrics2. Continual quality surveillance helps the project manager to identify and correct any defects, errors, or deviations from the quality standards, and to prevent or mitigate any risks related to quality2. The other options are not correct because they are either part of the planning phase or not sufficient to ensure full compliance of quality requirements during the execution phase.

References:
PMI Guide to Business Analysis
Professional in Business Analysis Reference Materials

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