ITIL® and Me

In the trenches with ITIL and ITSM.

Browsing Posts published by Michael

Often in my job I’m referred as a “bad guy” (since I’m 6’4″ I’ve considered wearing a Darth Vader costume to work, but that’s a topic for another day).  The idea of being a bad guy at my job is something I’ve been used to ever since I started working in my department, and my cohort in ITIL (Brett) is now finding out what it’s like to be a loathed member of a team.  Why are we even bad guys?  Is it because we help create policies and procedures that are accepted by the department leadership and meant to be followed by our coworkers?  Is it because when analysts don’t want to stick with policy that we stand our ground and justifiably deny their requests?  If we just look at why we even like policies and processes, is it because we like to have a structure in which the I.T. department can function as efficiently as possibly while providing value to the business?  Whatever the reason, the truth is that I’m often looked at as a bad guy.  Some of you may think I’m paranoid, but today I came across a realization that helps to prove my point.

A manager in my department has been really making my job difficult.  This particular manager is in charge of pretty much all of our I.T. infrastructure systems; servers, virtual applications, desktop images, his group is pretty much doing it all.  This also means that when there’s a Problem I’m required to go and question his staff as to why things break.  Often one analyst will give a “root cause” as being another system failing, and when I question why that system failed I’m often met with “I don’t know.”  When I ask how can we know, the response is either “I don’t know” or “we don’t collect logs from that particular system.”  Needless to say my attempts to get to a Root Cause from a Problem literally accomplishes nothing except having a bunch of meetings which wastes time of having a lot of blank stares (I think the next root cause analysis meeting should be at a local bar so at least I can numb my consciousness).  The manager in question also doesn’t help much by holding his staff accountable for their actions.  In fact, it often seems that whenever he’s involved with a Root Cause Analysis session he tends to not add much value except to constantly say jokes that derails the focus of the meeting.  Why is it so difficult for this manager to follow the processes?  I’ve been racking my brain for the past few days and I think I’ve finally found the answer.  In general, people don’t like to have their actions reviewed and questioned, especially when it has something to do with a failure.  For the past few weeks I’ve been raising a lot of questions about a particular group in my department and when the analysts can’t provide answers, who is responsible?  Who is accountable?  I could be wrong, but something tells me one of the responsibilities of a manager is to make sure his/her staff are following policies and procedures and are working as efficiently as possible.  When someone questions the actions of a group, it questions the managers ability to motivate and lead the staff of that group.  Suddenly it makes sense why this manager is blowing me off and making my job difficult; by my succeeding at my job it potentially could show that he’s not succeeding at his.  Now, do I really want someone to lose their job?  Absolutely not.  A core book in ITIL is Continual Service Improvement.  This could be improving processes, technology, or even people (preferably by training).

Since I don’t want to be paranoid and just assume this manager is “out to get me,” I’d like to talk about a different manager.  This manager is in charge of our network and communications group; a.k.a. “the network.”  During Root Cause Analysis meetings it’s a given that someone will blame the Problem on network instability.  My instinct is to defend the network team and force the members of the meeting to look for other causes.  Why do I do this?  Is it because the manager of the network team bribes me?  Is it because I have a crush on that manager and I show favoritism?  Or maybe it’s because whenever a network failure occurs I’m almost immediately notified of the outage even before users contact our Service Desk?  In fact, this particular manager keeps the team running like a well oiled machine.  Event monitoring is in place, communication is very open, and there’s always plenty of cooperation during Problem investigations.  That manager doesn’t even need to be present and I know the team will work as quickly and as efficiently as if the manager was present.

I’ve given examples of two managers.  One of them seems to be aloof and unaware of their team’s actions while the other one maintains contact with their team, helps during Root Cause Analysis and is always looking to improve how the team functions.  So, am I really a bad guy for asking questions and trying to find where improvements need to be made?  Maybe.  But if you know about the Deming Cycle then you would know that asking those questions is a part of Continual Service Improvement.  I may be viewed as a bad guy by some of my coworkers, but in the spirit of ITIL, I think it’s a good thing.  After all, Darth Vader may have been a bad guy but at least he knew how to maintain order.  And let’s face it, those Stormtroopers were pretty organized and efficient at what they did, even if they can’t find two little droids in a desert.

