The value Proposition for Problem Management

[LanceMNelson]

As the Problem Manager of our organization, I often struggle with demonstrating the value to the people that do all the work in addressing our problems.   We all know the theory behind Problem Management in the ITIL framework; reduce cost to the organization by stronger uptime of systems, and continuous improvement efforts to eliminate problem recurrences.   The workers are the ones that have to do all the problem solving work regarding problem tickets and to improve buy-in; I need for them to see the value of their efforts within Problem Management.

Before we consider the transformation from theory to practical, we must first ask the question is our Problem Management a compliance initiative and something we are told to do, or is it in place because we see the value and are able to show the return on investment.     Arguably the out of box functionality seems to focus on the basics of problem management and has the fields necessary to address the framework of problem management. It just says to me, fill out these fields because I said so, and not fill out these fields because you will see the value and benefit of doing so.     My goal is to transform the tool from compliance to a tool which shows the life cycle of problem management, but more importantly shows the value to all stakeholders of the process.

Stakeholders of Problem Management are most ITIL discipline owners, with Incident, Change and Problem being the most invested.   Resolver teams are obviously the most important stakeholders, but let's not forget your front lines support (help desk, service desk).  

All stakeholders need to know what current major incidents are impacting the organization.   As a Service Desk Agent and Incident Manager, they need to know how to communicate to the business as it relates to incident tickets and calls.   As a Resolver Group Owner, they need to know what happened, what did we do to resolve, and do we or did we take the necessary action to ensure the major incident doesn't happen again.       As a Change Manager, they would need to know if a Problem was a result of a Change and what improvement opportunity exists in the Change Management process. Lastly our leadership areas need to know that problems are being addressed effectively and are we focused on continuous improvement

Problem Management ITSM tools should facilitate all these elements to show value.     Ultimately Problem Management should show the cost value proposition through reporting analytics.   There needs to be application downtime metrics captured in a Problem Ticket, there needs to be business impact metrics as well.   Through reporting cost basis rubrics will need to configured, so that ultimately reports can be generated that show the impact of problems as well as the cost savings of having problem management.   The challenge will be not just showing what it is and trending but showing what it would be without problem management.     (I haven't figured that one out just yet)

ITSM Tool requirements for Problem Management will address the following features.   I might add with Servicenow, the tool out of box doesn't address these features to my requirements but are configurable with a modest amount of effort.       Servicenow out of box is a baseline in most ITIL disciplines and would conclude that all organizations build on the base to get the functionality specific to their needs. Problem Management Application is no different.

• Dashboard — Show the lifecycle of problem management, to easily see where in the process we are for each "active" problem ticket.
• Dashboard — Show problems that are unresolved and impacting the business currently.
• Better define "active" problem tickets. For example I currently don't have the transparency on Known Work Around problem tickets and those tickets are often ignored and not seen by my constituency.
• Workflow around RCA process so that managers see the RCA and have approvals. Also consider approvals from Change Manager and Problem Manager.
• Functionality within the RCA that asks the question, "what was done to prevent recurrences"?   Incorporate this into the RCA communication.     Root cause analysis is great but not of value unless you do something with the information.
• Visibility to the Service Desk, to empower them with information, so not only can they update and resolve all associated tickets but also to inform and communicate to end users as we are in the fray of resolving Major Incidents

Please share your thoughts on Problem Management.   I have looked for definition, examples as well as white papers and case studies and just not seeing a one size fits all process solution. It is my hope that Problem Management tightens up so that all organizations are stepping to the same beat. Maybe not the same song or even the same band, but perhaps we can all agree to dance to classic rock.

Lance Nelson

[ChrisPope · Accepted solution]

Lance,

This is a great post you have written and addresses a lot of the questions and gaps that ITIL does not always offer prescriptive advice or practical guidance on. The link to Major Incident is a key one, but unfortunately this is generally the reactive side of PM, whereby in practice you would like to be focusing on the proactive side as much as possible, thus preventing Major Incidents even occuring. Many organizations do this in many different ways, some trying to be ITIL aligned, other focus more on the process using the Kepner Tregoe methodology. I have used this in the past myself with great effect and benefits are very visible to see. (Kepner-Tregoe - Wikipedia, the free encyclopedia)

Lets see who else replies, as its a good conversation to be having. Thanks for posting,

Chris