Your FREE CAPM Flashcards 2026 – 250+ Cards

The Certified Associate in Project Management — PMI's entry-level credential for those starting a project-management career or supporting projects.

The Project Management Institute — the body that issues the CAPM and PMP and publishes the PMBOK Guide.

A Guide to the Project Management Body of Knowledge — PMI's standard; the 7th edition is principle- and value-based.

150 multiple-choice questions, answered in a single 3-hour (180-minute) session.

180 minutes (3 hours) for 150 questions.

Project Management Fundamentals & Core Concepts (36%), Predictive Plan-Based Methodologies (17%), Agile Frameworks/Methodologies (20%), and Business Analysis Frameworks (27%).

A secondary degree (high-school diploma, GED, or global equivalent) plus 23 hours of project-management education completed before the exam.

CAPM is the entry-level credential (no experience required, 23 contact hours); PMP is advanced and requires months of leading projects plus 35 contact hours.

Pass/fail. PMI sets the cut score psychometrically based on question difficulty; it does not publish a fixed passing percentage.

Three years; renew by earning 15 PDUs (professional development units) in the CCR cycle.

At a Pearson VUE test center or via online proctored testing from home.

Any individual, group, or organization that can affect, be affected by, or perceive itself affected by the project.

A temporary endeavor undertaken to create a unique product, service, or result; it has a definite start and end.

It has a defined beginning and end — it ends when objectives are met, when it's terminated, or when the need no longer exists.

A group of related projects managed together to obtain benefits not available by managing them individually.

A collection of projects, programs, and operations managed as a group to achieve strategic business objectives.

Operations are ongoing and repetitive (keeping the business running); projects are temporary and unique (creating change).

The series of phases a project passes through from start to completion: starting, organizing & preparing, carrying out the work, and closing.

The person assigned by the performing organization to lead the team responsible for achieving the project objectives.

The person or group that provides resources and support and is accountable for enabling the project's success.

The document that formally authorizes the project, names the project manager, and grants authority to apply resources.

A leadership style focused on serving and developing the team — removing impediments and enabling self-organization — rather than commanding.

A traditional hierarchy grouped by specialty; the functional manager holds authority and the project manager has little.

An organization structured around projects; the project manager has high authority and resources report to them.

A blend of functional and projectized structures; authority is shared, ranging from weak to strong matrix.

An organizational unit that standardizes project governance and shares resources, methodologies, tools, and techniques.

Conditions outside the team's control (culture, market, regulations, infrastructure) that influence the project.

The organization's own plans, processes, policies, templates, and knowledge bases used on projects.

The interrelated balance of scope, schedule (time), and cost; changing one usually affects the others, with quality at the center.

Value-based guides for behavior (stewardship, team, stakeholders, value, systems thinking, leadership, tailoring, quality, complexity, risk, adaptability, change).

Stakeholders, Team, Development approach & life cycle, Planning, Project work, Delivery, Measurement, and Uncertainty.

Deliberately adapting the approach, processes, and artifacts to fit the specific project context — there is no one-size-fits-all.

The worth, importance, or usefulness of something; projects exist to deliver value to stakeholders and the organization.

Any unique, verifiable product, result, or capability produced to complete a process, phase, or project.

A significant point or event in the project; it has zero duration and marks the completion of a major deliverable or phase.

A limiting factor that affects how the project is executed (e.g., a fixed budget, deadline, or required technology).

A factor considered true, real, or certain for planning purposes without proof; assumptions carry risk if wrong.

The documented justification for a project, showing the need, options, costs, and expected benefits and value.

Describes how and when a project's benefits will be delivered and measured against the business case.

Continuously improving and detailing a plan as more information becomes known — not the same as uncontrolled change.

The integrated document that defines how the project is executed, monitored, controlled, and closed; it includes the baselines and subsidiary plans.

An approved version of a plan (scope, schedule, or cost) against which actual performance is measured; change only via change control.

The ability to recognize and manage one's own emotions and read and influence others' — foundational to leading a team.

