Impediments, issues and escalation

Every project runs into obstacles: a supplier is late, a key person is pulled onto other work, a decision is stuck, a test environment fails, a rule is unclear. The 2026 outline asks project leaders to remove impediments and manage issues: to assess and prioritize impediments, apply ways to resolve them, reassess them regularly, recognize when a risk has become an issue, and work with stakeholders to resolve issues. PMP-131 covered issues from the risk and change side. This lesson treats impediments and issues as a Business Environment task, focusing on triage, ownership, escalation and the organizational obstacles that only governance can remove.

Risks, issues and impediments

The three terms overlap but are not the same, and the exam expects you to tell them apart.

A risk becomes an issue when it occurs. At that point, the planned risk response, if one exists, is put into action, and the item moves from the risk register to the issue log, with a cross-reference. Recognizing that moment matters: a team that keeps describing a problem as a risk after it has happened is likely to under-react. In adaptive teams, issues and impediments are often handled through the same mechanism: impediments are raised in the daily scrum, the Scrum Master or team lead works to remove them, and those the team cannot remove are escalated.

Triage: what to work on first

When several impediments and issues are open at once, the project manager needs a quick, consistent way to decide where to spend effort. A common approach scores each item on impact (how much it affects objectives) and urgency (how soon it must be resolved before the damage grows), assigns an owner and a target date, and tracks how long each item has been open. Items that are both serious and old are the strongest candidates for escalation, because they have shown they will not resolve themselves at the current level.

# Rank open impediments and issues by impact x urgency, then flag any that are too old.
from datetime import date
today = date(2027, 7, 14)
items = [
    ("Kiosk firmware fails RFID gate handshake", 4, 5, date(2027, 7, 9),  "Technology lead"),
    ("Second electrician crew not yet booked",     4, 3, date(2027, 7, 2),  "Project manager"),
    ("Product owner pulled into budget meetings",  3, 4, date(2027, 6, 28), "Sponsor"),
    ("Test devices for screen reader checks late", 2, 3, date(2027, 7, 12), "Scrum Master"),
    ("Union question on new self-checkout duties", 4, 4, date(2027, 7, 6),  "HR lead"),
]
limit_days = 10
print("Score  Age  Owner            Item")
for name, impact, urgency, raised, owner in sorted(items, key=lambda i: i[1] * i[2], reverse=True):
    age = (today - raised).days
    flag = "  <- escalate" if age > limit_days and impact * urgency >= 12 else ""
    print(f"{impact * urgency:>5}  {age:>3}  {owner:15}  {name}{flag}")

Score  Age  Owner            Item
   20    5  Technology lead  Kiosk firmware fails RFID gate handshake
   16    8  HR lead          Union question on new self-checkout duties
   12   12  Project manager  Second electrician crew not yet booked  <- escalate
   12   16  Sponsor          Product owner pulled into budget meetings  <- escalate
    6    2  Scrum Master     Test devices for screen reader checks late

The kiosk firmware problem scored highest, but it was only five days old and the technology lead was actively working with the vendor, so it stayed with its owner and was reviewed daily. Two items were flagged for escalation: the second electrician crew, which the project manager had been trying to book for 12 days, and the product owner being pulled into budget meetings, open for 16 days. The first needed a decision only the sponsor could make, to release management reserve for a premium-rate crew. The second was an organizational impediment: the director of finance kept scheduling Amara Osei into budget sessions, leaving the app team without a product owner for two days a week. The project manager could not fix that alone, because it involved competing priorities between two senior managers.

Ways to remove impediments

The outline speaks of applying intervention strategies. In practice the project manager or Scrum Master has a range of options, roughly in order of escalation.

• Remove it directly: fix the tool, book the room, find the information, clarify the requirement.
• Coach the team to remove it: many impediments are within the team's own power once someone points out the options.
• Negotiate: work with a functional manager, vendor or other team to free a person, a resource or a decision.
• Work around it: change the sequence of work, use a substitute, or adjust scope so the obstacle no longer blocks progress.
• Escalate: take it to the sponsor or governance body with an analysis of its impact and options, when it is beyond the project's authority or has resisted other approaches.

Servant leadership, covered in PMP-120 and PMP-140, puts removing impediments at the centre of the leader's job. The goal is not to solve every problem personally, but to make sure obstacles are seen early, owned clearly and removed at the lowest level that can remove them.

Escalating well

Escalation is not failure; it is how governance is supposed to work when a problem exceeds someone's authority or capability. But there is a difference between escalating well and simply passing a problem upward. A good escalation states the problem and its impact on objectives, what has been tried, the options available with their costs and consequences, a recommendation, and the decision needed and by when. It goes to the person or body with the authority to decide, through the agreed escalation path, not around it.

The sponsor raised the issue with the finance director the same day, and a deputy took over routine budget sessions until the opening. The issue log recorded the decision and its date, and the team's sprint 8 forecast returned to about 20 points.

The issue log

An issue log (or issue register) records each issue with its description, date raised, who raised it, category, impact and priority, owner, actions, target resolution date, status and final resolution. It supports reporting to governance, helps make sure nothing is forgotten and becomes a source of lessons learned. Reviewing the log regularly, weekly on most projects and daily for critical issues, keeps attention on ageing items. Closed issues should record how they were resolved, so that similar problems later can be handled faster.

Organizational impediments

Some of the hardest impediments are not technical at all. They are conflicting priorities between departments, policies that slow work without adding value, approval chains that take weeks, shared resources everyone is fighting over, or cultural habits such as reluctance to share bad news. These are Business Environment problems: the project manager cannot solve them by working harder inside the project. The project manager can make them visible, quantify their cost, propose changes and bring them to the people with authority. Over time, recording organizational impediments and their effects is one of the most useful inputs to the organization's improvement efforts, which lesson 12 covers.

Impediments on adaptive teams

Agile teams make impediments visible by design. Developers mention blockers in the daily scrum; many teams keep an impediment list or a column on their board; and the Scrum Guide makes the Scrum Master accountable for getting impediments to the team's progress removed. This visibility is valuable, but only if impediments are actually removed. A team that raises the same blocker in every daily scrum for a week, with no change, is learning that raising impediments is pointless.

A useful habit is to separate impediments the team can remove itself from those it cannot. The first group should be handled by the team, with the Scrum Master coaching rather than fixing everything. The second group, such as a missing test environment owned by another department or a policy that prevents deploying on Fridays, needs the Scrum Master or project manager to work with others in the organization. The Compass app team tracked both kinds on its board, with the date each was raised, so that ageing blockers were obvious at a glance.

Recurring impediments across teams are a strong signal for organizational improvement. When three projects in a year report waiting weeks for test devices, the right response is to change the procurement process, not to escalate the same problem three times.