Free PMI Certified Associate in Project Management CAPM Exam Questions

According to the PMBOK Guide, specifically within the Sequence Activities process of Project Schedule Management, the Precedence Diagramming Method (PDM) is a technique used for constructing a schedule model in which activities are represented by nodes and are graphically linked by one or more logical relationships to show the sequence in which the activities are to be performed.

Finish-to-Start (FS): This is the most commonly used type of precedence relationship. In this relationship, a successor activity cannot start until a predecessor activity has finished.

Example: The 'Install Hardware' (Successor) activity cannot start until the 'Build Foundation' (Predecessor) activity is finished.

Logical Significance: FS relationships are the default in most project management software because they represent the most intuitive and frequent flow of work in both traditional and agile projects.

Comparison with other options:

A . Start-to-start (SS): A successor activity cannot start until a predecessor activity has started. This is often used for overlapping activities but is less common than FS.

B . Start-to-finish (SF): A successor activity cannot finish until a predecessor activity has started. This is the least commonly used relationship and is rarely seen in standard project schedules.

D . Finish-to-finish (FF): A successor activity cannot finish until a predecessor activity has finished. This is used when activities must conclude at the same time (e.g., 'Documentation' cannot finish until 'Coding' finishes).

According to the PMBOK Guide, group decision-making techniques are used to reach a conclusion when multiple alternatives or requirements are being evaluated. These are primarily utilized in the Collect Requirements and Validate Scope processes.

Plurality: This is a decision-making technique where a decision is reached by the largest block in a group, even if a majority is not achieved. For example, if there are three options and the votes are split $40\%$, $35\%$, and $25\%$, the option with $40\%$ wins.

Other Group Decision-Making Techniques:

Unanimity: Everyone agrees on a single course of action.

Majority: Support from more than $50\%$ of the members of the group.

Dictatorship: One individual makes the decision for the entire group.

Analysis of Other Options:

A . Brainstorming: This is a Data Gathering technique used to identify a list of ideas in a short period of time. It is used to generate options, not to decide which option to pursue.

B . Focus groups: This is also a Data Gathering technique. It brings together prequalified stakeholders and subject matter experts to learn about their expectations and attitudes about a proposed product or service.

C . Affinity diagram: This is a Data Representation technique. It allows large numbers of ideas to be classified into groups for review and analysis. It organizes ideas but does not function as a decision-making mechanism.

According to the PMBOK Guide, specifically within the Control Costs process, Earned Value Management (EVM) is used to forecast the project's financial outcome based on current performance.

The Scenario: The question provides a Cost Performance Index (CPI) and an Estimate at Completion (EAC), while stating that the current performance is expected to continue for the remainder of the project.

The Formula: When the current $CPI$ is expected to continue, the formula for $EAC$ is:

$$EAC = \frac{BAC}{CPI}$$

Solving for BAC: To find the original budget (Budget at Completion or $BAC$), we must rearrange the formula:

$$BAC = EAC \times CPI$$

The Calculation:

$$BAC = \$1000 \times 0.80$$

$$BAC = \$800$$

This result indicates that the project was originally budgeted for $\$800$, but because it is performing inefficiently (spending $\$1.00$ to get $\$0.80$ worth of work), it is now expected to cost $\$1000$ to complete.

Analysis of Other Options:

B . $1000: This is the $EAC$ (the forecasted total cost), not the $BAC$ (the original budget).

C . $1250: This would be the result if you incorrectly divided $EAC$ by $CPI$ ($\$1000 / 0.80 = \$1250$), which does not align with the standard EVM mathematical relationships for this scenario.

D . $1800: This number has no mathematical basis in the provided EVM data.

According to the PMBOK Guide, the Develop Team process includes the specific output of Team Performance Assessments. As a project manager implements development strategies (such as training, team building, and ground rules), they must evaluate the effectiveness of these efforts.

Purpose of Assessments: The formal evaluation of the project team's effectiveness. This is not just about technical output, but about how the team is functioning as a cohesive unit.