A stakeholder-analysis tool mapping each stakeholder by power and interest to decide how closely to engage them.

A responsibility assignment matrix marking who is Responsible, Accountable, Consulted, and Informed for each task.

The single person who owns the outcome and signs off — there is exactly one Accountable per task.

The stages of team development: forming, storming, norming, performing, and adjourning.

The team-development stage where conflict surfaces as members assert ideas; the leader should coach and resolve conflict.

Working together to a win-win that addresses everyone's needs — the most effective, durable resolution and usually the preferred answer.

Pushing one viewpoint at others' expense — a fast win-lose outcome that breeds resentment.

Retreating from or postponing the conflict, leaving it unresolved.

Emphasizing agreement over differences and conceding your position; a temporary fix at best.

Each party gives up something for a partial, lose-lose middle ground.

n(n − 1) ÷ 2, where n is the number of people; it counts the possible communication channels in a team.

A document recording knowledge gained during the project so it can improve current and future work.

A document where current issues (events affecting the project that need resolution) are recorded and tracked to closure.

A collection of logically related project activities that culminates in the completion of one or more deliverables.

A review at the end of a phase to decide whether to continue, change, or end the project.

The framework of rules, processes, and authority that guides and oversees project decisions and performance.

Authorizing the project, providing the business case and funding, and signing the project charter.

Finalizing all activities, obtaining formal acceptance, releasing resources, and recording lessons learned.

The customer's or sponsor's sign-off that deliverables meet acceptance criteria — required to close a phase or project.

Authorizing the project: developing the charter and identifying stakeholders.

Defining scope, refining objectives, and creating the plan and baselines to achieve them.

Doing the work defined in the plan to deliver the project's objectives and manage the team.

Tracking, reviewing, and regulating progress and performance, and managing changes against the baselines.

A meeting to announce the start of a project (or phase), align the team and stakeholders, and review objectives and roles.

A document defining team values, agreements, ground rules, and operating guidelines.

Defines what information is communicated, to whom, when, how, and by whom on the project.

Push sends to recipients (email); pull lets recipients access at will (portals); interactive is real-time exchange (meetings).

Deliverables are what the project produces; benefits are the value the organization realizes from using them.

Confirming the project's intended benefits and value are actually achieved, often after the project closes.

A project can finish on schedule and budget yet fail if the intended value or benefits never materialize.

Scope, schedule, and cost are determined early and the project proceeds through sequential phases; best for stable, well-understood work.

When requirements are well-defined and stable, the deliverable is clear, and change is expected to be limited.

The description of the project scope, major deliverables, assumptions, and constraints — the basis for future decisions.

A hierarchical decomposition of the total project scope into deliverables and work packages; nothing outside it is in scope.

The WBS captures all of the project work and only the project work — no more, no less.

The lowest-level deliverable in the WBS — the unit you estimate, schedule, and assign.

A document detailing each WBS component: scope of work, deliverables, owner, milestones, and acceptance criteria.

The approved scope statement, WBS, and WBS dictionary used to measure scope performance.

The uncontrolled expansion of scope without adjustments to time, cost, and resources.

Adding extras the customer didn't request — wasted effort and added risk for no agreed value.

The longest sequence of dependent activities through the schedule; it has zero total float and sets the shortest project duration.

The time an activity can be delayed without delaying the project end date (total float) or the next activity (free float).

Zero total float — any delay to a critical-path activity delays the whole project.

Compressing the schedule by adding resources to critical-path activities, which raises cost.

Compressing the schedule by performing activities in parallel that were planned in sequence, which raises risk.

A bar chart showing the schedule with activity start/finish dates and durations along a timeline.

A schematic showing project activities and their logical dependencies (predecessors and successors).

The most common relationship: a successor activity cannot start until its predecessor finishes.

Lead lets a successor start earlier (overlap); lag delays a successor (a waiting period) relative to its predecessor.

Estimate = (Optimistic + 4 × Most likely + Pessimistic) ÷ 6, which accounts for uncertainty in the estimate.

