CAPM Exam Dumps - Certified Associate in Project Management (CAPM)

In Agile and Scrum frameworks, specifically during the Sprint Review and Sprint Retrospective, any work that does not meet the " Definition of Done " (DoD) cannot be considered complete or demonstrated to the customer.

Why Choice A is correct:

Maintaining the Backlog: According to the Scrum Guide, incomplete user stories are returned to the Product Backlog. They do not " automatically " move to the next sprint.

Reprioritization: The Product Owner must re-evaluate these stories. Business priorities may have shifted, or new information discovered during the sprint might make an incomplete story less valuable than other items currently sitting in the backlog.

Transparency: Moving them back ensures that the team’s velocity is calculated accurately (only counting completed points) and that the Product Owner maintains control over the project ' s direction.

Analysis of other options:

B (Remove these user stories): Just because a story wasn ' t finished in one sprint doesn ' t mean it lacks value. Removing them without a business justification violates the goal of delivering maximum value to the customer.

C (Advance to the top of the next sprint): This is a common mistake in practice, but it is technically incorrect according to Agile principles. The Product Owner, not a default rule, decides the priority of the next sprint. Forcing them to the top bypasses the Sprint Planning process.

D (Extend the sprint length): One of the core tenets of Scrum is the Timebox. Sprints have a fixed duration to create a predictable rhythm (cadence). Extending a sprint to finish work breaks this cadence and hides the team ' s true capacity/velocity issues.

Key Concept: The Project Management Institute (PMI) and the Agile Practice Guide emphasize that Incomplete Work (Choice A) should always be re-estimated and re-prioritized. This prevents " technical debt " from being hidden and ensures that the team is always working on the highest-priority items as defined by the most current business needs.

According to the PMBOK® Guide (specifically in the context of the Develop Project Charter process), the Project Statement of Work (SOW) is a critical narrative document used to define the boundaries of the project before it is formally authorized.

Definition: The SOW is a narrative description of products, services, or results to be delivered by the project. For internal projects, the project initiator or sponsor provides the statement of work based on business needs, product, or service requirements. For external projects, the statement of work can be received from the customer as part of a bid document (e.g., a request for proposal, request for information, or as part of a contract).

Key Components: The SOW typically references:

Business Need: An organization’s business need may be based on a market demand, technological advance, legal requirement, government regulation, or environmental consideration.

Product Scope Description: Documents the characteristics of the product, service, or results that the project will be undertaken to create.

Strategic Plan: Documents the organization ' s strategic goals and ensures the project aligns with the corporate mission.

Comparison with other options:

B. Business case: This document provides the necessary information from a business standpoint to determine whether or not the project is worth the required investment. It focuses on the economic feasibility and " why " of the project, rather than a narrative description of the deliverables.

C. Accepted deliverable: These are products, results, or capabilities produced by a project and validated by the customer or sponsor as meeting their specified acceptance criteria during the Validate Scope process.

D. Work performance information: This consists of the performance data collected from various controlling processes, analyzed in context and integrated based on relationships across areas. It describes how the project is performing (e.g., status of deliverables), but it is not the initial narrative description of what is to be delivered.

According to the PMBOK® Guide, the Develop Schedule process is the process of analyzing activity sequences, durations, resource requirements, and schedule constraints to create a project schedule model for execution, monitoring, and controlling.

Schedule Network Analysis and Critical Path Method (Choice A): These are core Tools and Techniques explicitly listed for the Develop Schedule process.

Schedule Network Analysis is the overarching technique that employs various analytical methods (like CPM) to generate the project schedule model.

Critical Path Method (CPM) is used to estimate the minimum project duration and determine the amount of scheduling flexibility (float) on the logical network paths within the schedule model.

Activity List and Expert Judgment (Choice B): While Expert Judgment is a technique used here, the Activity List is an Input (from the Define Activities process), not a technique used to develop the schedule.

Milestone List and Risk Register (Choice C): These are Inputs to the process. The Milestone List identifies specific points or events, and the Risk Register provides information on risks that could impact the schedule duration or logic.

Basis of Estimates and Rolling Wave Planning (Choice D): Basis of Estimates is an Input that provides the supporting detail for duration estimates. Rolling Wave Planning is a technique used in Define Activities, where work to be accomplished in the near term is planned in detail, while work in the future is planned at a higher level.

By utilizing Schedule Network Analysis and the Critical Path Method, the project manager can identify the sequence of activities that has the least amount of scheduling flexibility and ensure that the project is completed in the shortest time possible.

In accordance with the PMBOK® Guide (Project Quality Management), the Cost of Quality (COQ) is divided into two main categories: Cost of Conformance and Cost of Nonconformance.

Cost of Nonconformance (also known as failure costs) refers to the money spent during and after the project because of failures. This is further subdivided into:

Internal Failure Costs: Failures found by the project team before the product is released to the customer (e.g., scrap, rework).

External Failure Costs: Failures found by the customer after the product is released. Liabilities, warranty claims, lost business, and repairs fall under this category. These are particularly damaging as they can lead to legal costs and a damaged organizational reputation.

Analysis of Distractors:

B. Inspections: This is a Cost of Conformance, specifically an Appraisal Cost. It is the money spent to assess quality and uncover errors before they reach the customer.

C. Training: This is a Cost of Conformance, specifically a Prevention Cost. It is an investment made to ensure the team has the skills to do the work right the first time, thereby preventing defects.

D. Equipment: Costs associated with the equipment needed to perform the work correctly or to test the product (e.g., specialized testing hardware) are generally considered Prevention or Appraisal costs, which fall under the category of Conformance.

