Issue Log

An issue log is a delivery artifact that tracks problems that have already materialized on an engagement, recording each issue’s description, severity, owner, resolution plan, and target close date. Where a risk register is forward-looking, an issue log is the present-tense operational tool.

What an issue entry must include

A minimal issue entry contains:

• ID: a unique reference for tracking in status reports and client communications
• Description: a concrete, specific statement of the problem
• Date raised: when it was first identified
• Raised by: the person or team who surfaced it
• Severity: critical, high, or medium
• Owner: the named individual driving resolution
• Resolution plan: the specific steps being taken to close it
• Target close date: a real commitment, not a placeholder
• Status: open, in progress, escalated, or closed

Vague descriptions (“client unhappy with progress”) are not entries. Each item must identify a specific, actionable problem with a named owner.

The relationship to the RAID log

An issue log can exist as a standalone artifact or as the “I” column of a RAID log. In small engagements, combining all four categories into a RAID log is efficient. In large programs with multiple workstreams, a dedicated issue log reviewed daily by the delivery lead is more practical. The choice is determined by program complexity and the frequency at which issues need active management attention.

Severity discipline

The most common failure in issue log maintenance is treating every item as high priority. When everything is high, the log loses its signal. Reserve “critical” for genuine delivery blockers: the client environment is unavailable, a key decision is outstanding and a workstream cannot proceed, or a third-party dependency has failed. Use “high” for items that will block delivery within the current week if unresolved. Use “medium” for problems that affect quality or the client relationship but do not stop active work.

Consistent severity discipline is what makes the issue log a useful management tool rather than an administrative burden.

Escalation triggers

Any issue that has been open for more than one review cycle without forward movement should be escalated to the steering committee. The issue log should carry an “escalated” status for items that have moved beyond the delivery team’s authority to resolve. The engagement manager owns the escalation decision, even when individual issue owners are other team members.

A well-maintained issue log also drives the issues section of the weekly status report, ensuring that open items visible to management are the same items the delivery team is actively tracking.