Using actual values from a similar past project as the basis — quick and cheap but less accurate (top-down).

Using a statistical relationship between historical data and variables (e.g., cost per unit) to calculate an estimate.

Estimating individual work packages and rolling them up — the most accurate but most time-consuming method.

The approved, time-phased budget used to measure and monitor cost performance, excluding management reserves.

Budget set aside for identified ('known-unknown') risks; the project manager can use it.

Budget for unforeseen ('unknown-unknown') work; it requires management approval to use and is outside the cost baseline.

An integrated method combining scope, schedule, and cost to measure and forecast project performance objectively.

The authorized budget assigned to the work scheduled to be done by a given date.

The budgeted cost of the work actually completed by a given date.

The real cost incurred for the work completed by a given date.

CV = EV − AC; a negative value means the project is over budget.

SV = EV − PV; a negative value means the project is behind schedule.

CPI = EV ÷ AC; greater than 1 is under budget, less than 1 is over budget.

SPI = EV ÷ PV; greater than 1 is ahead of schedule, less than 1 is behind.

The total authorized budget for the project's planned work.

The forecast total cost; when current performance continues, EAC = BAC ÷ CPI.

Process-focused activities that build confidence the project will meet quality requirements (managing quality).

Product-focused activities that verify deliverables meet requirements (controlling quality).

Prevention keeps errors out of the process (cheaper); inspection keeps errors out of the customer's hands.

The total cost of conformance (prevention, appraisal) plus non-conformance (internal and external failure).

The artifact recording identified risks with their probability, impact, owner, and planned responses.

Prioritizing risks by assessing probability and impact, usually with a probability-and-impact matrix.

Numerically modeling the combined effect of prioritized risks on cost and schedule objectives.

Avoid, transfer, mitigate, accept, and escalate — for negative risks (threats).

Exploit, share, enhance, accept, and escalate — for positive risks (opportunities).

Reduce the probability or impact of a threat to an acceptable level.

Shift the impact of a threat to a third party (e.g., insurance, warranties, contracts).

Obtaining goods or services from outside the project team, governed by contracts.

A contract with a set price; the seller carries most of the cost risk.

A contract paying the seller's allowable costs plus a fee; the buyer carries more cost risk.

A hybrid paying hourly/unit rates with no fixed total; cost risk is shared.

A narrative description of the products, services, or results to be supplied under a contract.

A formally chartered group that reviews, approves, or rejects requested changes to the project.

The process of reviewing all change requests and managing changes to deliverables and baselines.

Validate Scope is formal acceptance of deliverables by the customer; Control Quality checks correctness against requirements first.

Adjusting start/finish dates based on resource constraints to balance demand with available supply; it may extend the schedule.

The approved version of the schedule model used to measure schedule performance.

Dividing project scope and deliverables into smaller, more manageable parts (used to build the WBS).

Planning near-term work in detail and future work at a higher level, elaborating it as the project progresses.

Controlling product characteristics and versions so the team knows the current approved state of deliverables.

Comparing planned to actual performance to determine the cause and degree of difference and decide on corrective action.

Corrective action realigns performance with the plan; preventive action reduces the probability of future negative outcomes.

An action to fix a nonconforming product component identified during quality control.

A bar chart showing the frequency distribution of data — a quality tool for spotting patterns.

A histogram ordered by frequency illustrating the 80/20 rule — focusing on the vital few causes.

A chart showing process performance over time against upper and lower control limits to detect whether it is stable.

Seven consecutive points on one side of the mean signal a non-random trend that should be investigated.

A quality tool plotting two variables to reveal the relationship or correlation between them.

A structured form for collecting and tallying data in real time, often to count defects by category.

The specific measures and how they are checked to determine whether the project meets quality requirements.

The degree of uncertainty an organization or stakeholder is willing to accept in pursuit of reward.

The level of risk exposure above which action is required and below which it may be accepted.

A grid rating each risk by likelihood and consequence to prioritize which risks need attention.

