What is a Issue Log Template?
An Issue Log Template provides a structured register for capturing, tracking and resolving problems that arise during a project or process operation. It ensures every issue has an owner, a resolution plan and a target date — preventing issues from being forgotten or unresolved.
When to use a Issue Log Template
Use it throughout the project lifecycle from kick-off to closure, and hand it over to the process owner as part of the Control phase deliverables. An ongoing issue log is also valuable as a permanent operational tool for managing process exceptions.
Who should use a Issue Log Template
- Black Belts and project leads — tracking and managing all open project issues to closure
- Process owners and team leaders — managing day-to-day process issues and exceptions as an operational tool
- Sponsors and steering groups — reviewing open issues that require escalated decisions or resources
- All project team members — logging issues as they are identified so nothing is lost
How to use a Issue Log — step by step
- 1Log the issue immediately
As soon as a problem is identified, capture it in the log with a description, date and who identified it. Don't wait for a meeting.
- 2Classify the issue
Categorise by type (technical, resource, process, people, external) and assign an initial severity (high/medium/low).
- 3Assign an owner
Every issue must have one named person responsible for its resolution. Without an owner it will not be resolved.
- 4Define the resolution plan
Describe the specific actions that will be taken to resolve the issue, with target dates for each.
- 5Set a target resolution date
Agree a realistic deadline for full resolution. Review and update it if circumstances change.
- 6Track status through to closure
Update the status regularly: Open → In Progress → Resolved → Closed. Closed requires confirmation the issue is fixed.
- 7Review at every project meeting
Open issues should be the first agenda item at every project team meeting until they are closed.
Worked example — DMAIC Project Issue Tracking
A Green Belt maintained a 12-item issue log throughout a 4-month project — including a data access delay that threatened the Measure phase timeline, resolved in 5 days by escalating to the IT sponsor contact named in the project charter.
Common mistakes — and how to avoid them
Logging issues but not resolving them. An issue log that grows but never shrinks is a failure log. Every issue needs active resolution — not just documentation.
No single owner per issue. Shared ownership means no real ownership. One named person is responsible for each issue, even if others support the resolution.
Severity ratings that never change. If a low-severity issue persists unresolved for weeks, it should be re-rated. Issues that linger often grow in impact.
Closing issues without verification. An issue is only closed when it has been confirmed fixed — not when the planned action has been completed. Those are different things.
Tips for getting better results
Keep it visible. An issue log that lives in a drawer or buried in a shared drive is not being used. Post it on the team board or share it in the team's daily communication channel.
Set a 'red flag' age threshold. Any issue open for more than N days without progress automatically triggers a review. Define N for your context and enforce it.
Link issues to risks. Unresolved issues often become risks. Maintain a connection between your issue log and your risk register so nothing falls between the cracks.
Frequently asked questions
Issue vs risk?
A risk might happen. An issue has already happened and is affecting the project.
Who can raise an issue?
Anyone on the project team or any stakeholder. The project lead logs and tracks it to resolution.
How quickly should issues be actioned?
Classify by severity. Critical issues affecting delivery should be escalated within 24 hours.
When can an issue be closed?
When the resolution has been implemented and confirmed effective.