Remove Impediments and Manage Issues

Introduction

This lesson covers task 4 of the Business Environment domain in the July 2026 PMP Examination Content Outline. Business Environment carries 26% of the exam. Every project meets obstacles: a test environment that is not ready, a decision that nobody takes, a supplier that delivers late, a key expert who is pulled to another initiative. When these obstacles are left alone, the team loses time, quality drops, morale falls, and a small blockage becomes a schedule problem. The project manager, or the scrum master and servant leader in an agile team, is expected to notice obstacles early, judge how serious they are, act, and keep checking until they are gone.

The exam tests situations such as: the team reports three blockers in the daily meeting and you must decide which to handle first; a risk in the register has just happened; a stakeholder keeps delaying a decision; an issue is outside your authority and must be escalated. You must separate impediments, issues, risks, and changes, evaluate the impact, choose an intervention, involve the right stakeholders, and reassess until the problem is closed. After this lesson you will be able to do this in predictive, agile, and hybrid projects.

Learning objectives

• Distinguish an impediment, an issue, a risk, a problem, and a change request.
• Evaluate the impact of an impediment on scope, schedule, cost, quality, benefits, and the team.
• Prioritize and highlight impediments using transparent criteria.
• Choose and apply an intervention strategy: remove, minimize, work around, escalate, or accept.
• Recognize when a risk becomes an issue and trigger the right response.
• Maintain an issue log and impediment board, and collaborate with stakeholders to resolve issues.
• Reassess blockers continually and learn from their causes.

1. Key concepts and vocabulary

Several terms look similar. The exam expects you to pick the right process for the right object.

An issue is certain; a risk is not. Once a risk event occurs, it leaves the risk register and enters the issue log (the register is updated with the occurrence, the response is executed, and the contingency or fallback plan may be triggered). An impediment is a kind of issue seen from the team's viewpoint: it blocks flow. Fixing an issue may require a change request, but the issue itself is not a change request.

A decision tree helps:

1. Has it happened? If not, it is a risk: assess and plan a response.
2. If yes, does it block or slow work now? It is an impediment or an issue: act.
3. Does the solution require changing a baseline, a contract, or the approved scope? Then raise a change request.
4. Is it beyond your authority or beyond the team's ability? Escalate with options.

2. Evaluating the impact of an impediment

The first reaction to a blocker should not be to fix it at once, but to understand it. A quick, structured evaluation takes a few minutes and avoids spending effort on the wrong thing.

Questions to ask:

• What is blocked? Which work items, deliverables, or milestones? Are they on the critical path or on the iteration goal?
• Who is blocked? One person, the whole team, several teams, a supplier?
• How long? Since when, and what is the expected duration without action?
• What is the cost of delay? Idle time, penalties, lost benefits, rework, overtime.
• What is the cause? Technical, organizational, a missing decision, a missing resource, an external party, a conflict.
• Does it spread? Could it block other work, create a risk, or affect quality or compliance?
• Who can remove it? Within the team, within the project manager's authority, or at the sponsor or another function.

Worked example: ranking impediments

Scenario. A product team of eight people builds a mobile banking feature in two-week iterations. Today, in the daily meeting, the team reports four blockers:

1. The security team has not yet reviewed the authentication design; the login story (13 points, the iteration goal) cannot be completed. The next review slot is in 6 days, after the end of the iteration.
2. A developer's licence for a testing tool expired; renewal takes one day through the normal process.
3. Two team members disagree about the logging format; they discuss it with raised voices in every meeting.
4. A third-party identity provider has not delivered the sandbox keys promised for last Monday; three stories depend on them.

Step 1: assess the impact of each.

Step 2: prioritize. Priority goes to what threatens the goal and has the highest cost of delay and the longest lead time: impediments 1 and 4. Number 2 is cheap and can be done in minutes by asking procurement to expedite, so it is also handled today although it ranks lower in impact. Number 3 is a conflict to manage in a separate conversation, not in the daily meeting.