A new risk that arises as a direct result of implementing a risk response.

The risk that remains after a planned response has been implemented.

The person responsible for monitoring a risk and carrying out the agreed response.

Deciding whether to perform work internally or procure it externally based on cost, capability, and risk.

Requests sent to sellers: RFP (proposal), RFQ (quote), and IFB (sealed bid) to solicit competitive responses.

The standards used to evaluate and choose among seller proposals (price, technical capability, past performance).

Verifying all work and deliverables are complete and acceptable and formally closing the procurement.

Techniques (e.g., critical path method) used to calculate early/late dates and identify schedule flexibility.

Calculating early start and early finish dates by working forward through the schedule network.

Calculating late start and late finish dates by working backward from the project end date.

Mandatory (hard logic) is required by the nature of the work; discretionary (soft logic) is a preferred best practice.

A relationship between project and non-project activities, often outside the team's control (e.g., a vendor delivery).

The project calendar shows working days for project work; resource calendars show when each resource is available.

Summing the estimated costs of work packages up the WBS to establish the cost baseline.

Comparing planned spending to any funding limits and adjusting the schedule of work to stay within them.

The expected cost to finish the remaining project work; ETC = EAC − AC.

The forecast budget surplus or deficit; VAC = BAC − EAC. A negative VAC forecasts an overrun.

The cost efficiency required on remaining work to meet a goal (e.g., (BAC − EV) ÷ (BAC − AC)).

An iterative, incremental approach that fixes time and cost and flexes scope by priority, delivering value in short cycles.

Four values: individuals & interactions over processes & tools; working software over documentation; customer collaboration over contract negotiation; responding to change over following a plan.

When requirements are uncertain or evolving, early and frequent feedback is valuable, and the team can deliver in increments.

An agile framework delivering work in fixed timeboxes (sprints) with set roles and ceremonies.

A short, fixed-length iteration (often 1–4 weeks) in which a Scrum team produces a usable increment.

The Scrum role accountable for maximizing value and managing (ordering) the product backlog.

The servant-leader who coaches the team, facilitates events, and removes impediments — does not assign work.

The cross-functional Scrum members who do the work to deliver a usable increment each sprint; they self-organize.

An ordered, evolving list of everything that might be needed in the product, owned by the product owner.

The set of product-backlog items selected for a sprint plus the plan to deliver them; owned by the developers.

The event that starts a sprint: the team selects backlog items it can complete and sets a sprint goal.

A short (≤15 min) daily sync where developers inspect progress toward the sprint goal and adapt the plan.

The event at the end of a sprint to demo the increment to stakeholders and gather feedback.

The event where the team inspects how it worked and commits to improvements for the next sprint.

A usable, potentially shippable piece of the product produced each sprint that meets the definition of done.

The shared, agreed checklist a backlog item must meet to be considered complete.

A short requirement from the user's perspective: 'As a [role], I want [goal] so that [benefit].'

The conditions a user story must satisfy to be accepted by the product owner.

A large body of work that can be broken down into multiple user stories.

The amount of work (e.g., story points) an agile team completes per iteration, used to forecast capacity.

A relative unit estimating the effort/complexity of a backlog item, not hours.

A consensus estimating technique where the team reveals story-point estimates simultaneously and discusses differences.

A chart showing remaining work over time in a sprint or release; the line trends down toward zero.

A chart showing completed work rising toward the total scope line over time.

An agile method based on visualizing work and limiting work in progress (WIP) to improve continuous flow.

A cap on how many items can be in a workflow stage at once, used in Kanban to improve flow and expose bottlenecks.

A visual board with columns (e.g., To Do, Doing, Done) showing work items as they move through the workflow.

Scrum uses fixed sprints, set roles, and a sprint commitment; Kanban uses continuous flow with WIP limits and no required roles or sprints.

The smallest releasable version of a product that delivers value and enables learning.

Allocating a fixed maximum amount of time to an activity (e.g., a sprint or a meeting).

A delivery approach blending predictive and agile elements, tailored to the project and organization.