Evaluation Criteria: Successful team development is measured by:

Improvements in individual skills that allow members to perform tasks more effectively.

Improvements in competencies and personality attributes that help the team work together.

Reduced staff turnover rate.

Increased team cohesiveness where members share information and help each other.

Continuous Feedback: These assessments are used to identify the specific training, coaching, or changes required to improve team performance.

Analysis of Other Options:

B . Hold weekly meetings to engage every member: While meetings are a tool for communication and engagement, the meeting itself is an activity, not a method of evaluation. You would use the results of those meetings to help inform the performance assessment.

C . Complete a personal skill assessment on each team member: While individual assessments (like the Individual Development Plan) are part of the process, they only measure one person. The question asks about project team development, which requires a broader assessment of the group's collective synergy.

D . Provide recognition awards to team members: This is a Tool and Technique used during the Develop Team process to motivate and reinforce positive behavior. It is a reward for performance, not the formal analytical tool used to evaluate the overall development of the team.

According to the PMBOK Guide, the Plan Quality Management process is the process of identifying quality requirements and/or standards for the project and its deliverables, and documenting how the project will demonstrate compliance with quality requirements and/or standards.

The primary inputs for this process include:

Project Management Plan: Specifically the requirements management plan, risk management plan, stakeholder engagement plan, and the scope baseline (which contains the project scope statement and WBS).

Project Documents: Key documents used as inputs include the assumption log, requirements documentation, requirements traceability matrix, risk register, and stakeholder register.

Enterprise Environmental Factors (EEF): These include governmental regulations, rules, standards, and guidelines specific to the application area.

Organizational Process Assets (OPA): These include the organization's quality policy, procedures, and historical databases from previous projects.

Analysis of Other Options:

A . Quality metrics, project documents, and financial performance: Quality metrics are an output of the Plan Quality Management process, not an input. Financial performance is generally not a direct input to quality planning.

B . Quality management plan, project documents, and quality metrics: Both the Quality Management Plan and Quality Metrics are outputs of this specific process. They cannot be inputs to the process that creates them.

D . Project management plan, quality metrics, and project documents: Again, quality metrics are an output of this process. This option incorrectly identifies an output as an input.

According to the PMBOK Guide, specifically within the Develop Schedule process, the Critical Path Method (CPM) is the primary technique used to estimate the minimum project duration and determine the amount of scheduling flexibility on the logical network paths within the schedule model.

Determining Duration: CPM calculates the theoretical start and finish dates for all activities without regard for any resource limitations. By performing a forward and backward pass analysis through the schedule network, the project manager identifies the sequence of activities that represents the longest path through the project.

The Critical Path: The 'critical path' is the sequence of activities that determines the shortest time possible to complete the project. Any delay in an activity on the critical path will directly impact the project's finish date.

Total Float: This method also identifies the 'float' or 'slack' (the amount of time an activity can be delayed without delaying the project finish date) for non-critical activities.

Answering the Sponsor: When a sponsor asks 'how soon' a project can be finished, the PM uses CPM to provide a data-driven completion date based on the logical sequence of work.

Analysis of other options:

Scope baseline (Option A): This is a component of the project management plan that includes the project scope statement, WBS, and WBS dictionary. While it defines what work needs to be done, it does not provide information on when or how fast that work can be completed.

Decomposition (Option B): This is a technique used in both Create WBS and Define Activities. It involves breaking down project deliverables into smaller, more manageable components. It is a prerequisite for scheduling but does not calculate the project duration itself.

Work breakdown structure (Option D): The WBS is a deliverable-oriented hierarchical decomposition of the total scope. Like the scope baseline, it identifies the work packages but does not include the logical dependencies or durations required to calculate a project's end date.

Per PMI standards, the Critical Path Method is the essential tool for schedule analysis, providing the project manager with the specific date the project can be completed based on the current sequence of activities.

According to the PMBOK Guide, specifically in the sections regarding Project Initiation and the Develop Project Charter process, projects are authorized by an organization to respond to specific business drivers.

