PMI Updated CAPM Exam Questions and Answers by moshe

According to the PMBOK® Guide, specifically within the Project Cost Management knowledge area, the process of Determine Budget is defined as the process of aggregating the estimated costs of individual activities or work packages to establish an authorized cost baseline.

Aggregation Hierarchy: The process follows a specific " bottom-up " flow. Cost estimates for individual activities are aggregated into work package estimates. These work packages are then aggregated into control accounts, which ultimately form the cost baseline.

The Cost Baseline: This is the approved version of the time-phased project budget, excluding any management reserves, which can only be changed through formal change control procedures. It is used as a basis for comparison to actual results (Earned Value Management).

Funding Requirements: A key output of this process is the Project Funding Requirements, which are derived from the cost baseline. Since the baseline is time-phased (often shown as an S-curve), the organization needs to know when the money will be spent to ensure cash flow is available.

Comparison with Other Options:

Baseline Budget (B): While " baseline " is a term used in project management, " Baseline Budget " is not the name of a formal PMBOK® process. The process that creates the baseline is Determine Budget.

Control Costs (C): This is the process of monitoring the status of the project to update the project costs and managing changes to the cost baseline. It occurs during the Monitoring and Controlling phase, after the budget has already been established.

Estimate Costs (D): This process involves developing an approximation of the monetary resources needed to complete project work. It focuses on the cost of individual activities; it is the input to Determine Budget, whereas the aggregation happens in Determine Budget.

As defined in the Agile Practice Guide and the Scrum Guide, scaling agile practices requires coordination between multiple teams working on the same product or program.

Why Choice D is correct: Scrum of Scrums (SoS) is a technique used when multiple teams (typically 3 to 9) need to coordinate their work.

Each team conducts its own Daily Standup to synchronize internal work.

A representative from each team (often the Scrum Master, but it can be any team member) then attends the Scrum of Scrums.

The focus of the SoS is on cross-team dependencies, integration issues, and blockers that affect more than one team. While a standard standup asks " What did I do? " , the SoS asks " What has my team done that might impact other teams? " and " What do we need from other teams? "

Analysis of other options:

A (SAFe®): While SAFe uses Scrum of Scrums as a component, SAFe is a massive, highly structured framework that includes many other elements like PI Planning and Release Train Engineers. The specific meeting described is the technique of SoS itself.

B (Disciplined Agile®): DA is a " toolkit " that helps teams choose their way of working (WoW). While it supports scaling, the specific meeting described is a standard Scrum pattern known as Scrum of Scrums.

C (LeSS): Large Scale Scrum (LeSS) is a specific framework for scaling. While it involves coordination, it emphasizes having a single Product Backlog and often uses " Overall Retrospectives " rather than the specific representative-based daily standup pattern described in the question.

Key Concept: The Scrum of Scrums is the most common and fundamental scaling technique. It ensures that even as a program grows, communication remains decentralized but coordinated, preventing the " silo effect " that can occur when four separate teams work on a single initiative.

According to the PMBOK® Guide, the formal gathering, ritualization, and archiving of lessons learned documentation is a primary activity of the Closing Process Group (specifically within the Close Project or Phase process).

While modern project management encourages the continuous recording of lessons learned throughout the project lifecycle (to the Lessons Learned Register), the formalization of these documents for the benefit of the organization occurs during Closing.

Final Archive: During the Closing phase, the project manager reviews all previous documentation to ensure that all " knowledge gained " is finalized.

Organizational Process Assets (OPAs): The primary output of this activity is an update to the Corporate Knowledge Base. This ensures that future project managers can benefit from the successes and failures of the current project.

Administrative Closure: This involves documenting the reasons for any deviations from the original plan and the effectiveness of the risk responses implemented.

A. Planning: This group focuses on defining the course of action. While you might review lessons learned from past projects here, you are not yet gathering them for the current project.

B. Executing: During execution, the team is performing the work. While the Lessons Learned Register (a project document) is updated during execution, the " Lessons Learned Documentation " as a formal project closure deliverable is a function of the Closing group.

D. Initiating: This group is for authorizing the project. At this stage, there is no project performance to reflect upon or document.

In the most recent editions of the PMBOK® Guide, there is a distinction between:

Lessons Learned Register: An active document used throughout the project (Executing/Monitoring).

Lessons Learned Repository: The final resting place for the documentation after the project is closed (Closing).

For the purpose of this examination, the act of " gathering " the final documentation for organizational use is strictly tied to the Closing of the project or phase.

According to the Agile Practice Guide and the PMBOK® Guide, the daily standup (also known as the Daily Scrum) is a key ceremony in adaptive environments designed for team synchronization and micro-planning.

The Three Questions: The traditional format of a standup involves each team member answering three specific questions to provide visibility into the iteration ' s progress:

What have I completed since the last meeting?

What do I plan to complete between now and the next meeting?

What are my impediments (blocks/risks) that are preventing me or the team from reaching the iteration goal?

Peer-to-Peer Communication: The primary purpose is not to " report status " to a manager, but for the team to communicate with one another. It ensures everyone is aligned on the current state of the sprint and can collaborate to resolve issues immediately.

Timeboxing: These meetings are strictly timeboxed (usually to 15 minutes) to keep the focus on immediate coordination rather than deep problem-solving, which should happen in separate " breakout " sessions.

Analysis of other options:

Option A: While removing impediments is a goal, calculating velocity is an activity typically performed at the end of an iteration (during the Sprint Review or Retrospective), not during the daily standup.

Option B: Similar to Option A, calculating velocity is out of place here. The standup is a planning and synchronization tool, not a metrics-gathering session.

Option D: The burndown chart is often updated by the team as they complete tasks, and it may be viewed during the standup, but " calculating velocity " remains an end-of-iteration metric. The core purpose of the meeting is the exchange of information regarding tasks and blockers.

Per PMI standards, the Adaptive Standup Meeting serves as a daily synchronization point for the team to share progress, commit to upcoming work, and highlight any impediments that require resolution to maintain project momentum.