Leaders serve the team — removing impediments, coaching, and protecting focus — so a self-organizing team can perform.

A team that decides internally how to accomplish its work rather than being directed by a manager.

A highly visible display (e.g., a task board or burndown chart) that broadcasts progress to anyone passing by.

The ongoing activity of adding detail, estimates, and order to product-backlog items.

A short, time-boxed research task used to reduce uncertainty about a story or technical approach.

A rhythm of activities conducted throughout a project (e.g., the regular sprint length).

Continuous improvement — the team reflects on its process and chooses concrete changes to try next.

Ordering the product backlog by value, risk, and dependencies so the most valuable work is done first.

Scrum's foundation: decisions are based on observation and experiment via transparency, inspection, and adaptation.

The agreed checklist a backlog item must meet before the team will pull it into a sprint.

A high-level visual of the product's direction and planned releases over time.

Mapping which features/increments will be delivered in which release to meet a goal or date.

Two or more team members working together on the same item to improve quality and share knowledge.

A small set of concrete, actionable improvements the team commits to for the next iteration.

Frequent increments produce early feedback, reduce risk, and let priorities adapt as understanding grows.

Adaptive (agile) flexes scope through iterations; predictive fixes scope up front and proceeds sequentially.

Iterative refines the same work through repeated cycles; incremental builds the product in successive usable pieces.

Engaging the customer continuously throughout development rather than only at contract or hand-off.

Agile favors delivering usable product as the primary measure of progress over exhaustive documentation.

Someone who guides individuals and teams in adopting agile practices and improving their ways of working.

Removing impediments, shielding the team from distractions, facilitating, and developing people.

Information flowing in the background among co-located team members, who absorb relevant details by being near each other.

Inspect progress toward the sprint goal and adapt the plan — it is for the developers, not a status report to managers.

The product owner, based on value, risk, and stakeholder priorities.

The single objective for a sprint that gives the increment coherence and guides the team's decisions.

Commitment, courage, focus, openness, and respect.

Twelve principles behind the Manifesto, including early/continuous delivery, welcoming change, and sustainable pace.

Working at a steady, indefinitely maintainable rate to keep quality high and avoid burnout.

From idea to refined and estimated, to selected for a sprint, to done — value-ordered throughout.

A piece of functionality that delivers value to a stakeholder; larger than a story, smaller than an epic.

The review inspects the product (with stakeholders); the retrospective inspects the team's process.

A chart showing the amount of work in each workflow state over time, used to spot bottlenecks in Kanban.

Lead time is from request to delivery; cycle time is from when work starts to when it's done.

The set of activities to identify business needs and recommend solutions that deliver value to stakeholders.

The BA defines and manages requirements and the solution scope; the PM manages the project scope, schedule, and delivery.

A condition or capability needed by a stakeholder to solve a problem or achieve an objective.

High-level needs of the organization — the why behind the project (goals, objectives, value).

The needs of a stakeholder or stakeholder group that must be met to achieve the business requirements.

The features and qualities of a solution; split into functional and non-functional requirements.

Functional describes what the solution must do; non-functional describes how well it must do it (performance, security, usability).

Temporary capabilities needed to move from the current state to the future state (e.g., data conversion, training).

Drawing out information from stakeholders and sources to discover requirements (interviews, workshops, observation, surveys).

Interviews, focus groups, facilitated workshops, surveys/questionnaires, observation, prototyping, document analysis, and brainstorming.

A structured session bringing key stakeholders together to define, refine, and reconcile requirements quickly.

Building an early working model of the solution to elicit and validate requirements through feedback.

A grid linking each requirement to its origin and to deliverables, tests, and objectives, ensuring nothing is lost.

To track requirements through the life cycle, confirm each delivers value, and manage scope and change.

Describes how requirements will be analyzed, documented, prioritized, traced, and managed throughout the project.

A prioritized list of requirements or work items, refined and reprioritized as understanding grows.

The conditions that must be met for a stakeholder to accept a requirement or solution as complete and correct.

