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.

avatar

Started working in IT in 1999 as a support desk analyst as a way to help pay for food during college. Studied Electrical Engineering for two years before realizing biochemistry was more fun than differential equations, and so ultimately graduated with a Biology degree in 2006. Having (reluctantly) failed at getting accepted into dental school, embraced working in IT and has gone broke becoming an ITIL Expert. Likes to jog, sing camp songs, quote Mel Brooks movie lines and make dumb jokes and loves working for an Israeli tech company where December 25th is a regular work day.