Remove Impediments and Manage Issues
Not sure you’re ready?
Take the ~3-minute readiness diagnostic and see where you stand.
A project schedule is an idealization of reality, much like the frictionless plane we use to teach introductory physics. The mathematical elegance of a critical path or the clean progression of a sprint backlog assumes perfect conditions. Yet, the moment a plan makes contact with execution, it encounters friction. Vendors miss delivery dates, core components fail during integration, and business requirements pivot overnight. Managing cross-functional delivery is fundamentally an exercise in neutralizing these sources of friction before they halt forward momentum. Understanding the precise taxonomy of project disturbances is not merely an academic exercise; it dictates the exact mechanical response required to keep the project moving, preserve the business case, and protect the team's capacity to deliver.
Before a project manager can clear a path, they must accurately classify the debris blocking it. We often use terms interchangeably in daily conversation, but in professional project management, precision matters.
The PMBOK Guide defines a risk as an uncertain future event or condition. It is a probability. By contrast, the PMBOK Guide defines an issue as a current condition or situation that may have an impact on the project objectives.
The transition between these two states is instantaneous: a project risk becomes an issue the moment the uncertain event actually occurs.
Imagine you are managing the deployment of a new financial system. A known risk is that the third-party payment gateway might update its API syntax before your launch. If you wake up Tuesday morning and the API has indeed changed, breaking your code, the probability has collapsed to 100%. The event has materialized. When a documented risk occurs, the project manager records the event in the project issue log. In predictive project management, an issue log formally documents all ongoing project issues, serving as the single source of truth for problem resolution.
The Agile Triad: Obstacles, Blockers, and Impediments
When operating in an agile or hybrid environment, we further dissect project friction based on its localized impact on team velocity and workflow.
| Disturbance | Definition | Real-World Example |
|---|---|---|
| Obstacle | A barrier that slows down team progress without completely stopping the work. The team is still moving, but inefficiently. | The staging server is running slowly, doubling the time it takes to compile code. |
| Blocker | A specific condition that entirely stops work on a single task or user story. Work on this item is paralyzed until resolved. | A developer cannot finish a login module because the cybersecurity team has not provided the required encryption keys. |
| Impediment | Any condition that prevents a project team from achieving a sprint goal or completing a project phase. It is a systemic or broad-scale failure. | The product owner is suddenly pulled onto another initiative and cannot approve any completed stories before the sprint ends. |
When an issue or impediment arises, the immediate physiological reaction is to panic or dive straight into fix-it mode. An elite project manager resists this impulse, opting instead for a calculated evaluation of the blast radius.
To govern effectively, you must measure the damage. Project managers evaluate the impact of an issue by assessing the effect on project cost baselines, as well as evaluating the impact of an issue by assessing the effect on project scope baselines. If a critical vendor declares bankruptcy (an issue), you must immediately determine: Will sourcing a replacement cost an extra $50,000, breaching our cost baseline? Must we drop a feature to launch on time, breaching our scope baseline?
For schedule delays, project managers evaluate the impact of an impediment by analyzing potential delays to the critical path. A blocker on a task that possesses twenty days of float is an annoyance; a blocker on a task on the critical path is an immediate threat to the final delivery date.
The Calculus of Prioritization
You will rarely have the luxury of facing only one problem at a time. Therefore, project teams prioritize impediments based on the severity of the impact on project objectives, counterbalanced by the urgency of resolving the blockage. A minor UI bug might be severe to the brand's look, but a blocked database migration that must happen this weekend possesses immediate, non-negotiable urgency.
A hidden problem is an unsolvable problem. High-performing teams do not whisper about blockers; they broadcast them.
Information radiators display impediments openly to ensure all stakeholders are aware of current blockers. By externalizing the problem, you invite organizational support and prevent duplicate effort. In agile workflows, Kanban boards highlight task blockers visually using specific tags or dedicated blocked columns. If a stakeholder walks past a team's physical or virtual board and sees a glaring red "BLOCKED" tag on a priority story, the conversation instantly pivots to resolution.
Teams also build this visibility into their daily cadences. Agile teams use daily standup meetings to verbally highlight new impediments, ensuring a maximum 24-hour feedback loop on any workflow stoppage. Concurrently, agile teams maintain an impediment board to continuously track the status of current blockers separate from the product work itself, ensuring that clearing the path becomes a managed workflow of its own.
Treating a symptom guarantees its return. To definitively eliminate friction, you must isolate its origin. Root cause analysis identifies the underlying source of an impediment to prevent future recurrence.
We achieve this through specific diagnostic frameworks:
- The Five Whys technique determines the root cause of an issue by repeatedly questioning the cause of a defect. If a server crashed, Why? (Memory overload). Why? (Inefficient query). Why? (Developer bypassed peer review). Why? (Unrealistic deadline pressure). The true issue is not hardware; it is scheduling pressure causing process circumvention.
- Ishikawa diagrams (or fishbone diagrams) visually map out potential causes of a specific project impediment, grouping potential causes into categories like people, processes, technology, and environment.
Formulating the Intervention Strategy
Once diagnosed, how do we act? The mechanics of the intervention depend on the nature of the event:
- Planned Responses: A realized negative risk requires the implementation of a previously planned risk response. Because you foresaw the possibility of the API changing, you already allocated a reserve budget and mapped out an architectural fallback. You simply execute the playbook.
- Workarounds: If an unplanned issue occurs, the project manager must develop a workaround to resolve the problem. This is an active, on-the-fly response to a wholly unforeseen event.
Because modern project management involves highly specialized knowledge work, project managers collaborate with subject matter experts to design effective workarounds for complex technical issues. Furthermore, collaborative problem-solving requires project managers to facilitate workshops with stakeholders to brainstorm issue resolutions. You are not expected to invent the solution; you are expected to construct the environment where the solution can be discovered.
In agile and hybrid frameworks, the authority dynamic shifts. Project managers use servant leadership to remove organizational impediments on behalf of the project team. You are the bulldozer driving ahead of the pavers. A Scrum Master acts as a servant leader by clearing blockers that the development team cannot resolve internally, such as negotiating cross-departmental resource conflicts or shielding the team from executive interruptions.
However, a servant leader must also recognize their jurisdictional limits. Project managers escalate an impediment when the resolution requires authority beyond the project team level. If resolving a blocker requires dissolving a multi-million dollar vendor contract, that is a decision for the C-suite, not the daily standup.
When resolving issues, communication and governance are just as vital as the technical fix. You cannot alter the project's foundation in the dark.
Before acting, project managers consult the stakeholder engagement plan to determine the appropriate method for communicating issues. Some stakeholders require daily briefings; others just want a dashboard update.
Crucially, you must respect the project's foundational constraints. Predictive projects use a formal change control process to implement issue resolutions that affect project baselines. If a workaround requires altering the fundamental agreement of the project, executive alignment is mandatory:
- A project manager updates the project sponsor when an issue resolution requires a change to the approved budget.
- A project manager updates the project sponsor when an issue resolution requires a change to the approved schedule baseline.
- A project manager updates the project sponsor when an issue resolution requires a change to the approved project scope.
Removing an impediment is not a one-time event; it is an iterative cycle of verification. A project manager's job isn't done just because an email was sent asking a vendor to fix a defect.
Project managers continuously review the issue log to ensure assigned issue owners are making progress. Accountability must be tracked. Once a fix is deployed, project managers must update the issue status in the issue log after applying an intervention strategy, closing the loop so the organization knows the threat is neutralized.
Finally, we look to the future. To prevent the team from facing the same hurdles in the next iteration, agile teams reassess systemic impediments during sprint retrospectives to improve future team velocity. By looking backward at what slowed them down—be it outdated software, clunky approval processes, or vague requirements—the team structurally improves its environment.
By mastering the identification, evaluation, and resolution of issues and impediments, a project manager ensures that the project schedule does not remain a theoretical, frictionless illusion, but rather a resilient engine capable of navigating the rugged terrain of reality.