Project Issue Log

A project issue log is a simple but essential tool for keeping a project's problems from slipping through the cracks. As a project runs, things go wrong or come up unresolved — a blocked task, a missing decision, a conflict between teams, a defect, an unclear requirement. An issue log captures each of these as an entry with the details that make it actionable: a description of the problem, the date it was raised, who raised it, an assigned owner responsible for resolving it, a priority, a status, and eventually the resolution and the date it closed. The log is a living document, updated as issues are added, worked, and closed, and reviewed regularly so nothing festers unseen. Its whole purpose is to make sure every problem is visible, owned, and driven to a conclusion rather than forgotten in a hallway conversation.

The value of an issue log is discipline. Without one, problems on a project get raised in meetings and emails and then evaporate, resurfacing later as crises that everyone assumed someone else was handling. With one, every issue has a name attached, a priority that decides what gets attention first, and a status that says whether it is open, in progress, or resolved. That turns a scattered set of worries into a managed list that a project manager can work through and report on. The log also creates a record: a history of what went wrong, how it was resolved, and how long it took, which is useful both for keeping the current project honest and for learning on the next one. It is low-tech and unglamorous, and it is one of the most reliable ways to keep a project from being sunk by its own loose ends.

An issue log is often confused with a risk register, but they track different things. An issue is a problem that has already happened or is happening now — it exists, and it needs resolving. A risk is a potential problem that has not yet occurred — it might happen, and it needs monitoring and, ideally, preventing. The risk register lists what could go wrong and the plans to avoid or soften it; the issue log lists what has gone wrong and who is fixing it. The two connect: a risk that materializes becomes an issue, moving from the register to the log. Keeping them separate matters, because managing possibilities and managing live problems call for different responses — one is watchful, the other is corrective.

An issue log also differs from a change log, though both track things that arise during a project. A change log records requested or approved changes to the project's scope, plan, or requirements — deliberate alterations to what the project will deliver. An issue log records problems that need solving, which may or may not lead to a change. Sometimes resolving an issue requires a formal change (so the issue spawns a change-log entry), and sometimes it is fixed within the existing plan. The distinction keeps the records clean: the change log answers what the project agreed to alter, the issue log answers what problems arose and how they were handled. Reading all three together — risks, issues, changes — gives a full picture of how a project is being steered through both its hazards and its surprises.

Keeping an issue log well means capturing issues promptly, assigning each a clear owner, and reviewing the log often enough that nothing stalls. Every entry should name a single accountable owner, because an issue owned by everyone is owned by no one; it should carry a priority, so scarce attention goes to what matters most; and it should have a status that is honestly maintained, so the log reflects reality rather than wishful thinking. Regular review — in a standing project meeting, for instance — keeps open issues moving and closes resolved ones cleanly. The log works best when it is lightweight enough that people actually use it and disciplined enough that entries are complete, because a log people ignore or fill in vaguely is worse than useless, lending false comfort that problems are handled when they are not.

The failures are familiar to anyone who has run a project. Letting issues be raised verbally and never logged means they vanish until they explode. Logging issues without assigning owners leaves them drifting, acknowledged but unworked. Neglecting priority buries the critical issue under a pile of trivial ones. Never reviewing the log lets it go stale, its statuses fiction. And confusing issues with risks or changes muddles the records so none of them can be trusted. The discipline is to log every real issue at once, give it an owner and a priority, keep its status honest, review the log regularly, and route it correctly relative to the risk register and change log, so the project's problems stay visible and driven to resolution instead of quietly accumulating.

A project issue log — a running, owned, prioritized record of problems tracked to resolution — keeps a project's loose ends visible and driven to closure, distinct from the risk register and the change log.

Etymology: source.

Search interest for this term over the last five years:

View interest-over-time on Google Trends →

Areas of marketing where project issue log is a core concern: