KEY CONCEPTS
The PMP exam is built from PMI’s Examination Content Outline, not from a single textbook. The 2026 ECO has three domains: People (33%), Process (41%), and Business Environment (26%). Inside them sit 26 tasks and 138 enablers, and every scored exam question traces back to one of them. This mind map puts the whole structure on one screen so you can see how the pieces fit together, then click any task to study it in detail.
The complete 2026 PMP ECO mind map
Click a node to expand or collapse it, drag to pan, scroll or pinch to zoom. Task names are links: click one to open the illustrated guide for that task; click an enabler number to jump straight to that section of the guide.
How to read this page. PMI’s official ECO wording is in bold black. The smaller green text is our plain-English translation and a worked example, added because the official wording tells you what is examined but rarely what it looks like on a real project. Enabler numbers such as 1.4.1 match the headings on each task page. PMI presents enablers as illustrations of the work rather than a complete list, so treat the numbering as a way to find things, not as an official count of what the exam covers.
Domain 1: People (33%)
8 tasks, 39 enablers.
1.1 Develop a common vision
Explained: People commit to work they can picture and drift away from work they cannot. Without one agreed picture of success, each group builds toward its own version and the parts do not fit together.
- 1.1.1 Help ensure a shared vision with key stakeholdersExplained: Get the people with real influence to agree, in the same words, on what a successful outcome looks like.
E.G.: At the kickoff for a hospital wing build, the sponsor, clinical lead and contractor agree on one written definition of success before design starts.See the illustration - 1.1.2 Promote the shared visionExplained: Repeat the vision often and in plain language, because saying it once does not make people remember it.
E.G.: The program manager opens every monthly steering meeting by reading the two-line project goal aloud before any progress is discussed.See the illustration - 1.1.3 Keep the vision currentExplained: Update the vision when the business situation changes, rather than defending a goal that no longer helps anyone.
E.G.: Six months in, a new regulation blocks the planned mobile app in two markets, so the sponsor rewrites the target around the remaining markets.See the illustration - 1.1.4 Break down situations to identify the root cause of a misunderstanding of the visionExplained: When people work at cross purposes, find out why they understood the goal differently instead of restating it louder.
E.G.: Two teams build overlapping login features, and asking why repeatedly shows the vision only ever existed in a slide nobody had read.See the illustration
1.2 Manage conflicts
Explained: Disagreement between capable people is normal and often improves the decision. Unmanaged disagreement turns personal instead, and the work slows while people protect their positions.
- 1.2.1 Identify conflict sourcesExplained: Find out what the disagreement is really about, which is often not the topic being argued over.
E.G.: An argument about coding standards turns out to be one developer feeling excluded from design decisions.See the illustration - 1.2.2 Analyze the context for the conflictExplained: Judge how serious the disagreement has become and what is driving it before you step in.
E.G.: The project manager notices two leads have stopped copying each other on email, which signals more than a technical difference of opinion.See the illustration - 1.2.3 Implement an agreed-on resolution strategyExplained: Agree the way forward with the people involved, then carry it out instead of leaving it as talk.
E.G.: Two leads agree to build small test versions of both database options and accept whichever one performs better in the measured results.See the illustration - 1.2.4 Communicate conflict management principles with the team and external stakeholdersExplained: Explain how disagreements will be handled here before one happens, so the rule is not invented under pressure.
E.G.: The team charter states that objections are raised in the meeting, not reopened afterward in private messages to the sponsor.See the illustration - 1.2.5 Establish an environment that fosters adherence to common ground rulesExplained: Make the agreed behaviors easy to follow and clearly normal, so following them takes no courage.
E.G.: Ground rules are posted in the team room, and the project manager asks for objections first in every decision meeting.See the illustration - 1.2.6 Manage and rectify ground rule violationsExplained: Address breaches quickly, privately where you can, and repair whatever damage the breach caused.
E.G.: A team member talks over a colleague again, so the project manager raises it the same day and the team revisits the rule.See the illustration
1.3 Lead the project team
Explained: A group of skilled people does not become a team on its own. Without someone setting expectations and clearing obstacles, decisions stall, work gets duplicated, and capable people sit waiting for permission.
- 1.3.1 Establish expectations at the team levelExplained: Agree what good working practice looks like for the whole team, covering quality, availability and how people communicate.
E.G.: A distributed team agrees on a four-hour daily overlap and a rule that code reviews finish within one working day.See the illustration - 1.3.2 Empower the teamExplained: Give the team real authority to make the decisions that sit inside its own area of work.
E.G.: The team selects its own testing tools and sets its own estimates without waiting for the project manager to approve them.See the illustration - 1.3.3 Solve problemsExplained: Work through obstacles with the team, defining the problem clearly before anyone proposes a fix.
E.G.: Overnight builds keep failing, so the team spends an hour mapping the cause and then splits the repair into three tasks.See the illustration - 1.3.4 Represent the voice of the teamExplained: Carry the team's position and concerns to management honestly, including the parts leaders will not enjoy hearing.
E.G.: The project manager tells the steering committee that the requested date needs two more testers, using the team's own estimates.See the illustration - 1.3.5 Support the team's varied experiences, skills, and perspectivesExplained: Use the differences inside the team deliberately, and make sure quieter or newer members actually get heard.
E.G.: A junior analyst spots a data privacy problem in a workshop because the facilitator asks every person for input in turn.See the illustration - 1.3.6 Determine an appropriate leadership styleExplained: Match how much direction you give to how experienced and confident the team is with this particular work.
E.G.: The project manager gives detailed direction to a new vendor team and only sets outcomes for the experienced in-house group.See the illustration - 1.3.7 Establish clear roles and responsibilities within the teamExplained: State who does what and who decides what, so no work sits unowned and nothing gets done twice.
E.G.: A hybrid project posts a table showing, for each deliverable, who builds it, who reviews it, and who approves it.See the illustration
1.4 Engage stakeholders
Explained: Projects are funded, approved and used by people outside the team, and their support is never automatic. Stakeholders left alone tend to arrive late with objections that are expensive to answer.
- 1.4.1 Identify stakeholdersExplained: List everyone who affects the project or is affected by it, including people who never attend a meeting.
E.G.: A payroll replacement project adds the union representative and the external auditor to the list after a colleague mentions them.See the illustration - 1.4.2 Analyze stakeholdersExplained: Work out each stakeholder's level of interest, influence and current attitude toward the project.
E.G.: A simple grid shows the finance director has high influence and low interest, so she gets a short monthly briefing.See the illustration - 1.4.3 Analyze and tailor communication to stakeholder needsExplained: Adjust what you send, how often you send it, and what form it takes for each audience.
E.G.: Executives receive a one-page monthly dashboard, while the operations team gets a detailed weekly email and a live task board.See the illustration - 1.4.4 Execute the stakeholder engagement planExplained: Do what the plan says, on schedule, rather than filing it and falling back on occasional contact.
E.G.: The demo happens every two weeks as promised, even in a thin week, and the team shows what did not work.See the illustration - 1.4.5 Optimize alignment among stakeholder needs, expectations, and project objectivesExplained: Find the workable overlap when what stakeholders want differs from what the project agreed to deliver.
E.G.: Sales wants extra reporting while the approved goal is faster order entry, so the team delivers one shared report first.See the illustration - 1.4.6 Build trust and influence stakeholders to accomplish project objectivesExplained: Earn credibility by keeping small promises, then use that standing to get decisions and resources released.
E.G.: After three months of accurate forecasts, the project manager asks for a dedicated tester and gets one within a week.See the illustration
1.5 Align stakeholder expectations
Explained: Different stakeholders often hold quietly incompatible ideas about the same deliverable. Surfacing those differences early costs a conversation, while finding them at handover costs rework.
- 1.5.1 Categorize stakeholdersExplained: Group stakeholders in a way you can act on, such as by influence, function, or how much their work changes.
E.G.: A regulator, a supplier and a call center team are grouped separately because each needs different information at different times.See the illustration - 1.5.2 Identify stakeholder expectationsExplained: Ask each group what they expect to receive and when, then write the answers down.
E.G.: Interviews reveal the warehouse manager expects barcode scanning at launch, although the plan places it in phase two.See the illustration - 1.5.3 Facilitate discussions to align expectationsExplained: Bring the conflicting expectations into one conversation and reach a decision everyone can work with.
E.G.: A joint session with finance and operations settles that month end reporting ships first and stock alerts follow later.See the illustration - 1.5.4 Organize and act on mentoring opportunitiesExplained: Arrange pairing and coaching so experience and shared understanding pass from senior people to others.
E.G.: A senior business analyst takes two junior colleagues into requirements interviews so all three hear the same commitments firsthand.See the illustration
1.6 Manage stakeholder expectations
Explained: What customers expect shifts during a project even when the plan holds still. Checking and correcting that gap as work proceeds prevents a technically complete delivery that nobody wanted.
- 1.6.1 Identify internal and external customer expectationsExplained: Find out what paying customers and internal users each expect, because the two rarely want the same thing.
E.G.: The external client wants a firm public launch date, while the internal support team wants training completed before that date.See the illustration - 1.6.2 Align and maintain outcomes to internal and external customer expectationsExplained: Keep the work pointing at those expectations as scope, staffing and dates change around it.
E.G.: When a feature is cut, the project manager confirms with both the client and the support lead which promise is affected.See the illustration - 1.6.3 Monitor internal and external customer satisfaction/expectations and respond as neededExplained: Check regularly whether customers are satisfied, then act on what you hear instead of only recording it.
E.G.: A short survey after each release shows falling satisfaction with system speed, so performance work enters the next iteration.See the illustration
1.7 Help ensure knowledge transfer
Explained: Most of what a project knows sits in people's heads and leaves when they do. Capturing and sharing that knowledge protects the work from a single resignation, illness or reassignment.
- 1.7.1 Identify knowledge critical to the projectExplained: Work out which knowledge the project cannot afford to lose and who currently holds it.
E.G.: Only one contractor understands the legacy billing interface, and his contract ends in eight weeks.See the illustration - 1.7.2 Gather knowledgeExplained: Collect that knowledge in a form others can use while the people holding it are still available.
E.G.: The contractor records a walkthrough of the billing interface and writes a two-page guide before his last day.See the illustration - 1.7.3 Foster an environment for knowledge transferExplained: Make sharing normal by giving people the time, the tools and a reason to pass on what they know.
E.G.: The team holds a thirty-minute session every second Friday where one member teaches something the others need to know.See the illustration
1.8 Plan and manage communication
Explained: Project managers spend most of their day communicating, and doing it by instinct leaves gaps. A planned approach decides in advance who needs which information, how often, and in what form.
- 1.8.1 Define a communication strategyExplained: Decide up front who receives which information, how often they receive it, and through which channel.
E.G.: The plan sets a weekly written status note, a monthly steering pack, and a same day call for anything blocking work.See the illustration - 1.8.2 Promote transparency and collaborationExplained: Share the real status, including bad news, and make project information easy for others to find.
E.G.: Progress charts and the open risk list sit on a page any stakeholder can view without asking the project manager.See the illustration - 1.8.3 Establish a feedback loopExplained: Create a routine way for people to say what is not working, then show them you acted.
E.G.: Each retrospective ends with one improvement the team will try, and the next one opens by checking whether it helped.See the illustration - 1.8.4 Understand reporting requirementsExplained: Find out what your organization, contract or regulator requires you to report before designing any report.
E.G.: A government funded project must report spend against approved budget lines every quarter using a fixed template.See the illustration - 1.8.5 Create reports aligned with sponsors and stakeholder expectationsExplained: Build reports around the decisions your readers need to make, not around the data easiest to export.
E.G.: The sponsor wants forecast finish date and remaining cost, so those two figures lead the report instead of task counts.See the illustration - 1.8.6 Support reporting and governance processesExplained: Give the committees that oversee the project what they need on time, and take part in their reviews.
E.G.: The project manager submits the stage gate pack a week early so board members have time to read it.See the illustration
Domain 2: Process (41%)
10 tasks, 64 enablers.
2.1 Develop an integrated project management plan and plan delivery
Explained: Plans written separately for scope, cost, schedule and risk tend to contradict each other. One combined plan makes those conflicts visible early, while separate documents hide them until delivery is underway.
- 2.1.1 Assess project needs, complexity, and magnitudeExplained: Judge how big, how uncertain and how complicated the work is before choosing how to run it.
E.G.: A bridge replacement with settled regulations and known methods rates low on uncertainty, so the team plans it in detailed stages.See the illustration - 2.1.2 Recommend a project management development approach (i.e., predictive, adaptive/agile, or hybrid management)Explained: Propose whether to plan the whole thing up front, work in short repeating cycles, or combine both.
E.G.: A bank runs its core ledger migration to a fixed plan while the customer app team works in two-week iterations.See the illustration - 2.1.3 Determine critical information requirements (e.g., sustainability)Explained: Decide which information the project must collect and report, such as energy use, safety records or carbon figures.
E.G.: A warehouse build must report embodied carbon for every material, so that data is captured at purchase instead of reconstructed later.See the illustration - 2.1.4 Recommend a project execution strategyExplained: Propose how the work will actually get done, covering sequence, locations, teams and handover points.
E.G.: A retailer rolls out new point of sale systems region by region, starting with three quiet stores before the holiday season.See the illustration - 2.1.5 Create an integrated project management planExplained: Bring the separate plans for scope, schedule, cost, quality and risk into one consistent document.
E.G.: Reviewing the scope, resource and cost plans together reveals that the agreed launch date assumes two testers nobody has hired.See the illustration - 2.1.6 Estimate work effort and resource requirementsExplained: Work out how much effort each part needs and what people, skills and equipment it will take.
E.G.: A pharmaceutical validation team estimates 400 hours of testing and finds it needs a qualified analyst for six of those weeks.See the illustration - 2.1.7 Assess consolidated project plans for dependencies, gaps, and continued business valueExplained: Review the combined plan for missing work, links between activities, and whether the promised benefit still holds.
E.G.: A joint review shows training starts after go live, although the expected savings depend on staff being trained before then.See the illustration - 2.1.8 Maintain the integrated project management planExplained: Keep the plan current as things change, so the document stays the one people actually work from.
E.G.: When a supplier slips four weeks, the schedule, cost forecast and risk register are all updated in the same sitting.See the illustration - 2.1.9 Collect and analyze data to make informed project decisionsExplained: Base decisions on measured facts from the project rather than on opinion or optimism.
E.G.: Defect counts by module show one component causing most of the rework, so the next iteration adds a second reviewer there.See the illustration
2.2 Develop and manage project scope
Explained: Scope is the boundary between what the project delivers and what it leaves alone. Left undefined, that boundary gets decided later by whoever asks most persistently, and the work grows without extra time or money.
- 2.2.1 Define scopeExplained: State clearly what the project will deliver and, just as usefully, what it will not.
E.G.: The statement covers a new claims portal for auto policies only, and names home insurance as outside the project.See the illustration - 2.2.2 Obtain stakeholder agreement on project scopeExplained: Get the people who fund and use the outcome to accept that boundary in writing.
E.G.: The operations director and the finance sponsor both sign the scope statement before any design work is allowed to start.See the illustration - 2.2.3 Break down scopeExplained: Split the work into pieces small enough to estimate, assign and track without guessing.
E.G.: A university records system is split into admissions, timetabling and results, then each part into features one team can build.See the illustration
2.3 Help ensure value-based delivery
Explained: A project can finish on time and on budget while giving the organization very little. Tracking the benefit, and not only the effort, keeps the work pointed at the reason it was funded.
- 2.3.1 Identify value components with key stakeholdersExplained: Agree with sponsors and users which specific outcomes count as value, in terms you can measure.
E.G.: A utility agrees that value means fewer site visits, so avoided truck trips per month becomes the headline number.See the illustration - 2.3.2 Prioritize work based on value and stakeholder feedbackExplained: Do the highest value work first, then reorder the queue when users say their needs have changed.
E.G.: A city adds online permit payment ahead of an internal reporting screen because residents request payment far more often.See the illustration - 2.3.3 Assess opportunities to deliver value incrementallyExplained: Look for ways to release useful parts early instead of holding everything back for one final handover.
E.G.: A logistics firm gives driver tracking to one depot in month three, so savings begin before the full rollout.See the illustration - 2.3.4 Examine the business value throughout the projectExplained: Recheck during delivery whether the expected benefit is still real and still worth the remaining spend.
E.G.: Halfway through a call center upgrade, call volumes drop sharply and the sponsor rescopes the work around self service.See the illustration - 2.3.5 Verify a measurement system is in place to track benefitsExplained: Confirm somebody is actually measuring the promised benefit, with a starting figure and an owner after handover.
E.G.: Before launch the team confirms that finance will report processing cost per invoice every month for a year.See the illustration - 2.3.6 Evaluate delivery options to demonstrate valueExplained: Compare ways of proving the benefit early, such as a pilot, a prototype or a limited release.
E.G.: A hospital pilots the new scheduling tool in one clinic for six weeks before committing to all thirty departments.See the illustration
2.4 Plan and manage resources
Explained: Work only moves when the right people, equipment and materials are free at the same time. Resource plans that ignore competing demands produce schedules nobody can actually staff.
- 2.4.1 Define and plan resources based on requirementsExplained: Start from what the work needs, then decide which people, skills, equipment and materials to secure.
E.G.: A mine expansion needs two certified welders in weeks nine to fourteen, so both are booked five months ahead.See the illustration - 2.4.2 Manage and optimize resource needs and availabilityExplained: Keep matching what you have against what the work needs, settling clashes before they stop progress.
E.G.: A shared database expert is booked twice in one week, so the project manager moves one task rather than losing five days.See the illustration
2.5 Plan and manage procurement
Explained: Projects rarely own everything they need, so part of the outcome sits with suppliers. Weak agreements and unwatched vendors turn other people's problems into your delays.
- 2.5.1 Plan procurementExplained: Decide what to buy, what to build yourselves, and when each purchase has to be underway.
E.G.: A water treatment project writes its own control software but buys the pumps, and pump lead time sets the order date.See the illustration - 2.5.2 Execute a procurement management planExplained: Run the buying process as planned, covering tender, evaluation, award and the paperwork behind each step.
E.G.: Three bids arrive by the published deadline and are scored against the stated criteria before any price is opened.See the illustration - 2.5.3 Select preferred contract typesExplained: Choose the payment structure that fits how well the work is understood and who carries the risk.
E.G.: Well defined civil works go out at a fixed price, while exploratory data cleanup runs on time and materials.See the illustration - 2.5.4 Evaluate vendor performanceExplained: Check what suppliers actually deliver against what they promised, using evidence rather than impressions.
E.G.: Monthly reviews show a vendor hitting delivery dates but failing one quality check in four, so inspection is increased.See the illustration - 2.5.5 Verify objectives of the procurement agreement are metExplained: Confirm the supplier has delivered everything the contract requires before you accept the work and pay.
E.G.: Final acceptance is held back until the vendor supplies the maintenance manuals and operator training listed in the agreement.See the illustration - 2.5.6 Participate in agreement negotiationsExplained: Take part in the discussions that set price, dates, standards and remedies, rather than inheriting the result.
E.G.: The project manager joins the contract talks and gets a two-week acceptance testing window written into the terms.See the illustration - 2.5.7 Determine a negotiation strategyExplained: Decide beforehand what you need, what you can trade away, and when walking away is the better option.
E.G.: Before talks open, the team agrees the installation date is fixed while payment timing and warranty length can move.See the illustration - 2.5.8 Manage suppliers and contractsExplained: Hold the working relationship together day to day, tracking obligations, changes, invoices and disagreements.
E.G.: A change to the steel specification is logged, priced and approved in writing before the fabricator starts cutting.See the illustration - 2.5.9 Plan and manage the procurement strategyExplained: Set the overall buying approach, including how many suppliers to use and how the work is packaged.
E.G.: A telecom program splits its rollout between two regional contractors so one failure cannot stop the whole build.See the illustration - 2.5.10 Develop a delivery solutionExplained: Shape the overall arrangement of suppliers, internal teams and technology that will produce the outcome.
E.G.: The chosen arrangement combines a hosted platform, one integration partner, and internal staff for data migration and training.See the illustration
2.6 Plan and manage finance
Explained: Project money is approved in advance and spent unevenly, so the picture keeps changing. Without forecasting and tracking, an overspend surfaces only after the commitment has been made.
- 2.6.1 Analyze project financial needsExplained: Work out how much money the project needs and when each part of it is required.
E.G.: A plant upgrade needs sixty percent of its budget in the first quarter because equipment is paid for on order.See the illustration - 2.6.2 Quantify risk and contingency financial allocationsExplained: Put a figure on what the identified risks could cost, then hold that amount as contingency.
E.G.: Two weather delay risks are priced at 90,000 dollars between them, and that amount sits in a named reserve.See the illustration - 2.6.3 Plan spend tracking throughout the project life cycleExplained: Decide in advance how spend will be recorded and compared against budget while the project runs.
E.G.: Costs are coded by work package, so the monthly report shows spend against plan for each package separately.See the illustration - 2.6.4 Plan financial reportingExplained: Agree who receives which financial figures, in what format, and how often they receive them.
E.G.: The steering committee gets committed spend, actual spend and forecast cost to finish on one page each month.See the illustration - 2.6.5 Anticipate future finance challengesExplained: Look ahead for money problems such as currency shifts, price rises, or funding that expires.
E.G.: A project buying components in euros builds a currency allowance into its forecast before the exchange rate moves against it.See the illustration - 2.6.6 Monitor financial variations and work with the governance processExplained: Watch for differences between planned and actual cost, then take them through the proper approval route.
E.G.: A ten percent overrun on installation goes to the change board with options, rather than being absorbed quietly.See the illustration - 2.6.7 Manage financial reservesExplained: Control the contingency money so it is released for real risks and not treated as spare budget.
E.G.: Contingency is drawn only on written approval, and the register records which risk each release paid for.See the illustration
2.7 Plan and optimize quality of products/deliverables
Explained: Quality checked only at the end is expensive, because defects have already been built into everything downstream. Deciding early how quality gets checked during the work keeps rework small.
- 2.7.1 Gather quality requirements for project deliverablesExplained: Find out what standards the deliverable must meet and how each one will be judged.
E.G.: A medical device project records the tolerance limits and the exact test each component must pass to be accepted.See the illustration - 2.7.2 Plan quality processes and toolsExplained: Decide which reviews, tests and measurements will be used, and who carries out each of them.
E.G.: Every code change needs automated tests and one peer review, and the build blocks release whenever a test fails.See the illustration - 2.7.3 Execute a quality management planExplained: Carry out those checks as agreed, including in the weeks when the schedule feels tight.
E.G.: Concrete samples are still tested on the scheduled day even though the crew is running behind on pours.See the illustration - 2.7.4 Help ensure regulatory complianceExplained: Confirm the work meets the laws, codes and standards that apply, and keep the evidence.
E.G.: An electrical contractor files inspection certificates floor by floor as work completes, rather than collecting them at handover.See the illustration - 2.7.5 Manage cost of quality (CoQ) and sustainabilityExplained: Balance what prevention and inspection cost against what failures cost, including environmental and longer term effects.
E.G.: A second inspector costs 20,000 dollars and avoids an estimated 120,000 dollars of field repairs and return visits.See the illustration - 2.7.6 Conduct ongoing quality reviewsExplained: Check quality repeatedly while work is in progress instead of once at the end.
E.G.: Each iteration ends with a demonstration where the product owner tests the feature against its written acceptance criteria.See the illustration - 2.7.7 Implement continuous improvementExplained: Change how the team works based on what the defects and the reviews keep showing you.
E.G.: Repeated data errors at import lead the team to add a validation step, and error reports fall by half.See the illustration
2.8 Plan and manage schedule
Explained: Dates are promises made to other people, and they rest on work nobody has done yet. A timeline never compared against actual progress stops being a forecast and starts misleading the people relying on it.
- 2.8.1 Prepare a schedule based on the selected development approachExplained: Build the timeline in the form your chosen approach uses, such as a network diagram or a release plan.
E.G.: A plant shutdown uses a detailed activity network, while the software team plans releases in fixed two-week iterations.See the illustration - 2.8.2 Coordinate with other projects and operationsExplained: Align your dates with other work competing for the same people, systems and shutdown windows.
E.G.: A payroll release moves by a week because the finance team is closing the year in the same window.See the illustration - 2.8.3 Estimate project tasks (milestones, dependencies, story points)Explained: Size the work and record what must happen before what, using whichever units your team estimates in.
E.G.: The team assigns story points to backlog items and notes that reporting cannot start until the data model is agreed.See the illustration - 2.8.4 Utilize benchmarks and historical dataExplained: Use recorded figures from similar past work instead of estimating every activity from scratch.
E.G.: Records from three earlier store fitouts show installation averaging eleven days, so the proposed eight days is challenged.See the illustration - 2.8.5 Create a project scheduleExplained: Turn the estimates and dependencies into dated work, allowing for real availability and working calendars.
E.G.: The schedule allows for a two-week factory closure in August, which pushes commissioning into September.See the illustration - 2.8.6 Baseline a project scheduleExplained: Freeze an approved version of the timeline so later progress can be measured against something fixed.
E.G.: The approved baseline is saved before construction starts, and every later change is tracked against those original dates.See the illustration - 2.8.7 Execute a schedule management planExplained: Run the schedule as agreed, updating progress, reforecasting, and following the change route for date moves.
E.G.: Progress is updated every Friday, and any slip beyond three days goes to the sponsor with a recovery option.See the illustration - 2.8.8 Analyze schedule variationExplained: Compare actual progress against the baseline, then work out what caused the difference.
E.G.: Testing is nine days late, and the cause is late access to the test environment rather than slow testers.See the illustration
2.9 Evaluate project status
Explained: Status is a claim about where the work stands, and it only helps when the numbers behind it agree. Weak measurement produces reports that read confidently while hiding problems until they are expensive.
- 2.9.1 Develop project metrics, analysis, and reconciliationExplained: Choose what to measure, decide how to read it, and check the figures agree with each other.
E.G.: Reported percentage complete is checked against hours booked and features accepted, and the three no longer tell different stories.See the illustration - 2.9.2 Identify and tailor needed artifactsExplained: Decide which documents and records this project genuinely needs, then size them to fit the work.
E.G.: A six-week internal project keeps a one-page charter and a risk log, dropping the full management plan template.See the illustration - 2.9.3 Help ensure artifacts are created, reviewed, updated, and documentedExplained: Confirm the chosen documents get written, checked, kept current, and stored where people can rely on them.
E.G.: The risk register is reviewed in every weekly meeting, and each entry shows the date it last changed.See the illustration - 2.9.4 Help ensure accessibility of artifactsExplained: Make project information easy for the right people to find, without them having to ask you first.
E.G.: Plans and reports sit in one shared folder with read access for the vendor and the operations team.See the illustration - 2.9.5 Assess current progressExplained: Judge how much of the work is genuinely finished, rather than how much has been started.
E.G.: Six features are coded but only two pass acceptance testing, so progress is reported as two features complete.See the illustration - 2.9.6 Measure, analyze, and update project metricsExplained: Take the measurements on a regular cycle, interpret what they show, and revise them when they stop helping.
E.G.: Velocity is tracked each iteration, and a burn chart replaces the task count report because it explains delays better.See the illustration - 2.9.7 Communicate project statusExplained: Tell stakeholders where the project stands, in their language, including the parts going badly.
E.G.: The monthly note leads with two slipping milestones and the recovery plan, ahead of the completed work.See the illustration - 2.9.8 Continually assess the effectiveness of artifact managementExplained: Keep asking whether the documents and records are still used and still worth the effort they cost.
E.G.: A weekly report nobody opens is dropped once the team checks who reads it, freeing two hours a week.See the illustration
2.10 Manage project closure
Explained: Projects that simply stop leave open contracts, unreleased staff and unrecorded lessons. Formal closure hands the outcome to whoever runs it next and settles what is still owed.
- 2.10.1 Obtain project stakeholder approval of project completionExplained: Get written confirmation from the people who accept the outcome that the project is finished.
E.G.: The operations manager signs acceptance after the new line runs for five days without an unplanned stop.See the illustration - 2.10.2 Determine criteria to successfully close the project or phaseExplained: Agree in advance what has to be true before the project or phase can be called complete.
E.G.: Closure requires all severity one and two defects fixed, training delivered, and the support contract already active.See the illustration - 2.10.3 Validate readiness for transition (e.g., to operations team or next phase)Explained: Check the receiving team can genuinely run and support the outcome before you hand it over.
E.G.: Support staff run the system for two weeks with the project team watching before that team stands down.See the illustration - 2.10.4 Conclude activities to close the project or phase (e.g., final lessons learned, retrospectives, procurement, financials, resources)Explained: Finish the administrative work, closing contracts and accounts, releasing people, and recording what was learned.
E.G.: Final invoices are paid, the equipment lease ends, contractors are released, and lessons go into the shared repository.See the illustration
Domain 3: Business Environment (26%)
8 tasks, 35 enablers.
3.1 Define and establish project governance
Explained: Governance is the set of rules saying who decides what and how the project reports progress. Without it, decisions get made twice or not at all, and problems reach senior people too late to fix cheaply.
- 3.1.1 Describe and establish the structure, rules, procedures, reporting, ethics, and policies through the use of organizational process assets (OPAs)Explained: Set the project's rules and reporting using your organization's existing templates, policies and past project records, known as organizational process assets.
E.G.: A public sector project reuses the department's approved risk template, ethics code and stage gate reporting pack instead of writing new ones.See the illustration - 3.1.2 Define success metricsExplained: Agree the measures that will show whether the project succeeded, in numbers you can actually collect.
E.G.: A billing replacement sets three measures: invoice errors below one percent, monthly close in two days, and support calls cut by half.See the illustration - 3.1.3 Outline governance escalation paths and thresholdsExplained: Write down which problems go to whom, and the size at which a problem must move up.
E.G.: The plan states that any delay over ten days or cost overrun above fifty thousand dollars goes to the steering committee.See the illustration
3.2 Plan and manage project compliance
Explained: Compliance means following the rules the project has no choice about, such as laws, safety regulations and contract terms. Missing one can stop the work, void an approval, or expose the organization to fines and legal action.
- 3.2.1 Confirm project compliance requirements (e.g., security, health and safety, sustainability, regulatory compliance)Explained: Find out exactly which laws, standards, sustainability duties and internal rules this project must obey, then confirm them in writing.
E.G.: Before design starts, a medical device project confirms FDA submission rules, ISO quality standards, hospital data privacy rules and packaging recycling targets.See the illustration - 3.2.2 Classify compliance categoriesExplained: Sort the requirements into groups such as safety, data privacy or financial, because each group is handled differently.
E.G.: A bank project separates its obligations into data privacy, anti money laundering and accessibility, then assigns a named owner to each group.See the illustration - 3.2.3 Determine potential threats to complianceExplained: Work out where the project could realistically break a rule, and what would cause that to happen.
E.G.: A construction team notes that hiring subcontractors at short notice risks using workers without current safety certification.See the illustration - 3.2.4 Use methods to support complianceExplained: Put practical checks into the way you work, so following the rules happens by default.
E.G.: An agile team adds a security review item to its definition of done, so no story ships unchecked.See the illustration - 3.2.5 Analyze the consequences of noncomplianceExplained: Understand what actually happens if a rule is broken, including fines, lost approvals, delays and damage to reputation.
E.G.: The team calculates that a failed safety audit would halt site work for three weeks and cost the contract bonus.See the illustration - 3.2.6 Determine the necessary approach and action(s) to address compliance needsExplained: Decide how the project will meet each requirement and who does the work to make that happen.
E.G.: A hybrid project appoints a compliance lead, books an external audit before launch, and adds two accessibility testing sprints.See the illustration - 3.2.7 Measure the extent to which the project is in complianceExplained: Check and record how much of the requirement list the project currently meets, rather than assuming it does.
E.G.: A monthly checklist shows twenty two of twenty five privacy controls in place, with the three gaps named and dated.See the illustration
3.3 Manage and control changes
Explained: Change is normal on projects, yet a change accepted quietly still consumes money, time and testing effort. One agreed route for requests keeps the approved plan and the actual work describing the same thing.
- 3.3.1 Execute the change control processExplained: Run every change request through the agreed steps of review, impact assessment and a recorded decision.
E.G.: A requested extra report goes to the change board, which sees a two week schedule impact and defers it to phase two.See the illustration - 3.3.2 Communicate the status of proposed changesExplained: Tell the requester and everyone affected where their change stands, including when the answer is no.
E.G.: The project manager publishes a weekly list of change requests showing which are approved, rejected, or still awaiting cost estimates.See the illustration - 3.3.3 Implement approved changes to the projectExplained: Once a change is approved, build it into the plan, the budget and the team's actual work.
E.G.: After approval, the new tax rule enters the backlog, the release date moves two weeks, and testing is rebooked.See the illustration - 3.3.4 Update project documentation to reflect changesExplained: Correct the plans, requirements and baselines so the written record matches what the project is now doing.
E.G.: The requirements document, test cases and training guide are all revised after the approved change, not just the schedule.See the illustration
3.4 Remove impediments and manage issues
Explained: An impediment is anything blocking the team from making progress, while an issue is a problem already happening rather than a possible one. Both stall work quietly as people build workarounds instead of asking for help.
- 3.4.1 Evaluate the impact of impedimentsExplained: Judge how much each blocker is costing in delay, idle people or unfinished work.
E.G.: A missing test environment leaves four developers waiting, which the project manager records as sixteen lost person days per week.See the illustration - 3.4.2 Prioritize and highlight impedimentsExplained: Rank blockers by the damage they are doing, and make the worst ones visible to people who can clear them.
E.G.: The team keeps a visible blocker list at the top of its board, with the two oldest items flagged red.See the illustration - 3.4.3 Determine and apply an intervention strategy to remove/minimize impedimentsExplained: Choose a specific way to clear the blocker, then act on it rather than reporting it repeatedly.
E.G.: Rather than escalate again, the project manager borrows a license from another team so testing restarts the next morning.See the illustration - 3.4.4 Reassess continually to help ensure impediments, obstacles, and blockers for the team are being addressedExplained: Keep checking that blockers are actually being cleared, because a logged item is not a solved one.
E.G.: Each daily standup reviews the blocker list and names who is chasing each one before new work is discussed.See the illustration - 3.4.5 Recognize when a risk becomes an issueExplained: A risk is something that might happen; once it happens it becomes an issue needing action now.
E.G.: A supplier delay risk becomes an issue the day the confirmed delivery date slips, so it moves to the issue log.See the illustration - 3.4.6 Collaborate with relevant stakeholders on an approach to resolve the issuesExplained: Work with the people who own or are affected by the problem to agree how it gets fixed.
E.G.: The project manager, vendor account lead and operations manager meet within a day of the outage to agree recovery steps.See the illustration
3.5 Plan and manage risk
Explained: Risks are uncertain events that could help or harm the project, and every project carries them whether or not anyone writes them down. Naming them early buys cheap options, while ignoring them leaves only expensive reactions.
- 3.5.1 Identify risksExplained: List what could go wrong, and what could go unexpectedly well, before either of them happens.
E.G.: A workshop with the team and the supplier produces twenty risks, including a known shortage of qualified welders.See the illustration - 3.5.2 Analyze risksExplained: Judge how likely each risk is and how much damage it would do if it occurred.
E.G.: A rating of high likelihood and high cost moves the data migration risk to the top of the register.See the illustration - 3.5.3 Monitor and control risksExplained: Watch the risks you listed, check whether they are getting closer, and act when they do.
E.G.: A monthly review shows the currency risk growing, so the finance lead fixes the exchange rate with a forward contract.See the illustration - 3.5.4 Develop a risk management planExplained: Decide in advance how the project will find, rate, own and respond to risks.
E.G.: The plan sets monthly risk reviews, a rating scale, and a rule that every high risk needs a named owner.See the illustration - 3.5.5 Maintain a risk register (e.g., poor IT security)Explained: Keep one living list of risks with owners, ratings and planned responses, then revisit it regularly.
E.G.: The register is reviewed every second week, closed risks are archived, and two new cyber security risks are added.See the illustration - 3.5.6 Execute a risk management plan (e.g., risk response for security and managing sustainability risks)Explained: Carry out the planned responses, spending the time and money the plan said the risk deserved.
E.G.: The agreed response to a single supplier risk is executed by qualifying a second supplier before the build phase starts.See the illustration - 3.5.7 Communicate the status of a risk impact on the projectExplained: Tell stakeholders which risks now threaten the date, the cost or the scope, and by how much.
E.G.: The status report shows the permit risk could add six weeks, so the sponsor approves an earlier submission date.See the illustration
3.6 Continuous improvement
Explained: Teams repeat mistakes when what they learn stays with the people who learned it. Improvement only holds when a lesson changes a process, a template or a checklist that somebody else will use.
- 3.6.1 Utilize lessons learnedExplained: Read what earlier projects recorded, then change your own plan because of what you find.
E.G.: Before estimating, the team reads the last two data migration reviews and doubles its allowance for cleaning source data.See the illustration - 3.6.2 Help ensure continuous improvement processes are updatedExplained: Check that the routines you use to review and improve the work are still running and still useful.
E.G.: Retrospectives had become a status update, so the team changes the format and agrees one improvement action each time.See the illustration - 3.6.3 Update organizational process assets (OPAs)Explained: Feed your improvements back into the company templates, checklists and procedures that other projects will use.
E.G.: After a difficult handover, the team adds three missing steps to the organization's standard go live checklist.See the illustration
3.7 Support organizational change
Explained: A delivered product creates value only when people change how they work, and that change happens outside the project team. Ignoring the receiving organization produces systems that go live and then sit unused.
- 3.7.1 Assess organizational cultureExplained: Understand how this organization really makes decisions and treats change, rather than how its policies say it does.
E.G.: The project manager learns that nothing proceeds without the operations director's informal approval, whatever the governance chart shows.See the illustration - 3.7.2 Evaluate the impact of organizational change on the project and determine required actionsExplained: Work out how a restructure, merger or leadership change affects your project, then adjust the plan and the sponsorship.
E.G.: A departmental merger removes the project's sponsor, so the project manager secures a new sponsor and reconfirms the funding decision.See the illustration
3.8 Evaluate external business environment changes
Explained: Projects run for months inside a world that keeps moving, so regulations, technology and markets shift while the plan stays still. Work approved a year ago can become noncompliant, outdated or commercially pointless.
- 3.8.1 Survey changes to the external business environment (e.g., regulations, technology, geopolitical, market)Explained: Watch for outside changes in law, technology, politics and competitors that could affect what you are building.
E.G.: A quarterly scan finds a new privacy regulation taking effect in nine months, before the planned launch of the app.See the illustration - 3.8.2 Assess and prioritize the impact on project scope/backlog based on changes in the external business environmentExplained: Decide what each outside change means for the work list, then reorder that list so urgent items come first.
E.G.: The new privacy rule moves consent screens to the top of the backlog and pushes the loyalty feature to next year.See the illustration - 3.8.3 Continually review the external business environment for impacts on project scope/backlogExplained: Repeat that scan on a schedule, because one review at the start goes stale within months.
E.G.: A two year infrastructure program adds an external factors review to every quarterly gate, not just the business case stage.See the illustration
Frequently asked questions
How many questions are on the 2026 PMP exam?
180 questions in total, of which 170 are scored and 10 are unscored pretest questions that PMI is trialing for future exams. You cannot tell the two apart, so treat every question as if it counts. You get 240 minutes, four hours, to answer all 180. The tutorial and the survey at the end are not taken out of that time.
How long is the 2026 PMP exam and when are the breaks?
240 minutes of exam time, with two 10-minute breaks. The first comes after the case study section, and the second falls roughly halfway through the independent questions. Once you have reviewed your answers for a section and started a break, you cannot go back to that section, so review before you stand up.
What is the Examination Content Outline?
The Examination Content Outline (ECO) is PMI’s official specification for what the PMP exam tests. It is organized into domains, tasks, and enablers. Every question on the exam maps back to an ECO task, which makes it the most reliable study checklist available.
How is the 2026 PMP ECO structured?
Three domains: People (33% of scored questions), Process (41%), and Business Environment (26%). Those contain 26 tasks in total, and the tasks break down into 138 enablers, which are the specific capabilities a project manager is expected to demonstrate.
Why study the ECO as a mind map?
Because the ECO is a hierarchy, and a linear list hides that. Seeing tasks grouped under their domain shows you which areas carry the most exam weight and how related tasks connect. It also makes the scope of the exam feel finite, which is worth a lot when you are planning study time.
What changed from the 2021 ECO?
The domain weightings shifted, the task list was rewritten and renumbered, and Business Environment grew substantially. Two new question types also arrived, Case or Scenario and Graphic-Based, alongside enhanced matching, point and click, and multiple-response questions. Any study material built on the old outline will point you at the wrong things. See what changed in the 2026 PMP exam for the full comparison.
Do the domain percentages equal the number of questions?
They are the approximate share of the 170 scored questions, not an exact count. Treat them as a guide for how to divide your study time rather than a precise question tally.
Where can I practice with sample PMP questions?
The free Practice Paths page offers map-based quiz games with sample PMP questions for every domain, including the new case study and graphic question types on the Sustainability path.