Step 3: interventions. For 1, ask the security manager for an exceptional review slot, and offer options: a one-hour session tomorrow with the architect, or an asynchronous review. If refused, escalate to the sponsor with the cost of delay. For 4, call the vendor's account manager, state the date promised and the effect on the project, request a firm delivery date, and prepare a workaround: a mock service so the team can continue. For 2, request the expedited renewal. For 3, speak with both people separately, then agree on a standard with the tech lead and record it in the team agreement.

Step 4: visibility and follow-up. Put each item on the impediment board with an owner and a date. Review the board every day.

Why not the other choices? Starting with number 2 because it is easy leaves the high-impact items waiting. Telling the team to work around everything hides the problem. Waiting until the retrospective to talk about the vendor delay loses a week.

3. Prioritizing and highlighting impediments

Prioritization criteria

Combine several criteria rather than relying on instinct:

• Impact on objectives: iteration goal, critical path, milestone, regulatory deadline.
• Number of people or work items affected.
• Urgency: time before the damage becomes permanent.
• Effort and time to remove. Quick wins are done at once.
• Probability of recurrence and effect on other teams.

A simple scoring grid can help. Score impact (1 to 5), urgency (1 to 5), and breadth (1 to 5), multiply or add the scores, and rank. The numbers support the discussion; they do not replace judgment.

Making blockers visible

Visibility is a core agile and leadership practice. Information radiators show the state of the work honestly and give the sponsor and stakeholders a reason to act.

• Impediment board: a physical or digital board, with columns such as New, In progress, Waiting for others, Resolved. Each card has an owner, a date, and a business effect.
• Blocked marker on the task board, with the reason written on it.
• Daily meeting: each member states what blocks them; the facilitator captures and follows up. The daily meeting reveals blockers; it is not the place to solve long technical debates.
• Issue log in predictive projects: identifier, description, date raised, owner, priority, status, resolution date, link to related risks and changes.
• Status reports and steering committees: top impediments and decisions requested, with deadlines and consequences of inaction.

Highlighting does not mean blaming. Present the facts and effects, then ask for what is needed: a decision, a person, a budget, access.

4. Intervention strategies

Once the impact is known, choose the response. Several are possible:

The servant leader and the project manager

In agile teams, the scrum master or agile coach removes impediments that the team cannot remove itself, protects the team from outside interruption, and teaches the team to resolve what is within its power. The team members are encouraged to solve what they can without waiting; the facilitator takes what requires organizational influence. In predictive projects, the project manager manages issues through the issue log, assigns owners, sets deadlines, and escalates according to the governance plan.

Escalation

Escalation is not failure. It is the correct response when the problem is beyond your authority. Good escalation:

1. Describes the situation in a few lines, with data.
2. States the effect on scope, schedule, cost, quality, or benefits, and the effect on the date if nothing is done.
3. Lists the actions already taken.
4. Presents options with a recommendation.
5. States clearly what decision or support is needed, from whom, and by when.

Use the escalation path and thresholds defined in the governance plan. Do not skip levels without reason, and do not escalate before trying what is within your authority, unless the situation is urgent or concerns ethics, safety, or compliance.

Worked example: escalating a vendor delay

Scenario. A construction-software project depends on a supplier that must deliver a hardware gateway by 1 March. On 12 February the supplier says the delivery will be 6 weeks late because of a component shortage. The critical path will slip by 4 weeks; the penalty to the client for a late go-live is 10,000 per week. The governance plan says the project manager can approve cost impacts up to 15,000; larger ones go to the sponsor. The contract with the supplier includes a clause for expedited shipping at the supplier's cost only if the delay is due to the supplier's fault.

Step 1: confirm the facts. Ask the supplier for written confirmation, the cause, and the earliest realistic date.

Step 2: evaluate options.

Step 3: act within authority. Option c costs 12,000, within the project manager's 15,000 authority, but it modifies the delivery approach, so inform the sponsor. Option b exceeds the threshold and needs the sponsor.

Step 4: escalate and negotiate. Inform the sponsor and procurement of the delay, the options, and the recommendation (option c). Ask procurement to review the contract clause with the supplier.

Step 5: record and follow up. Log the issue, owner, due dates, decision; update the schedule, risk register, and stakeholders; check the supplier weekly.

Why not wait or hide it? Waiting converts a 12,000 solution into a 40,000 penalty. Hiding it breaks transparency and trust with the sponsor.

