We track issues with three main purposes in mind:
- To identify, communicate, and resolve issues as quickly and efficiently as possible
- To learn from our issues so we can hopefully avoid them in the future
- To provide a historical record of where things did not go as expected so we can explain any deviations in our project from the original plan
The Issue Log should be used to track everything that happened (or is happening) which did not go to plan and subsequently impacted the project. Obviously, big issues like system outages or non-performance to contract are things we would log as issues. But we should also track any event which forces us to change our project plan or deliverables. For example, if your customer is a couple days late providing a dependency, if your architect was out sick and had to push a key deliverable, or if the currency exchange rate fluctuates and now some materials cost more than budgeted – these are all issues you should log. The way to think of it is this: when the project is done, the Issue log should explain every unexpected difference between the approved project baseline (scope, schedule and budget) with the approved changes, and what was actually delivered.
When you review your RAID, your issue review should be first, focusing on active, in-flight (or on-fire!) issues.
Issue Sensitivity
If your team is not used to the concept of issue tracking and communication, documenting an issue can make some people very uncomfortable. This can be particularly true if you have to identify a person or team as part of the issue.
This is where your skills as a leader and communicator will come into play. On the one hand, you have to document the issue and hold team members accountable. But on the other hand, calling people out, especially your own team members, can impact morale if not done correctly. Even with the best intentions, when issues are communicated outside the project team, they can be misinterpreted and seen negatively, rather than as an opportunity for improvement. This can lead to negative opinions by external stakeholders who don’t understand the whole story, and can damage trust in your project team.
For this reason some organizations, often those that are agile-leaning, prefer to keep issues internal to the team. The logic is that this fosters more open discussion of issues among the team members because there isn’t fear of their dirty laundry being aired to external stakeholders. While team members do need to feel safe about confronting issues, the RAID log owner needs to be able to communicate issues to stakeholders outside the team when appropriate. The RAID log owner should work with the team to establish expectations on what is communicated outside the team and what is not. In your RAID log you can add a column to identify “internal” items which stay within the project delivery team, versus “external” items that are shared with external stakeholders. As project leader you need to have the final word on this, but being transparent about this to your team can help build trust.
Taking this concept a step further, there may be issues you need to record which shouldn’t even be shared with your own team. For example, if there is a personality conflict between team members which is impacting morale and productivity, you might not want that Issue visible to internal members of the team, but you may need to escalate to specific members of your management team for advice and support. So, as project leaders, we need to exercise judgment for what we share and how we share it in our RAID log.
Whether they be internal only, external or “for my eyes only,” you should find a way to document your issues, regardless. You need an honest log of the issues, and you will be remiss if you don’t communicate issues that affect stakeholders to them. You will also be remiss if you don’t identify internal team issues and don’t have honest conversations to address them. But to safeguard sensitive issues, your RAID log platform needs a reliable way to protect access to sensitive Issues.
