Controlling the Reopened Issues Chaos: Metrics and Strategies 📊🏆

[#1]

We all love when issues are closed. One more success to celebrate. One less problem to worry about. That's why watching Opened vs. Closed reports makes everyone happy, regardless if these are software-related issues, service management-related issues, or any work management tasks. 🏅

But what if those issues, once closed, rise again because the initial resolution didn't quite hit the mark? What would be the impact of issues being reopened? (Apart from the uneasy feeling?)

Issues in ITSM  📈

Well, the most well-known impact would be on operational processes in IT Service Management. It is obvious that no user is pleased when they have to reopen tickets that were closed mistakenly by the Service Desk. Keeping track of the metric for reopened issues is important to monitor how many issues are being reopened. While it may not be possible to prevent issues from being reopened, tracking this metric can provide valuable insights into the overall health and quality of your project.

And whatever you track, you can also improve and see which adjustments you need to make to optimize the quality of service in the team. Your customers will be happy about that.

Let's see where it could be important to monitor reopened issues (or tickets, if we speak about service management) for:

Domain	Practice	Impact of Issues being Reopened
ITSM	Incident Management	The primary purpose of this process is to restore normal service operation as quickly as possible and minimize the adverse impact on business operations. If incidents are frequently being reopened, it can indicate that resolutions are not effective or that root causes are not being adequately addressed.
ITSM	Service Request Management	Monitoring reopened tickets in service requests can highlight areas where users might need additional assistance or where the initial fulfillment was not adequate. This ensures user satisfaction and timely service delivery.
ITSM	Problem Management	This process focuses on identifying the root cause of incidents and finding ways to prevent them in the future. A high rate of ticket reopenings can signal deeper underlying issues that need to be addressed through problem management.
ITSM	Change Control (Change Management)	Sometimes, changes introduced into the environment can lead to issues. If tickets related to specific changes are frequently reopened, it might indicate that the change was not effectively implemented or that it introduced unforeseen difficulties.
ITSM	Service Level Management	Service Level Agreements (SLAs) often have criteria related to the resolution time of incidents. Reopened tickets can affect SLA compliance, as the initial "resolution" did not truly resolve the issue for the end user.
ITSM	Knowledge Management	Reopened tickets can be an indication that the solutions provided in the knowledge base are not effective or might be outdated. Keeping track of reopenings can guide updates to the knowledge articles to ensure they remain relevant and helpful.
ITSM	Configuration Management	If specific configuration items (CIs) are associated with frequently reopened tickets, it might indicate that those CIs are problematic and require closer examination or changes.
ITSM	Release Management	Reopened tickets related to recent releases can indicate problems with those releases. It might be a sign that the release was not thoroughly tested or that unforeseen Issues arose in the production environment.
ITSM	Measurement and Reporting	Regularly monitoring and reporting on reopened tickets can provide essential metrics to stakeholders and decision-makers about the health of IT services and the effectiveness of the current ITSM processes.
ITSM	Continual Improvement	ITSM frameworks, like ITIL, emphasize the importance of continual improvement. Analyzing the reasons behind ticket reopenings can provide insights into areas that need improvement, whether it's in training, documentation, tooling, or other aspects of service delivery.
Agile & SAFe	Sprint Retrospectives	Reopened Issues indicate areas where the development or testing process might have lapsed. This feedback is vital for continuous improvement.
Agile & SAFe	Backlog Prioritization	Reopened tickets can influence the prioritization of the backlog, ensuring crucial fixes aren't overlooked in subsequent sprints.
Agile & SAFe	CI/CD	Monitoring reopened tickets is critical in CI/CD pipelines to ensure software quality and reliability during rapid releases.
Agile & SAFe	Program Increments	In SAFe, reopened tickets can influence planning for future Program Increments (PIs), ensuring alignment and addressing core Issues.
Enterprise Service Management (VeriSM based)	Service Culture	Reopened tickets in ESM can reveal gaps in the service delivery, impacting the service culture and end-user experience.
Enterprise Service Management (VeriSM based)	Define (VeriSM)	Understanding the frequency of reopened tickets helps in defining service management principles aligned with organizational objectives.
Enterprise Service Management (VeriSM based)	Produce (VeriSM)	Reopened tickets offer feedback on service production and delivery, ensuring alignment with consumer needs and expectations.
Enterprise Service Management (VeriSM based)	Service Measurement (VeriSM)	Tracking reopened tickets provides key metrics for service measurement, crucial for evaluating service quality and areas of improvement.

How to control Issues being Reopened? 🕵️‍♂️

First step: Numbers 📊📚

There are two basic metrics one could track to control Issues being Reopened:

• Number of reopened Issues in a given period of time

• Relation between the total number of Issues being closed and ones being reopened in a given period of time

The second metric is referred to as the "Reopened tickets rate" or "Reopened issue rate". It provides valuable insights into the effectiveness of issue resolution and/or closure procedures.

Formula to calculate the opening rate

The formula to calculate the reopened issue rate typically involves comparing the number of tickets that were reopened to the total number of resolved (closed) tickets within a given time frame as mentioned above.

Here's a basic formula you can use:

Reopened Tickets Rate = ( (Count of Tickets Reopened) / (Count if Tickets Resolved or Closed) ) x 100%

This formula will give you the percentage of tickets that were reopened after they had been initially resolved.

To use it effectively, you need to rely on:

1. Number of Reopened Tickets: Count the tickets that were reopened after being resolved. A ticket is considered "reopened" if it was marked as resolved or closed (for instance, by changing it’s status category to DONE) and later changed it status category back to TO DO or IN PROGRESS .

2. Total Number of Resolved Tickets: Count all the tickets that were resolved in the same time period, including those that were later reopened.

3. Time Frame: Choose a consistent time frame for measuring this rate, such as weekly, monthly, or quarterly. This will help in tracking trends and making meaningful comparisons over time.

Second step: Visuals 🎨

While tracking the number of reopened issues is essential, presenting this data visually can offer a more comprehensive understanding. Visual reports and dashboards provide a clear and immediate overview of the reopening trends, allowing teams to identify patterns, outliers, and areas that need improvement at a glance. Utilizing visualizations not only enhances the accessibility of the data but also facilitates more effective communication and decision-making within the team or organization. Whether it's bar charts, trend lines, or heat maps, visual representations can turn raw metrics into actionable insights.

[Andreas Springer _Actonic_]

... and if you're wondering if there's a better way than counting tickets and calculating the reopening rate manually – well, of course there is. Reporting apps on the Marketplace like Report Builder will make quick work of this. There's even a dedicated report template for this exact use case.

PS: Yes, I'm tooting our own horn here, but I just couldn't resist. 😉 Sorry about that...