Internal Business Needs: This is the foundational factor for project selection. A project is a means to achieve a strategic goal or solve a specific problem within the organization. These needs are typically documented in the Business Case, which justifies the investment based on market demand, organizational need, customer request, legal requirement, or ecological impacts.

Strategic Alignment: Projects are selected based on how well they align with the organization's strategic objectives. If a project does not meet an internal business need or provide value to the organization, it is unlikely to be selected, regardless of its budget or schedule.

The Selection Process: Organizations often use a variety of selection criteria (such as Net Present Value, Internal Rate of Return, or scoring models) to evaluate which projects best address their internal business needs and offer the highest return on investment.

Analysis of Other Options:

A . Types of constraints: While constraints (such as scope, time, and cost) are critical to manage once a project is selected, they are secondary to the reason for doing the project in the first place.

C . Budget: The availability of a budget is a requirement for a project to proceed, but the decision to allocate that budget is based on the underlying business need. A project is not selected simply because money is available; it is selected because there is a need that justifies the expenditure.

D . Schedule: Similar to budget, the schedule is a constraint. A project must be feasible within a certain timeframe, but the timeframe itself is not the most important driver for selection---the business outcome is.

According to the PMBOK Guide, specifically regarding the Project Manager's Role and Project Integration Management, issues involving the project's continued viability are business-level concerns.

Business Value and Viability: The project manager is responsible for delivering the project's outputs, but the Project Sponsor is the owner of the Business Case. When a competitor releases a product that potentially makes the current project redundant, it threatens the project's strategic alignment and expected return on investment (ROI).

The Role of the Sponsor: Because the sponsor provides the financial resources and is accountable for the project's business benefits, they are the only ones with the authority to decide whether to continue, pivot, or terminate the project based on the new market reality.

Escalation: This is not a technical project issue that can be handled via a standard change request or risk mitigation plan within the project's boundaries. It is a high-level strategic risk that must be escalated immediately so the organization can perform a cost-benefit analysis of finishing the project versus stopping it.

Analysis of other options:

Initiate change control (Option A): Change control is used for modifications to the project scope, schedule, or budget. It is not the appropriate mechanism for deciding the existential fate of a project due to external market shifts.

Address risk mitigation (Option B): Mitigation is done to reduce the impact of a risk. Once the competitor has already released the product, the threat has realized into an issue. You cannot 'mitigate' the fact that a competitor's product now exists; you must decide if your product still has value.

Initiate project closure (Option D): A project manager does not have the authority to unilaterally close a project because of a competitor's move. Closure only happens after the sponsor or a steering committee formally decides to terminate the project.

Per PMI standards, the project manager must ensure the project remains aligned with organizational goals. When an external event significantly alters the business value, the Project Sponsor must be engaged to re-evaluate the project's justification.

According to the PMBOK Guide, specifically within the Develop Project Charter process, the project charter documents high-level information that authorizes the project manager to begin work. One of the most critical elements for governance is the definition of 'Exit Criteria.'

Defining Exit Criteria: These are the specific conditions or standards that must be met to officially close a project or, more commonly, to complete a specific Project Phase. Exit criteria ensure that all deliverables have been met, all activities are finished, and the project is ready to move to the next stage or final closure.

Purpose of Phase Gates: Exit criteria are often evaluated at 'Phase Gates' (also known as kill points or stage gates). Without clearly defined exit criteria in the project charter, it becomes difficult to determine whether a phase has been successfully completed, leading to 'project drift' or incomplete transitions.

Analysis of other options:

Purpose (Option A): The purpose (or Business Case) explains why the project was initiated and the strategic goals it intends to achieve. It does not provide the technical or procedural conditions for closing a phase.

Approval requirements (Option B): These define who has the authority to sign off on the project and what constitutes project success. While related, approval requirements focus on the 'who,' whereas exit criteria focus on the 'what' and the specific conditions of the work itself.

