IT Service Management Problem Management

The Problem of CSFs

If you are unable or unwilling to appoint a Problem Manager, you are not ready for Problem Management.

That’s what I said. Or at least I think that’s what I said.

The venerable and ubiquitous Chris Dancy quoted me this January 2011 on episode 1 of the re-formed Pink Elephant Practitioner Radio podcast. He quoted me as saying “you can’t do Problem Management without a Problem Manager”. I finally listened to it last Friday.

I want to apologize to Chris. First, I apologize that I didn’t listen to his podcast earlier. I am a couple months behind on my podcast queue. Second, I apologize that I didn’t thank him personally at #PINK11 in February for the mention. I love Chris in almost every conceivable way.

I don’t fully agree with the paraphrase. I think a company can successfully implement a Problem Management process without a Problem Manager. What I really wanted to say was this: If you are unable or unwilling to appoint a Problem Manager, you probably haven’t achieved all the critical success factors you need to successfully carry out Problem Management. Unfortunately, this sentence doesn’t tweet well, so I abbreviated.

ITIL v3 Service Operations lists the critical success factors for Service Operations processes:

  1. Management Support
  2. Business Support
  3. Champions
  4. Staffing and retention
  5. Service Management training
  6. Suitable tools
  7. Validity of testing
  8. Measurement and reporting

All of these are necessary to successfully implement Problem Management. Organizations that lack any of these factors won’t appoint a Problem Manager. My advice to organizations, then, is very simple: appoint a Problem Manager. If they cannot do this, they are not ready for Problem Management.

In fairness, a few organizations do meet all the above CSF’s and choose to implement Problem Management without a centralized point of contact. It is the responsibility of managers to perform Problem Management activities inside their own group. Organizations with the right culture can get away with this. Most organizations cannot.

For that matter, most organizations cannot muster the courage or resources to appoint a Problem Manager.

Problem Management

The Problem of Revealed Preferences

Consumers express their rational interests through their behaviors. Economists call these revealed preferences.

IT Service Management trainers and consultants tell other companies how they should run their businesses, based on industry best practice frameworks. We seldom examine revealed preferences, but perhaps we should.

One of my first engagements as an ITSM consultant involved the planning and implementation of a Problem Management process at an organization that had committed to widespread ITIL adoption. For several years after I was an acolyte of Problem Management.

I have implemented Problem Management at a dozen customers and tried to sell it to even more. Among the latter, most resisted. The excuses often included “we are too busy putting out fires”, “we aren’t ready for that”, and “that’s not our culture”. Perhaps I wasn’t selling it well enough.

Most organizations do ad-hoc Problem Management, but few organizations have defined processes. Their reasons probably contain some legitimacy.

Organizations do need to be in control of their Incident Management process before they are ready for Problem Management. They do need to be in control of putting out fires and fulfilling service requests. Most organizations find themselves with a backlog, even those under control, and that is alright. A reporting history is a prerequisite.

Organizations must also be in control of its Changes. The resolution of known errors take place through Change Management, and organizations in control of Changes are better able to prioritize the resolution of its known errors. Anyway, at most organizations, an effective Change Management process is more beneficial than Problem Management.

I usually told customers they were ready for Problem Management only if they could devote at minimum one-quarter to one-half of an FTE to the Problem Manager role, and this person would need to have a good overview of the architecture or be well-connected throughout the organization.

In other words, the Problem Manager should be reasonably senior and independent of the Service Desk Manager. Without this the Problems will be starved of resources. Someone needs to liaise with senior management, ascertain business pain points, prioritize tasks, acquire resources, and hold people accountable. In other words, Problem Management requires commitment at senior levels, and it isn’t clear all organizations have this. Many don’t.

There is another reason that is more important. Organizations that are so focused on executing strategic projects won’t have the resources to execute Problem Management processes consistently. There are several reasons this can occur. In one instance the organization had acquired another and had dozens of projects to deliver on a tight deadline. In another, the reverse situation was occurring, as they built functions to replace those provided by a former parent company. In another, the organizations simply put a lot of focus on executing projects in support of the organization’s new strategy.

Some organizations plainly require Problem Management processes. I have seen more rigorous adherence among organizations who provide IT services to other technical organizations, such as data center outsourcers, hosting providers, or organizations who provide services such as video distribution or mapping to telcos. When services are interrupted, the customers demand root causes analyses.

But it is probably true that many organizations don’t need or aren’t ready for Problem Management. Problem Management is an investment, and like all investments should deliver returns that exceed not only its own costs, but also exceed the benefits of similar efforts the organization may undertake. So it has been revealed.