CAPM Exam Outline and 2026 Domain Weights

Four domains, one integrated exam

The current CAPM outline divides the exam into Project Management Fundamentals and Core Concepts (36%), Predictive, Plan-Based Methodologies (17%), Agile Frameworks and Methodologies (20%), and Business Analysis Frameworks (27%). The percentages describe the approximate blueprint share for each domain. They do not promise exact item counts on a particular exam form. With 150 total items, multiplying by the weights gives rough study-planning estimates of 54, 25, 30, and 41. But 15 items are unscored pretest questions and candidates are not told which ones, so do not treat those calculations as a forecast of scored questions.

The outline is organized around tasks candidates should understand and perform. Learning a definition is useful only when you can apply it to a situation: identify who should decide, what information is missing, which plan is affected, or how the team should check that a result meets a need. Scenarios may draw on several domains at once. A requirements change, for example, can involve stakeholder analysis, predictive change control, agile prioritization, and value measurement.

Fundamentals and Core Concepts: 36%

This is the largest domain. It establishes the common frame for project work: what makes an effort a project, how projects differ from ongoing operations, how roles interact, how life cycles shape delivery, and how governance, ethics, stakeholders, constraints, risks, and value influence decisions. A project is temporary and creates a unique product, service, or result. Operations are ongoing activities that sustain a business. A project can hand a new service into operations, so transition planning matters.

Suppose a hospital performs daily patient scheduling and also launches a new scheduling platform. Scheduling appointments is an operational process. Designing, configuring, testing, and deploying the replacement platform is a project. A good project plan includes not just installation but training, data migration, support ownership, acceptance, and transition. Treating

Understand the purpose of roles, while recognizing that titles vary by organization. A sponsor connects the project to organizational support and may resolve high-level barriers. A project manager coordinates planning, communication, and delivery. Team members perform project work. Stakeholders affect or are affected by the outcome. A business analyst helps clarify needs and requirements; a product owner or business representative may set priorities in adaptive work. In a scenario, choose the person with the relevant authority or knowledge rather than assuming every decision belongs to the project manager.

Separate a risk from an issue. A risk is uncertain and may occur; an issue has already occurred. If a supplier might deliver late, record and assess the risk, identify an appropriate response, and monitor it. Once the delivery is late, manage the issue, assess the impact, communicate, and take action within authority. A team should not silently change an approved baseline or conceal a variance to make a report look better. Transparency supports a timely decision.

Predictive, Plan-Based Methodologies: 17%

Predictive methods work well when the important requirements, dependencies, and acceptance criteria can be understood early enough to plan a sequence of work. CAPM candidates should understand planning and control across scope, schedule, cost, quality, resources, communications, risk, procurement, and stakeholders. These plans interact. Adding a deliverable may require more work, time, money, testing, suppliers, and communication; an assessment should consider those effects before anyone commits.

A work breakdown structure decomposes project scope into manageable components. Activities and dependencies inform the schedule. Estimates support a cost plan. A baseline is the approved reference for monitoring performance. It is not a reason to ignore changing conditions. When a request would change accepted scope, clarify it, analyze likely impacts, and use the agreed change process. After approval, update relevant plans and communicate the decision.

Example: a facilities team has a fixed inspection date and equipment that must arrive before installation. A department requests a second room after the baseline is approved. Starting immediately could affect procurement, installation, testing, and the inspection date. The responsible move is to clarify the need, estimate effects, and route the change to the authorized decision maker. If the request is rejected or deferred, record the outcome so the requester understands the decision.

Predictive does not mean immutable. A project can respond to evidence and approved change. Monitor actual work against the plan, investigate significant variance, forecast what it means for objectives, and recommend a response. Reporting a late activity alone does not resolve its cause; changing the target without approval does not make performance better. A useful answer addresses the problem while respecting authority and the project’s decision process.

Agile Frameworks and Methodologies: 20%

Agile approaches deliver in increments and use feedback to refine what should happen next. They are useful when user needs may evolve and a team can show working outcomes. The domain covers agile principles, roles, planning, prioritization, iterations or flow, and adaptation. Agile teams still have goals, quality expectations, dependencies, budgets, and accountability. They make a plan at a useful level and revise it as they learn.

