Impediment Log

سجل العوائق

tasleemat asset PMO-05.10 template --lang en

Deliverable Summary & Governance Boundaries

Lifecycle Phase Alignment

Phase 05: Executing

Sizing Tier Requirements

Tier 1 Tier 2 Tier 3

Validation Contract

This deliverable conforms to a strict companion Draft 2020-12 JSON Schema for automated structural and semantic validation.

tasleemat validate PMO-05.10 ./completed_data.json

Template Markdown (Bilingual)

<!-- LLM INSTRUCTIONS: Fill in the [ Add details... ] placeholders based on project context.

Context and Definition:
An impediment log is the record of the things standing between a team and the
work it has taken on, recorded so that they are raised rather than worked
around. An impediment is not an issue: an issue is something wrong inside the
team's own work, which the team fixes by working differently, while an
impediment is something the team cannot remove by itself. That distinction is
what the log records, and it is why every entry has an owner, because the
person raising an impediment is rarely the person who can clear it.

It can receive information from:
*   Sprint planning log
*   Daily stand-up notes
*   Team performance assessment

It provides information to:
*   Issue log, once the impediment becomes work the team can do
*   Decision log, when clearing it needed a decision
*   Project status report, because a long-standing impediment is a status fact
*   Retrospective, which is where a resolved one is worth reading again

Tailoring Tips:
*   Raise it rather than absorb it. A team that quietly works around an
    impediment looks productive for exactly as long as the workaround holds.
*   Name the cost, not the annoyance. An entry that says the work is blocked
    without saying what it costs cannot be weighed against anything else.
*   Write the resolution. The entry is closed when the impediment is gone, and
    the note about how it went is the part the next team can use.

Alignment:
The impediment log should be aligned and consistent with:
*   Issue log
*   Decision log
*   Risk register, because an impediment that recurs is a risk being realised

Section Instructions:
*   Impediment Log: for each impediment standing between the team and its
    work, give its identifier, the date it was raised, what it is in terms
    someone outside the team would understand, what it costs, who is pursuing
    it, and whether it is open, in progress or resolved.
-->

<h3 dir="ltr" align="right">{{Company_Name}}</h3>
<h2 dir="ltr" align="right">{{Project_Name}} - {{Project_ID}}</h2>
<h1 dir="ltr" align="center">IMPEDIMENT LOG</h1>

| **Date Prepared:** {{Current_Date}} | **Project Manager:** {{Project_Manager_Name}} | **Prepared By:** {{Prepared_By}} |
| :--- | :--- | :--- |

---

## Impediment Log

| Impediment ID | Date Raised | Description | Impact | Owner | Status |
| :---: | :---: | :--- | :--- | :--- | :---: |
| [ Add details... ] | [ Add details... ] | [ Add details... ] | [ Add details... ] | [ Add details... ] | [ Add details... ] |
| [ Add details... ] | [ Add details... ] | [ Add details... ] | [ Add details... ] | [ Add details... ] | [ Add details... ] |
| [ Add details... ] | [ Add details... ] | [ Add details... ] | [ Add details... ] | [ Add details... ] | [ Add details... ] |

---

### Sign-off and Approvals

| Role | Name | Signature | Date |
| :--- | :--- | :---: | :---: |
| **Scrum Master / Agile Coach** | {{Scrum_Master_Name}} | _______________________ | [ .... - .... - .... ] |
| **Team Member / Contributor** | {{Contributor_Name}} | _______________________ | [ .... - .... - .... ] |
| **Project Manager** | {{Project_Manager_Name}} | _______________________ | [ .... - .... - .... ] |
---

<div dir="ltr" align="right" style="margin-top: 20px; font-size: 12px; color: #7f8c8d;">
  <span>Electronic Audit Trail: Hash SHA256: {{Audit_Trail_SHA256_Hash}}</span> <br>
  <strong>Template:</strong> IMPEDIMENT LOG | <strong>Ref:</strong> PMO-05.10 <br>
  <i>Generated on: {{Current_Timestamp}}, by <a href="https://github.com/fakhruldeen/Tasleemat/" style="color: #7f8c8d;">Tasleemat</a></i>
</div>

User Guide & Practitioner Instructions

Tasleemat Forms Guide

Project Artifact: Impediment Log

Document Reference: PMO-05.10

This document provides a comprehensive, professional reference to understand the purpose and effective usage of the Impediment Log in alignment with the Tasleemat framework.

1. What?

