III.4 — Remove Impediments and Manage Issues
III.4 · Last updated: 11/10/2026
Removing impediments left the People domain
III.4 — Remove Impediments and Manage Issues is the fourth task in the Business Environment domain of the 2026 ECO, a domain that carries 26% of the exam. In 2021 this topic was the seventh task of the People domain and talked only about impediments. In 2026 it changed domain and gained issue management as well. The ECO gives it six enablers:
- Evaluate the impact of impediments
- Prioritize and highlight impediments
- Determine and apply an intervention strategy to remove/minimize impediments
- Reassess continually to help ensure impediments, obstacles, and blockers for the team are being addressed
- Recognize when a risk becomes an issue
- Collaborate with relevant stakeholders on an approach to resolve the issues
The first four describe a loop, in which an impediment is noticed, weighed, removed, and then checked again to see whether it is really gone. The last two move from impediments to issues and tie the task to risk management.
🔴 Both of this task's numbers belong to other topics
| 2021 | 2026 | |
|---|---|---|
| Number | I.7 | III.4 |
| Domain | People | Business Environment |
| Title | Address and remove impediments, obstacles, and blockers | Remove impediments and manage issues |
Here the numbering confusion comes from two directions at once. The old number I.7 went to a completely different task in 2026, I.7 — Help Ensure Knowledge Transfer. The new number III.4 meant support for organizational change in 2021, and that topic now lives in III.7 — Support Organizational Change. A question tagged "I.7" or "III.4" in an older source therefore cannot be placed correctly until you know which ECO it was tagged against. All shifts of this kind are collected in what changed in the 2026 PMP exam.
The direction of the move says something too. In 2021, removing impediments was presented as the behavior of a leader who shields the team. In 2026 the same work sits beside the governance, compliance, change, and risk tasks, and the question being asked has changed with it: who has the authority to remove the impediment, and through which mechanism. PMBOK® 8 builds the same link into its structure. Among the responsibilities of the Governance performance domain, the Guide lists monitoring and managing internal and external dependencies, risks, issues, and escalations (PMBOK® 8, Guide p.15).
Impediment, obstacle, blocker
The 2021 title named three words, which led people to look for a difference between them. The book draws no such distinction. Its glossary defines an impediment as an obstacle that prevents the team from achieving its objectives and gives blocker as another name for it (PMBOK® 8, Guide p.268), while the entry for "blocker" simply refers the reader to "impediment" (PMBOK® 8, Guide p.266). On the exam there is no need to rank these words. What matters in a question is who holds the authority to remove the impediment, whatever it happens to be called.
The leadership side of the task did not disappear with the move. The Guide says that supporting team members by solving problems and removing the obstacles in their way builds a supportive culture and leads to an environment of trust and collaboration (PMBOK® 8, Guide p.90).
Making impediments visible
An impediment nobody can see cannot be prioritized, which is why the second enabler mentions highlighting separately. The Guide offers two concrete tools for it. The first is the daily coordination meeting. In this short meeting the team reviews the previous day's progress, states what it will do that day, and highlights the impediments it has run into or expects to run into (PMBOK® 8, Guide p.162). Raising an impediment at the stage where it is only expected, before it has actually appeared, is part of what the meeting is for.
The second tool is the impediment log, which the Guide describes as a visual chart showing the description of each obstacle preventing work from being done, its severity, and the actions being taken to resolve it (PMBOK® 8, Guide p.214). Those three pieces of information line up with the ECO's enablers, since severity feeds the evaluation of impact and the prioritizing, while the actions taken correspond to the intervention strategy. When the log is kept current, the fourth enabler is covered as well, because anyone can see each day which impediments are still open.
Who removes the impediment
At this point the Guide describes two mechanisms that depend on the approach, and most III.4 questions grow out of that difference.
In predictive environments, escalation is listed as an additional governance component. According to the Guide, escalation is useful in hierarchical organizations where decision authority extends to people outside the project team, or where people higher up have more power to remove persistent obstacles and resolve conflicts (PMBOK® 8, Guide p.13). The Standard says who those people are. The sponsor, the customer, or the product owner can lead on decisions that fall outside the project management team's authority, and their work includes handling issues beyond that team's authority and removing impediments (PMBOK® 8, Standard p.32).
In adaptive environments, the mechanism is built inside the team. The Guide describes daily coordination meetings as a self-governance tool that helps the team stay focused and aligned, and adds that adaptive teams work autonomously (PMBOK® 8, Guide p.34). An impediment becomes visible inside the team first, and the team tries to remove it on its own.
The two mechanisms can coexist. The process for leading the team names both side by side, with the project manager tracking team members' performance, giving feedback, and resolving issues and escalating them when necessary (PMBOK® 8, Guide p.84). When you work through an exam question, start by asking whose authority the impediment falls under. Escalating something the team could have solved itself is a premature move, while holding on to an impediment that exceeds the team's authority only delays the work.
When a risk becomes an issue
The ECO writes this enabler out separately because it is one of the distinctions the exam tests most. The Guide defines an issue as a current condition or situation that may affect one or more project objectives. An issue has already happened, and it usually calls for immediate action or management attention (PMBOK® 8, Guide p.93). The same paragraph shows how the two are linked. An issue can arise from a poorly managed risk, yet issues are conditions that have occurred or are still ongoing, while risks describe possible future problems that have not happened yet.
The distinction has a counterpart in the records. An event that has occurred goes into the issue log, which the Guide defines as the project document where information about issues is recorded and tracked (PMBOK® 8, Guide p.123). A possibility that has not materialized stays in the risk register. If the event described in the question stem has already happened, spending time on planning a risk response is usually the wrong move, and if it has not happened, opening an issue log entry usually is. The risk side is covered in full on III.5 — Plan and Manage Risk.
One terminology overlap deserves attention. In the book, escalation is also the name of one of the risk response strategies. Escalating a risk means transferring its ownership to a relevant party in the organization, and it applies when the risk lies outside the project scope or when the team lacks the authority to deal with it (PMBOK® 8, Guide p.273). The logic is the same as escalating an impediment or an issue, but the subject is a risk that has not yet occurred.
Resolving issues together with stakeholders
The ECO's last enabler assumes that an issue is something the project manager does not solve alone. The Guide shows this in the processes that take the issue log as an input. The log is among the inputs to identifying stakeholders, managing stakeholder engagement, and managing communications (PMBOK® 8, Guide pp.71, 74, and 75). The Guide also notes that reviewing the issue log and the risk register can reveal difficulties related to individual stakeholders (PMBOK® 8, Guide p.93). Resolving an issue therefore often begins with finding the stakeholder who is affected by it or who has the authority to settle it.
The control side of governance points to the same place. When the Guide checks the outcomes of the Governance performance domain, the items the team should focus on include known risks, response plans, and escalation criteria, along with issues and issue response plans (PMBOK® 8, Guide p.37). That ties the decision to escalate to a criterion set in advance. Where and by whom those criteria are set is the subject of III.1 — Define and Establish Project Governance.
About the citations
Every page number above refers to the PMBOK® Guide, Eighth Edition (PMBOK® 8); references to the 2026 ECO are marked "ECO" separately.
⚠️ PMBOK® 8 contains two separate books in one volume, and their page numbering is independent:
- The Standard for Project Management — cited as Standard p. X
- A Guide to the Project Management Body of Knowledge — cited as Guide p. X
This page cites both books; which number belongs to which book is stated in every citation. The numbers are the books' printed page numbers.
This page describes the book; it does not replace it.