High-level requirements (Option D): These describe the characteristics of the product, service, or result that the project must deliver. While the fulfillment of requirements is often part of the exit criteria, requirements alone do not define the procedural steps or conditions for phase transition.

Per PMI standards, establishing Exit criteria early in the project charter provides the project manager and the sponsor with a objective framework for measuring progress and ensuring the project remains on track through each phase of its lifecycle.

According to the PMBOK Guide, the process of formalizing acceptance of the completed project deliverables is known as Verify Scope (Note: In newer editions of the PMBOK Guide, this is referred to as Validate Scope).

Primary Objective: The key benefit of this process is that it brings objectivity to the acceptance process and increases the probability of final product, service, or result acceptance by validating each deliverable.

Key Output: The primary output of this process is Accepted Deliverables. These are deliverables that have been completed and signed off on by the customer or sponsor, indicating formal acceptance.

Comparison with Quality Control:

Verify Scope is primarily concerned with the acceptance of the deliverables by the stakeholders.

Perform Quality Control is primarily concerned with correctness of the deliverables and meeting the quality requirements specified for the deliverables. Quality Control is generally performed before Verify Scope, although they can be performed in parallel.

Why other options are incorrect:

Control Scope: This is the process of monitoring the status of the project and product scope and managing changes to the scope baseline.

Develop Schedule: This is a planning process focused on analyzing activity sequences, durations, and resource requirements to create the project schedule model.

According to the PMBOK Guide, the Plan Cost Management process creates the Cost Management Plan, which is a subsidiary of the Project Management Plan. This document defines how the project costs will be planned, structured, and controlled. It does not contain the actual dollar amounts (estimates) but rather the rules for managing them.

Control Thresholds (Choice D): This is a key component of the Cost Management Plan. Control thresholds are variance thresholds (typically expressed as a percentage) that specify the allowed amount of variation before some action needs to be taken. For example, the plan might state that a 5% variance in cost requires a status report, while a 10% variance requires a formal change request. Other components include units of measure, levels of precision, and organizational procedure links.

Cost Baseline (Choice A): The cost baseline is the approved version of the time-phased project budget. It is an output of the Determine Budget process, not a component of the Cost Management Plan itself. The plan describes how to develop the baseline, but does not contain it.

Cost Estimates (Choice B): These are the quantitative assessments of the probable costs required to complete project work. They are the output of the Estimate Costs process.

Basis of Estimates (Choice C): This document provides the supporting detail behind the cost estimates (assumptions, constraints, range of possible results). Like the estimates themselves, this is an output of the Estimate Costs process.

By establishing Control Thresholds in the planning phase, the project manager sets clear expectations for when a project's financial performance is considered 'out of bounds,' allowing for efficient monitoring and controlling throughout the project life cycle.

According to the PMBOK Guide (6th and 7th Editions) and the PMI Lexicon of Project Management Terms, the definition of a project is a 'temporary endeavor undertaken to create a unique product, service, or result.'

Why Choice A is correct: This is the foundational definition of a project.

Temporary: Every project has a definite beginning and end.

Unique: The outcome of a project is distinct in some way from all other products, services, or results. Even if a project is to build a house similar to others, the location, timing, and specific circumstances make it unique.

Business Value: Projects are initiated by organizations to drive change and reach a future state, often motivated by market demand, strategic opportunities, social needs, or legal requirements.

Analysis of other options:

B and C: While a project might incidentally teach discipline or increase understanding of project management, these are educational by-products, not the reason a project is undertaken. These relate more to Organizational Process Assets (OPAs) or corporate training.

D: Achieving better management of resources is typically a goal of Portfolio or Program Management, or a functional management objective. While a project must manage its own resources efficiently, the underlying purpose of the project itself is to deliver the specific unique outcome.

In summary, the Standard for Project Management clarifies that projects exist to bring about value (economic, social, or environmental) through the delivery of a specific, unique objective.

In accordance with the PMBOK Guide, the Plan Risk Responses process identifies several strategies for dealing with negative risks or threats.

