Changed CAPM Exam Questions

According to the PMBOK® Guide, specifically the section detailing Organizational Influences and Project Life Cycle, a Functional Organization is a classic hierarchy where each employee has one clear superior. Staff members are grouped by specialty, such as production, marketing, engineering, and accounting.

Project Manager Authority: In a functional structure, the project manager has little to no formal authority. They often function more as a " Project Coordinator " or " Project Expediter " rather than a true manager.

Resource Availability: Since resources (people, equipment, and funds) are " owned " by the functional departments, the project manager has little to no power to assign or move resources. They must negotiate with functional managers to get work done.

Budget Control: The Functional Manager maintains complete control over the project budget. The project manager typically has no autonomy to make financial decisions or reallocate funds.

Communication Flow: Communication usually follows the departmental hierarchy. If a project requires work from multiple departments, the request often goes up to the top of one department, across to the head of another, and then back down to the relevant staff.

Comparison with Other Options:

Limited project manager authority (B): This characterizes a Weak Matrix organization. In a weak matrix, the project manager has a bit more influence than in a functional setup but still works part-time and lacks budget control.

Low to moderate authority (C): This characterizes a Balanced Matrix organization. Here, the project manager is usually full-time and shares authority/budget control with functional managers.

High to almost total authority (D): This characterizes a Projectized (Project-Oriented) organization. In this structure, the project manager has full authority, a full-time staff, and total control over the budget, as the organization is built specifically around project delivery.

According to the PMBOK® Guide (Project Management Body of Knowledge), specifically within the Project Integration Management knowledge area, the Close Project or Phase process is the process of finalizing all activities for the project, phase, or contract. The standard tools and techniques for this process are:

Expert Judgment (Option C): This is required to ensure the closure meets organizational and legal standards. Experts provide insight on administrative closure, final lessons learned, and the transfer of the product to operations.

Analytical Techniques (Option C): In the context of closure, analytical techniques are used to perform regression analysis, trend analysis, and variance analysis to verify that the project met its objectives and to document the final project performance.

Meetings (Option B and D): While meetings are used in nearly every process (including closure for lessons learned or wrap-up sessions), they are often paired with other specific tools.

Reserve Analysis (Option A): This is a tool used in Cost Management and Risk Management to determine if the remaining contingency and management reserves are sufficient. It is not a primary tool for the formal administrative closure of a project.

Performance Reviews (Option D): These are typically part of Control Schedule, Control Costs, or Manage Team to compare actual performance against the baseline. While relevant to the final report, the PMBOK® specifically highlights " Analytical Techniques " as the broader category for closure.

In the PMI framework, the combination of Expert Judgment, Analytical Techniques, and Meetings represents the standard toolkit for ensuring a project is legally, financially, and administratively finalized.

According to the PMBOK® Guide, specifically the Monitor Risks and Manage Team processes, the loss of a key resource is a common project risk that should be identified and planned for during the planning phase.

Risk Management Framework: When a key resource leaves, an identified risk has been triggered (it has become an Issue). The first step for a project manager is to consult the Risk Register to see if this specific event was anticipated. If it was, the register will contain a pre-approved Risk Response Plan (such as a contingency plan or fallback plan).

Using the Plan: The response plan might include specific steps, such as hiring a contractor, cross-training existing staff, or utilizing a specific secondary resource. Following the established plan ensures that the project manager acts based on the strategy previously agreed upon by stakeholders and the sponsor, rather than reacting impulsively.

If the Risk was Unidentified: If the risk was not in the register, the project manager would then perform a " workaround " —an unplanned response to an emergent issue. However, in PMI ' s " best practice " scenario, the PM should always check the formal risk documentation first.

Analysis of other options:

Option A: Submitting a change request for budget is a potential result of a risk response, but it is not the next step. You must first determine if you have a plan or if the budget is actually needed.

Option B: Consulting a functional manager is a common action in a matrix organization, but this is a tactical step. The PM should first consult the project ' s own management artifacts (the Risk Register) to understand the overall strategy for such an event.

Option C: Distributing work to others (crashing or increasing the load) can lead to team burnout and decreased quality. This should only be done if it was the agreed-upon risk response or if no other options are available.

Per PMI standards, the project manager is expected to be proactive. By consulting the risk register, the PM ensures that the response to the team change is systematic, authorized, and aligned with the project ' s risk management strategy.

According to the PMBOK® Guide and the Agile Practice Guide, the nature of stakeholder engagement changes significantly when moving from a predictive (waterfall) to an adaptive (agile) lifecycle.

Continuous Involvement: In agile projects, key stakeholders (including customers and product owners) are continuously involved. They do not just provide requirements at the beginning and check the results at the end; they provide ongoing feedback, clarify requirements, and participate in iterative reviews.

Frequency of Interaction: High-frequency interaction reduces the risk of building the wrong product. By being continuously involved, stakeholders can see the product as it grows, allowing them to request changes or pivot the project ' s direction based on real-time learning.

Collaborative Environment: Adaptive environments emphasize " Customer Collaboration over Contract Negotiation. " This requires a partnership where stakeholders are integrated into the rhythm of the project, often participating in Daily Stand-ups, Sprint Reviews, and Backlog Refinement.

Why other options are incorrect:

Option A: Key stakeholders are regularly involved: While " regularly " implies a pattern, it doesn ' t quite capture the " always-on " nature of agile. In agile, the involvement is tighter than just " regular " intervals—it is a continuous loop.

Option C: Key stakeholders are involved at specific milestones: This is a characteristic of Predictive (Waterfall) lifecycles. In those projects, stakeholders are often only engaged during major phase gates or milestone approvals, which can lead to significant gaps between expectations and reality.

Option D: Key stakeholders are always involved: While it sounds similar to continuous, " always " can be misleading in a professional context. Stakeholders are not literally present 24/7 (as " always " might imply), but their feedback and presence are continuous throughout the iterative process. " Continuously " is the formal term used by PMI to describe the active, ongoing engagement model.