Issue happen at work, that is a fact of life. But just because they happen often doesn’t mean we know how to talk about issues.
In this article you will learn about the reasons IT teams should communicate with business teams about issues. You’ll see the common issues technical and business teams face when communicating about issues. And finally, I’ll share a step-by-step process for how to talk about issues with business teams.
First, we should clarify the difference between an issue and a risk.
- A risk is something that might happen in the future
- Issues are problems with current or planned work. They have a definite negative impact on a process, goal, or outcome
Now that’s out of the way, let’s take a look at why IT teams should talk openly about issues.
Why should IT teams talk to the business teams about issues?
There are many reasons to talk about issues. Some of the most important are:
- The longer you leave an issue without sharing it, the worse it can be. The options to recover are fewer and often more expensive or less desirable
- Understanding the true impact of an issue can only happen when all the impacted stakeholders know about it. Issues often impact other people in ways you don’t know about. This understanding cannot happen if issues stay within a single team
- Issues mean extra work — work to fix the issue, work to repair any damage the issues caused, and work to prevent the issue occurring again in the future. This extra work needs planning and funding
- The issue might not be an issue for the business. It is a waste of time and money if IT spends time and money trying to fix the issue only to find out it wasn’t important to the end user
Common issues when tech teams communicate about issues
Every company has a different way to communicate and manage issues. Some companies use an issue management system. Others leave it to the individuals and teams to choose the best method for talking about and solving issues.
Whatever the approach, there are some common issues many companies face when it comes to communication about issues.
- Raising issues too late. Issues are usually avoided if managed as risks first
- Limiting the discussion to one team. Issues need evaluation by all impacted stakeholders, not just the stakeholders responsible for fixing the issue. Other teams are the best judge of what impacts them and by how much. It is risky to assume you know the impact to someone else
- Assuming the business already knows about the issue. Linked to the line above. Too often business teams find out about an issue days or even weeks, after the event. If the issue impacted business processes the delays can have terrible results
- Focusing on the issue instead of the solution. This is when an issue is raised but no thought has gone into what to do about it. There is no solution proposal
- Not thinking about future impacts. Too often issues are treated as a one-time event. Teams fail to take action to avoid the issue repeating in the future
How to talk about issues
Important: You should follow the established processes for raising and acting on issues that are defined in your company. I am not suggesting you follow the process below instead of adhering to the rules within your company. The process and questions described here can supplement an established process. And if you work somewhere without a formal issue reporting process you can absolutely use this process as your guide.
Now that’s out of the way, here are the four steps for how to talk about issues. Each step includes questions and suggestions for what to talk about with the business teams.
Step 1: Prevent issues occurring
Technically this isn’t part of how to talk about issues, but the best way to address issues is to avoid them. Do all you can to avoid issues before they happen by identifying and managing risks before they become issues. This reduced the number of issues you eventually need to talk about with the business teams.
Talk about risks when you see them. Use risk management processes if they exist in your team. How to talk about risks will be covered in a separate article.
Step 2: Evaluate the issue
After finding an issue, you need to find out what has happened, and what, or who, it affects. You cannot effectively deal with an issue if you don’t understand the potential repercussions.
Check the risk log for the project if one exists. Was the issue flagged as a potential risk at planning stage? If yes, did anyone try and mitigate the impact of the issue? The risk log should include a list of stakeholders involved. This helps you connect with the right people.
Assess who the issue impacts. It is often more than your own team. Look up and downstream of you in the system and data flow — does it impact anyone else?
Look at the business processes the issue impacts. What business teams does it impact today? Which teams will it affect in the future? Example of future impacts: Data doesn’t get recorded for a day. Are there any weekly, monthly, or annual reports impacted by the missing data? Who will need to know there is a data gap? For example, will the day of missing data impact accounting when filing taxes next year?
Step 3: Communicate about the issue
Share the information quickly:
Never assume the business already knows about an issue — even if there is an obvious business impact (like an application or service being unavailable).
The size/scale/impact of an issue determines how fast this needs to happen. Minor issues can wait for scheduled updates, but you should share major issues sooner. The later an issue is raised the smaller the chance of minimizing the impact.
Summarise the issue clearly:
Using the goal-problem-solution framework makes describing issues simple and clear.
- Goal: If the issue impacts a project the goal might be to deliver a part of, or the whole project. If the issue impacts a production system the goal might be whatever the use or output is for the process that has the issue.
- Problem: What is broken or failed and what is the impact of this? The impact relates to the goal — usually the goal isn’t achievable because of the issue. Make it clear how significant the issue is to you and ask what the impact is to the other stakeholders. Minor for you might be major for someone else, and the opposite can also be true.
- Solution: A proposal for solving the problem and therefore achieving the goal. Always propose a solution, even if you aren’t sure it is a good one. In situations where you cannot propose a solution, you should talk about next steps. Ways to help recover from the issue, or ways to prevent the issue happening again in the future.
When talking about the solution, consider the following:
- What must we fix now?
- What can we fix at a later date?
- Do we need to repair any damage caused by the issue?
- What design, process, planning, and updates will be made to reduce the risk of the issue happening again in the future?
Try and use language from the impacts and outcomes model when talking about the issue. This will help everyone have a common understanding of the significance of the issue.
Step 4: Fix the issue (and keep communicating!)
Knowing how to communicate about issues involves more than talking about the issue. Communication is important during and after the work to fix the issue. After doing whatever work is agreed, go back to the impacted stakeholders. Find out if the solution was successful — did it resolve the issue?
Conclusion
Issues happen. We wish they didn’t, but life and work is unpredictable. If you manage risks well there should be fewer issues, but sooner or later something will go wrong. When that happens use the evaluate, communicate, fix and communicate framework. This ensures clear and concise communication with the people who need it.