A backlog is an ordered set of potential work. The person responsible for business priorities helps order it by value, risk, and need; the team considers capacity and technical work. In an iteration-based approach, the team selects a realistic amount, collaborates to complete it, and inspects the result. In flow-based work, the team manages work in progress and seeks steady movement. Do not assume every agile team uses identical events or titles.

Imagine a city team building a permit portal. A pilot shows residents cannot tell which documents are required. The team should understand the feedback, clarify the user problem, and consider a small high-value improvement. Defending the original screen because it matched an old note ignores evidence. Promising a broad redesign immediately ignores capacity and priorities. A balanced decision makes the request visible and orders it with other work.

Distinguish iteration from release. An iteration is a timeboxed cycle in some methods; a release makes a capability available to users. A team can complete several increments before release, or release more frequently when quality and operations support it. The best response in an exam scenario follows the method and constraints actually described.

Business Analysis Frameworks: 27%

Business analysis is the second-largest domain. It begins with a business need and continues through stakeholder identification, elicitation, requirements analysis and documentation, prioritization, traceability, solution validation, and evaluation. A requested feature is not automatically the right solution. The analyst needs to understand the underlying problem, affected people, constraints, alternatives, and how success will be assessed.

Elicit information with a method suited to the question. Interviews can reveal individual goals; workshops surface conflicting expectations; observation can reveal workarounds users forget to describe; surveys can gather patterns from many users; prototypes help stakeholders react to a concrete interaction. Record assumptions and unresolved decisions. A quiet meeting is not evidence that everyone agrees.

Make requirements clear enough to guide a solution and its verification.

A clinic wants to replace appointment reminders. The manager asks for more messages, while patients complain that reminders arrive at inconvenient times. The analyst should identify user groups, contact preferences, privacy constraints, current failure points, and success measures before proposing message volume as the solution. A testable requirement might specify supported channels, a user-selected reminder window, and opt-out behavior. Confirm actual policy before finalizing the detail.

Why the domains overlap

A project starts with a need, develops requirements, selects an approach, coordinates delivery, and checks whether the result creates value. The exam may focus on one task, but the scenario can include dependencies. A retailer trying to reduce abandoned orders might use analysis to find mobile checkout errors, an agile pilot to test a change, predictive security review for payment controls, and fundamentals to clarify sponsor and team responsibilities.

When a prompt asks what to do next, identify the immediate decision and the information needed. If requirements are unclear, clarify before estimating. If a proposed change affects an approved plan, assess and route it. If an agile team receives new feedback, make it visible and consider priority. If a solution is delivered, validate against requirements and evaluate outcomes. Selecting a familiar method without reading the actual conditions leads to avoidable errors.

Use weights to shape preparation

Weights are a way to allocate attention, not a reason to neglect a smaller domain. Start with a diagnostic by task, not just a percentage score. If business analysis is weak, practice elicitation, requirement quality, traceability, and validation. If agile is unfamiliar, rehearse backlog and feedback decisions. Review fundamentals throughout because they provide the language used in every other domain.

• Map each ECO task to a note, one practice scenario, and a confidence rating.
• Spend extra review time on weak tasks in the 36% and 27% domains while setting a minimum target for predictive and agile content.
• For every missed item, label the skill: clarify, plan, prioritize, assess impact, communicate, validate, or measure.
• Use domain percentages as approximate planning guidance; never infer guaranteed individual question counts.

Integrated example with a worked decision

A nonprofit plans to replace its donation form before a public campaign. The launch date is fixed, donor needs are partly known, and a small pilot is possible. A sponsor asks for recurring donations, which are outside approved scope. First, clarify the donor problem and define acceptance conditions. Next, assess work, payment testing, support, schedule, and any compliance constraints. Route the decision through the organization’s approval process. If approved, an adaptive team can pilot and refine the experience; the fixed launch and quality conditions remain visible. The answer combines analysis, governance, planning, and feedback instead of treating the request as an automatic yes or no.

If the scenario says the team has authority to reprioritize the backlog, the best immediate action may be to discuss the request with the product owner and team. If it says scope is controlled by a formal change board, follow that route. If the request addresses a legal requirement, treat the obligation as a constraint and elevate it appropriately. The words in the prompt determine which decision path applies.