Issue Log Template: How to Write One, and Operating Rules That Keep It Alive

Most project delays are not caused by unforeseen accidents. They are caused by issues everyone had noticed but nobody moved on. An issue log is the minimum mechanism for preventing that. This article covers the column structure you can use as-is, the rules for writing entries, how to set priority, and — the hardest part — how to build operating rules that keep the log from being abandoned.

What an issue log is, and how it differs from tasks and risks

An issue log is a table that lists the issues arising during a project and tracks each one through to resolution, tying it to an owner, a due date and a status. Three things are easily confused, so it is worth separating them up front.

• Task: work whose content is already decided. Managed in a WBS or a Gantt chart.
• Issue: something that has already happened, and for which the answer or decision is not yet settled.
• Risk: something that has not happened yet but would affect the project if it did.

The dividing line is whether the answer is already decided. "Produce the artwork files" is a task; "we cannot produce the artwork files because nobody knows who to ask about image rights" is an issue. Mix the two into one table and the issues disappear under the sheer volume of tasks. Making it a rule that a risk moves into the issue log once it materialises also keeps the relationship between the two tables clear.

Issue log column structure

Twelve columns are the minimum, and also close to the maximum. The more fields you add, the less often the log gets updated, so we recommend not going beyond this.

• ID — a sequential number, so people can say "the issue 12 thing" in a meeting or chat.
• Raised date — used to detect neglect. Without it you lose track of how long an issue has been sitting there.
• Raised by — makes it clear who to ask for detail.
• Category — spec, schedule, staffing and resources, cost, external factors. Five is enough.
• Issue — written according to the rules below.
• Impact — what stops if this is not resolved. This column is the basis for priority.
• Priority — high, medium, low.
• Approach — the current thinking on how to handle it. Write "undecided" if it is undecided.
• Owner — one person.
• Due date — the deadline for the next action.
• Status — Not started / In progress / Awaiting confirmation / Done / On hold.
• Closed date and outcome — one line on how it was settled.

The column most often dropped is impact, and an issue log without it will almost certainly become a formality. Priority turns subjective, and everything ends up marked high.

Four rules for writing entries

1. Write the issue as a decision to be made

A bad entry reads "about the homepage design". A good one reads "decide whether the homepage hero goes with option A or option B". Write to a level of detail where one line tells the reader what to do next. Any issue phrased as "about X" will almost certainly be left alone.

2. Always write the impact

Write it in terms of the work that stops and the days involved: "until this is decided we cannot start implementation, and launch slips by three working days". When this is concrete, priority discussions stop being a contest of opinions, and the same line doubles as escalation material.

3. Assign exactly one owner

"Everyone involved" or "the production team" is the same as nobody. Even when the decision itself sits with another department, name one person on your own team responsible for extracting an answer from them. What goes in the owner column is not the person who resolves the issue but the person accountable for moving it.

4. Set the due date for the next action, not for resolution

The less visibility you have on an issue, the less possible it is to set a resolution date — which is exactly why the field ends up blank and the issue gets forgotten. Enter the deadline for the next move instead: "send the question to legal by the 8th". That way even unresolved issues always carry a date, and slippage can be detected mechanically.

How to set priority

Priority is decided on two axes, impact and urgency. If you want a single test, it is whether the issue stops work on the critical path.

• High: work is already stopped, or a date will move.
• Medium: there is a workaround for now, but work stops unless it is resolved by a specific date.
• Low: the project can proceed without resolving it.

As a running check: once more than thirty percent of open issues are marked high, priority has stopped functioning. Either tighten the criteria, or suspect that the issues themselves have not been separated properly.

Building operating rules that keep it alive

Almost every failure of an issue log comes down to one thing: it was created and then never updated. The operating rules matter more than the format of the table.

1. Decide where it gets reviewed, first

Fix the first ten minutes of the weekly meeting as issue review, and put that slot in the calendar on the same day you create the log. "Whoever notices updates it" is not an operating rule.

2. Make overdue and stalled rows stand out automatically

Use conditional formatting to turn unresolved rows past their due date red. The formulas below assume the raised date is in column B, the due date in column J and the status in column K.

=AND($J2<>"", $J2<TODAY(), $K2<>"Done")

To catch rows that have not moved in more than thirty days since being raised, add the following as a separate rule.

=AND($B2<>"", TODAY()-$B2>30, $K2<>"Done")

3. Never allow "on hold" without a review date

The most dangerous status is "on hold". It is the classic parking space where a deferred decision quietly gets forgotten. Make it mandatory to enter a review date in the due date column whenever something goes on hold. An on-hold issue with an empty date is, in practice, an issue that has disappeared.

4. Define what closing means

Close on "the impact is gone", not on "we did something about it". Believing an issue is handled while its impact persists is exactly how the same problem comes back under a different name. Leaving one line for the closed date and outcome lets you trace the history if it does recur.

5. Agree the escalation trigger in advance

Set a rule at the start, along the lines of "any high-priority issue more than a week past its due date goes to the decision maker at the next meeting". Without a trigger, whether to escalate becomes a question of an individual's willingness to raise their hand, and it will always be late.

Three common failure modes

Too many issues, so nobody reads it

Without a bar for raising issues, passing worries end up on the list too. Setting the bar at "something the owner cannot move forward on their own judgement alone" brings the volume back to a sensible level.

Only the status gets updated

A row that has said "in progress" for two months is, in practice, not started. Status is not evidence of progress. Manage by due date and raised date instead.

It is only ever updated in meetings

Cancel one weekly meeting and the log sits still for a fortnight. Keep it on a shared drive with edit access for everyone, so anyone can raise an issue the moment they notice it.

Where spreadsheet management runs out

An issue log works perfectly well in a spreadsheet for a single project. Management costs climb sharply, though, once any of the following is true.

• Campaigns run in parallel and issues are scattered across separate files
• There is no way to trace afterwards how an issue affected the schedule or the budget
• Past issues and their resolutions are buried in a sea of files, so the same debate keeps repeating

Xtrategy keeps issues in the same place as campaign schedules, budget and KPIs, so you can trace after the fact what caused a plan to drift. For managing work at the campaign level, see also the marketing campaign management template.

Summary

• Separate issues from tasks and risks. The line is whether the answer is already decided.
• The five columns that carry the log are impact, priority, a single owner, due date and status.
• Set the due date for the next action, not for resolution.
• Let conditional formatting surface overdue and stalled rows automatically.
• Never allow "on hold" without a review date. An on-hold issue with no date is a lost issue.