A table of the things standing between the team and its work, one row each: an identifier, the date it was raised, what it is, what it costs while it stands, who is pursuing it, and whether it is open, in progress or resolved. The owner column is the one that distinguishes this from an issue list, because it names the person chasing the obstacle rather than the person blocked by it.

2. Why?

Because an impediment that is absorbed is an impediment that is hidden. A team that works around one looks productive for exactly as long as the workaround holds, and the cost of the workaround arrives later and separately, where nobody connects it to the decision not to ask. The log also accumulates something an issue list does not: a record of how each one was cleared, which is the part the next team can actually use.

3. When?

Raised as soon as it is recognised, and not batched to the end of the cycle. The date it was raised is what makes a stale one visible, because an entry with no date is one nobody can tell has been sitting there. It is closed when the impediment is gone, not when it stops being inconvenient.

4. Who?

Raised by whoever hits it, which on an agile team is any member rather than the lead. That is the point of the form: the person nearest an obstacle is the one best placed to name it, and a log that only the lead writes is a log of what the lead noticed. The team lead signs because escalation is their responsibility, and the project manager signs because most impediments can only be cleared above the team.

Tailoring Tips

Raise it rather than absorb it. The workaround is cheaper this cycle and it hides the cost, which is the whole reason the cost is not being argued about.
Name the cost, not the annoyance. An entry that says the work is blocked without saying what it costs cannot be weighed against the other things that need the same person.
Write the resolution. The entry closes when the impediment is gone, and the note about how it went is the part anyone can reuse.

Alignment & Dependencies

1. Pre-requisites & Inputs (Upstream Dependencies)

Mandatory:
- Project Management Plan (PMO-04.01.01)
- Approved Baselines (Scope/Schedule/Cost)
Optional / Contextual:
- Risk Register (PMO-04.08.02)
- Stakeholder Engagement Plan (PMO-04.10.01)

2. Downstream Dependents

Mandatory:
- Project Status Reports (PMO-06.01)
- Change Log (PMO-05.04)
- Lessons Learned Summary (PMO-07.01)
Optional / Contextual:
- Variance Analysis (PMO-06.04)
- Decision Log (PMO-05.02)

5. How?

To accurately complete the Impediment Log, populate the following sections based on the project context (ensuring reference to parameters.md for the general project variables):

Impediment ID: A short identifier, so an impediment can be referred to in a stand-up without being described again. A number is enough if it is the only one in use.
Date Raised: When it was identified. The date is what makes an old impediment visible: an entry with no date is one nobody can tell has been sitting there.
Description: What is standing between the team and the work, in terms someone outside the team would understand. A description the reader can only decode by asking is not one that can be escalated.
Impact: What it costs while it stands: the work it holds up and what that costs in the cycle. An impediment with no stated impact cannot be prioritised against anything else.
Owner: Who is pursuing the resolution, which is not the same as who the impediment affects. The person raising it may be pursuing it and the person who can remove it may be elsewhere.
Status: Open, in progress, or resolved, and the date it was resolved. A resolved entry with no resolution recorded is worth little, because the next team to hit it cannot use what was learned.

Associated Templates

6. Reference Example

A fully completed, gold-standard reference example illustrating this artifact in practice is available:

📖 Completed Example: 05_10_Impediment_Log_Example.md

LLM Generation Prompt & Agent Instructions

Impediment Log - LLM Generation Prompt

SYSTEM INSTRUCTIONS: This document is the detailed instruction set for generating the Impediment Log. When asked to populate the template, follow the guidance for each section below to produce the requested content. Refer to parameters.md for the general project variables.

Context and Definition: The record of the things standing between a team and the work it has taken on, kept so that they are raised rather than worked around. An impediment is not an issue: an issue is something wrong inside the team's own work, which the team fixes by working differently, while an impediment is something the team cannot remove by itself. That distinction is what the log records, and it is why every entry has an owner, because the person raising an impediment is rarely the person who can clear it.

Alignment & Dependencies: * Pre-requisites (Inputs): * Mandatory: Project Management Plan (PMO-04.01.01), Approved Baselines (Scope/Schedule/Cost) * Optional: Risk Register (PMO-04.08.02), Stakeholder Engagement Plan (PMO-04.10.01) * Downstream Dependents: * Mandatory: Project Status Reports (PMO-06.01), Change Log (PMO-05.04), Lessons Learned Summary (PMO-07.01) * Optional: Variance Analysis (PMO-06.04), Decision Log (PMO-05.02)

Impediment Log

Impediment ID

Instructions: A short identifier, so an impediment can be referred to in a stand-up without being described again. A number is enough if it is the only one in use.