CAPM Leak Questions

According to the PMBOK® Guide, the Change Control Board (CCB) is a formally chartered group responsible for reviewing, evaluating, approving, deferring, or rejecting changes to the project, and for recording and communicating such decisions.

Primary Function: The CCB acts as the " gatekeeper " for the project baselines (Scope, Schedule, and Cost). Their role is to ensure that no change is made to a baseline without a thorough assessment of its necessity and impact.

Authority: The powers and responsibilities of the CCB are defined within the Change Management Plan and the Configuration Management Plan. On many projects, the CCB includes the project sponsor, customer, and functional managers, though the Project Manager often facilitates the meetings.

The Process: When a change request is submitted, it is the CCB ' s duty to review the analysis provided by the project team and make a final decision. This decision is then documented in the Change Log.

Analysis of other options:

A. Responsible for presenting the change: This is typically the responsibility of the Project Manager or the Change Requestor. The CCB receives the presentation; they do not perform the act of presenting to themselves.

B. Analyze the change impact: While the CCB reviews the impact, the actual technical analysis (calculating exactly how many days or dollars a change will cost) is performed by the Project Manager and the Project Team before the CCB meeting occurs.

C. Managing systems: The " management " of the physical software or procedural systems for change and configuration is an administrative task, usually handled by the project management office (PMO) or the project manager, rather than the board members who focus on decision-making.

Per PMI standards, the Change Control Board is essential for maintaining Integrated Change Control, ensuring that all changes are aligned with the project ' s strategic goals and stakeholder expectations.

According to the PMBOK® Guide (Project Scope Management), the Requirements Traceability Matrix (RTM) is a grid that links product requirements from their origin to the deliverables that satisfy them.

The implementation of an RTM provides a structure to ensure that each requirement adds business value by linking it to the business and project objectives. It provides a means to track requirements throughout the project life cycle, helping to ensure that requirements approved in the requirements documentation are delivered at the end of the project.

Key attributes tracked in the Requirements Traceability Matrix often include:

Business needs, opportunities, goals, and objectives.

Project objectives.

Project scope/WBS deliverables.

Product design.

Product development.

Test strategy and test scenarios.

High-level requirements to more detailed requirements.

Analysis of Distractors:

A. Requirements documentation: This document describes how individual requirements meet the business need for the project. While it lists the requirements, it does not inherently provide the " linkage " or " traceability " to the specific deliverables in a matrix format.

C. Project management plan updates: While the requirements management plan or scope baseline might be updated, these documents do not serve the specific functional purpose of linking requirements to deliverables.

D. Project documents updates: This is a generic output category. While the RTM is a project document, the question asks for the specific output that performs the linking function.

This question utilizes the Earned Schedule (ES) method, which is an extension of the traditional Earned Value Management (EVM) framework. While traditional EVM measures schedule variance in currency (dollars/units), Earned Schedule measures it in units of time.

According to the PMI Practice Standard for Earned Value Management and references in the PMBOK® Guide:

Identify the Variables:

Earned Schedule (ES): 16 weeks. (Note: In this specific calculation context, " ES " refers to Earned Schedule—the duration that should have been taken to achieve the current earned value—rather than " Early Start " ).

Actual Time (AT): 12 weeks.

Schedule Performance Index (SPI): 1.3 (given).

Formula for Schedule Variance (Time):

The formula for Schedule Variance in terms of time ($SV_t$) is:

$$SV_t = ES - AT$$

Substituting the given values:

$$SV_t = 16 - 12 = 4$$

Validation with SPI:

The formula for the Schedule Performance Index in terms of time ($SPI_t$) is:

$$SPI_t = ES / AT$$

Substituting the values:

$$SPI_t = 16 / 12 = 1.33...$$

This matches the provided SPI of 1.3 (rounded to one decimal place), confirming that the interpretation of the variables is correct.

Conclusion:

A positive Schedule Variance of 4 indicates that the project is 4 weeks ahead of schedule. This is consistent with an SPI greater than 1.0 (1.3), which denotes efficient schedule performance.

In the PMBOK® Guide, the process of Identify Risks begins early in the project life cycle. To find where risks might be hiding, project managers look at the documents that contain uncertainty.

Why Choice A is correct:

The Nature of Assumptions: Every project is built on assumptions (factors considered to be true, real, or certain without proof). By their very nature, assumptions are sources of potential risk because if an assumption proves false, the project may be negatively impacted.

Constraints and Risks: The Assumption Log tracks both assumptions and constraints. Constraints (like a hard deadline or a fixed budget) are also primary drivers of project risk.

Initial Identification: During the initiation and early planning phases, the Assumption Log is one of the first documents created (often alongside the Project Charter). Reviewing it is a fundamental step in the initial risk identification process to ensure that " what we think we know " doesn ' t become " what causes us to fail. "

Analysis of other options:

B (Risk management plan): This document describes how risk management activities will be structured and performed. It provides the methodology and the tools, but it does not contain the actual risks themselves.

C (Risk register): This is the output of the risk identification process. You don ' t use the register to start identifying risks; you identify risks and then record them in the register.

D (Issue log): Issues are risks that have already occurred. While looking at old issues can help identify future risks, the Issue Log is primarily a tool for tracking current problems, not for the forward-looking discovery of new risks at the start of a project.

Key Concept: The Project Management Institute (PMI) emphasizes that Assumptions Analysis is a key technique in risk management. By using the Assumption Log (Choice A) as a starting point, the project manager systematically explores the " blind spots " of the project, turning uncertainties into identified risks that can be managed proactively.