However much you plan your project, engage your stakeholders or mitigate your risks, things will never turn out exactly how you planned. Projects have too many uncertainties and are affected by too many external and internal forces to go exactly to plan. As Helmuth von Moltke the Elder said, ‘No plan survives contact with the enemy’.
When something that you haven’t planned for does happen, that’s an issue. Project managers keep an issues log that is used to record all the problems, incidents and disasters on the project and what they are going to do about them.
Your Project Management Office may have a template that you can use, or your online project management software may also have the feature to record and manage risks and issues. Don’t reinvent the wheel – use whatever template or tool you have available. Whatever system you use, here are 3 critical things that should definitely be included on your issues log.
#1. A Description of the Issue
Of course! You need a full description of the issue. This should include what has happened and what caused it to happen (if you know). Describe the problem in a few sentences and make a note of any risk it relates to – issues are often caused by risks that suddenly materialize, although they don’t have to be.
Your description should also cover the impact on the project. Does this cause a big problem for the team, or is it something that can be managed quite easily? Will it create a delay, or result in a milestone being missed? Will it cost a lot of money to put right?
Understanding the impact on the project will help you decide who is the best person to manage it and what is required to do something about it.
However, you don’t want to be describing the problem using a paragraph each time you mention it in conversation, so it is a good idea to have a short description of just a few words as well. This can become shorthand for the long issue description and helps everyone realize what you are talking about. Creating a common language can also create common understanding, so in day-to-day conversation, use the short description.
For status updates, even the short description can be too much, so give all the issues a tracking number as well. The format ‘I-001’ works well, and you can use the same numbering system for risks (‘R-001’ etc) and changes (‘C-001’ etc). Then, when you are writing reports or referring to issues on status updates you can just use the number. Team members can refer to the log for the full description.
#2. An Owner for the Issue
Who is going to be responsible for managing this problem? This is the issue owner, and this should also be noted down on the issue log. Online project management software often has the option of assigning the management of an issue to a project team member, so you can automatically allocate it to the right person to pick up the problem and work on the resolution.
Don’t be tempted to take on all the management of issues yourself. While you may well have the knowledge and skills to be able to carry out the tasks required to resolve the problem, your role as project manager is to oversee the whole project.
You may decide to keep the management of very significant issues for yourself so that you have the confidence that they are being dealt with in a timely fashion and so that you can report regularly to your stakeholders. You could also decide to keep yourself as the owner for the most difficult ones, as this can shelter the project team members from some of the organizational politics or challenging discussions. But generally, look at delegating the management of issues to your team members.
This can also be a great opportunity to build responsibility in team members and help them develop professionally. You can always support a more junior member of the team, or ask their mentor, a more experienced project team member or their line manager to help out as well.
#3. An Action Plan
The third critical feature of an issues log is the action plan: what you are going to do about the problem. It is fine to have identified the issue and who is going to take responsibility for dealing with it, but what are they actually going to do?
The action plan should cover the tasks required to resolve the problem. This could take a bit of brainstorming if the path for resolving the issue isn’t clear. You may have to have a separate meeting about how to tackle the issue, so you may not be able to log all the actions at the time that you are making the entry on the issues log.
That’s OK: just write down that the first step is to do some detailed analysis and planning and that a full action plan will be added to the log later.
The issue owner doesn’t have to be the only person who has tasks allocated to them on the action plan. Sometimes it is not appropriate for them to do all the tasks – and sometimes they can’t.
Like the rest of the project, issue management is a collective effort. If the issue owner is not going to carry out all these tasks themselves then the action plan should also note who is going to do them. You can then allocate these tasks to the relevant project team members. The issue owner is responsible for making sure that the action plan gets done.
Don’t forget that sometimes doing nothing is an acceptable course of action. If this is reasonable for the issue that you have logged, note down why you have decided to do nothing.
For example, the issue could have an unexpected benefit, so resolving it would be counter-productive. Or it could be caused by a change in local policy or legislation, and as a result you cannot do anything about it apart from replan around it.
Issues log templates can include a lot more than this, but these are the three most important things to make sure you record when you are logging issues on your project. If you know what the problem is, who is responsible for managing it and what they are going to do about it, then you are well on the way to having a successful resolution plan for your project issues.