Avoid: Risk avoidance is a strategy where the project team acts to eliminate the threat or protect the project from its impact. This typically involves changing the project management plan to eliminate the risk entirely. Common examples of avoidance include extending the schedule, changing the strategy, or, as mentioned in the question, reducing or removing scope that is deemed too high-risk for the organization to manage.

Transfer: This involves shifting the impact and ownership of a threat to a third party (e.g., through insurance, performance bonds, or warranties). It does not eliminate the risk from the project scope; it simply makes another party responsible for the financial consequences.

Exploit: This is a strategy used for positive risks (opportunities), not threats. It seeks to ensure that the opportunity is realized.

Accept: This strategy indicates that the project team has decided not to act against a risk. It can be passive (doing nothing) or active (establishing a contingency reserve).

Per PMI standards, when a project manager decides that a specific technical deliverable or scope element is beyond the team's risk appetite, the most effective way to 'Avoid' that risk is to remove that requirement from the project scope statement.

According to the PMBOK Guide, any change to a project deliverable, project management plan, or project document must be processed through the Perform Integrated Change Control process.

Handling Defects and Modifications: When defects are identified that require a modification to functionality (a change in scope or product requirements), it is not enough to simply fix the defect. The change must be formally requested and evaluated for its impact on the project's constraints (cost, time, scope, and quality).

Stakeholder Buy-in: The core of 'obtaining stakeholder buy-in' for changes lies within the Change Control Board (CCB) or the formal change process. This process ensures that the Sponsor, Customer, and other key stakeholders review the change, understand its implications, and provide formal approval or rejection. This prevents 'scope creep' and ensures all parties are aligned before the modification is implemented.

Analysis of other options:

Control Schedule (Option A): This process is focused on monitoring the status of project activities to update progress and manage changes to the schedule baseline. It does not provide the framework for approving functional modifications.

Perform Qualitative Risk Analysis (Option B): This involves prioritizing individual project risks by assessing their probability and impact. While a defect could be viewed as a realized risk (an issue), the process for getting 'buy-in' for a fix is the change control process, not risk analysis.

Control Scope (Option D): This process monitors the status of the project and product scope. While it identifies the need for a change (variance), the actual approval and 'buy-in' for that change happen through Integrated Change Control.

Per PMI standards, the project manager is responsible for ensuring that no changes are made to the project's baselines without going through the Perform Integrated Change Control process, which serves as the formal mechanism for stakeholder communication and agreement regarding modifications.

According to the PMBOK Guide, the Plan Procurement Management process involves documenting project procurement decisions, specifying the approach, and identifying potential sellers. A key output of this process is the Procurement Strategy.

Once the make-or-buy analysis is complete and the organization decides to procure goods or services from an external source, the project manager must define how the procurement will be executed. The procurement strategy typically includes:

Delivery Methods: For professional services, this might involve specifying whether the work is a 'turnkey' project, a design-build approach, or a sub-contracting arrangement. For construction, it defines the relationship between the owner, designer, and contractor.

Contract Payment Types: This defines how the risk is shared between the buyer and the seller. Common types include Fixed-Price (FP), Cost-Reimbursable (CR), and Time and Material (TandM).

Procurement Phases: This defines the sequencing of the procurement, such as whether there will be a pre-qualification phase, a formal bidding phase, and how the procurement is integrated into the overall project schedule.

Why other options are incorrect:

Option B: Make-or-buy decisions and the Procurement Statement of Work (SOW) are separate, high-level outputs or components of the procurement documentation. The 'Procurement Strategy' specifically refers to the methods of delivery and payment.

Option C: Vendor selection criteria and stakeholder roles are part of the broader Procurement Management Plan. While important, they describe the selection process and governance, rather than the strategic structure of the procurement itself.

Option D: A timetable is a schedule-related document, and product cost is a budget/estimate factor. These are constraints or data points but do not constitute the 'strategy' for how the procurement contract and delivery will be managed.