We all like to think that our projects will go well. However, you can do all the planning in the world and you’ll still hit issues from time to time. Things never seem to turn out exactly as the plan predicts!

That’s because projects inherently have a lot of uncertainty. They are affected by things that happen outside of the project that you have no control over. They are affected by how the people on the team behave. There are a lot of factors that influence how projects turn out.

With that in mind, it’s sensible to prepare for what might happen. You do this through your risk log. When something does happen that affects your project’s ability to progress as planned, that’s an issue. Issues can be risks that you thought might happen and then actually do, or something that hits your project from the left field and that never appeared on the risk log.

Either way, they are still issues, and the most important thing about issues is that you have to do something about them. Otherwise these problems can grow and grow.

Your issue log is where you record the problems that have happened on the project. Your issue log can be a simple spreadsheet or built in to your project management software. You may have a template from a previous project or your PMO. It really doesn’t matter how you record the issues in the log, as long as you have a log.

However, it does matter what goes into the issue log. Here are three things that definitely need to be included for each entry in your issue log.

1. Issue Description

This might seem obvious, but too many project managers give the issue a title but don’t write down what that actually means. Or perhaps your colleague enters the issue and gives it a title – and you don’t have a clue what they are referring to.

You can save trouble by including a description. This should include:

  • What happened
  • What cause the issue to happen (if you already know the root cause)
  • What impact this has on your project (budget, schedule, resources etc)
  • Your initial assessment of how big the impact is.

You should write a few sentences that describe the situation. You might not know the impact at the time that you are entering the details in the issue log. You can do a full analysis and work out the exact issues in due course, but if you don’t have those details to hand, include your gut feel for what kind of problem this presents for the project. Is it a big issue? Or something you can handle with ease? Do you have the right skills in the team already to put it right? Or will you need expert input from other people? Do you know it’s going to cost a lot to fix? Or can you resolve the issue within the budget you already have? That’s the kind of thing that you should be recording on the issue log.

The reason for all this detail is that the more you know about the issue, the easier it is to work out who should take responsibility for fixing it.

2. An Issue Owner

That leads us on to who is going to be the single point of contact for managing this issue.

Record their name on the issue log (not just their role – you want the issue owner to be a named individual).

Tip: The issue owner should be someone who has the resources available (i.e. the team members) to fix the problem. In most situations, this will be a workstream lead or subject matter expert, not the project manager. Don’t put your own name as project manager against all the issues or you’ll spend all day chasing other people for updates. Issue resolution should be something you can delegate quite easily. You may want to ‘keep’ a few issues for yourself, for example those that involve organizational politics or negotiating with other projects. If you think it’s prudent to take on responsibility as the issue owner do, but don’t worry about delegating out all the issues you can to other members of the team.

3. Issue Action Plan

Finally, the third thing to include is what you are going to do about the issue. This is the action plan. It describes what is going to be done to address the problem.

Each issue action plan will be fully dependent on the issue itself. You are going to need a bespoke plan to address each issue, so I can’t give you a summary or step-by-step guide here. You need to assess the issue and work out how best to deal with it. And you have to do that on a case-by-case basis.

The action plan sets out what is going to be done to resolve the issue. You may not have space in your issue log to record everything that’s being done (dependent on what that is). If it makes more sense, simply add a reference to where people can find more information about the action plan. For example, if you have added the tasks to the main project schedule, note that down.

In my experience, you can record a few sentences about what is being done, and that’s adequate for the issue log. As the project manager, all you want to know is that something is being done about it, and who to ask for updates. As long as you have confidence that your team are doing the work, that’s good enough.

Tip: Sometimes doing nothing is an appropriate course of action. In that case, you will not have an action plan. Record the fact that the issue has been assessed and that you have taken the decision (with the Project Board if necessary) to do nothing on this occasion.

Your issue log template might include a lot of other fields, and that’s fine. Fill in what you feel you need to record about each issue. If you are creating an issue log from scratch, then these are the three fields that I think are the most important.