PMP Process — Managing Technical Aspects Practice Question

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

• ✗

  Ignore the defect since it is minor and does not affect functionality.

  Why it's wrong here

  Ignoring any identified defect, regardless of its perceived minor nature or immediate impact on functionality, is a critical deviation from quality management principles. All defects must be formally documented in an issue or defect log to ensure proper tracking, assessment, and potential resolution. Failing to log defects can lead to an accumulation of technical debt, obscure underlying process issues, and potentially result in more significant problems later in the project lifecycle.

• ✗

  Fix the defect immediately to avoid a potential quality issue.

  Why it's wrong here

  Fixing a defect immediately without proper assessment and prioritization can introduce significant risks and inefficiencies. Such an ad-hoc approach may disrupt planned project activities, divert critical resources, and potentially introduce new defects without a controlled testing or verification process. Project management best practices dictate that defects should first be logged, analyzed for impact and urgency, and then scheduled for resolution according to the project's change control or defect management plan.

• ✗

  Report the defect to the change control board to get approval for rework.

  Why it's wrong here

  Reporting a defect directly to the Change Control Board (CCB) for rework approval is typically a premature step in the defect management process. Before CCB involvement, the defect must first be formally logged, analyzed for its root cause and impact, and then evaluated by the project team. Only significant defects requiring substantial scope, schedule, or budget changes, or those that cannot be resolved within the team's delegated authority, are escalated to the CCB via a formal change request.

• ✓

  Log the defect in the issue log and decide with the team whether to fix it now or in a future sprint.

  Why this is correct

  Logging the defect in the issue log is the foundational step in effective defect management, ensuring it is formally tracked and visible to all stakeholders. Subsequently, collaborating with the project team to decide on its resolution timing, whether immediately or in a future sprint, allows for a collective, informed decision. This approach balances the need for quality with project constraints, ensuring resources are optimally allocated and the defect is addressed within a structured process.

Go deeper

Related to this question