What are you really trying to do with IT service management (ITSM) Are you focused on aligning your organization with ITIL or some other framework; or are you concentrating on process improvement?
Too often I see the two confused; with ITIL alignment mistaken for process improvement instead of being treated as one tool in the process improvement tool chest.
Recently, I was talking to a colleague about Problem Management, and, as a result, started to think about the best Problem Management I’ve seen. There was one company that stood out as having a process that delivered results clearly superior to all of the many organizations. This organization was incredibly effective at determining the underlying cause of incidents and preventing repeats. When there was a major incident they generally informed the CIO by the next business day, telling him what happened, why, and what they did (or needed from him) to fix it.
Most organizations struggle with Problem Management, so having highly effective Problem Management was remarkable in itself. What was really perplexing to me was, in ITIL terms, their Problem process was nonexistent. No one used the term “Problem.” Root cause investigations were handled as part of a well defined Incident process (that was also uninformed by ITIL ). There was no separate Problem ticket, nor was there a known error database, Problem manager, or error control. Oh, and their ticketing tool was a complete mess.
So why were they so effective?
Culturally, it was understood that dealing with repeat incidents wasn’t acceptable; availability was king. Staff at all levels were expected to resolve the incident and do whatever it took to keep it from happening again If they didn’t, they were called out. This went for everyone from desktop support to high level engineers. They did have a process; it just didn’t look anything like ITIL.
So how is it possible that the most effective Problem Management I’ve ever seen completely disregarded ITIL? A few thoughts:
Culture trumps process – Having a culture of accountability is more important than aligning to “best practice.” The CIO holding peoples’ feet to the fire is worth far more than an intranet full of flow-charts.
Process adoption and adherence trump process design – Having a process that is well understood and followed is much more important than having an optimum process that aligns to a framework that is not universally known and used. They didn’t call it a Problem process, and it didn’t resemble ITIL , but there was a well defined process that everyone followed.
People-quality trumps process-quality – This organization paid above average, had great benefits, and was insanely selective in their hiring. They also invested in training and education. Every organization says their people make the difference, but this one put their money where their mouth was. As a result they expected, and received, more from their people.
Continuous Improvement trumps best practice – This organization was always looking for ways to get better. It was always important to do things better today than they were done yesterday. They didn’t preach quality, a 7-Step improvement processes, or even Plan, Do, Check, Act — they just tried to get better every day. Besides, the term “best practice” has always bothered me as being antithetical to improvement; doesn’t “best” imply there isn’t a need to get better?
To anticipate your question: How do I know that Problem Management was effective if there wasn’t a process? Because they were clearly meeting one of the key objectives ITIL lays out for Problem Management, which is to eliminate recurring incidents. I know this because I saw a root cause investigation and corresponding action for every major incident and repeat major incidents were extremely rare.
So I’ve talked about how it is possible to have an effective process without adherence to frameworks. The reverse is true, as well: You can have adherence to the framework and a completely ineffective process.
While we are on Problem Management, I think it is an area where a lot of organizations completely miss the point. Specifically, they treat it as more of a function than a process. My feeling is as soon as you set up a “Problem” box on the org-chart you ensure that very little Problem Management occurs outside of that box.
With Incident and Change Management people intuitively understand that that these are process that need to be practiced across the organization. But for Problem, and a lot of other process areas, everyone seems to want to set up a stand-alone group with responsibility for Problem investigation or coordination.
Please keep in mind I’m not trying to disparage ITSM here. I firmly believe ITSM and ITIL are extremely valuable tools. I’ve staked my career on it. To expand my example here, even though this organization was more than effective while ignorant of ITSM, they were definitely able to draw on ITSM to guide some improvements to areas that needed it.
Working in the ITSM space, it is very tempting to hope that we can move a box on a flowchart and realize results and sometimes we can. It is appealing as a manager to think that moving a box on an org-chart will yield improvement, or that a sub-optimal tool is the primary impediment to progress. More often than not, however, these are just pieces of the puzzle, and to complete a puzzle you need more than some of the pieces.