More than just a place to log things that went wrong, your Issue log provides you with a mechanism for communicating, resolving, remediating and learning from issues that occur on your project. That process may look like this:
1. Identify the issue
As soon as you have established that there is (or may be) an issue affecting your project, put it in your Issue log. Your understanding of the issue will grow over time, but first thing is to put it in your log so you can start collecting information to understand if there really is an issue, and how big the impact is.
2. Clarify the Impacts and the affected
Work with your team to get a comprehensive understanding of the issue’s impacts not only to your project, but also to the broader organization affected by your project. Identify currently known impacts, potential impacts and all stakeholders who are or could be affected. This is the stage where, with the help of your team, you determine if there is a real issue, how bad it is, and how urgently you need to communicate and escalate it.
3. Communicate!
Now it’s time to start communicating. Communicate the issue to the impacted stakeholders and your management team as appropriate. Be sure to be very clear about the issue, including what you know, what you do not know, and what the next steps are.
For critical ongoing issues especially, communication is key. When there is a critical issue, your team, your stakeholders and even your leadership team need direction and confidence that the issue will be resolved. Even if it is not possible to know exactly what the issue is or when it will be resolved, you can start building that confidence through good communication. This is where you as a PM can really shine if you rise to the occasion. One way to do so is by committing to a regular cadence. For example, “I will have an update for you in 30 minutes. That update may be that I have no news yet, but I will give you an update in 30 minutes regardless of our progress.”
Although your stakeholders would prefer to have the issue is resolved, it’s surprising how much peace of mind your stakeholders will have – and how much more space they will give you to resolve the issue – if you can give them something to have confidence in, even if that something else is simply that there will be a call in 30 minutes with an update.
Perhaps most importantly, don’t communicate based on assumptions. Be transparent and be factual. It’s better to say that you don’t know than to make an assumption and give incorrect information. This can lead to finger-pointing and affixing blame incorrectly, potentially harming your team’s credibility and damaging relationships.
There is a reason why communicating an issue is not the first thing you do. You need to first understand what the issue is, what the impacts are and to whom, otherwise you risk becoming the PM who cried wolf, escalating non-issues and losing stakeholder credibility.
4. Resolve and Remediate
It’s OK not to have a resolution immediately, but you must have a plan to get to a resolution. As you develop and implement your plan to get to a resolution, capture the plan, activities and progress in your Issue log. Your Issue log should be the source of record for your resolution plan and progress, and is the ultimate tool for communicating progress to your stakeholders.
Sidebar: It’s OK not to have a resolution immediately, but you must have a plan to get to a resolution.
When it comes to solving issues, make sure you are clear about two categories of activities: resolution and remediation.
- Resolution is fixing the problem. For example, you have a broken pipe in your data center. This is resolved when the pipe is fixed and it is no longer leaking.
- Remediation is the cleanup after the fact – mopping up the water, replacing any damaged equipment and getting everything back into working order
It is important to understand the differences because remediation should typically be deferred until the issue is resolved and is no longer causing problems. In this example, there is limited value in mopping up the water until you’ve at least turned the water off. Further, it can be easy to declare victory over an issue when a resolution has been found, but depending on the issue, resolution may be only a small part of setting things right. For many issues, there is a lot more to the unplanned remediation work to clean up after an issue than there was in resolving it. And avoiding or skimping on that remediation can cause yet more issues.
5. Root cause and Lesson Learned
Sometimes the root cause of an issue may seem readily apparent when you resolve it, but often it is not. If the root cause of an issue is not identified and you have no idea what caused it, there is risk that the issue may occur again. Establishing root cause is not always necessary for minor and obvious issues. But they should certainly be investigated for issues that are highly impactful, and the root cause addressed as well. Even when the root cause seems obvious, dig deeper by asking “why” until you get to a satisfactory and addressable root cause. Something like the 5 Why’s. Taking our broken water pipe example through this process:
- Why did we flood?
- A water pipe broke in our data center, causing the flood.
- Why did it break?
- One of the fittings failed
- Why did it fail?
- The fitting was not installed correctly
- Why wasn’t it installed correctly?
- The plumber wasn’t trained for this kind of plumbing installation
- Why did we have a plumber that wasn’t properly trained?
- Because we don’t have any method for vetting the quality of our suppliers or checking the quality of their work
The obvious bigger question would be why we had water plumbed near our data center in the first place, but the lesson here is not about plumbing, it’s that drilling down into the root cause of impactful issues is essential for lessons learned – not just for your current project, but for future projects as well.
