Why You Should Have an Issue Log in Your Project

Why You Should Have an Issue Log in Your Project

Do you have an Issue Log in your project and do you use it consistently? In my view, the Issue Log is one of the most neglected or underestimated tools in project management. The Issue Log is not just a simple list of issues, but behind it is a management culture of how you handle issues in your project. If you want to know what exactly an Issue Log is, how to apply it, its benefits and how to implement it in SharePoint or Excel, then read on.

What are Issues?

First, a question: Is everyone on your project team familiar with the difference between a risk and an issue? Probably not. A risk is an uncertainty that could occur with a certain probability—and when it occurs, it becomes an issue. You won’t find a clear definition of issue in project management, and the PMBOK doesn’t provide more clarity on this either. In this article: Risks, Problems, Issues and Impediments – What is the difference, I described the difference in more detail.

Issues are not uncertainties—this should be clear! Issues are problems, conflicts, impediments or open questions in your project. They often appear suddenly somewhere and “disturb” your project. They are topics that need to be solved, worked on or clarified. Even if a risk occurs, you have a problem or an issue.

How Do You Handle Issues?

Issues hinder your project in some way and, if not solved quickly, always have an impact on the costs, deadlines or quality in your project. If issues are not solved promptly, there is a risk that they will become bigger and bigger, or more and more difficult to solve, or that the negative impact on your project will increase.

The earlier issues and impediments in your project are known and visible to everyone, the earlier they will be solved and the less they will have a negative impact on your project. This statement is probably obvious to you. However, the Issue Log, the tool that supports this process, is still highly neglected. The issue log is actually just a list of current problems. Behind it, however, there is a lot more to collaboration, as well as team and error culture in the project.

Fixing Project Defects and Problems early
If issues, problems and impediments are not solved early, this happens: They get bigger an bigger and …

In Scrum, for example, the Scrum Master is responsible for monitoring impediments in the Impediment Log and working with the Scrum Team to ensure that they are removed as soon as possible. All members of the Scrum team are responsible for continuously identifying impediments, which are then discussed during the daily standup meeting. So issues are on the agenda here every day!

Transparency and an Open Error Culture

One of the five Scrum values is openness. According to this value, information can only generate benefits if it is freely accessible and one deals with it openly—and this, of course, also applies to errors and problems. This enables informed decisions, promotes efficiency during work, and provides the highest possible transparency to the project team and stakeholders. In an open error culture, errors and problems, i.e. issues, can be openly communicated so that they can be quickly resolved and everyone can learn from them.

Issues Should be Visible to Everyone

There is nothing worse than having project issues that are not quickly visible to everyone on the project team. The worst thing would be to sweep them under the carpet. Only when issues are communicated and visible can the project team work on them—and the better these issues are visualized, the better our subconscious works on solutions. Review the Issue Log and the Risk Log at every project status meeting. Visibility is already half the way to a solution!

Of course, I exclude from this transparency personal, private issues that may have an impact on the project. These should be discussed, if possible and trusted, directly with the project manager, HR or the company’s social services.

Problems that are not visible cannot be solved quickly

Ray Dalio, the well-known hedge fund manager, also installed an issue log in his company, Bridgewater Associates, a few years ago. It does not have to be a project, an issue log is also helpful in a financial company or in the line organization. Here is a short section from his book Principles – Life and Work:

Having a process that ensures problems are brought to the surface, and their root causes diagnosed, assures that continual improvements occur. For that reason, I insisted that an issue log be adopted throughout Bridgewater. My rule was simple: If something went badly, you had to put it in the log, characterize its severity, and make clear who was responsible for it. If a mistake happened and you logged it, you were okay. If you didn’t log it, you would be in deep trouble. This way managers had problems brought to them, which was worlds better than having to seek them out. The error log (which we now call the issue log) was our first management tool.

Project problems should be visible to everyone as quickly as possible so that they can be tackled and solved as quickly as possible—and the issue log is an ideal tool for this. You surely know yourself, problems rarely disappear into thin air!

How to Create an Issue Log

In my project practice, I often find that an issue log is created, maintained for a few weeks, and then slowly discontinued. In this case, the project manager has to convince the team members that the issue log is of significant benefit to the team and keep requesting it.

The issue log can be created in Microsoft Excel or in a SharePoint list and should include the following columns (italic, SharePoint column types):

  • ID ( sequential number), SharePoint standard field
  • Title, Single line of text (3 to 6 Words, keep it short)
  • Issue Description, Multiple lines of text
  • Action/Decision, Multiple lines of text
  • Action due, Date and Time
  • Implementation Update, Multiple lines of text (describe the implementation status of the resolution)
  • Status, Choice [New, Open, Closed]
  • Owner, Person or Group
  • Area, Choice [Your work streams or subprojects or defined topics, e.g.: Business, Testing, IT Delivery, Migration, PMO, StC]
  • Severity, Choice [1 Minor, 2 Moderate, 3 Severe]
  • Raised by, Person or Group
  • Closed, Date and Time
  • Date last updated, Date and Time (when was the Issue last updated)

The Issue Log, together with the Risk Log, is in my view, one of the most neglected or underestimated tools in project management. Both reflect your work and leadership culture. I hope I could show you in this article that the issue log is not just a simple list of issues that you quickly forget.

Here You Can Find More Knowledge

Would you like to learn more about how to make your projects more successful with SharePoint? Save time and money and get first hand experience with my book “SharePoint Online for Project Management“. It takes you an important step further!

Do you know somebody who might be interested in this article? Then simply forward it or share it. Thank you! 

Posted in Project Control, Project Leadership, Risk Management, SharePoint.