3 Tips for Reviving Problem Management

Problem management has a vital role to play within the world of IT service management. Yet, all too often, it remains a neglected process to some degree or another. This can be due to a number of factors. Sometimes it is due to an organization being more focused on innovation and growth. Sometimes it’s because the value of IT itself within an institution may not be clearly understood. Or, perhaps IT themselves are stretched with resources aligned more on incident management and keeping the “lights on” to the peril of problem management as an independent function and capability within IT. Whatever the reason may be, no doubt we see that problem management is not always given the importance, priority, and requisite resources that it needs to deliver the distinctive business benefits that ensue from it.

Problem management often remains a neglected process to some degree or another.

I am a freelance consultant who has been working with ITIL implementations since my first exposure to the framework in 2003. More recently, I worked with a telecommunications operator, helping them revive and “relaunch” the ITIL based process for problem management. Previous attempts had been made and were not successful. With sound planning, smart implementation, and the support of key stakeholders, the initiative turned out to be a success. The tips below summarize key lessons learned and advice on how to run such an initiative successfully, even when you face unexpected challenges and constraints that pose a risk.

Tip # 1: Market the Strategic Benefits

Almost every single organization I have been with postpones problem management, and this, to be frank, is not entirely a surprise. However, I do recommend that the value of this process be talked about and that it be raised up to the CIO or relevant management’s radar on a regular basis. It is not that we want IT to be aggressive and push to lower incident volumes for the sake of fancy reports as some would claim. More than this, we want to be raising the bar on ourselves as service providers within the organizations we serve. Don’t forget that IT services not only enable key business processes and operations within our organizations, but we also often even directly support external customers as well, bringing in vital revenue needed for survival.

We complain that IT is excluded from boards and executive decision making. At the same time, we can inadvertently be lulled into a false sense of security when IT operations seem to be relatively smooth and be ticking along. We can become lackadaisical. We need to make use of certain capabilities that, even if they take time and focus to develop, deliver tangible benefit that create impact on a tactical and strategic timeline. Problem management leverages capabilities that are at our fingertips to help us achieve this.

Unlike incident management, the problem management process searches for the root causes of failure (incidents) and strives to eliminate them wherever feasible and beneficial to do so. Where this is not tenable or beneficial at the time, then at the very least to reduce the impact of these along with reducing associated risks entailed is important. Will this mean that we will make redundant resources who are currently deployed on incident management? My advice is that if people are freed up; they should be cross trained and re-deployed into new roles and functions.

A detailed assessment or audit of so many service providers will demonstrate that there is always room for improvement. Poor documentation, patchy implementation of knowledge management, over-reliance on heavily customised tools, inaccurate measurements of customer satisfaction, and an inordinate reliance on a handful of “superstars” in the organization are all common challenges we face today. If we can free up smart and hardworking people to engage on some of these, it would raise the bar for IT in a significant manner.

My work on reviving problem management for my client spun off from another project; it emanated as a result of weekly roundtable discussions we were having with a complex mixture of stakeholders. At that early stage, I had to look at the viability of what we wanted to do. Due to past experiences of former attempts on this, staying optimistic was one of the most important actions required from my side. Dealing with people’s possible disinterest and lost vigour, revitalizing the initiative, and keeping it alive with a smiling face until the project was closed was part-and-parcel of my role.

Tip #2: Manage Stakeholder Expectations

My role as an external consultant was understood. However, to some degree, I did have to step into the shoes of the people I was there to help. There was a need sometimes to roll up my sleeves and advise on the nitty-gritty parts. This caused some level of antagonism. However, I strived to keep my head straight. Why was I there? Was it not for the purpose of succeeding? It took some patience and the passing of time to allow parties across the board to understand the value of our work and what we would do or not do within our scope of delivery. Periodic reporting to the project management function and keeping related parties updated on pitfalls and progress was important.

I had to tread carefully working in an interim role. Time was precious, and I had major deliverables and responsibilities other than this initiative. Once I understood who the stakeholders were, I pushed process implementors to take an active role in chasing things up. Important information was required…tool capabilities, resource availability, the roles of disparate support groups, etc. My role as an advisor meant I had to engage and empower the people who would run this after my departure. Key to my success was the commitment of the process owner and process managers. Both were energetic and helpful, and they became critical to my success through the entire project.

No doubt we stay attuned to the environments we work in. Sometimes our work has an impact on some other area within the organization. Or we rely upon them for input or direction. There are times where we move too fast and need to slow our pace to allow others to catch up. However, where we know our scope is to fix or enhance, we fix or enhance. In this scenario, we need to have a laser sharp focus on the result and refuse to allow any factor to come between us and success in our endeavor.

I approached any objection/issue/risk/gap that came up by bringing up a solution. This showed my determination to win, no matter what came in the way. Being solution-oriented in a smart way is a major value-add we can bring to our clients who themselves may be too deep in the water to be able to take and run these initiatives.

In addition to being solution oriented, I always pushed for simplicity. Aware of my temporary role, I wanted to leave behind steps that were actionable and would be adapted well by implementation teams.

Tip #3: Plan, Deliver, and Close

Early on in the project, I managed to put together a Gantt-chart-based plan for key delivery milestones on the project that was agreed upon and shared. Weekly meetings were documented and distributed to all. Progress was steady yet discernible. Falling a little back during a holiday meant we had to catch up straight after. Management became more relaxed as they saw the outcomes of the project coming to fruition. We faced challenges yet didn’t shy away from them. I engaged with representation from the client’s service design department explaining my modus operandi and encouraging open discussion and healthy critique. We then connected the dots, bringing the process managers and problem analysts who would implement into the same discussion. We saw an influx of issues identified as we drilled down to the step-by-step implementation details. Tasks were meted out to the respective people and a log of progress against them was made and shared. I had to distinguish between the must-haves and the nice-to-haves and prioritize delivery.

Toward the end of the project, COVID-19 had struck and around the world, entire nation states almost overnight had to adapt. Remote working became de facto; we did the same. However, we managed well and once all were accustomed to this new way of working, our pace picked up to better than it was previously. The project was closed and signed off by management. Before departure I made sure that all documents were uploaded to the client’s shared drive for their reference later on and that no questions were left unanswered in respect to on-going roles and responsibilities.

Take Charge of Process Improvement

I hope that sharing my story will help you during your launch or reviving of processes. Guidance here isn’t necessarily applicable only to problem management; it can be beneficial for other processes as well. Your feedback is most welcome.

Musab Qureshi discovered ITIL back in 2003 while working on support processes for a utility provider. His journey to the ITIL Expert Certification involved on-the-ground implementation of the framework in greenfield as well as very mature environments. He was a reviewer of UK government publications such as SLM and the Service Level Manager . His main focus on client projects is to be solution oriented. Musab’s ITIL project clients have included The University of Manchester, NSB, and stc. Read more of his writing on his blog, and contact him directly by email.