5. When a risk becomes an issue

A risk is a possibility; when it occurs, it is now an issue. The project manager must recognize this change quickly, because the response changes from planning to action.

Signals that a risk has materialized:

• A trigger defined in the risk register is reached (for example, a vendor misses an interim milestone).
• A team member, a report, or a test shows the event has happened.
• A threshold in a metric is crossed (cost performance index below 0.9).

What to do:

1. Confirm that the event has occurred and what happened.
2. Update the risk register: mark the risk as occurred and close it or reduce it, and record the actual effect.
3. Open an issue in the issue log with an owner and date.
4. Execute the planned response: contingency plan, fallback plan, or the response chosen. Use the contingency reserve if approved; if the reserve is not enough, a request for management reserve passes through change control.
5. Look for secondary risks and new risks created by the event or by the response, and add them to the register.
6. Communicate to stakeholders according to the communications plan.
7. Learn: record the lesson and update the risk identification checklist.

If no response was planned, treat it as an unplanned issue: analyze, choose the response, and then add the lesson to the risk process.

6. Collaborating with stakeholders to resolve issues

Many issues cannot be solved by the team alone. The project manager brings the right people together, shares the facts, and works toward a decision.

Good practices:

• Identify who owns the solution, not just who is affected. Include the people who control the resource, the budget, or the decision.
• Use facilitation techniques: a short problem-solving workshop, brainstorming, the five whys, a fishbone diagram, and a decision matrix.
• Agree on the problem statement first. Different stakeholders often describe different problems.
• Define options with criteria, such as cost, time, quality, risk, and value, and let the decision-maker choose.
• Agree on actions, owners, and dates, and record them in the issue log.
• Keep communicating: inform affected stakeholders of progress, even when the news is bad.
• Manage conflict when an issue involves disagreement between stakeholders: focus on interests, not positions, use collaborative or problem-solving approaches, and escalate only if no agreement is possible.

Root cause analysis

Resolving the symptom brings the problem back. Techniques include:

• Five whys: ask why repeatedly until you reach a cause that can be acted on.
• Fishbone (Ishikawa) diagram: group potential causes by category such as people, process, tools, environment, and materials.

Example: The same test environment is unavailable every week. Why? It restarts at night. Why? An automatic update runs. Why? The environment is managed by another team with a different maintenance window. Why? The project never agreed on a service level with them. Action: negotiate a service agreement and a maintenance window; the cause is organizational, not technical.

7. Continual reassessment

An impediment that is "being worked on" is not solved. Its situation changes: the impact grows, the workaround fails, the owner changes, or new information appears. The project manager reviews the list regularly.

• Review the board daily in agile teams and at least weekly in predictive projects.
• Re-evaluate priority and impact at each review.
• Close an item only when the effect is gone and the owner confirms.
• Look at the ageing of items: an impediment older than the agreed limit, such as three days, is escalated automatically.
• Watch for patterns: repeated blockers of the same kind indicate a systemic problem to be raised in the retrospective or with management.
• Track metrics such as the number of open impediments, average resolution time, and the blocked time of work items.

At the end of each iteration or phase, run a retrospective or lessons learned session, and update organizational process assets with the reusable lessons.

8. Common pitfalls and exam tips

Common pitfalls

• Fixing the symptom and not the cause.
• Handling everything personally instead of enabling the team to solve its own blockers.
• Waiting for the retrospective to raise a blocker that costs money every day.
• Escalating without data or options, or escalating too early without trying.
• Confusing a risk with an issue and updating the wrong log.
• Treating a change request as if it were an issue, or implementing a fix that changes the baseline without approval.
• Closing the item when the action is done instead of when the effect is gone.

Exam tips

• Exam tip: If the risk has occurred, the next step is to treat it as an issue and execute the planned response, not to reassess the probability.
• Exam tip: When several blockers exist, choose the one with the greatest effect on the goal or critical path and the longest lead time, unless a quick action solves another at no cost.
• Exam tip: In an agile team, the scrum master removes impediments the team cannot remove; the team is encouraged to self-organize first.
• Exam tip: If the solution is outside your authority, escalate with options and a recommendation, following the governance plan.
• Exam tip: Investigate before acting: the best first step is often to gather facts and assess the impact.
• Exam tip: If the issue requires changing a baseline, submit a change request.

