---
title: "Issue Log Template"
methodology: "traditional"
complexity: "advanced"
owner: "mirichard"
updated: "2025-08-05"
primary_principles: ["risk-optimization", "stewardship"]
secondary_principles: ["evidence-based-decisions"]
principle_rationale: "Assigns actual delivery problems a severity, owner, response and escalation path with evidence of resolution."
---

# PROJECT ISSUE LOG

## When to Use

- During delivery when an actual problem needs an owner, action, and resolution decision.
- When severity, workarounds, and escalation must be visible between reviews.

## When NOT to Use

- For uncertain future events that have not occurred; use the risk register.
- Do not use a completed template or example configuration as proof of fitness for the actual environment. See [Template as substitute for judgment](../../../../../../docs/principles/anti-patterns.md#template-judgment).

## Pairs Well With

- [Risk Register Template](../../../../../../domains/uncertainty/project-lifecycle/02-planning/risk-management/risk-register-template.md).
- [Raid Log Template](../../../../../../domains/delivery/templates/traditional/Traditional/Templates/raid_log_template.md).

Selection context: Delivery domain; traditional methodology; advanced complexity. Match the situations above to project phase, risk, team size, and industry using the [decision-engine context model](../../../../../../meta/architecture-research/800-801-context-assessment-model.md).

## Document Control Information
**Project/Program Name:** *[Enterprise Resource Planning Implementation]*  
**Document Version:** *1.0*  
**Prepared By:** *[Jane Smith, Project Management Professional]*  
**Preparation Date:** *[YYYY-MM-DD]*  
**Last Updated By:** *[Jane Smith, Project Management Professional]*  
**Last Revision Date:** *[YYYY-MM-DD]*  

---

## Document Purpose
*This Issue Log documents and tracks all identified issues for the [Project Name]. It serves as the central repository for capturing problems, defects, or concerns that have already materialized and require resolution. Unlike risks (which may or may not occur), issues are current problems that need to be addressed to maintain project progress and success.*

---

## Table of Contents
1. [Issue Management Approach](#1-issue-management-approach)
2. [Issue Identification and Categorization](#2-issue-identification-and-categorization)
3. [Priority and Severity Assessment](#3-priority-and-severity-assessment)
4. [Impact Analysis](#4-impact-analysis)
5. [Resolution Planning and Tracking](#5-resolution-planning-and-tracking)
6. [Escalation Procedures](#6-escalation-procedures)
7. [Issue Log](#7-issue-log)
8. [Issue History Log](#7-issue-log)
9. [Approval](#3-priority-and-severity-assessment)

---

## 1. Issue Management Approach

### 1.1 Issue Management Process Overview
*Briefly describe the issue management approach for the project, including how issues will be identified, logged, analyzed, resolved, and closed.*

*Example: This project follows a structured issue management process to ensure all problems are identified, documented, and resolved in a timely manner. Issues may be identified by any project stakeholder and should be reported to the project manager or designated issue coordinator. All issues will be logged, assessed for priority and impact, assigned to an owner for resolution, tracked until closure, and reviewed for lessons learned. Status updates on active issues will be provided in weekly status meetings, with high-priority issues escalated according to the defined procedures.*

### 1.2 Roles and Responsibilities

*Define who is responsible for various issue management activities.*

*Example:*

| Role | Responsibilities |
|------|------------------|
| Project Manager | Overall accountability for issue management, issue prioritization, escalation decisions, status reporting to stakeholders |
| Issue Coordinator | Maintaining the Issue Log, following up with issue owners, preparing issue status reports |
| Issue Owner | Developing and implementing resolution plans, providing regular status updates, coordinating with other team members as needed |
| Project Team Member | Identifying and reporting issues, supporting issue resolution when assigned |
| Subject Matter Expert | Providing expertise for issue analysis and resolution |
| Steering Committee | Making decisions on escalated issues, approving additional resources for resolution |

### 1.3 Issue Management Workflow

*Outline the workflow for managing issues from identification to closure.*

*Example:*

1. **Issue Identification**
   - Issue identified by stakeholder
   - Initial information gathered

2. **Issue Logging**
   - Issue entered in Issue Log with unique ID
   - Initial categorization and description

3. **Issue Assessment**
   - Priority and severity determined
   - Impact analysis performed

4. **Resolution Planning**
   - Issue assigned to owner
   - Resolution approach determined
   - Resources identified

5. **Resolution Implementation**
   - Resolution actions executed
   - Progress updates provided

6. **Verification**
   - Resolution effectiveness verified
   - Stakeholder approval obtained

7. **Closure**
   - Issue formally closed
   - Lessons learned documented

8. **Monitoring**
   - Closed issues monitored to prevent recurrence
   - Trends analyzed for systemic improvements

---

## 2. Issue Identification and Categorization

### 2.1 Issue Categories

*Define the categories used to organize issues.*

*Example:*

| Issue Category | Description | Examples |
|----------------|-------------|----------|
| Technical | Issues related to technology, software, hardware, infrastructure | System errors, performance problems, compatibility issues |
| Process | Issues related to business processes, workflows, procedures | Inefficient workflows, process gaps, procedural problems |
| Resource | Issues related to human resources, skills, staffing | Resource shortages, skill gaps, availability conflicts |
| Scope | Issues related to project scope, requirements, deliverables | Scope gaps, unclear requirements, scope disagreements |
| Quality | Issues related to quality standards, defects, testing | Failed test cases, quality standards not met, defects |
| Vendor/Supplier | Issues related to vendors, suppliers, third parties | Delivery delays, quality concerns, contract issues |
| Documentation | Issues related to project documentation, artifacts | Inaccurate documentation, missing information |
| Communication | Issues related to communication, information sharing | Miscommunication, information not received, unclear messaging |
| Organizational | Issues related to organizational structure, politics, decisions | Decision delays, organizational conflicts |

### 2.2 Issue ID Format

*Define the format for issue identification numbers.*

*Example: Issue IDs follow the format ISS-[Category Code]-[Sequential Number]:*
* *ISS-T-001: First technical issue*
* *ISS-P-001: First process issue*
* *ISS-R-001: First resource issue*
* *ISS-S-001: First scope issue*
* *ISS-Q-001: First quality issue*
* *ISS-V-001: First vendor/supplier issue*
* *ISS-D-001: First documentation issue*
* *ISS-C-001: First communication issue*
* *ISS-O-001: First organizational issue*

### 2.3 Issue Sources

*Identify potential sources of issues to help with proactive identification.*

*Example:*

* Team member observations
* Status meetings
* Quality reviews
* Testing activities
* Stakeholder feedback
* Vendor deliverable reviews
* Process execution
* Materialized risks
* External events
* Audit findings

---

## 3. Priority and Severity Assessment

### 3.1 Priority Levels

*Define the priority levels for issues based on urgency and need for resolution.*

*Example:*

| Priority Level | Description | Response Time | Example |
|----------------|-------------|---------------|---------|
| **Critical** | Immediate action required; project is blocked or significant objectives threatened | Same day response; continuous work until resolved or mitigated | Production system down preventing all work |
| **High** | Urgent issue requiring prompt attention; significant impact on project component | Response within 24 hours; resolution efforts prioritized | Critical path activity blocked, major deliverable at risk |
| **Medium** | Important issue requiring scheduled resolution; moderate impact on project component | Response within 2-3 days; resolution according to planned schedule | Non-critical path activity impacted, manageable workaround exists |
| **Low** | Issue requires resolution but is not time-sensitive; minimal impact on project | Response within 1 week; resolution as resources permit | Minor inconvenience, cosmetic issues, documentation error |

### 3.2 Severity Levels

*Define the severity levels for issues based on impact to the project.*

*Example:*

| Severity Level | Description | Impact |
|----------------|-------------|--------|
| **Showstopper** | Catastrophic impact; prevents essential functions from being performed | Prevents project continuation, critical business functions cannot be executed |
| **Major** | Significant impact; severely restricts functionality | Major project components or deliverables affected, limited workaround available |
| **Moderate** | Noticeable impact; some functions affected but overall functionality maintained | Specific project activities affected, workarounds available but not optimal |
| **Minor** | Minimal impact; minor inconvenience but no functional restriction | Limited effect on project activities, easy workaround available |

### 3.3 Priority-Severity Matrix

*Provide a visual representation of the relationship between priority and severity.*

*Example:*

| Priority/Severity | Showstopper | Major | Moderate | Minor |
|-------------------|-------------|-------|----------|-------|
| **Critical** | Critical-1 | Critical-1 | Critical-2 | High-1 |
| **High** | Critical-1 | High-1 | High-2 | Medium-1 |
| **Medium** | High-1 | High-2 | Medium-1 | Low-1 |
| **Low** | High-2 | Medium-1 | Low-1 | Low-2 |

*Legend:*
* *Critical-1: Highest urgency, immediate executive notification, all-hands resolution*
* *Critical-2: Immediate resolution team, daily executive updates*
* *High-1: Dedicated resources, reported to steering committee*
* *High-2: Scheduled resolution team, reported in status reports*
* *Medium-1: Planned resolution, weekly tracking*
* *Low-1: Resolution during normal activities*
* *Low-2: Resolution when resources available*

---

## 4. Impact Analysis

### 4.1 Impact Areas

*Define the areas to consider when analyzing the impact of issues.*

*Example:*

| Impact Area | Description | Assessment Considerations |
|-------------|-------------|----------------------------|
| Schedule | Impact on project timeline and milestones | Schedule delay (days/weeks), critical path affected, milestone jeopardy |
| Budget | Financial impact on project | Additional cost ($), percentage of budget impact |
| Scope | Impact on project scope and deliverables | Features/functions affected, quality compromised, requirements not met |
| Resources | Impact on human and material resources | Additional resource needs, reassignment requirements |
| Quality | Impact on product/service quality | Quality metrics affected, standards compromised |
| Risk | New risks introduced or existing risks elevated | Additional risk exposure, risk rating changes |
| Stakeholders | Impact on stakeholder satisfaction | Stakeholder groups affected, level of concern |
| Benefits | Impact on project benefits and business case | ROI affected, benefit delivery delayed or reduced |

### 4.2 Impact Assessment Process

*Describe the process for analyzing the impact of issues.*

*Example:*

1. **Initial Screening**
   - Quick assessment of immediate impact
   - Determination if emergency response needed

2. **Comprehensive Analysis**
   - Detailed evaluation across all impact areas
   - Consultation with relevant subject matter experts
   - Documentation of specific impacts

3. **Stakeholder Impact Assessment**
   - Identification of affected stakeholders
   - Assessment of stakeholder concerns

4. **Cumulative Impact Assessment**
   - Evaluation of combined impact with other active issues
   - Assessment of impact on overall project health

5. **Impact Documentation**
   - Clear documentation in Issue Log
   - Communication to relevant stakeholders

---

## 5. Resolution Planning and Tracking

### 5.1 Resolution Approach Options

*Outline different approaches to issue resolution.*

*Example:*

| Approach | Description | When to Use |
|----------|-------------|-------------|
| **Fix** | Directly solve the issue by addressing root cause | When root cause is clear and fixable within project constraints |
| **Workaround** | Implement alternative solution that mitigates impact without addressing root cause | When immediate resolution needed or root cause cannot be addressed |
| **Defer** | Postpone resolution to a later phase or project | For low-priority issues that don't threaten project objectives |
| **Accept** | Acknowledge the issue without resolution action | When resolution cost exceeds benefit or impact is minimal |
| **Transfer** | Shift responsibility for resolution to another party | When issue best addressed by external party (vendor, other department) |

### 5.2 Resolution Plan Components

*Define what should be included in an issue resolution plan.*

*Example: Issue resolution plans should include:*

* Specific actions to be taken
* Resources required
* Timeline for implementation
* Dependencies and prerequisites
* Potential risks of the resolution approach
* Success criteria for resolution verification
* Stakeholder communication needs
* Follow-up actions to prevent recurrence

### 5.3 Resolution Progress Tracking

*Define how progress toward issue resolution will be tracked and reported.*

*Example:*

| Progress Status | Description |
|-----------------|-------------|
| **Not Started** | Resolution planning may be complete but implementation not begun |
| **In Progress** | Resolution actions underway, with percentage complete indicator |
| **Blocked** | Resolution implementation halted due to dependencies or obstacles |
| **Verification** | Resolution implemented, effectiveness being verified |
| **Resolved** | Resolution complete and verified effective, pending closure approval |
| **Closed** | Issue formally closed, lessons learned documented |
| **Reopened** | Previously closed issue that has recurred |

---

## 6. Escalation Procedures

### 6.1 Escalation Triggers

*Define the conditions that trigger issue escalation.*

*Example:*

* Issue with Critical priority not responded to within 4 hours
* High priority issue not resolved within agreed timeframe
* Issue resolution repeatedly blocked or delayed
* Issue impact assessment reveals critical business impact
* Resource conflicts preventing issue resolution
* Stakeholder disagreement on issue priority or resolution approach
* Issue resolution requires authority beyond assigned owner
* Multiple related issues indicating systemic problem

### 6.2 Escalation Levels

*Define the hierarchy for issue escalation.*

*Example:*

| Level | Escalated To | Timeframe | Communication Method |
|-------|--------------|-----------|----------------------|
| 1 | Project Manager | Immediate | Direct contact (phone/in-person) |
| 2 | Project Sponsor/Functional Manager | Within 4 hours | Email + phone call |
| 3 | Steering Committee | Within 24 hours | Formal memo + emergency meeting |
| 4 | Executive Leadership | Within 48 hours | Executive briefing |

### 6.3 Escalation Information Requirements

*Define the information needed when escalating an issue.*

*Example: Issue escalation should include:*

* Issue ID and description
* Current priority and severity
* Complete impact assessment
* Resolution efforts attempted
* Reason for escalation
* Recommended action
* Decision needed
* Timeframe for decision
* Consequences of delayed decision

---

## 7. Issue Log

*The main issue log table containing all identified issues and their assessment, resolution planning, and status information.*

| Issue ID | Issue Description | Category | Identified By | Identification Date | Priority | Severity | Impact Summary | Resolution Approach | Owner | Status | Target Resolution Date | Actual Resolution Date | Comments |
|----------|------------------|----------|---------------|---------------------|----------|----------|----------------|---------------------|-------|--------|------------------------|------------------------|----------|
| *ISS-T-001* | *System integration with finance module fails when processing transactions over $10,000* | *Technical* | *John Smith* | *YYYY-MM-DD* | *High* | *Major* | *Financial reporting delayed, manual workaround required* | *Fix: Modify code to handle large transactions* | *Jane Doe* | *In Progress (75%)* | *YYYY-MM-DD* | | *Root cause identified as buffer size limitation. Code fix in development.* |
| *ISS-R-001* | *Lead developer resigned unexpectedly* | *Resource* | *HR Department* | *YYYY-MM-DD* | *Critical* | *Major* | *Technical development delayed, knowledge transfer incomplete* | *Mitigate: Promote senior developer, hire contractor* | *Mike Johnson* | *In Progress (50%)* | *YYYY-MM-DD* | | *Senior developer assuming lead role, contractor interviews scheduled.* |
| *ISS-V-001* | *Vendor delivered training materials with significant quality issues* | *Vendor* | *Training Team* | *YYYY-MM-DD* | *Medium* | *Moderate* | *Training preparation delayed, materials require rework* | *Transfer: Return to vendor for correction with expedited timeline* | *Sarah Williams* | *Resolved* | *YYYY-MM-DD* | *YYYY-MM-DD* | *Vendor redelivered corrected materials, verified by training team.* |
| *ISS-S-001* | *Reporting requirements were underestimated in initial scope* | *Scope* | *Business Analyst* | *YYYY-MM-DD* | *High* | *Moderate* | *Additional development effort required, potential delay to reporting module* | *Fix: Add required reports, adjust schedule and resources* | *Robert Brown* | *In Progress (30%)* | *YYYY-MM-DD* | | *Impact assessment complete, change request in process for additional resources.* |
| *ISS-C-001* | *Change Management team not receiving timely information about system changes* | *Communication* | *Change Manager* | *YYYY-MM-DD