I’ve been working to help a coworker resolve an issue on a Service that’s involved with multiple systems.  At one point an email was sent from an analyst and they gave the “it’s not me” response.  This is where Customer Service suffers at the hands of the “not my department” mentality.  Too often analysts/programmers/support staff look for a reason as to why they’re not responsible for the cause of a problem and are more than happy to announce that they don’t need to be bothered by the issue since it doesn’t involve them.  Going back to my previous story about the analyst that gave the “it’s not me” response, part of the problem did actually turn out to be an issue with a system he supports.  So instead of looking at the problem and making sure the components that he supports are functioning without a problem, he just immediately passed over the issue and now more time is wasted having to go back to the said analyst in order to get the issue resolved.

This is where the concept of Service Ownership really helps.  The idea that I.T. provides services removes the cultural trap of I.T. analysts living in a bubble of “this is what I support and I don’t care about anything else.”  In ITIL’s Service Transition book there’s the concept of a Service Design Package (SDP).  A SDP is basically the architectural blueprint on what is needed to provide an I.T. Service, which includes the hardware, software and processes required to make that Service available for users.  The person responsible for making sure that Service is available and working is the Service Owner.  So under ITIL there’s an intrinsic person that’s responsible for the availability of a Service and now when someone sends that email of “it’s not me” there’s a person responsible for going back and saying “if you can’t fix it, who can?” instead of everyone else ignoring the problem because they are all thinking the same thing:  “It’s not my problem.”  Not only does ITIL force an I.T. department to assignment responsibility of Service availability, but a positive side effect is a change in the culture.  When analysts and programmers know that a specific person is in charge for making sure something works there’s a feeling that their work is being questioned, which it most likely is.  Suddenly the thinking will change from “it’s not me” to “I better make sure it’s not me.”  This helps to push I.T. staff to act in a proactive manner instead of the issue being passed around the different technical groups like it’s a hot potato.  If there’s no ownership on such an issue then eEventually a user will complain, management will get involved and more than likely someone will call a meeting to pull all the different technical teams together to get everyone focused on finding a resolution.  As much as I love for everyone to work together, I hate to pull technical people together in those types of meetings because most of the conversation involves one technical analyst stating another analyst should be doing a specific task, and so on and so forth.  If all the technical teams just checked their systems to begin with and report this information to the Service Owner, more of those “problem solving” meetings could be avoided and the issue could be resolved in less time, and with less meetings, which means less time of Service unavailability and a savings in money with not having to pay for people to attend a (possibly) pointless meeting.

I came across another great ITIL posting that has a nice excerpt on the importance of Service Ownership. This fits in perfectly with my current organization because as of now we don’t have the greatest track record on ownership, so when an improvement needs to be made the “blank stare” look is often given. If you’ve also ever heard of Lean Principles, then you also know that this article has a good point that things should be as simple and concise as possible. I definitely recommend this as a good read. http://blogs.pinkelephant.com/index.php?/troy/using_lean_principles_for_effective_continual_service_improvement/

I subscribe to The IT Skeptic since I don’t believe that ITIL is the end all, be all answers to I.T. processes.  Don’t get me wrong, I love it, but I just don’t believe in “drinking the coolaid” of any belief or methodology and even though I refer to my Service Operations book as 1/5th of the bible, I still keep in mind that ITIL is a framework and allows flexibility in its application.

On that note; here’s an interesting post regarding someone that’s asking a “is it too good to be true” question when it comes to implementing an out of the box ITIL tool.  Since my I.T. department is also looking at the same kind of technology I couldn’t pass up some of the sarcasm when it comes to the posting.  The big lesson I learned after reading this post is that there’s no point in migrating to a new tool if you’re only changing technology; the processes need to be changed as well or else you’ll just end up in the same boat.  Without further ado, here’s the post.  Happy reading!  http://www.itskeptic.org/node/1873.