Mini case study

Case. You are the project manager of a regulatory reporting system for an insurance company. The team of ten works in three-week iterations, and the steering committee meets monthly. Three weeks before the regulatory deadline, the following happens in one morning:

1. The risk register contained "Data feed from the actuarial department may be delayed (probability medium, impact high)". The trigger was "no test file by day 10". Today is day 12 and no file has arrived.
2. The lead tester says she cannot start the final acceptance tests because the production-like environment is shared with another project that has booked it for ten days.
3. A business analyst says the compliance department keeps changing the report layout by email, and two developers have built different versions.

You have a contingency reserve of 20,000 and the sponsor is available in the afternoon. The penalty for missing the deadline is 50,000 plus supervisory attention.

Question. What should you do?

Solution (commented).

1. Item 1 is now an issue. The trigger was reached and the event occurred. Confirm with the actuarial manager, update the risk register (risk occurred), open an issue, and execute the planned response; suppose it was to use anonymized production extracts as a fallback. Request them at once, and approve the use of the reserve if the response has a cost within the contingency reserve. Look for secondary risks, such as data privacy and extract quality, and register them.
2. Item 2 is an impediment with a high effect on the critical path. Contact the other project manager to negotiate a shared schedule; ask the environment owner whether a second environment can be created temporarily. If neither is possible within a day, escalate to the sponsor with the cost of delay (the 50,000 penalty), options (split the environment, prioritize this project, reduce the other project's booking), and the decision needed by tomorrow.
3. Item 3 is a change and conflict problem: informal changes are creating rework. Stop the work on the two competing versions, ask the compliance department for a single written layout through the change process, and name one person as the decision contact. Show the cost of the duplicated effort.
4. Prioritize: items 1 and 2 first (critical path and a deadline), item 3 in parallel because the cost grows each day.
5. Communicate: brief the sponsor in the afternoon, update the steering committee, and tell the team what has been decided.
6. Follow up: put the three items on the board with owners and times, and review them daily until the deadline.
7. Address the causes later: in the retrospective, examine why environment booking and layout changes had no rules.

Wrong approaches: Waiting for the monthly steering committee, absorbing the delay by asking the team to work overtime without fixing the cause, or letting the compliance department keep changing the layout informally.

Key terms

• Impediment (blocker): something that prevents the team from working effectively.
• Issue: a current condition that affects the project objectives; a risk that has occurred.
• Issue log: a record of issues, owners, status, and resolution.
• Impediment board: a visible list of blockers and their status.
• Escalation: passing a matter to a higher authority when it is beyond your level.
• Workaround: an unplanned response to a threat that has occurred, when no contingency was planned.
• Contingency plan: a response prepared in advance and triggered by an event.
• Fallback plan: an alternative if the first response is not effective.
• Root cause analysis: a technique to find the underlying cause of a problem.
• Servant leader: a leader who serves the team by removing obstacles and enabling its work.
• Information radiator: a visible display of project information.

Summary checklist

• I can tell a risk from an issue, an impediment, and a change request.
• I evaluate the impact of each blocker on goals, schedule, cost, and quality.
• I prioritize blockers using impact, urgency, breadth, and effort.
• I make impediments visible on a board or log with owners and dates.
• I choose an intervention: remove, minimize, work around, escalate, change, or accept.
• I escalate with facts, options, and a recommendation, following the governance plan.
• I convert a risk into an issue when it occurs and execute the planned response.
• I collaborate with the right stakeholders and find root causes.
• I reassess continually and close items only when the effect is gone.

Official sources

• PMI, PMP Examination Content Outline (July 2026): https://www.pmi.org/-/media/pmi/documents/public/pdf/certifications/new-pmp-examination-content-outline-2026.pdf (opens in a new tab)
• PMI, About the new PMP exam: https://www.pmi.org/certifications/project-management-pmp/new-exam (opens in a new tab)
• PMI, Project Management Professional (PMP): https://www.pmi.org/certifications/project-management-pmp (opens in a new tab)
• PMI, Standards: https://www.pmi.org/standards (opens in a new tab)