Right now my manager is working on improving the first call resolution (FCR) rate for our Service Desk. A very critical part of this improvement is to understand the types of calls that the Service Desk is taking and determining what’s being escalated and why. Here’s the problem though; the category list that we use is too generic and it’s difficult to easily find trends in the data. To try and overcome this challenge I’m pulling a report of where the escalated tickets are being assigned so we can take view the categories (even if they’re too generic) and start drilling down into the data to find improvements. After looking through some of the escalated Incidents, I think the ITIL process we should be implementing to improve the FCR is Knowledge Management. A large portion of the calls are either “how do I…” types of questions or the system is functioning correctly, but the user made a mistake in their work-flow. I definitely think that other actions will need to take place to improve the FCR, such as a change in responsibilities and roles for the Service Desk. First thing is first though, and that is implementing a Knowledge Management solution to empower the Service Desk with information they need to help the users. At the end of the day an improvement of FCR isn’t just about proving we have a great team at the Service Desk, but it’s also about making sure our customers are happy with the service.
Browsing Posts published by Michael
I’ll keep this post short and to the point; beware of the “Bubble Culture.” My manager also referred to this as “The Silo’s,” but even though a silo may be a better metaphor, I like the idea of bubbles. First, the word “bubble” is just more fun to say, and second, as difficult as it can be to change a culture I feel that identifying a change as a hardened, concrete structure can be more discouraging then thinking of simply popping a barrier and letting the contents (in this case people) wake to the shock of what’s outside. So what is this “Bubble Culture” I’m referring about? Quite simply, it’s the idea that the technical talent (a.k.a., just about everyone that’s not on the Service Desk), lives inside a bubble and they don’t have any interactions with anyone else; even with other roles in the department. At my current job we’re in the middle of fighting a Bubble Culture, and these bubbles aren’t very easy to break. It’s easy to assign an issue (Incident, Request, etc.) to someone in a bubble, but if there’s something wrong, such as information not being correct or missing, the person in the bubble would prefer to just send the issue back to the Service Desk to gather everything. As great as it sounds to have the Service Desk be a total Single Point of Contact; it’s just not realistic where I work. By the time the issue travels back to the Service Desk technician and the technician is actually made aware of it and eventually gets around to contacting the user, the technical analyst probably could have just contacted the user directly and had everything resolved. Not only does busting the bubble have to do with increasing communication between analysts and users, but often incorrectly assigned tickets will travel back to the Service Desk, often to (again) be incorrectly assigned and more time being spent with getting the issue to where it needs to go. Usually such actions can be avoided if the bubbles are just gone and a technical analyst walks over twenty feet to talk with the person they think that can actually resolve the problem and just get the ticket resolved. So this bubble not only prevents communication but it’s depriving the entire department of efficiency, ruining the positive customer service the user would like to receive, and ultimately just wasting energy by wasting time. So when getting ready to put improvements in place, be it ITIL, Lean, Six Sigma, etc., be ready to bust some bubbles. The people living in them may get a shock when they’re nice and cozy little atmosphere changes, but we’re talking about changing a culture to provide better service, not just keeping everyone all nice and comfy.
As I’ve been working on Problem Management at my job I’ve realized that problem solving in this organization is almost like running a mini project. I’m sure in the perfect ITIL world Problem Management flows beautifully into Change Management once a Root Cause is found and a Change needs to be made to fix it, but one part to that flow is the full understanding of what’s going on in the I.T. environment. Since we don’t have a CMDB this makes Problem Management and RCA as difficult as having a blind person drive in the Indianapolis 500; they can still do it, but it’s going to be messy. And keeping with this analogy of a blind driver, it means that to get to the finish line someone is going to have to give detailed instructions on where to go. This is why I’m thinking to treat Problems as projects and consider a Problem Life-cycle. So far I’ve broken the life-cycle down into six (6) phases. First phase is Initiation, in which detection, logging and categorization occurs. Second phase is Assessment, where Prioritization occurs based on the assessment of the impact on the users. The third phase is Investigation where investigation and diagnosis occurs, as well as finding a workaround to resolve Incidents and minimize impact on the organization. The fourth phase is Confirmation/Elimination of Root Causes. I took part of the Kepner and Tregoe methodology of problem solving and considered that during the Problem Life-cycle several possible Root Causes will probably be found, so they’ll need to be tested. It’s at this phase that the majority of work will occur if Event Management or a CMDB are not in place. Here is where tasks need to be given, results need to be reported and if a task isn’t complete, follow-ups will occur. This is also the phase that mimics a project with meeting minutes, action items and a lot of work to ensure involvement from the different technical teams within the I.T. department. All this has the goal of trying to find the Root Cause. Problem resolution efforts will probably also go back and fourth between phase three and phase four since it’s possible that all possible root causes will be eliminated and efforts will have to “go back to the drawing board,” so to speak. Phase five is Analysis in which the cost and benefits of implementing the Resolution are compared to the costs of keeping with a workaround, assuming a workaround has actually been found. If it’s decided to implement a resolution, then the final phase is reached; Change and Validation. Here a Request for Change will be submitted and once complete, reporting will need to take place to validate the reduction in Incidents. The validation is extremely important and often overlooked in my department because of the assumption that our work is flawless so a Change to resolve a Problem will indeed work. This phase also helps to keep with the “Check” phase of the Deming Cycle.
Like a project, I’ve broken down the steps of the Problem Management Process into different divisions, each with their defined goals and as I work on this idea, I’ll also develop documentation for each phase. I know there are other ways for Problem Management, but the beautiful thing about ITIL is that it’s a set of best practices, which means I have the flexibility to mold the processes to my department’s culture and as my organization changes, the implementation of those processes will change as well.
I just read the IT Skeptic’s post about how APGM is raising the limit of students for an ITIL v3 intermediate course from 12 to 18. The IT Skeptic makes a very good argument in his blog about how this is degrading ITIL standards and will only hurt the industry (http://www.itskeptic.org/apmg-further-degrade-standards-itil-v3-certificati). I couldn’t agree with the author more on this point and to be honest, I’m a little depressed that I’m now just starting in ITIL and I’ll be receiving my certification in v3 and not v2 just for the sheer fact that the v2 testing standards are much more difficult and the answers require an explanation as opposed to just choosing from “A,B,C, etc.” I’m certainly not against making the test easier since I’ll be taking those tests, but with easier requirements comes an increase in likeliness that a bunch of yahoos will be going into ITIL so it looks good on their resumes. Since I’m someone that truly likes the framework and loves learning the material and how it can be applied to I.T., it’s degrading to be part of an “ITIL Generation” that doesn’t have a weed out system. And I’m not talking about an intelligence filter, but something that helps to keep unmotivated and close-minded people out of ITIL, because the people that take the Intermediate courses should be those that want to see a change for the better and not just because they want to add another line to their resumes or their job requires them to take a certification course. For my long-term goals this means I have to possibly contend with people that have advanced certifications in ITIl v3 but don’t truly have an understanding on how it can be applied or how it can change an organization for the better.
And what about the short term impact of this change? For me, it doesn’t matter. I’m learning something new about ITIL each day and this knowledge will only help me in my current job and organization. So ultimately the change may mean less competent people will have advanced ITIL certifications, but it doesn’t mean I have to join the ranks of the incompetent. After all, what do you call the bottom ranking student in medical school? The answer is “doctor.”
Comments