According to the PMBOK® Guide, specifically the Monitor and Control Project Work and Control Schedule processes, a Project Manager must validate information before taking corrective or preventive actions.

Validation First: When a new Subject Matter Expert (SME) provides feedback that a schedule was " not assessed properly, " the Project Manager’s first responsibility is to verify the accuracy of this claim. The PM cannot act on an opinion without first performing a technical Review of the Schedule Baseline.

Schedule Crashing Analysis: Crashing is a schedule compression technique used to shorten the duration for the least incremental cost by adding resources. Before crashing, the PM must review the baseline to identify the Critical Path. Crashing only works on critical path activities; crashing non-critical activities provides no benefit to the project end date.

Integrity of the Baseline: A baseline is a formal, approved version of the schedule. It should not be changed (Option A) or modified via a change request (Option C) until a thorough analysis proves that a change is necessary and beneficial.

Professional Judgment: By reviewing the baseline with the SME, the PM can determine if the original assumptions were flawed or if the SME has identified a legitimate opportunity to optimize the project timeline.

Analysis of other options:

Option A: Updating the schedule baseline is a premature step. A baseline is only updated after a Change Request has been formally approved by the Change Control Board (CCB).

Option C: Initiating a change request is a " doing " step. You cannot justify a change request until you have conducted the Review (Option B) to understand the impact on cost, scope, and resources.

Option D: While the SME ' s feedback might suggest a risk, the primary issue raised is about the current assessment and optimization of the schedule. Updating the risk register is a secondary administrative task that follows the technical review of the schedule itself.

Per PMI standards, when new technical expertise suggests an error or opportunity in project planning, the Project Manager must first Review the Schedule Baseline to perform an impact analysis and validate the findings before taking further action.

According to the PMBOK® Guide, specifically within the Develop Schedule process and the Critical Path Method (CPM), the total float is a measure of schedule flexibility.

The Definition of Critical Path: The critical path is the sequence of activities that represents the longest path through a project, which determines the shortest possible project duration.

Total Float on the Critical Path: By definition, activities on the critical path have zero total float. This means there is no flexibility; any delay in a critical path activity will delay the project finish date.

Negative Float: Negative float occurs when a constraint on a finish date (a " Must Finish By " date) is violated. If the calculated early finish of the network is later than the required constraint date, the critical path will show negative float. This indicates that the project is already behind schedule relative to its constraints.

Positive Float: Positive float exists only on non-critical paths. These are sequences of activities that have " slack, " meaning they can be delayed without affecting the project completion date.

Comparison with other options:

A. Can be any number: While float can be many values, it is mathematically constrained by the network logic and project targets. It cannot be " any " number in the context of the critical path ' s definition.

B. Zero or positive: This describes a healthy, unconstrained schedule. However, it ignores the reality of negative float, which is a standard PMI concept for schedules that have missed their mandatory deadlines.

D. Depends on the calendar: While calendars (working vs. non-working days) affect the calculation of dates, the definition of the critical path float is a mathematical result of the forward and backward pass, not the calendar itself.

According to the PMBOK® Guide, the Performance Measurement Baseline (PMB) is an integrated scope-schedule-cost plan for the project work against which project execution is compared to measure and manage performance.

Components of the PMB: The PMB is formed by the integration of three specific baselines:

Scope Baseline: Includes the Project Scope Statement, WBS, and WBS Dictionary.

Schedule Baseline: The approved version of the schedule model used to compare actual results to the plan.

Cost Baseline: The approved version of the time-phased project budget, excluding management reserves.

Earned Value Management (EVM): The PMB is the fundamental reference point for EVM. When project managers calculate variances (like CV or SV) and indices (like CPI or SPI), they are measuring the project ' s current status against this integrated baseline.

Change Control: Once established, the PMB can only be changed through formal change control procedures. It is used throughout the Monitoring and Controlling process group to identify deviations from the original plan.

Analysis of Other Options:

B. Scope baseline, project management baseline, and quality baseline: " Project management baseline " is not a standard term for a specific baseline, and while quality is planned, a " quality baseline " is not a component of the PMB.

C. Cost baseline, schedule baseline, and risk baseline: There is no such thing as a " risk baseline " in official PMI terminology. Risk is managed via the Risk Register and Risk Management Plan.

D. Cost baseline, project management baseline, and schedule baseline: This option incorrectly replaces the Scope Baseline with the non-standard term " project management baseline. " Scope is a mandatory pillar of performance measurement.

According to the PMBOK® Guide and the PMI organizational theory, the level of authority a project manager possesses is directly tied to the organizational structure. In a Matrix environment, authority is shared between functional managers and project managers, but the balance shifts depending on the specific type of matrix.

Matrix-strong: In this structure, the project manager has a high to almost total level of authority. They often have a full-time staff and a dedicated project administrative staff. The power dynamic favors the project manager over the functional manager, and the project manager often controls the project budget.

Matrix-balanced: The project manager and functional manager share power and authority equally. This can often lead to conflicts regarding resource priority.

Matrix-weak: The project manager ' s role is more akin to a project coordinator or expeditor. They have very limited authority and act more as a facilitator than a manager with decision-making power.

Organic or Simple: Typically found in small businesses or startups, authority is very flexible or resides almost entirely with the owner/founder. The " Project Manager " role is often part-time or non-existent in a formal capacity.

In the hierarchy of authority defined by PMI, the only structure providing more authority than a Strong Matrix would be a Project-Oriented (Projectized) organization, where the project manager has total control. Since " Project-Oriented " is not an option here, Matrix-strong is the correct choice as it offers the highest level of authority among the listed selections.