Validation confirms requirements deliver business value (right thing); verification confirms they are well-formed and meet quality (built right).

Assessing how well a delivered solution meets the business need and identifying improvement opportunities.

Current state is how things work today; future state is the desired condition the solution should achieve.

Comparing the current state to the desired future state to identify what must change to close the difference.

Identifying the underlying cause of a problem (e.g., the 5 Whys or a fishbone diagram) rather than treating symptoms.

A cause-and-effect diagram that groups potential causes of a problem into categories to find root causes.

Evaluating Strengths, Weaknesses, Opportunities, and Threats to inform decisions and solution options.

Classifying requirements as Must have, Should have, Could have, and Won't have (this time) to manage scope.

Identifying stakeholders and assessing their influence, attitudes, and requirements to plan engagement.

A description of how an actor interacts with a system to achieve a goal, including the main and alternate flows.

A visual representation of a business process showing the sequence of activities, decisions, and flows.

A high-level model showing the system, its boundaries, and how it interacts with external entities.

Tools that map combinations of conditions to outcomes, clarifying complex business rules.

A specific, testable directive that defines or constrains some aspect of the business (e.g., approval thresholds).

Helping clarify, detail, and prioritize requirements so the team always works on the most valuable, well-understood items.

An agreed, approved set of requirements that changes only through a controlled change process.

Managed through impact assessment and approval; uncontrolled requirement changes drive scope creep.

Performance, scalability, security, reliability, usability, availability, and compliance.

The problem or opportunity, defined by its impact, that justifies starting a project or initiative.

The boundaries of the solution that will satisfy the business need and stakeholder requirements.

A group technique to generate many ideas or potential requirements quickly without early judgment.

Reviewing existing materials (procedures, contracts, regulations) to discover relevant requirements.

Watching how work is actually performed to elicit requirements that stakeholders may not articulate.

A set of written questions to gather information from many stakeholders efficiently, often when they are dispersed.

A direct conversation with one or a few stakeholders to draw out detailed requirements and expectations.

Roughly a quarter of the exam covers BA frameworks because requirements drive the value a project delivers.

Ranking requirements by value, cost, risk, and dependencies to decide order and what is in or out of scope.

Reviewing elicited information with stakeholders to ensure it is accurate, complete, and consistent before use.

Product/solution scope is the features of the product; project scope is the work needed to deliver it.

Future cash flows discounted to today minus the investment; a positive NPV adds value and a higher NPV is preferred.

The percentage gain from a project relative to its cost; higher is better.

The time it takes for a project's cumulative cash inflows to recover its initial investment; shorter is better.

Comparing the expected costs of a project to its expected benefits to support a go/no-go decision.

An assessment of whether a proposed solution is technically, operationally, and economically practical.

The stages a solution passes through from concept and development to operation and eventual retirement.

Determining how business-analysis work will be performed: approach, stakeholders, governance, and information management.

Building and maintaining working relationships with stakeholders to keep requirements accurate and supported.

Managing and maintaining requirements from inception through retirement, including tracing, prioritizing, and approving them.

Assigning requirements to solution components and releases to deliver the most value within constraints.

Obtaining agreement on and sign-off of requirements from the responsible stakeholders before development.

Keeping requirements accurate and current and reusing them where possible across initiatives.

The metrics used to evaluate whether a delivered solution is meeting the business need and delivering value.

Identifying and assessing risks related to requirements and the solution so they can be managed.

Continuously detailing, estimating, and prioritizing requirements so the team works on the highest-value items.

Grouping ideas or requirements into related clusters to organize and analyze them.

Interviews suit deep, detailed input from a few; surveys suit broad input from many, dispersed stakeholders.

A visual technique that branches ideas from a central concept to explore and organize requirements.

Comparing practices, processes, or metrics against peers or standards to identify improvement opportunities.

Reconciled through negotiation, prioritization, and stakeholder collaboration to reach an agreed, consistent set.

Metadata about each requirement (source, priority, owner, status, version) that supports tracing and management.