Cory and I attended the Pink Elephant ITSM conference, which took place February 19 - 22 at the Bellagio in Las Vegas. This was the third time we have participated in this conference - and the first time as Sologic. We met up with a pallet full of our new booth gear - and I have to admit, I almost broke down and looked at the manual for how to assemble it. But we persevered, and when we were done, it was obvious that the new booth was a big step up. And it paid off in the form of high-quality attendees visits throughout the conference.
We really like this conference. It's certainly not the cheapest, nor is it the largest we attend. But the Pink folks do things right. As vendors, we're full attendees with all the rights and privileges. And as much as we enjoy the relaxed atmosphere, as well as the free food and drinks, the high-quality conversations truly make it worthwhile.
Over the years, we've seen maturation in IT with respect to Problem Management. Three years ago, I remember most people wondering what we were doing there. Last year, we heard a lot of comments like "we're getting Incident Management off the ground, and then we'll focus on Problem Management." And this year, we had many conversations about the intricacies of a Problem Management program and how root cause analysis fits. This growth is admirable, no doubt. However, in my opinion the IT sector in general still has tremendous opportunity to more fully understand the potential of a sophisticated root cause analysis program.
I spent a lot of time this year asking questions. I wanted to know exactly how visitors to our booth were conducting root cause analysis. My rough, unconfirmed estimate is that, of those who do anything at all, about half use a classic method such as the 5 Whys or the Fishbone. The other half simply get together and talk about the problem until the group decides on a root cause. This isn’t surprising since ITIL is largely silent when it comes to recommending any specific type of methodology. It says you need to complete a root cause analysis, but stops short of explaining exactly how you are supposed to do it.
I was also a bit surprised to find that many of our visitors are isolated from other areas of their business that also use root cause analysis, such as Safety, Quality, and Reliability. I finally made it part of my standard pitch to let visitors know that we train thousands of people every year - and most of them aren't from IT! That this was surprising to many was actually a surprise to me. What a great opportunity to do some match-making between departments.
Mark Phillips, the Operations Services Director at Brigham Young University, led a very interesting session. Mark provided attendees with a case study detailing their experiences with Problem Management at BYU. They took a two-phased approach. The first phase was very much under the radar. They didn’t tell many people what they were doing… they just started doing it. Once they found some success, they found the courage to bring their Problem Management program out into the light. And their Directors bought into the program because it was achieving results. This mirrors our own experience as well. Start with a low-risk pilot program. Work out the kinks and prove value. Then scale it up. By taking things in easily digestible steps, no one gets in over their head.
Another interesting parallel has to do with who is actually conducting the analyses. They use work-study students as principle investigators. These students come from diverse majors – and none of them were from IS/IT. Mark said that technical experience was nice to have, but that it wasn’t a consideration for whether a student got the job. It required for the analyst to have excellent customer service skills and be able to learn quickly. That perfectly mirrors my own experience, and it was nice to see it validated independently.
If you aren’t from IT but you are an RCA expert, I would encourage you to reach out to those responsible for Problem Management in your IT organization. Your perspective on RCA would be very valuable to them. And I’m sure they would find it refreshing to hear from you about a proactive opportunity rather than a debilitating IT failure!