1. Show Notes Links:
    Troy’s Thunder Bolt Tip of The Day:....WAIT...it's NOT TROY!

    Graham Tip Synopsis: Change is not what something imposed on us Change is something we do for managing Risk.

    Moustache Wars
    Turf wars between Project, Software Development (SDLC) and ITSM processes
    SDLC & ITSM
    Prince 2 vs PIMBOK cio.com.au/article/402347/pmbok_vs_prince2_vs_agile_project_management/#closeme

    Project & Operations need to work together to manage Risk
    Project are just another name for Change
    Why is Project Management almost invisible in ITIL V3? (IT Skeptic)
    itskeptic.org/why-project-management-almost-invisible-itil-v3

    Sources of Projects
    Systems of Change: What you actually call a Change Management is not the totality of your Change Management System.
    Service Portfolio Management
    blogs.pinkelephant.com/index.php?/troy/comments/practitioner_radio_episode_13_-_service_portfolio_management/

    Projects & Change Management both focus on: Output, Outcome & Benefits
    Project Managers are in effect a Change Manager for Projects and the Steering Committee the CAB
    Major Changes are Often Called Projects
    DevOPS ITSM Weekly Podcast
    servicesphere.com/blog/2012/7/9/i-will-cut-you-devops-culture-itsm-weekly-the-podcast-episod.html

    The Philosophy of Project Management office: We are about introducing change to the organization that best helps to manage the risk of that change?
    Project Managers have to often move things into production even when they raise flags.
    On Time, On Budget often overrides Risks
    Where should the governance be for “Go Live” decisions?
    Tiered Governance Levels: Board, IT Portfolio, Project,
    In an organization where the focus is on Build over Run, everything is a Project
    Business Relationship Manager
    blogs.pinkelephant.com/index.php?/troy/practitioner_radio_episode_15_-_business_relationship_management/

    Graham Tip Synopsis: Change is not what something imposed on us Change is something we do for managing Risk.

    # vimeo.com/50683008 Uploaded 22 Plays / / 0 Comments Watch in Couch Mode

  2. Show Notes with links:
    servicesphere.com/blog/2012/8/6/common-is-the-new-black-working-with-global-processes-practi.html

    Show Notes and Transcription:
    roy’s Thunder Bolt Tip of The Day:

    Troy’s Thunderbolt Tip: Remember that that a Common Process can be defined at different levels of commonality. It is important to make a decision based on value cost and risk just how common you need your processes to be.

    Show Notes:

    Global Processes
    Viewer Mail and Feedback
    Where do you see SHOW NOTES? Troy’s Blog or Chris’ Blog
    Common Definition of Terms, What’s Common?
    COMMON PHOTO SEE ABOVE
    Standard vs. Core Plus vs.
    Regional Tool 1 vs Regional Tool 2
    What’s easier to manage a completely common process or a core plus?
    Change Management CORE ….but PLUS regional differences.
    Repeatable processes show the most process when customer facing?
    The THREE ITIL Customer Facing Process in ITIL: Service Desk, Request Provisioning, & Strategic Intact (Demand Intake)
    Shares Services, YOU HAVE to have common processes
    It’s easier to make common processes that don’t involve humans
    Is Cloud really the savior we think it is….I THINK NOT…it’s much more dangerous.
    ITSM tool philosophies, HAVE NO GUARD RAILS
    Sun Tzu Toyota - You can copy someone’s process, you can't copy someone's culture
    It’s not American to be “common”
    McDonalds is “Core Plus”

    Transcription:
    TRANSCRIPTION:

    Welcome to another edition of Practitioner Radio. Pink Elephants podcast for the IT management community. Welcome to Practitioner Radio: Pink Elephants Podcast. IT service management, IT management, just the IT community, everybody. It's even good for people not in IT. We've got a couple of HR folks out there.
    Hey, this is Chris Kensy (sp?) episode 30. Troy, 30. 30, can you believe it? Wow. 30, 30, that is 15 hours of practitioner radio. Well, some times it feels like 15 hours, and sometimes a [xx] just a few minutes minutes ago so. So, this wee on the This is 30 minutes in ITSM audio.
    We've got global processes; we're gonna talk about that.
    We've been inundated -different parts of the globe you were in Asia and I was, I don't know where I was. And we got some actual mail. So real quick, for me I met somebody who is a big fan of yours, Troy. His name is Russell. He works at a company called Manta. I was out speaking in he says, "I listen to you guys all the time; even my family listens to you." I feel sorry for them.
    But, big hello to Russell.
    We're home entertainment now Do you believe it? Actually I can, I see what's on television. Come on. What families say. Hey Russell, how are you doing? And then You were just in Asia and then you got a couple of pieces of fan mail while you were there, you wanna talk about those? Well yeah, one was about, there was a question about key performance indicators and critical success factors and I said we could address it briefly in the next show, though that's not the topic for today.
    And another one was that, hey! We're on iTunes, right? So, one of the things you and I have forgotten to do, if we keep talking about our shows and our show notes, and it's in the show notes, but we never tell them where it is, where are the show notes. Because we always assume they actually get there from one of our two blogs, either your blog or my blog.
    Yes.
    And that's of course where the show notes are. But if you're on iTunes and you've subscribed to Practitioner Radio, we've never actually said that.
    No.
    So shame on us.
    We're in IT. We don't communicate.
    So if anyone's looking for the show notes servicesphere.com or pinkelephant.com and look for the blogs. The big red button that says don't panic, that's my hitchhiker's guide to the galaxy blog and you can get from there.
    Yeah, so if you want to go back because I actually had a request I didn't mention yet on air, just because I was actually to the point where I get too many requests about Practitioner Radio. All of the show notes are available in a couple of different places. So you can go to Vimeo, V-I-M-E-O. You can find them there if you just search for Practitioner Radio.
    If you go to Sound Cloud all the show notes are always there, just search for Practitioner Radio by [xx].com or Pink Elephant and the blog for Troy, the show notes are there. And just recently some people have noticed, thank you For those of you sending me emails saying thank you. All of our shows are actually transcribed.
    So if you can't get an episode of Practitioner Radio... or you just don't have time to listen or you're on a plane disconnected, you can actually read the transcriptions. So I know I post the transcription on Sound Cloud and on my blog. I don't know, Troy what's going on, but there's lots of places.
    So thank you for the feedback. Thank you for letting us know that not everyone knows where these things are. It's important that people know how to get to them. As far as the KPI question, Troy, we'll keep that for next week and try to address that. Because that;s SLA's [xx] yes, critical success factors and how do they all work together.
    That might be up, that's the next show.
    Well, there ya go.
    So, a big thank you to Mark from The phone for defining episode 31. So, your definition on common, I doubt is the same as mine.
    You know, this is the thing about having a common language and some people say that's the best element of having a framework- that we can actually have a common definition of terms. This actually became very interesting because I had if that's true with all and this is a global organization and they wanted to talk about deploying global processes and I said, OK, that's cool, a challenge, but cool what do you mean by the word "common"?
    And I proceeded to give them four different definitions of what common can mean. Well, actually three. There's a fourth which, you know, you can't ignore either. So when you think about common, and we're going to put some discussions or a picture about how this might be received in the show notes but first of all there's the not common- do your own thing, everybody basically does their own process the way they want to do it.
    But then there's another concept that people talk about a lot which is, we're gonna create this center of excellence and what is a center of excellence? Well think about a small group of people who get together and they collect collateral, they collect documents, templates, and they create really kind of a repository of IP, knowledge documentation, and this might be an internal process engineering group, an ITSM group whatever.
    But what the idea here is that you have, this common resource pool of information, and if you're so inclined you can go and you can use that information, use that content, so at least there is a same gene or DNA pool where various parts of the organisation polls their stuff [xx] now that doesn't guarantee you a [xx], but at least it's the same family background, so you can trace your ancestry back to this center of excellence.
    feel uncontrolled because of unexcess of works, OK they kind of moving upon a continue a comment you have something called Core Plus, or Core and Additional. And I like to think of this as, okay, there's these base elements that we must all agree on. Right, so we all agree that the process flow has six steps not five.
    We have a common understanding of prioritizing. or, what a major change is versus a minor change; common goal and target for restoration SLA, so these are common things we have to have as core, but above and beyond that, by regional variance differentiation, you can have differences. So, there's core and the plus might be, for example, yes we have a chosen set of key performance indicators.
    A severity or priority one incident is defined this way and a goal is restoration within SLA target within 4 hours 80% of the time. Okay, that's a chosen KPI. everyone shares that one but you might have a half a dozen more metrics you want to record for your own personal basis you might decide your region's going to use one tool and another region another tool.
    That's possible. It's more expensive. What you've done there is determine that you're going to have both these tools kind of configured exactly the same way; but because you're using different technologies, you're going to have different procedures.
    So, Core plus gives you the sense of, you know, the base elements are core and common, but i can have variance above and beyond and then the other [xx] concept of common is really common, everything is standard, there is no deviation. Process rolls off the assembly line the same way every Every single time.
    Everything is equal, every thing is common across the entire scope of whatever you call your process of organization. one of the interesting things here is that you don't have to pick just one of these four levels, you really can process by process, have four .. different decisions- do your own thing, center of excellence, core plus, or standardize.
    So it's not just a statement, we're gonna have common and everything will be the same. That doesn't make any sense. It's not logical. Well it certainly seems easier to manage. Well, in a sense yes, but it's also more difficult to keep glued together just think about a process across multiple [xx] you got [xx] how do you keep that together its not impossible but it is definitely First Speaker: lot more work.
    So, you know, we think about things from a value cost and risk perspective. So in one organization, and this is specifically so for, lets call them engineering or architecture type processes.
    Second Speaker: Mm-hmm.
    First Speaker: What's the value of having a common engineering or architecture process across the US, Latin America, Australasia. You know, what's the value? It could be that you see that value, that you might decide, because that's a very tailored type of outcome, I want a unique solution You might choose to leave architecture processes at a very do-your-own-thing level; you might decide at availability capacity to leave those at a center of excellence; you give them some some base reports some templates for how to collect and aggregate capacity data and you might say OK, here is some guidance on a, let's say, I am thinking some examples here uh change management, concept.
    You know, we have to have these base core elements, but there are regional changes that might be able to be done regionally. so there is a slight variance of how you do regional or local change approvals verses changes that must go to the global change advisory board. But then if you are trying to hold together a common support organization, with a fall service desk, we had that conversation a couple of episodes ago.
    You need common prioritization, common support model, common queue system, common tool. Because you're literally gluing together this organization as one continuous support organization. So then those four examples you've made a choice based on value, cost and risk of having various levels of common.
    and we have a diagram that we'll put right in the show notes online so people can see this when it comes to these four types of process standardization. You took apart at a very fine level, because in my head I'm listening and picturing it. one level, center of excellence level for support. Change or lease having a core plus.
    And I think I can really get my hands around and the idea of regardless of where we are on the globe or [xx] from our support are almost assembly line like driven, because excellence and repeatable process I would think, I'm stretching Troy This is where Practitioner Radio gets dangerous. We'll probably be most important at the customer facing side, right?
    So the repeatable McDonald's experience. in fact that's the way we look at it and you think about it, its really only three customer facing processes and ideas in context. There is the service desk and the support which is what we just talked about. There's a request provisioning side of it, you know, front-ended by catalog or the service desk.
    And then there's strategic intake or demand And in tech we are looking for new customer requirements to understanding new markets new technical events you can take eventual of. Or else we he called it, "B-Y-O-D."
    Well, that's one way to go, yeah.
    You know those are [xx] customer facings. You might want to standardize those.
    But, a lot of the processes of the back-handing Especially when we get to, like,more of the design and strategy processes. Yeah. Those could have variances. Depending on, truly, your enterprise [xx]. strategy; or if you have one.
    Very few organization actually have an enterprise strategy; they might have an enterprise infastructure strategy across the globe that doesn't mean they have an enterprise application strategy right, and that is a variance there as well concept of common actually has to be looked at in varying levels.
    It's not, I think, accurate or even logical to assume thing across that span of control can be, you know, assembly line like standardized. It doesn't make sense from a value cost to risk perspective. Some things do. I mean literally some things, the risk of not having a standard approach, especially when you're in a shared services organization and you're trying to support a common customer across that organisation, you've gotta have it all glued together, and that's not just the internal organisation, but if you're, and you probably are going to be integrating suppliers Right, in various regions.
    Each of those suppliers must now integrate into your common management system and frame of reference. They can't have their own base for severity or priority definition. They have to share yours. Because when you bring in family members into your value system, they literally have to adopt your family morals, values and ideals to become a family member.
    No, and we talked at great length about the importance of suppliers and making them part of your family. And I will put a link because that was a really good show. I wish we had that one transcribed. I guess it's not to late. A global infrastructure standardization seems to almost the common play some in some folks.
    Because they do, they look at their infrastructure, whether it's completely internal to buildings or data centers they own, or they they work for the supplier, but either way they've thought very carefully about the approach to the infrastructure, what's involved in the infrastructure and I think part of that's because people just have this illusion that the widgets, the hardware, the Almost to make a klacklebargle, or somehow he's more easily controlled?
    I don't know, but when you said that it really made me think that Why is it because we always do have an infrastructure team, but we don't really look at these other teams and they integrate. do they ever sit down and talk about common. Well actually one thing that's important to understand- it is easier to standardize the non-human element.
    right so we know what it means to do data center consolidation, desktop image standardization. Well, until the machines talk back. Yeah. Enterprise application standardization and more and more of our applications are becoming standardized; what was kind of custom, if you had collaboration or a CRM tool; now we're all using the same one so there's fewer and fewer applications which are actually unique to each business unit and/or each region.
    So there's this growth towards standardization, which is being fueled by Cloud. Mm. You know, because that's a key note there. Standardization is key. But let's take that apart for about standardization Cloud and because i am also witnessing watching a lot of news around Cloud. There are people, I know these guy be aware of Matt Baron.
    You know, he was talking to me on the phone the other day, and he develops on the Service Now platform, and he needed so he just wrote an application on the platform, and just started using it; and then when he [xx] somebody doing this, "Oh, I wrote something; i started using it ."
    So, while the infrastructure of the platform itself was common, he was taking pieces and creating new things that really didn't fit into any of the process.
    And begin to have deviation again, right? Here's something that's [xx] taking a side note, but this is very interesting. I was talking to Ray Garrett, one of my co-workers. Love Ray, by the way. Oh, yes, that's right you're in the same city. Yeah. And she and I were talking about the, kind of the difference between the new ITSM tool philosophy and the pre [xx] post generation and before, you had a tool which would have a process and that process was very rigidly designed into the tool, so there was lot of guidance [xx] force you into doing unless you chose to break the back of the tool and make it do whatever you did before.
    It was hard. Though to do that you had to make some pretty willful [xx]. The new generation of tool, and these are her words, not mine. This is a quote of Rae[sp?]. Have no guard rails.
    Hmm. Right? They have, you know You're bowling and there is nothing in the gutter. Yeah. To keep the ball between the gutter. If there is a there is path but there is no guard rails. It will let you do any thing you choose to. It was actually easier in the new generation of platform as a service-type product to actually go anywhere you want to and this is where you do need to have the process and the human controls to make that sure people don't, when it's not required or not the ideal thing take off on their own path, some times it is in fine to be [xx] things sometimes it is not.
    Are your similar to the term anthrophy [sp?]. anthrophy [sp?] yes, any human system unless you coninue to add energy to actually fail. Yeah, so I was watching a special on television about how, it was on string theory so there. Laugh at me now. They were talking about on trivia and this idea of the error of time and how One of the ways we can measure time is the fact that things go from a state of consistency to a state of an inconsistancy.
    We can't measure, we percieve forward movement because we see things change.
    It unravels, yes.
    And it end up in my words, not the television show's, a hot mess. And it's funny because there are so - we're talking about common processes and your four levels here, whether they be standard or core plus, center of excellence or do your own thing. And at Subway's, you know, Tools have always gotten this, you know.
    Oh, this tool's better! You know, since it's newer and shinier, and everything else. Because it doesn't have the hangups of these other tools! But they just end up developing a different set of hang ups. In this case yes we have the ability to go much wider in our variance. Yeah. but in you know what nothing is ever static and that's a key point you made and new direction and improvement, every [xx] will basically die on the vine.
    Yeah. Right? You have to put it in the context of a continual service improvement or quality system approach. Because unless you do it doesn't remain relevant, it becomes static, it becomes old, it becomes useless and it dies. The entropy kills it. Yeah. even though it was theoretical physics I'm sitting in there watching that, thinking of Practitioner Radio, which is pretty Pretty crazy in itself.
    Made me think of Big Bang theory. No, No. Ah, Eldon, Sheldon, my friend. a guy named John Williasont [sp?] talking about devops, he mentioned Toyota and their processes he made a real interesting comment and I wanted to share it with you. But when they were interviewing, I can't pronounce the gentleman's name, but one of the Chairmans of Toyota, and they were allowing Americans to come in and see how they ran their plants and things.
    He says they can copy our processes all they want, they can't copy our culture. And discipline. And culture has a big deal to do with Whether who want common or not. Do you know its American to be common. Its not to say that [xx] common. Its not American to be common. or the same as. I think you're messing with my head because I'm American.
    What does that mean? It could be more of a western cultural thing. No, you're Canadian, for people who don't know Troy's Canadian which is what Americans pretend to be when they leave the country, what does that mean. Well I actually I am do that actually. Are you? Yes I am, But the reality is. There is a persona in the US, which values uniqueness above commonality.
    We don't want to be one of a large family context. We prefer to be unique. In fact it's almost non-American to be standard. Because there's this concept of kind of wild west, unique, on the cutting edge, entrepreneur, innovator. And you think, culturally in other parts of the world, that's, for lack of a better [xx] heresy I mean.
    Absolutely so the rights of individual outweigh the rights of the many in the U.S.. this is counter the spot conversation we've had before. But if you're in India, the rights of the many out weigh the rights of the few. Right? So when you're in the classic arranged marriage going to be arrange to be married to somebody, it's a family decision.
    Both families interview each other and the families decide whether the match is good. that would never fly in the US because the rights of the individual outweigh the rights of the many. In the US, the rights of the individual outweigh their rights. And this is probably true of Western culture in general.
    So there's this view of my rights are greater than the family culture I belong to. So, there's this move the individualism always. I want to be different and unique, stand out. Well, yeah, I couldn't get any more American. Except maybe if my B M I was made five points higher closer to ninety one, I'd be probably more American.
    But I. So ask yourself: does it appeal to you to basically follow the same path as other people? So, it comes back to our show about process standardization. You know, it's great. We've got these four levels of process standardization that we can apply to our different, you know, depends whether there be support or quest management, change, etc., but do we design or do we you know, you talked about continual service improvement.
    You know, at what point do we introduce a cultural aspect to these? And are these influenced by culture, or is culture or do we not even let that enter, I mean the process is the process. I mean obviously do your own thing.
    Well there is definitely a culture international application. Right. Because working on a global basis I've seen it many times. I've had the honor to be part of five different global initiatives. So one was a a major goods manufacturer which was based out of the UK had a major US operations, well, when you believe the friction between the two because the US will reject anything coming the UK was a tea party all over again, every single time any conversation [xx].
    Ah, familiar. Right. Another major initiative was started in the US and had a European specifically UK side of it, and there was this belief that nothing good could come out of the colonies. So it was like that was a major issue. in Asia, especially in the Indian culture, you can provide that rights of the many take precedent over the rights of the few, so there's not a major issue for compliance there.
    Right. In Latin America, because they're never rushed to do anything, they'll certainly say yes, they agree but it's always manana. In fact manana, tomorrow, never comes. So absolutely, culture has a major implication on acceptance of comment. There's a much higher willingness to accept comment in a dramatic culture then in the U.S., for example.
    Because, I would think, in, you know in a design and build project, if you're really focusing on being agile and scrummy and trying to get something done, The idea of do your own thing might make a lot of sense unless you're in a culture where they don't want to do their own thing because it doesn't feel natural.
    or it's too much risk, or the cost of variance is too unwieldy. Because do your own thing comes with two outcomes. It has three outcomes. It has a high tailored outcome, a highly tailored outcome, and that's a positive for some people. I get a unique experience every time I come to this thing. okay now.
    But it also means you have a higher variance of activity, because every place you do this you'll find it done differently and because you have a higher variance from a [xx] prospective, you're going to have high risk and high cost The more times you duplicate something, the willingness you have to live with for high variance high cost high risk.
    So you have to balance the value of uniqueness against the variance cost risk component. What our challenge is in for IT culture is that we are more on the do it your own way kind of concept. Almost everything is in that category. So we have multiple change processes, multiple ticketing processes, multiple inventory processes and we duplicate and make redundancy almost a way of life, which has a high cost, high variance, high risk.
    So there's some balance, we have to kind of swing the needle back in some areas. This also applies to services, by the way. Right, because you have a common hosting service but you might have a very unique desktop service in different regions. Yeah, and a lot of services that I, you know, from a technology standpoint subscribe to, offer me in the process of signing up for them, wildly different options that I'm willing to pay for, which is one of these kind of panaceas that we dream of when it comes to IT.
    You know, having the ability to say "well I demand 24 by 7 even though the rest of the company doesn't have it."
    When you were talking about this, I thought, I kind Should you almost as a human cultural process Geiger counter. Do you have a like listen and go "Okay, high variance, high cost and just like that's what you're thinking and then you listen to someone and go okay, standard and good, low cost, and repeatability, and consistency and, I mean, is that the way you think?
    I mean, you think in a way that I would love to learn how to think.
    Well, you've got to know the game you're in to play the game, right? So you've got to understand what are the expectations and the rules. So yeah, I mean, I help people understand what their decisions mean, that's primarily what I do. So, you know, this wonderful thing of uniqueness is great but you understand there's a cause and effect here.
    You can have uniqueness but this is what it means. high cost, high variance, high risk. And if the value of that outweighs the other three, wonderful! Stay the way you are. There's no reason to change. But if you can tolerate those three, and you look at it from the perspective, you've gotta make some changes, you have to come up with this continuum somehow to you earlier because you made me think of a non I T context, you're the one usually bringing these to my head, but this is a great kind of example of the core plus.
    McDonald Global McDonalds is Core Plus. Oh, yeah. Why do you think I say that? Oh, completely, because I can get my core food items, whether I'm in Brazil, France or Hong Kong. But what's really interesting is if you go to McDonald's in those places, they'll always have the [xx] which is the big mac but with a fish on top.
    Big mac with anchovies hmm, yum. Yeah. Well I don't know. I'm trying to think. I mean they just have the sandwiches, I'm like "Ah I wish they had that in America." But they always have my core stuff. It's because I feel safe. We've talked about me and when I was in Germany, just recently first thing I did was look for the McDonald's, right?
    I had to have something that made me feel safe. And to be honest it was french fries. Yeah, so they have this concept of core plus, right? As opposed to, you know, that gives you the variance, that kind of balance between standardized, which gives me better agencies better cost, but also better margins, because I can buy in volume.
    I can do things, and in a common way in bulk and build supplier models that allow me to optimize that. But I also had that variance as I need it. I mean, that's a really great example Troy have to put that on a slide deck because, you know, McDonald's Global is core plus. I mean, that is like the most perfect example.
    And maybe our listeners They are thinking about their process standardizations and how they look locally, may be we can not to borrow their concepts, I mean It definitely addresses the cultural issues we were talking about. Though people wanna feel like they have some basis of uniqueness right, that's the core human is that I want to be unique, I want to stand out, I don't want to be one of a crowd.
    Right. But can you find some middle ground where there's [xx] and that allows me [xx] above the [xx] of the unique variance versus its all just do it your own way everywhere because I can't bring anyone to agree that we should have common. Well, one place where Core Plus... I was just in the Midwest, and they have Tim Horton's there.
    for now, so you people successfully like driven your scurge through the border. For those of you who don't know, Tim Hortons is a coffee...how do you describe Tim Hortons to someone not from Canada?
    It's Canadian culture.
    Yeah, it's Canadian culture like, yeah, literally. But I was sitting there and I went through the drive through and it was all the same stuff you had in Canada. And I was like, make it a little American, offer me a doughnut with triple glaze or something.
    That 's standardized, that's a good example of standardized, but so is other coffee places, right?
    Starbucks doesn't vary no matter where you go it's the same thing.
    No, Starbucks is standardized, and they have the business model that allows them to do that and they optimized their profit and their margins because of it.
    All right, Center of Excellence, Core Plus Standard or do your own thing. I'm gonna do my own thing and say that it's time for Troy's Thunderbolt Tip of the Day.
    Okay, Chris, remember that a common process can be defined at many different levels of commonality. It's important to take a decision or make a decision based on the value cost of risk of just what has to be standardized and what could be core plus. Don't assume everythinguniversally the same level of consistency.
    Nice. Consistently quality, good stuff. Thank you, Troy DuMoulin. I'll see you in two weeks. Take care. life.
    Welcome to another edition of Practitioner Radio. Pink Elephants podcast for the IT management community. Welcome to Practitioner Radio: Pink Elephants Podcast. IT service management, IT management, just the IT community, everybody. It's even good for people not in IT. We've got a couple of HR folks out there.
    Hey, this is Chris Kensy (sp?) episode 30. Troy, 30. 30, can you believe it? Wow. 30, 30, that is 15 hours of practitioner radio. Well, some times it feels like 15 hours, and sometimes a [xx] just a few minutes minutes ago so. So, this wee on the This is 30 minutes in ITSM audio.
    We've got global processes; we're gonna talk about that.
    We've been inundated -different parts of the globe you were in Asia and I was, I don't know where I was. And we got some actual mail. So real quick, for me I met somebody who is a big fan of yours, Troy. His name is Russell. He works at a company called Manta. I was out speaking in he says, "I listen to you guys all the time; even my family listens to you." I feel sorry for them.
    But, big hello to Russell.
    We're home entertainment now Do you believe it? Actually I can, I see what's on television. Come on. What families say. Hey Russell, how are you doing? And then You were just in Asia and then you got a couple of pieces of fan mail while you were there, you wanna talk about those? Well yeah, one was about, there was a question about key performance indicators and critical success factors and I said we could address it briefly in the next show, though that's not the topic for today.
    And another one was that, hey! We're on iTunes, right? So, one of the things you and I have forgotten to do, if we keep talking about our shows and our show notes, and it's in the show notes, but we never tell them where it is, where are the show notes. Because we always assume they actually get there from one of our two blogs, either your blog or my blog.
    Yes.
    And that's of course where the show notes are. But if you're on iTunes and you've subscribed to Practitioner Radio, we've never actually said that.
    No.
    So shame on us.
    We're in IT. We don't communicate.
    So if anyone's looking for the show notes servicesphere.com or pinkelephant.com and look for the blogs. The big red button that says don't panic, that's my hitchhiker's guide to the galaxy blog and you can get from there.
    Yeah, so if you want to go back because I actually had a request I didn't mention yet on air, just because I was actually to the point where I get too many requests about Practitioner Radio. All of the show notes are available in a couple of different places. So you can go to Vimeo, V-I-M-E-O. You can find them there if you just search for Practitioner Radio.
    If you go to Sound Cloud all the show notes are always there, just search for Practitioner Radio by [xx].com or Pink Elephant and the blog for Troy, the show notes are there. And just recently some people have noticed, thank you For those of you sending me emails saying thank you. All of our shows are actually transcribed.
    So if you can't get an episode of Practitioner Radio... or you just don't have time to listen or you're on a plane disconnected, you can actually read the transcriptions. So I know I post the transcription on Sound Cloud and on my blog. I don't know, Troy what's going on, but there's lots of places.
    So thank you for the feedback. Thank you for letting us know that not everyone knows where these things are. It's important that people know how to get to them. As far as the KPI question, Troy, we'll keep that for next week and try to address that. Because that;s SLA's [xx] yes, critical success factors and how do they all work together.
    That might be up, that's the next show.
    Well, there ya go.
    So, a big thank you to Mark from The phone for defining episode 31. So, your definition on common, I doubt is the same as mine.
    You know, this is the thing about having a common language and some people say that's the best element of having a framework- that we can actually have a common definition of terms. This actually became very interesting because I had if that's true with all and this is a global organization and they wanted to talk about deploying global processes and I said, OK, that's cool, a challenge, but cool what do you mean by the word "common"?
    And I proceeded to give them four different definitions of what common can mean. Well, actually three. There's a fourth which, you know, you can't ignore either. So when you think about common, and we're going to put some discussions or a picture about how this might be received in the show notes but first of all there's the not common- do your own thing, everybody basically does their own process the way they want to do it.
    But then there's another concept that people talk about a lot which is, we're gonna create this center of excellence and what is a center of excellence? Well think about a small group of people who get together and they collect collateral, they collect documents, templates, and they create really kind of a repository of IP, knowledge documentation, and this might be an internal process engineering group, an ITSM group whatever.
    But what the idea here is that you have, this common resource pool of information, and if you're so inclined you can go and you can use that information, use that content, so at least there is a same gene or DNA pool where various parts of the organisation polls their stuff [xx] now that doesn't guarantee you a [xx], but at least it's the same family background, so you can trace your ancestry back to this center of excellence.
    feel uncontrolled because of unexcess of works, OK they kind of moving upon a continue a comment you have something called Core Plus, or Core and Additional. And I like to think of this as, okay, there's these base elements that we must all agree on. Right, so we all agree that the process flow has six steps not five.
    We have a common understanding of prioritizing. or, what a major change is versus a minor change; common goal and target for restoration SLA, so these are common things we have to have as core, but above and beyond that, by regional variance differentiation, you can have differences. So, there's core and the plus might be, for example, yes we have a chosen set of key performance indicators.
    A severity or priority one incident is defined this way and a goal is restoration within SLA target within 4 hours 80% of the time. Okay, that's a chosen KPI. everyone shares that one but you might have a half a dozen more metrics you want to record for your own personal basis you might decide your region's going to use one tool and another region another tool.
    That's possible. It's more expensive. What you've done there is determine that you're going to have both these tools kind of configured exactly the same way; but because you're using different technologies, you're going to have different procedures.
    So, Core plus gives you the sense of, you know, the base elements are core and common, but i can have variance above and beyond and then the other [xx] concept of common is really common, everything is standard, there is no deviation. Process rolls off the assembly line the same way every Every single time.
    Everything is equal, every thing is common across the entire scope of whatever you call your process of organization. one of the interesting things here is that you don't have to pick just one of these four levels, you really can process by process, have four .. different decisions- do your own thing, center of excellence, core plus, or standardize.
    So it's not just a statement, we're gonna have common and everything will be the same. That doesn't make any sense. It's not logical. Well it certainly seems easier to manage. Well, in a sense yes, but it's also more difficult to keep glued together just think about a process across multiple [xx] you got [xx] how do you keep that together its not impossible but it is definitely First Speaker: lot more work.
    So, you know, we think about things from a value cost and risk perspective. So in one organization, and this is specifically so for, lets call them engineering or architecture type processes.
    Second Speaker: Mm-hmm.
    First Speaker: What's the value of having a common engineering or architecture process across the US, Latin America, Australasia. You know, what's the value? It could be that you see that value, that you might decide, because that's a very tailored type of outcome, I want a unique solution You might choose to leave architecture processes at a very do-your-own-thing level; you might decide at availability capacity to leave those at a center of excellence; you give them some some base reports some templates for how to collect and aggregate capacity data and you might say OK, here is some guidance on a, let's say, I am thinking some examples here uh change management, concept.
    You know, we have to have these base core elements, but there are regional changes that might be able to be done regionally. so there is a slight variance of how you do regional or local change approvals verses changes that must go to the global change advisory board. But then if you are trying to hold together a common support organization, with a fall service desk, we had that conversation a couple of episodes ago.
    You need common prioritization, common support model, common queue system, common tool. Because you're literally gluing together this organization as one continuous support organization. So then those four examples you've made a choice based on value, cost and risk of having various levels of common.
    and we have a diagram that we'll put right in the show notes online so people can see this when it comes to these four types of process standardization. You took apart at a very fine level, because in my head I'm listening and picturing it. one level, center of excellence level for support. Change or lease having a core plus.
    And I think I can really get my hands around and the idea of regardless of where we are on the globe or [xx] from our support are almost assembly line like driven, because excellence and repeatable process I would think, I'm stretching Troy This is where Practitioner Radio gets dangerous. We'll probably be most important at the customer facing side, right?
    So the repeatable McDonald's experience. in fact that's the way we look at it and you think about it, its really only three customer facing processes and ideas in context. There is the service desk and the support which is what we just talked about. There's a request provisioning side of it, you know, front-ended by catalog or the service desk.
    And then there's strategic intake or demand And in tech we are looking for new customer requirements to understanding new markets new technical events you can take eventual of. Or else we he called it, "B-Y-O-D." Well, that's one way to go, yeah.
    You know those are [xx] customer facings. You might want to standardize those.
    But, a lot of the processes of the back-handing Especially when we get to, like,more of the design and strategy processes. Yeah. Those could have variances. Depending on, truly, your enterprise [xx]. strategy; or if you have one.
    Very few organization actually have an enterprise strategy; they might have an enterprise infastructure strategy across the globe that doesn't mean they have an enterprise application strategy right, and that is a variance there as well concept of common actually has to be looked at in varying levels.
    It's not, I think, accurate or even logical to assume thing across that span of control can be, you know, assembly line like standardized. It doesn't make sense from a value cost to risk perspective. Some things do. I mean literally some things, the risk of not having a standard approach, especially when you're in a shared services organization and you're trying to support a common customer across that organisation, you've gotta have it all glued together, and that's not just the internal organisation, but if you're, and you probably are going to be integrating suppliers Right, in various regions.
    Each of those suppliers must now integrate into your common management system and frame of reference. They can't have their own base for severity or priority definition. They have to share yours. Because when you bring in family members into your value system, they literally have to adopt your family morals, values and ideals to become a family member.
    No, and we talked at great length about the importance of suppliers and making them part of your family. And I will put a link because that was a really good show. I wish we had that one transcribed. I guess it's not to late. A global infrastructure standardization seems to almost the common play some in some folks.
    Because they do, they look at their infrastructure, whether it's completely internal to buildings or data centers they own, or they they work for the supplier, but either way they've thought very carefully about the approach to the infrastructure, what's involved in the infrastructure and I think part of that's because people just have this illusion that the widgets, the hardware, the Almost to make a klacklebargle, or somehow he's more easily controlled?
    I don't know, but when you said that it really made me think that Why is it because we always do have an infrastructure team, but we don't really look at these other teams and they integrate. do they ever sit down and talk about common. Well actually one thing that's important to understand- it is easier to standardize the non-human element.
    right so we know what it means to do data center consolidation, desktop image standardization. Well, until the machines talk back. Yeah. Enterprise application standardization and more and more of our applications are becoming standardized; what was kind of custom, if you had collaboration or a CRM tool; now we're all using the same one so there's fewer and fewer applications which are actually unique to each business unit and/or each region.
    So there's this growth towards standardization, which is being fueled by Cloud. Mm. You know, because that's a key note there. Standardization is key. But let's take that apart for about standardization Cloud and because i am also witnessing watching a lot of news around Cloud. There are people, I know these guy be aware of Matt Baron.
    You know, he was talking to me on the phone the other day, and he develops on the Service Now platform, and he needed so he just wrote an application on the platform, and just started using it; and then when he [xx] somebody doing this, "Oh, I wrote something; i started using it ." So, while the infrastructure of the platform itself was common, he was taking pieces and creating new things that really didn't fit into any of the process.
    And begin to have deviation again, right? Here's something that's [xx] taking a side note, but this is very interesting. I was talking to Ray Garrett, one of my co-workers. Love Ray, by the way. Oh, yes, that's right you're in the same city. Yeah. And she and I were talking about the, kind of the difference between the new ITSM tool philosophy and the pre [xx] post generation and before, you had a tool which would have a process and that process was very rigidly designed into the tool, so there was lot of guidance [xx] force you into doing unless you chose to break the back of the tool and make it do whatever you did before.
    It was hard. Though to do that you had to make some pretty willful [xx]. The new generation of tool, and these are her words, not mine. This is a quote of Rae[sp?]. Have no guard rails.
    Hmm. Right? They have, you know You're bowling and there is nothing in the gutter. Yeah. To keep the ball between the gutter. If there is a there is path but there is no guard rails. It will let you do any thing you choose to. It was actually easier in the new generation of platform as a service-type product to actually go anywhere you want to and this is where you do need to have the process and the human controls to make that sure people don't, when it's not required or not the ideal thing take off on their own path, some times it is in fine to be [xx] things sometimes it is not.
    Are your similar to the term anthrophy [sp?]. anthrophy [sp?] yes, any human system unless you coninue to add energy to actually fail. Yeah, so I was watching a special on television about how, it was on string theory so there. Laugh at me now. They were talking about on trivia and this idea of the error of time and how One of the ways we can measure time is the fact that things go from a state of consistency to a state of an inconsistancy.
    We can't measure, we percieve forward movement because we see things change.
    It unravels, yes.
    And it end up in my words, not the television show's, a hot mess. And it's funny because there are so - we're talking about common processes and your four levels here, whether they be standard or core plus, center of excellence or do your own thing. And at Subway's, you know, Tools have always gotten this, you know.
    Oh, this tool's better! You know, since it's newer and shinier, and everything else. Because it doesn't have the hangups of these other tools! But they just end up developing a different set of hang ups. In this case yes we have the ability to go much wider in our variance. Yeah. but in you know what nothing is ever static and that's a key point you made and new direction and improvement, every [xx] will basically die on the vine.
    Yeah. Right? You have to put it in the context of a continual service improvement or quality system approach. Because unless you do it doesn't remain relevant, it becomes static, it becomes old, it becomes useless and it dies. The entropy kills it. Yeah. even though it was theoretical physics I'm sitting in there watching that, thinking of Practitioner Radio, which is pretty Pretty crazy in itself.
    Made me think of Big Bang theory. No, No. Ah, Eldon, Sheldon, my friend. a guy named John Williasont [sp?] talking about devops, he mentioned Toyota and their processes he made a real interesting comment and I wanted to share it with you. But when they were interviewing, I can't pronounce the gentleman's name, but one of the Chairmans of Toyota, and they were allowing Americans to come in and see how they ran their plants and things.
    He says they can copy our processes all they want, they can't copy our culture. And discipline. And culture has a big deal to do with Whether who want common or not. Do you know its American to be common. Its not to say that [xx] common. Its not American to be common. or the same as. I think you're messing with my head because I'm American.
    What does that mean? It could be more of a western cultural thing. No, you're Canadian, for people who don't know Troy's Canadian which is what Americans pretend to be when they leave the country, what does that mean. Well I actually I am do that actually. Are you? Yes I am, But the reality is. There is a persona in the US, which values uniqueness above commonality.
    We don't want to be one of a large family context. We prefer to be unique. In fact it's almost non-American to be standard. Because there's this concept of kind of wild west, unique, on the cutting edge, entrepreneur, innovator. And you think, culturally in other parts of the world, that's, for lack of a better [xx] heresy I mean.
    Absolutely so the rights of individual outweigh the rights of the many in the U.S.. this is counter the spot conversation we've had before. But if you're in India, the rights of the many out weigh the rights of the few. Right? So when you're in the classic arranged marriage going to be arrange to be married to somebody, it's a family decision.
    Both families interview each other and the families decide whether the match is good. that would never fly in the US because the rights of the individual outweigh the rights of the many. In the US, the rights of the individual outweigh their rights. And this is probably true of Western culture in general.
    So there's this view of my rights are greater than the family culture I belong to. So, there's this move the individualism always. I want to be different and unique, stand out. Well, yeah, I couldn't get any more American. Except maybe if my B M I was made five points higher closer to ninety one, I'd be probably more American.
    But I. So ask yourself: does it appeal to you to basically follow the same path as other people? So, it comes back to our show about process standardization. You know, it's great. We've got these four levels of process standardization that we can apply to our different, you know, depends whether there be support or quest management, change, etc., but do we design or do we you know, you talked about continual service improvement.
    You know, at what point do we introduce a cultural aspect to these? And are these influenced by culture, or is culture or do we not even let that enter, I mean the process is the process. I mean obviously do your own thing.
    Well there is definitely a culture international application. Right. Because working on a global basis I've seen it many times. I've had the honor to be part of five different global initiatives. So one was a a major goods manufacturer which was based out of the UK had a major US operations, well, when you believe the friction between the two because the US will reject anything coming the UK was a tea party all over again, every single time any conversation [xx].
    Ah, familiar. Right. Another major initiative was started in the US and had a European specifically UK side of it, and there was this belief that nothing good could come out of the colonies. So it was like that was a major issue. in Asia, especially in the Indian culture, you can provide that rights of the many take precedent over the rights of the few, so there's not a major issue for compliance there.
    Right. In Latin America, because they're never rushed to do anything, they'll certainly say yes, they agree but it's always manana. In fact manana, tomorrow, never comes. So absolutely, culture has a major implication on acceptance of comment. There's a much higher willingness to accept comment in a dramatic culture then in the U.S., for example.
    Because, I would think, in, you know in a design and build project, if you're really focusing on being agile and scrummy and trying to get something done, The idea of do your own thing might make a lot of sense unless you're in a culture where they don't want to do their own thing because it doesn't feel natural.
    or it's too much risk, or the cost of variance is too unwieldy. Because do your own thing comes with two outcomes. It has three outcomes. It has a high tailored outcome, a highly tailored outcome, and that's a positive for some people. I get a unique experience every time I come to this thing. okay now.
    But it also means you have a higher variance of activity, because every place you do this you'll find it done differently and because you have a higher variance from a [xx] prospective, you're going to have high risk and high cost The more times you duplicate something, the willingness you have to live with for high variance high cost high risk.
    So you have to balance the value of uniqueness against the variance cost risk component. What our challenge is in for IT culture is that we are more on the do it your own way kind of concept. Almost everything is in that category. So we have multiple change processes, multiple ticketing processes, multiple inventory processes and we duplicate and make redundancy almost a way of life, which has a high cost, high variance, high risk.
    So there's some balance, we have to kind of swing the needle back in some areas. This also applies to services, by the way. Right, because you have a common hosting service but you might have a very unique desktop service in different regions. Yeah, and a lot of services that I, you know, from a technology standpoint subscribe to, offer me in the process of signing up for them, wildly different options that I'm willing to pay for, which is one of these kind of panaceas that we dream of when it comes to IT.
    You know, having the ability to say "well I demand 24 by 7 even though the rest of the company doesn't have it."When you were talking about this, I thought, I kind Should you almost as a human cultural process Geiger counter. Do you have a like listen and go "Okay, high variance, high cost and just like that's what you're thinking and then you listen to someone and go okay, standard and good, low cost, and repeatability, and consistency and, I mean, is that the way you think?
    I mean, you think in a way that I would love to learn how to think.
    Well, you've got to know the game you're in to play the game, right? So you've got to understand what are the expectations and the rules. So yeah, I mean, I help people understand what their decisions mean, that's primarily what I do. So, you know, this wonderful thing of uniqueness is great but you understand there's a cause and effect here.
    You can have uniqueness but this is what it means. high cost, high variance, high risk. And if the value of that outweighs the other three, wonderful! Stay the way you are. There's no reason to change. But if you can tolerate those three, and you look at it from the perspective, you've gotta make some changes, you have to come up with this continuum somehow to you earlier because you made me think of a non I T context, you're the one usually bringing these to my head, but this is a great kind of example of the core plus.
    McDonald Global McDonalds is Core Plus. Oh, yeah. Why do you think I say that? Oh, completely, because I can get my core food items, whether I'm in Brazil, France or Hong Kong. But what's really interesting is if you go to McDonald's in those places, they'll always have the [xx] which is the big mac but with a fish on top.
    Big mac with anchovies hmm, yum. Yeah. Well I don't know. I'm trying to think. I mean they just have the sandwiches, I'm like "Ah I wish they had that in America." But they always have my core stuff. It's because I feel safe. We've talked about me and when I was in Germany, just recently first thing I did was look for the McDonald's, right?
    I had to have something that made me feel safe. And to be honest it was french fries. Yeah, so they have this concept of core plus, right? As opposed to, you know, that gives you the variance, that kind of balance between standardized, which gives me better agencies better cost, but also better margins, because I can buy in volume.
    I can do things, and in a common way in bulk and build supplier models that allow me to optimize that. But I also had that variance as I need it. I mean, that's a really great example Troy have to put that on a slide deck because, you know, McDonald's Global is core plus. I mean, that is like the most perfect example.
    And maybe our listeners They are thinking about their process standardizations and how they look locally, may be we can not to borrow their concepts, I mean It definitely addresses the cultural issues we were talking about. Though people wanna feel like they have some basis of uniqueness right, that's the core human is that I want to be unique, I want to stand out, I don't want to be one of a crowd.
    Right. But can you find some middle ground where there's [xx] and that allows me [xx] above the [xx] of the unique variance versus its all just do it your own way everywhere because I can't bring anyone to agree that we should have common. Well, one place where Core Plus... I was just in the Midwest, and they have Tim Horton's there.
    for now, so you people successfully like driven your scurge through the border. For those of you who don't know, Tim Hortons is a coffee...how do you describe Tim Hortons to someone not from Canada?
    It's Canadian culture.
    Yeah, it's Canadian culture like, yeah, literally. But I was sitting there and I went through the drive through and it was all the same stuff you had in Canada. And I was like, make it a little American, offer me a doughnut with triple glaze or something.
    That 's standardized, that's a good example of standardized, but so is other coffee places, right?
    Starbucks doesn't vary no matter where you go it's the same thing.
    No, Starbucks is standardized, and they have the business model that allows them to do that and they optimized their profit and their margins because of it.
    All right, Center of Excellence, Core Plus Standard or do your own thing. I'm gonna do my own thing and say that it's time for Troy's Thunderbolt Tip of the Day.
    Okay, Chris, remember that a common process can be defined at many different levels of commonality. It's important to take a decision or make a decision based on the value cost of risk of just what has to be standardized and what could be core plus. Don't assume everythinguniversally the same level of consistency.
    Nice. Consistently quality, good stuff. Thank you, Troy DuMoulin. I'll see you in two weeks. Take care. life.

    # vimeo.com/47252779 Uploaded 151 Plays / / 0 Comments Watch in Couch Mode

  3. Show Notes and Links:
    servicesphere.com/blog/2012/7/9/justifying-service-process-improvement-practitioner-radio-ep.html

    Show Notes:
    US Heat Wave
    Service Owner? Episode 28
    Justifying the investment in ITSM improvement?!
    Qualitative Examples vs Quantified Proof
    Pink Leadership Forum 2012 (PDF Brochure)
    The formula for investment, is based in current REALITY
    What are your CURRENT COSTS for service…come on…tell me….
    Pink Elephant Asia and TROYS PERSONAL MESSAGE
    What is the catalyst for Change?
    What is the strategic goal?
    Cobit Management Guidelines
    Can you quantify investment, just by cutting down on meetings?
    80% of the time to fix something is finding out what happened.
    How long does it take a knowledge today to create?
    The worlds most advanced monitoring system for your network? Your customers.
    Risky Business, is nothing new.
    Made to Order (The Demand Show)

    The Executive Check List:
    • How does it benefit the business?:
    • Link To Strategic Goals?
    • Improved Productivity?
    • Reduction of risk of current practices?
    • Improved efficiencies
    • Return on investment?
    • Reduction of cost?

    Show Transcription:
    Welcome to another edition of Practitioner Radio, Pink Elephant's podcast for the IT management community. Welcome to Practitioner Radio Episode 29. Justifying this service and process improvement, Pink Elephant's podcast for the IT service management, IT management community. Hey, it's Chris Dancy, I'm here with.

    Troy DuMoulin. Hey Chris, how you doing?

    Doing good, doing good. We were just cross continental, now we're back together, we're on the state side, and everything's good?

    Yes, in fact, are you caught up in this heatwave? Like, we're getting extraordinary temperatures here, up in Canada. Fucking, I mean, 40 Celsius, so that's got to be like 90 something Fahrenheit. And we have record breaking temperatures all over the country, as you know, Colorado is ablaze as we speak, I can add you know, is it affecting you?

    And I'm like, well, you can actually see the fire from like different parts, and they're like, how is that possible, i'm like, well, mountains are vast. Well yeah.
    I can actually see it.

    I was going to ask you, because I've had several Pinkers are connected in Denver as well, as you know.

    Yeah, we've, there's a big Pink family here in Denver, in Colorado. Well, best of fortune with that. I know that it's starting to get under control so that's good.

    Yeah, so it'll all sort itself out. Episode twenty-eight seems to be wildly popular with people. People enjoy the idea of a service owner. I know I've been using it in my daily work, but today we're actually going to take on something a little bit along same lines but basically justifying service and process improvement we've got executive checklists, a bunch of other things we're going to talk about.

    To get things moving along here, justifying That's a big word, I mean, we'd almost need to look that up.

    Why should I do this, Chris? Why should I spend the money? Why would I even bother changing anything? You know? that's the key question, we get that often, why should we entertain anything different then we're doing today. You gonna have to have decent answers for that. Eventually if you are in this business and you're espousing improvement of any kind, you've got to show some justification for it.

    Right, some return on investment, some productivity lift, efficiency gain, use whatever buzz word you want, you've got to show that tomorrow will be better than today, somehow.

    Oh yeah, I think that whole concept as far as I'm concerned has really started out with "Annie".

    Sun will come out tomorrow. See now you're singing, last time I sung. Alright, so this comes on I think a couple of different levels. We've learned over our 29 this a practice of getting and buying at all different levels looking at a service organization service management office.. we talked about the idea of never use the word outsourcing and partnering and but justifying and getting It's a big deal, because you really need to make, I would think different types of justifications, so almost like views on a service catalogs you would need views on justification.

    And some people are fine with qualitative examples some people are not they need quantified proof, right, show me then the numbers, the analysis, the data. So you've got to be able to come up with both the fuzzy, warm, and scenario-based, qualitative examples, but also really got to get to the point you can get some quantified data going too.

    So that's depending on your personality.

    The overly qualified consultants over a pink .And, by the way, good luck. We'll talk before your event in Arizona. Are you guys ever when you come in To help an organization, are you guys ever asked, help us justify this?

    Oh, absolutely, absolutely, in fact, it's this kind of viewpoint, you guys have been doing this for a long in time so you'll be able to tell me what's the ROI, the return on investment, of implementing these good practices. You know, iTol, whatever framework you choose. And I have to ask some hard questions in return.

    Because first of all, for the listeners, ROI is a financial calculation, right, and that is, what will I get based on the changes that I'm going to implement that will be better off than I am today. So that's the base premise, but that is a calculation that starts with the benefits divided by the current cost.

    All right, so what will be the extrapolated benefit divided by what my current reality is. But the reality in our experience is, most organizations are not In a place, or mature enough, or haven't stood on the scale of reality to say what is current cost You know, statements, you can say "Well, we can become more productive and we'll reduce this and we'll improve that and we'll have less incidents and have lower down time" and all of these things.

    but, those are all relatively true. Based on experience, qualitative experience. But if I'm going to then, give you quantified, I have first of all figure out what the cost of the current scenario is, and then extrapolate those benefits into an improvement on current cost. But Chris, in your experience, how many people have a And along even the current cost of doing business.

    No and I think one of the things that I've seen happen at conferences over the past eighteen months is, I don't remember who it was, maybe it was Patrick from Hornville, I can't remember who it was. I'm sorry if I'm giving credit away, someone will email me and tell me I did it wrong, but he always says, can anyone in here tell me how much it costs you to support an email user.

    And no one raises their hand, right? So, how much for the hosting, and the infrastructure and the actual support personnel You just looking at some thing simple as how much a person sending a e-mail which is gonna IT 101. So there seems to be a trend toward, and I'm seeing this more and more on the blogs, people wanting to talk about financial management.

    I know that's not where we are today but I think maybe that might be a good topic for the future.

    Well that's basically because anything you do should be based on good financial decision making, right? So you have to have some knowledge of your current financially to make any relevant business decisions about it. But they expect the consultant walking in, the vendor with the software tool, to basically have the magic wand in all the data from all the other organizations that are somehow better and have a better understanding and say here's the ROI.

    There are ways to get there. We're going to talk about that. But that's not the only thing we can talk about relative to justification. So what are some quick wins, low hanging fruit when talking about looking at things you should measure before, we need to understand what we are measuring before we can help in justifying and show some returning investment.

    Are there any things you kind of see in every organization as a start before we get into the unique snowflake scenarios? Yeah, well this actually coincides with a presentation I'm delivering in about a week and a half at Pink Asia, which is an event in Malaysia and Singapore. I got to be part of that event two years ago.Thats right .Top notch.

    Yeah its a good time, I'm looking forward to it. I'm looking forward to meet any listeners out there. I'll stop by and say hi. But the session I'm doing is going through this kind of executive checklist. These are the things you got to cover and make sure tie into to make relevant sense to anyone.

    The first thing, though, we have to kind of get to grips with is, people don't typically change or want to change until their current world no longer fits them, right? Status quo is no longer viable. There's been crisis some catalyst, whether it's positive or negative, to basically say what worked today won't work tomorrow.

    We've got to do something. So, a decision has to be made first of all that status quo is no longer viable. First thing you have to figure out and hang your hat on and figure out what it is, that urgency, driver for you. And before you even begin presenting data you have to look for the catalyst, right, that could be an upcoming merger, that could be..

    Cutbacks..

    Cutbacks, could be. You've had several major business outages in the last week and you can no longer tolerate current state because you you are about to have your job handed to you so there is some catalyst who has to shake things up.

    That's pretty scary that's almost like waiting until you have to but think about how often do we We should get on a scale right?

    *laughs*

    sorry, i know sorry that will be the last, it takes real courage to Well it certainly does.

    Some navel gazing.

    Yes.

    Well if you can even get past her navel, i mean, i'm sorry.

    So, you know you have to be willing to step on the scale, first. And there's going to be some driver, whether you just had a mini stroke or your doctor basically said, "shape up or you're shipping out."

    Yep.

    Right? you gotta find that, yeah because urgency this is John Cordor speaking here Professor Cordor he says no one's gonna move out after Unless you can get a emotional urgency tied to your change, so where's the catalyst? Figure it out, and if you don't have one, you may not be ready for this.

    The catalyst, starting at that point, with this checklist, it almost makes me Do we gleed with, sounds like we're leading with the soft and fuzzy, the emotional, the heart, over the hardcore numbers. Because we need to get to the hardcore number.

    Yeah. This is simply the thing that makes people believe something change is necessary. Now you've got to actually prove change would be better. That's where we get into the justification. But you can't even get their attention and time of day until there's a common belief change is required. Okay.

    All right.

    So let's assume there's some catalyst like we've just described. Now we got to do some linking of this potential improvement, whether it's a service offering we're improving, or a process, which you know we've talked in the past processes are just services with a different name. Professional services.

    We have to first of all figure out we don't do anything in IT for no reason.

    Right.

    There's some basis. We're a service organization within a bigger service ecosystem called the business. So what business objectives, strategic goals, whether that's a new market penetration, improving customer satisfaction, improving cost reduction, new agility going into new technologies, or market spaces, new platforms, what business goals can we draw and grab on to and link whatever service or process of improvement we're going to do.

    Now, that's a little bit challenging sometimes because to get from an operational improvement of a process up to a business goal, you need a couple of linking artifacts and our deliverables on a strategic and governance level. From business perspective, I would hope to find IT goals kind of mirroring or matching those, so you know, using the balance score card.

    Financial, goals, customer goals, internal maturity goals, innovation and agility goals. Right? And then From there we would say, from these goals this is the operating model conversation we've had before. We've got to have these capabilities in place. And some of these capabilities are project management, plan build.

    Some of them are architecture, some of them are management like the change or incident conversation. But we should be to link the operational goals to the operating capabilities. To the IT strategic goals to the business goals. There's this kind of cascade. Now that might sound difficult for an organization that's kind of starting this net new, but I'll give you a tip.

    It's already documented for you. Go to COBIT, look up the Management Guidelines document from version 4.1 it's still there, and it has it all mapped out in the appendix.

    Really?

    Business schools right down to the operational process level goals.

    All right, say that one more time, where do we go?

    The ISASA website, and then look for the document called the Management Guidelines, and from that document, you'll be an appendix, which is this whole business value linkage.

    Wow. All right, Ross, throw us a mini thunderbolt, just real quiet, real quiet thunderbolt. All right, that's cool. I'll put a link to that in the show notes. I didn't know such a thing existed.

    So now I can talk strategically how my little thing down here, this little dial I'm gonna turn down here to left is actually going to impact something up there at the top right.

    Yup.

    So now enable the strategic goal again. That's one, step one. Checklist. Done. Now checklist, part one, I'm done then I have to think about another way you look at it is productivity. How much time to we spend in meetings, Chris, that we think we could be somewhere else and be using our time much more efficiently?

    I think Human Nature
    99 .9% of the time I'm at a meeting I'm thinking about being someplace else and being productive.

    Most long, drawn out meetings are a huge waste of productivity and they usually have to be long huge attendance because we have very little formality in our practices we haven't got sources of true documentation to rely on a configuration that is drawn out to check and validate information from.

    So we've got to walk in our corporate knowledge into these meetings and have big long drawn out conversations because of basically lack of mature practice. So let's take change management for a little moment. Without that CMDB conversation where I can say, if I make the change to this application, here is the upstream and downstream impact I gotta literally walk my CMDB into the room.

    And that's probably a stakeholder from every domain. And now because I haven't got any release assurance before this production change meeting. I'm asking questions like, did I do enough testing?, did I do enough training?, did I talk to the right people?, Well, there's a long, drawn out cab meeting with 20 people plus in it, and some company will actually have 2 of these a week.

    because they have so much production change going on. Let's say, if I make some improvements to knowing where things were, documenting my environment, improving improving the way that we handle changes in general I could probably shrink that meeting down to half, and only have half of the people necessary I do today.

    So, if I take the salaries of the individual people that I got in this meeting, and they're going to be high paid, I times that by the meeting time duration and how many of these meetings I've got per week. I've got a pretty big number and I could say and share with an organization and I can reduce this meeting by third or 50% here's the productivity gain.

    You've got to talk in that kind of language, productivity. Right. So that's another idea.

    No I mean that makes sense, because there are a lot of things that we and measure if we look at the time that you spend doing it. Was it a conference call like you said? Was it a meeting? How long did it take you to actually research. So a lot of times I'm asked to create something.

    Well, the time to actually create something for me as a knowledge worker, you know, between you and me through and So you know the people who listen to the show. It's relatively small. You know what takes me time, looking for the information to create that. You have hit a key point here. I had some one quote about this.

    I don't know where they got the statistic but they said 80% of the time to fix something is in discovering what broke.

    Yeah, it takes me no time to do things. It takes me all the time to be able to do things. And I can measure that. If my boss said to me, Chris, that was a great webinar, how long did it take you to do it? Well it took me an hour to deliver it. It took me about three hours to create it. But it took me about 24 business hours to research it.

    And people only eat the one hour. And before the internet, it would have Taking a lot longer, right? So at least we've got improvement of data sources there.

    Yea, yea. Sorry, go ahead. I was, wanted to jump on your quantify wagon.

    Yep. You can quantify product productivity gains. But you have to start expressing the quantified cost of current productivity. If you've got a lot of people doing manual labor, and you are evaluating that into the price of the saw per year thinking about purchasing which will automate i will take good example of would be if I look at how I worked just 5 or 6 years ago before I had BoxNet, GoogleDocs, DropBox, I would actually have to make sure that my laptop was authenticated and signed in, you know, remotely or however, to a network, and then I would then have to go searching through file systems and folders for documents and things.

    Now, and when I find those you might have to get a local copy and then if I left my place where I was working I'd have to sync it to my laptop. So that's time I could actually measure. But now I look at something, you know, how much it would cost our organization to buy network collaboration files like Dropbox or Boxnet or something.

    Well gosh, it was $2,000. Yeah, but you know what, I don't spend an hour every week before I head out on the road, syncing my documents.

    That's a good example. Let me give you another kind of IT management example. If the investment monitoring tools and setting up with those monitoring tools beyond just domain group, each one looking at their green, yellow, red lights individually like being able to aggregate this into a business impact conversation and knowing what to do with it, you know, mean time, to repair.

    A good portion of the time is, when the event actually happens that you discovered something broke, right, usually it's the customer calling you and telling you because you haven't got good alerting and monitoring mechanisms going on.

    You do, you 've got the world's best monitoring systems. It's called your customers.

    Well, A, I'd want to be the one to discover it before they do.

    Yeah, I know, I'm being.

    But without setting off your monitoring technology and integrating that with your incident management, sort of, restoration processes and tools, right, you are leaving that whole front end of that mean time to repair process wide open for basically subjectivity and whatever happens.

    Hmm.

    And, again, it could be 80 percent of the time you didn't even know it was broken until someone told you. So investment in monitoring tools and in event management process linked to an incident process is a huge way to talk about productivity. Because meanwhile, back at the farm, your customers are experiencing outages that you don't even know about.

    And you've got to measure their productivity loss in quantifiable ways.

    So A, create this linking architecture. B, learn to quantify and measure what you're going to improve.

    The cost of what the current scenario is.

    The current real dollars for the current pain, because once, you know, we just gave two or three great examples of how to do that.

    Another one is risk. One of the.

    I'm not good with this one.

    Where I like to start this conversation, I'll sometimes go into an executive session and they'll look at me with very steely eyes and then say, prove why I should listen to you. And the first thing I even say to them, I said okay, I'm here to talk to you about service management and all of that and ITOL [sp?], yes, okay.

    But the reality is I wanna tell you that I'm not gonna give you any of information or tell you about anything new that you don't already do today. Right? You already take requirements from the business, demand from the business, you turn that into design and blueprints. You have to then build those blueprints, test those systems and service offerings you have, move those to production and then support it when it's live
    the business.

    So, that's all that service management is, right, so the question is, your current level of maturity, relative to any of that practice, isn't satisfactory. It's status quo sufficient, because on the scale of I do this engineering to order thing. Right? We talked about before,
    where it's custom every time.

    To something that on the other side of the dial has this formality repeatable consistency. If you ask anyone they'll say that most IT practices, almost 90 plus percent, are all going to be custom every time. That's okay, from the point of view if you really need them to be, but the reality there's a lot of risk to that and not only that everything is redundant.

    We're doing this assess right now, I can't mention with who, they've got decent practice and release practices but they're by department so one group does their thing, another group does their thing its by application but none of these departments live in an isolated world. So they make changes to their own environment based on their own change processes, without knowing or communicating those changes to their teammates next door.

    And we did have a whole show on made to order and artist versus, you know, crafts people, and I'll put a link to the show notes to that. Because that really was a really good show on understanding the value of consolidating and creating repeatable automated processes that people can just consume and not everything was this fine piece of art.

    Yeah, and it comes back to risk, if you can tolerate the risk of current state, if you're okay, and the analogy we used once, flying in all of these diffferent planes to your data center like a chain Coming into the data center and having 12 control towers talking to themselves and only themselves but all using the same environment to changes into.

    If you're okay with that kind of risk, then so be it. But if you're not, you gotta point the risk out of your current practice.

    When you have that risk My gut's telling me that a lot of people don't even, you know, it's kind of like you said, pointing out the obvious. Most people probably have never even thought about The volume of risk that you're actually managing. I mean that's not a big deal when you do this?

    Yeah, I mean you have to point it out 'cause you know what You have to make it black and white. You have to define it in order to control it, in order to measure it, in order to improve it and you have to get it on paper. We have this relativity conversation and we're just, it's kind of like the show, we're bringing all this stuff back, right.

    It's all relative and subjective until it's written down. Until you force people to look at themselves in the mirror or on the scale and say, "Really, is that really what you want to exist like truly?" 'Cause until you got on that scale, you were in blissful ignorance, you knew something was wrong.

    You didn't have to face the facts, Jack.

    Oh yeah, I hear you.

    Yeah, because I would think, actually, taking time to document your risk state would be so compelling that David said, "Okay, fine. You're justified." Just the documenting of your current risk state I think would be enough for most people.

    No. Well let's keep going, there's more.

    All the way, all right, keep going.

    All right, now we're taking about how efficient are we? We get things done, but largely inefficient ways. It's like not even anything, any process So remember, all things we get accomplished, is the product of a process. There's stuff we want to get done. There's raw inventory coming into it. There's a set of stuff and activities we accomplished to get some outcome.

    But not all the processes we do are the greatest lean up you know version over they could be. I remember when we were working on a financial management process for project approval mechanism. So this is, you know, I need to get funding and approval for a new corporate and capital initiative. Well what does ITIL have to say about that?

    It says you should be good at financial management. Stop. So you have to basically take some common horse sense, some lean approaches here Lets map out the current process for approving projects, project funding, there's 3, 4, different authorization loops, in the current process. All capital funding projects go through the same, funnel.

    Regardless if they're, fifty million verses 200 thousand. yep. Really is that the best way to do this? Then they all need 5 funding cycle loops. may be But you have to ask yourself, can I not tier this a little bit? Can I maybe remove some of these redundant loops for lower risk, lower cost, put empowerment in some people to have signing authority at certain levels and require more due diligence with higher risks and higher costs.

    But if you have one process for handling all funding, you probably are not very efficient. You've got to start looking at this from a waste perspective, a leaning out of what's really fit for purpose here. Not just because the book said so, but because I need this level due diligence. Too much process is as bad from an efficiency perspective as no process from a risk perspective.

    Again, I would have never thought of looking at eased as in that view. I thought we'd really done enough for just quantifying productivity but now you are the risk and waste on top of it. All right, go ahead. You don't have any more do you?

    Return on investment. You've got more. You were just like a one-two punch for that executive room. So all of these examples, whether it's strategic, productivity, risk, efficiency, they all have some element of current state, right? Quantifiable current state.

    Right.

    And sometimes it's not just dollars but it's quantified in the sense that I can get there from here. The business wants me to move to the next level, to act faster, to be quicker and more agile for a new value generation, and what my current practices are not scalable, right? You've got to get that clear picture on the table first, and now you put that underneath your ROI calculation, that's your current state cost of current state.

    Now I can start to think about the benefits, that I hope to see. Relative to let's take it from the tool perspective. You know, you're in the tool business. One of the things I advocate strongly, and again, we just saw this with another client we were working with, is you can create these process idles where you all go off and do your own process.

    Even if the same process using different tools. Or it's different processes. Like incident problem and change using different tools. But the reality is, if you've got have an integrated process architecture, you should have an integrated application architecture, which, because you need an integrated data architecture.

    So I worked in organizations, and you probably have too Chris, that says if I come down and consolidate onto one tool, even an existing tool, I don't even have to go out and buy a new one, I've probably got enough, maybe I need a need one. That's a, you know, I'll leave that for off the conversation.

    If I can consolidate my current tool environment by a third, or even down to one, I could fund this process improvement engagement for the next six year because of the cost of maintaining a current tool environment. So you've got to look at the benefit of single tool now compared to the cost of all the tools.

    And this is your ROI calculation coming into play. Current divided by [xx], benefit divided by current.

    Right and people love to talk about the ROI.

    Yeah, but they'd come to the table with their portion of it.

    Troy, I hate I hate to do this to you.

    It's that time already?

    It's that time and I know you got a tip. So we got one more tip left on this. We'll pick it up next time. But folks, I'm sorry it's the fastest 30 minutes in service management radio. Troy, it's time for your Thunderbolt Tip of the Day! Okay, Chris. Justifying process improvement or service improvement starts with determining if you can really tolerate the status quo.

    ROI back calculation can never be accurately expressed without understanding your current environment costs and risk.

    Well Troy, you have convinced me and justified this entire situation. So thank you, and we will catch everyone in two weeks, and best of luck on your travels and I will make sure we don't let anything else catch on fire. As always, such a pleasure.

    Take care Chris, bye.

    Bye bye. [music]

    # vimeo.com/45522484 Uploaded 178 Plays / / 0 Comments Watch in Couch Mode

  4. Show Notes & Links:
    servicesphere.com/blog/2012/6/25/the-role-of-the-it-service-owner-practitioner-radio-episode.html

    Show Notes:

    Troy’s Thunder Bolt Tip of The Day:

    Everything that you care about managing should have an owner responsible for the full lifecycle. Without this explicit assigned accountability Services will continue to be managed on a best effort level.

    Show:
    Chris visits SDI and Ovum
    Listener Mail. Networked Help Desk Site
    Service Management Organization White Paper
    Technology focused organizations do not focus on ownership of "outcomes"
    The Service Stack
    Service Ownership is NOT unique to the IT department
    Service Owners and Business Relationship Owners
    Service Owner role-playing outside of IT, Fleet Management
    Human Barometer for CSI
    Service Owners and Service Level Agreements
    Ok, so I have not slept a lot
    Service Owner role-playing for an IT service
    What comes first define the service owner or define the service
    How is the service owner involved in the support process?
    Hamster Wheel of Death
    Org Chart for a Service Organization is Horizontal management

    Show Transcription:

    Welcome to another addition of Practitioner Radio. Elephants podcast for the IT management community. Welcome to Practitioner Radio pink elephants podcast for the IT service management community, the fastest 30 minutes in service management radio. Episode number 28 already. We are on 28 already, it's hard to believe.
    How are you Troy?
    I'm doing okay Chris. How are you doing today?
    Oh It's been a day full of exciting challenges.
    Yeah, you told me you were on the other side of the ocean again. Yes I am, I don't know how I Columbus. So I thought we'd kick things off today with some listener mail. A listener here from Germany so hello to Germany out there. Howdy Germany. Hey Germany. Klaus wants to know, he says he's a loyal listener to the pod cast, appreciates our work.
    Has a question regarding episode 26 about the open ticketed initiative that I mentioned. So, in episode 26 I talked about this concept that some vendors have taken part in that allows service desks to seamlessly pass tickets amongst disparate systems, seamlessly being probably the scariest word there - and that's the Networked Help Desk Initiative.
    And it's networkedhelpdesk.org is what it is. Is that right? Network That's what you told me about earlier, yeah, that's that open ticket initiative for passing tickets between systems. Just making sure you were listening, I'm just making, that's what it was. It's network helpedus.org. So you guys can check that out I'll put a link in the show notes if you didn't.
    I am at a show here in the U.K. and one of the things that someone asked was about who owns the actual service catalog? And it got me thinking about all of our chats about process owners and service owners and the service management or the service organization. And we have a link to White Paper for that, because I'm hearing a lot, just everywhere I go now, everyone's always talking about the service organization.
    Service owners, not addressing this person's question directly, but I'm sure we'll get to it. Can we talk a little bit about that missing role, the role of who owns the individual services and how that even marks.
    Absolutely, so we've talked about the service management organization and this is one role of many. In this there's the process side and process owners. And that's relative to who manages or who owns a process cross organization and you've got this concept of a distributed ownership. We talked about that as well.
    But now we're talking more about the services, the things that are actually being provisioned to the business unit. Or not just the business unit because there are many different customers in this context, right? We could have services provided to development function by an infrastructure organization such as hosting.
    Or we could also have a service delivered to a business unit such as a messaging service for telephony. I have the services I can extend to an external community or an external market. So I can be a Telco and I can be providing data services to another Telco. There's this concept of services at different levels of discontinuum.
    And the concept of life cycle management is that anything you care about managing should have someone who owns this life cycle and basically cares from birth to retirement and in a technology focused organization, we know what it is to there is this person who say, okay, you're the administration of this server you're the developer of this application.
    We know who it is who manages the collection of light technologies. Like there's the server guy. And over here we have this lady who's responsible for the web applications, right? So this domain kind of ownership. But where we're missing in a technology focused organization, we are missing a level of governance that who owns the outcome, like who's owning the outcome called financial management or payroll from an IT services perspective.
    Or messaging or hosting for that matter, as we talked about a few minutes ago. This concept of a service owner is really important when you start managing anything above the technology layer in this service stack you need someone to basically care and feed this thing. Look at it from, you know, a glimmer in someone's eye to its strategy, to its plan, to its run.
    This is a missing link for most organizations who are moving from technology to service orientation, and that's something that has to be dealt with and put in place.
    So from a technology standpoint this makes sense, because it almost sounds like, you know, the experience manager for a particular service. Because wouldn't they also have to also understand, like you said, what it looks like as far as the customer as well as the tech side of it? You need both views.
    Okay, so one consideration is that service ownership is not unique to the IT function.
    Right.
    Yes, we are a service organization but so is HR. There's HR services, there should be service owners within HR. There are fleet management services. But on the business side, you have business services to the outside market. But let's take an internal context here. Let's say on the business side, we have someone who's responsible for financial management, you know, accounts payable, accounts receivable, all of those, you know, classic financial services that are provided as a shared service to the other business units.
    Well, IT manages a set of technology automations to support financial management. But there's a counterpart on the technical side, saying, okay, this is the service owner for financial management, he or she deals directly with the business service owner for financial management and comprising that financial management service are some systems They might be an ERP system like SAP or Oracle Financials.
    You know, so we've got this person not the business relationship manager necessarily, who can speak and deal with the business for business requirements, but also knows the technologies and is responsible for assembling the right technologies to deliver that service outcome. Does that make sense, Chris?
    Yep, I'm thinking the service center is probably part of the career path to get to my dream job of business relationship manager.
    Some organizations, they have every service owner playing this role of business relationship manager. But that causes complications because you might have, I don't know, 30, 40, or more services. That means you have 30 or 40 people to talk to for service presentations, service management. This is where we kind of bundle these up into the Account Manager role.
    Yeah, I meant it's part of the career path, like you have to be a service owner before I'll even consider you for the Business Relationship Manager. You've walked the walk, you've been in the trenches I suppose. Yeah. That's true. This sounds like a trench job. So, that's for the sake of clarity, stay with the tech for a minute.
    Okay. And talk about a service owner for fleet management, or for any of the other things you're talking about. All right, so fleet management. So I'm in fleet. And I'm one of many shared service functions to the business, right? So I have to understand what does fleet do in the context of the business model.
    Fleet can be part of my transportation mechanism for delivering product to market. So big trucks. It can be responsible for a fleet of cars for executives one of their executive perks. It could respond to and deliver rental vehicles for visiting people from another part of your organization, who are visiting your area and so you basically put a fleet together that way, maybe dealing with an external supplier like one of the rental companies.
    So you've got these series of types of services you're offering to the business. So the service owner would have to understand the business requirement for each of these service areas and then develop an offer with the right resources, in this case, vehicles of different size and shape and attribute with the right price point for the right business requirement.
    And as that business requirement changes those offers change and of course they're dealing with the consumers of this fleet service to say what that change is. And they're continually modifying and improving their fleet offerings based on changing requirements dealing both with functional, what it must do, and non-functional, you know, how it must exist and be supportive.
    So is this some type of human parameter for looking in your service improvement?
    Well, someone who is visioning what this is and is continually modifying and augmenting or changing it based on changing needs. Right. But this is not just the guy or person responsible for leasing a bunch of cars. Or a bunch of trucks.
    No, he saying from suit to nut.
    There's so much more to a service than just the physical resources.
    But when we talk about continual service improvement, because the word service gets tossed around like the word fine when you ask someone else how they're doing. Continual service improvement means you're continually refining and looking at the life cycle and having to removing, you know, the pipeline, what's coming in, what's going out.
    I would think a service owner, for that matter, would be responsible for making sure that it's constantly improving.
    And meets the needs. And It's not just the product, right?
    Right, it's also the experience.
    We've discussed this before that the product, in the case the car or the truck, is not the totality of the service being offered. No, it's the financial aspects of the service, it's the experience from the outside in with the customers that are using and consuming that service. It's understanding the needs of the business and the demand for that service.
    It's a lot of things, correct? Correct. So the product is only one element of the service experience, the service outcome, right? So being able to track the trucks through a GPS technology and understand where they are for point of time delivery at any moment, would be part of that fleet service.
    You gotta be a pretty expansive thinker. You have to understand the business requirement for that service to build that offer that meets the need. And the business requirement, what business you're actually in, and it might be helpful if you understood something about the service. And the technology and/or the resources that you need to build it.
    So you need to know both, the technical aspect as well as the business requirement, and marry those two together with the right Ingredients, the chef. The service owner is like the chef who has to pick his ingredients, her ingredients from various suppliers. And come up with an offering, an a la carte menu, that the customer wants to buy from.
    Does the service owner have any input? Would they have anything to do with this service level agreement negations and creation of that documentation? Absolutely, because of of the things that we have to keep in mind is that its not just defining and developing an offer which will be published in the catalog, which is another discussion, but it's also about being involved in all the processes which are required to support the service.
    In fact, the one you just mentioned, service level management. So the service owner would be part of the negotiations and discussions for internal operational level agreements between different groups which own different elements of the service offering. That service level of agreement now with the customer, right, my agreement about how I will deliver the service to The end consumer is also something the service owner would work with the service level management process owner to define.
    So, its really the service owner that actually varies the responsibility for definition. A service level manager process works with the service owners to achieve those results.
    Reminds me of the scene in the original Superman movie. Or at least the ones from 1977 where they're on Krypton, and Superman's parents are part of like this jury, and they send those 3 bad guys off to space but it's like all those people in that big judging room are like all service owners and they find some rogue element and banish the e-mail service back off into space until it explodes on the moon and then has superpowers and comes to take on the social media collaborative service.
    Wow, that's pushing it.
    Wow, that was a stretch for me, but I see. Okay. Whatever you want.
    Oh, you were there. Don't lie. You were there. Okay you were there until the I was there.
    I was there. I remember this movie. I'm just trying to build the correlations that you have.
    Alright, well there's some somebody in the audience, its probably in Germany. So now let's role play. So now I have a better understanding [xx] fleet manager. I have a better understanding what the service level agreement information you give me. I want to be the service owner for a particular service in my infrastructure.
    I want to talk to you about it as a consultant to help me understand what I need to think about.
    Okay, so let's talk about data centers and the kind of services you would find in an infrastructure type organization. Because often that's, in the place where many times this service concept begins, actually. So, you know you gotta bunch of servers, in a bunch of racks, right, but those servers and those racks and that data center environment and the power generation capability and the cooling generation, those are all specific elements to deliver a service called hosting.
    Where I have come up with a number of different offers and those offers might be represented by a development server of a certain size, A, B, and C server, a testing server, and literally you'd have these kind of products that are, you know, part of this hosting service but they would be just the forward facing instantiation of the service.
    Because built into that development server that I could ask for, whether it's physical or it's a virtual machine provision through cloud, you know, or those types of activities. Not only do I have the physical or virtual server that I have the monitoring built into that, I've got the security and auditing and compliance checking built into that.
    I have, let's say, the service level agreements that have been defined into this offer. We have the support that for, you know to get access to support for. So, you have all these elements that would be built into this hosting service, which is more than just the server that you're actually provisioning as the product.
    So many people when they're at conferences - to just go back to the conference they're talking about services, really start with, you know, you see it all over the map, but most people seem to get to the point where they go, "Okay." They just almost like get exhausted and they go okay. I understand how to define a service.
    Now I don't think a lot of people...I would have never in listening to you I thought, "Oh, hosting service." But you went there and I'm like, "Okay, you're right. That makes sense. You lose some of them but you went to the highest, purest level." So most people get that and then they always go, Okay so I figured out how to build my service.
    How, or is it too soon, once you've identified all the pieces and parts that make up that consumable service. The service owner you just can't by proxy be the person or the teams, is there a process or is there a person who makes the most sense to be the service owner? How does someone get trained to understand what they're owning?
    Okay. Remember, we talked about the fact that they have to have both a business understanding of the requirement as well the technology. So they can't be too far from the technology viewpoint and/or the colleagues they work with to pull this together. Okay Before I can create this offer, I literally have to go shopping internally, because let's say I have this hosting service, well, some of it will come from the infrastructure part of it, some of it will come from a monitoring group.
    Some of the elements will come from a security group, some of it will come from an architecture group. Some of it will come from the support organization, the service desk, and the knock more corporation center. All of these are elements. I literally have to go shopping internally and externally because I can build my service out of components which are both internal and external.
    It doesn't all have to be internal. Right. I have to build that package and negotiate how that's going to be built before I can go go to my consumer customer and say, Okay here is what I can do and here are the elements, the attributes, the measurements, the SLAs, the supporting elements. So you have to be an inside person to be able to do this effectively.
    To try to do this without the technical concepts and the relationships would be a very difficult thing. Someone in the audience is thinking - because I know if I'm thinking it, someone else is - what comes first, the chicken or the egg? And you know the chicken and you know the egg. Well, we're delivering services today.
    We just haven't defined them well, right? What do we do first to find the services or find a service owner. We haven't done either well. But, let's step back in the evolution of service design. You're always putting me in that Troy Dumalay Delorean, you're always doing that to me. The interesting thing is, this is not totally foreign to the whole value chain we've come from.
    The technical value chain. So when a new capital initiative is invested in, it's because there's a business requirement hopefully that's been put forward. We want to go into this market. We want to adopt this new online capability. We want this new solution. But to develop that solution, the architect doing the designing has to think about the whole model.
    They have to think about the business process, understand the requirements, then understand the application layer that would support that, the infrastructure layer that needs to be in place to support the application layer, and then the data layer. So they have to design the service outcome tip-to-toe, end-to-end, as a full service entity, because that's the only way I can build it in design.
    And so when that architect has completed that design, sourcing strategy determines which elements are internal, which will be external. But then we take that design and we move it to production as the result of a major capital investment or project. And we move it to production, but what happens to that end-to-end relationship model when it moves to production?
    It's not a rhetorical question. It literally evaporates. What was created as this end-to-end service concept in design, when moved to production, now is managed as if every component of it exists in mythical isolation. So we actually manage to design it in a service orientation put to the run environment we treated it as individual resources or domains.
    So we have to kind of find an owner for that end-end view, and maintain that owner from design going forward into production. Does that make sense? Yeah, I think what you're saying is that we need to know, the owner needs to be part of the process of making this happen. Well yes, cause right now we treat it like a project.
    We have a project manager which is kind of the proxy owner of this whole thing. I guess I I'll just put it real simple. I would think that most organizations, struggling, or not struggling, or thinking they're doing fine, would get a bunch of people together in IT, and say okay, we're going to create our service catalog.
    So to do that we need to define our services. And let's define at least one service. Let's all talk about one service. What service should we talk about? And someone says communications or something hosting. Okay, let's talk about hosting and then they start, What pieces of hosting? Alright we got the server, we got the security, all the things you mentioned earlier, right, everyone sitting together at this table.
    At that table, is the service owner present or is it possible for that team or that project or I shouldn't have even been thinking about project mentality because we know that's between a group and a team. We discussed that last time. When does this person get infused into the process of the birthing of a service or is a service handed to them on a bundle of blankets and it's theirs to care for for life or is there benefits to one and not the other.
    Does that make sense?
    It does. You can't manage what you haven't defined first.
    Some people do.
    It's the first exercise organization usually get through or go through is to create their service taxonomy. When I say create, that's the wrong word actually, because we're already delivering these services.
    Yeah.
    Identify their service taxonomy it already exists. They just haven't managed it as this service structure. They're managing it as a bunch of technology domains. So the first thing they get together and say, "Here are all the things that we do today relative to business.com." All right, there it is, there is the list of services and their corresponding systems and resources.
    Now, the second question is, who owns those areas, right? Because right now very rarely will you find an organization that owns any resources other than that within their functional area. So the concept of owning a service, which is comprised of elements outside of their functional department, is totally foreign to our Org [sp?] design.
    it's this horizontal role like a process owner. You've got to know what you do first. Identify your services. And then the second question is, okay, who gets to own the is going forward? And that is a role.
    In your experience, does that person become apparent once you have that discussion, or what have you seen?
    Well in some cases where there's really complex mission critical things in place already. You already have a service owner. If you have an enterprise resource planning application like SAP or oracle financials, I guarantee you I can point to someone and say she or he owns SAP as a system and the service of financial management, RHR, by extension.
    So the more mission critical you are, probably already done this. You might find somebody responsible for messaging because that is a service that is typically, mostly with an infrastructure, like an enterprise application. You kind of have sporadic ownership identified for the stuff that is really deemed important, but everything else has no ownership.
    When things break in an organization fingers usually point to the person who owns the piece of the service. The piece. That's right. They're all going "Well it's not my problem". The networks up, right? Well, the server is running or the application went down or the database hasn't crashed. So where is the service owner when something breaks?
    Well, let's ask that question a different way. How is the service owner involved in support? Can we go there and take it from that?No , you read my mind. Okay. So actually let's...you started this conversation with a service level management question you asked earlier. Yeah. I try to be smart. So Let's say a major, mission-critical service has failed.
    Yep. Part of the ITIL process of incident management is a major incident process and many organizations will call the meeting, [xx] the war room together. Everyone will go into a conference room or a bridge will be opened. and everyone, basically all hands on deck will be part of this major incident process.
    Who would be a critical person to be in that room or on that bridge called the service owner, because he or she is responsible to communicate to the business what the current status of that service is and when it's likely to be back up. because they're the senior sponsor within an IT context who owns the accountability for that offering to be provided as required.
    They'd have to be involved in the incident process You follow me there?
    Oh yeah. Let's keep going.
    Problem management. Over and over again, we experience incidents against this service outcome. When there's no one accountable or worried about the outcome as a service. We can totally go and basically live with the repeat issues over and over again, because no one is accountable for it. Everyone's got their little piece.
    But I call that the hamster wheel of death because we're willing to resolve the same incidents thousands of times. If I'm the service owner for that incident, I'm going to be asking some hard questions and get problem management involved and say, "This is not acceptable. I've been called on the carpet ten times this past month because of the same damn incident repeat over, repeat over.
    We need problem investigation done. So they would drive problem management.
    How about change and release?
    Most outages are caused by production changes to an outcome, to a service not because we have a technical failure. That means there's a certain level of due diligence, production assurance we do with release management, and approvals for, you know, promotion and the production that changed, takes care of his scheduling.
    I would want to be, if I'm the service owner, one of the last points of approval, to say A, this change can go. Yes or no based on release having defined that this is production ready and is ready to be moved to production based on all these criteria having been satisfied. So the service owner would be critical, because again, their skin is in the game and they're accountable.
    A critical reviewer and approver of both release acceptance and change readiness for promotion to production. Without that, no one else is accountable for the outcome. They all have their little piece.
    So if I've got a process center for change management, a service owner for hosting, and a business relationship manager sitting in a room and there was some major incident. All three of those people would have different audiences, they'd be responsible and communicate to.
    Yes and if I was the service owner who was the owner a very problematic, unstable service. Be asking some very hard questions around the design, the availability, the capacity, the service continuity, all of those elements.The processes are enabling the service owner. And when they are in lack, the service owner is in a great deal of pain because they're in front of the firing line here if things go wrong.
    There's almost a second org chart.
    Think about your vertical, traditional org charts.
    Yeah. You have development. You have infrastructure. Yep. And each of those have vertical departments, right.
    Yep.
    Horizontally crossing both of these are services and processes.
    Yep.
    So in the same way as processes span functional structures, so do services. But this concept of horizontal management, or virtual management across vertical structures, that's a difficult challenge because right now we have mostly vertical governance, not horizontal.
    Have you seen Prometheus yet?
    No, I haven't.
    Yeah, there's this UI at the end that he initiates where he sees things from inside this 360 degree, 3 dimensional, almost 4 dimensional UI. And that's almost sounds like the horizontal org chart you're talking about. Because literally when I think about the process owner for the change management process, the business relationship manager and the service owner all in the room after a major incident, I start to think almost multi-dimensionally about my organization.
    Because it is multi-dimensional, right? It's vertical as well as horizontal at the same time. Because demand, plan, build, run is a horizontal value chain which spans our vertical org structures and the services do the same.
    I'm on. I totally get. I guess I never realized how multi-dimensional our organization was because I've always been so, well not very flat, kind of bumpy. Well, you know what I mean.
    But right now most organizations only have roles and structures which manage vertically, you know, their domains and technologies and very little governance or ownership for anything moving horizontally.
    It might be time for a COBIT talk.
    We can do that, we'll see if we can get Jennifer to join us.
    We should.
    Yeah, it'd be great.
    We should put someone else over the practitioner, coals of the fires of this. Oh, goodness. It's teatime here in England, or as I call it Truth Thunderbolt Tip of the Day!
    Okay. Remember, Chris, everything that you care about managing should have an owner responsible for the full life cycle. Without this explicit assigned accountability, services will only continue to be managed on a best effort level.
    Not hire nannies carefully. This has been Chris Dancy and Tory Dumolet for Park National Radio. Episode 28, service owner. This is a good one. Again this is one of those ones we could go on for days. Thanks so much, Tory and I'll see you in two weeks.
    Two weeks, take care Chris.
    All right, buddy. [music]
    Welcome to another addition of Practitioner Radio. Elephants podcast for the IT management community. Welcome to Practitioner Radio pink elephants podcast for the IT service management community, the fastest 30 minutes in service management radio. Episode number 28 already. We are on 28 already, it's hard to believe.
    How are you Troy?
    I'm doing okay Chris. How are you doing today?
    Oh It's been a day full of exciting challenges.
    Yeah, you told me you were on the other side of the ocean again. Yes I am, I don't know how I Columbus. So I thought we'd kick things off today with some listener mail. A listener here from Germany so hello to Germany out there. Howdy Germany. Hey Germany. Klaus wants to know, he says he's a loyal listener to the pod cast, appreciates our work.
    Has a question regarding episode 26 about the open ticketed initiative that I mentioned. So, in episode 26 I talked about this concept that some vendors have taken part in that allows service desks to seamlessly pass tickets amongst disparate systems, seamlessly being probably the scariest word there - and that's the Networked Help Desk Initiative.
    And it's networkedhelpdesk.org is what it is. Is that right? Network That's what you told me about earlier, yeah, that's that open ticket initiative for passing tickets between systems. Just making sure you were listening, I'm just making, that's what it was. It's network helpedus.org. So you guys can check that out I'll put a link in the show notes if you didn't.
    I am at a show here in the U.K. and one of the things that someone asked was about who owns the actual service catalog? And it got me thinking about all of our chats about process owners and service owners and the service management or the service organization. And we have a link to White Paper for that, because I'm hearing a lot, just everywhere I go now, everyone's always talking about the service organization.
    Service owners, not addressing this person's question directly, but I'm sure we'll get to it. Can we talk a little bit about that missing role, the role of who owns the individual services and how that even marks.
    Absolutely, so we've talked about the service management organization and this is one role of many. In this there's the process side and process owners. And that's relative to who manages or who owns a process cross organization and you've got this concept of a distributed ownership. We talked about that as well.
    But now we're talking more about the services, the things that are actually being provisioned to the business unit. Or not just the business unit because there are many different customers in this context, right? We could have services provided to development function by an infrastructure organization such as hosting.
    Or we could also have a service delivered to a business unit such as a messaging service for telephony. I have the services I can extend to an external community or an external market. So I can be a Telco and I can be providing data services to another Telco. There's this concept of services at different levels of discontinuum.
    And the concept of life cycle management is that anything you care about managing should have someone who owns this life cycle and basically cares from birth to retirement and in a technology focused organization, we know what it is to there is this person who say, okay, you're the administration of this server you're the developer of this application.
    We know who it is who manages the collection of light technologies. Like there's the server guy. And over here we have this lady who's responsible for the web applications, right? So this domain kind of ownership. But where we're missing in a technology focused organization, we are missing a level of governance that who owns the outcome, like who's owning the outcome called financial management or payroll from an IT services perspective.
    Or messaging or hosting for that matter, as we talked about a few minutes ago. This concept of a service owner is really important when you start managing anything above the technology layer in this service stack you need someone to basically care and feed this thing. Look at it from, you know, a glimmer in someone's eye to its strategy, to its plan, to its run.
    This is a missing link for most organizations who are moving from technology to service orientation, and that's something that has to be dealt with and put in place.
    So from a technology standpoint this makes sense, because it almost sounds like, you know, the experience manager for a particular service. Because wouldn't they also have to also understand, like you said, what it looks like as far as the customer as well as the tech side of it? You need both views.
    Okay, so one consideration is that service ownership is not unique to the IT function.
    Right.
    Yes, we are a service organization but so is HR. There's HR services, there should be service owners within HR. There are fleet management services. But on the business side, you have business services to the outside market. But let's take an internal context here. Let's say on the business side, we have someone who's responsible for financial management, you know, accounts payable, accounts receivable, all of those, you know, classic financial services that are provided as a shared service to the other business units.
    Well, IT manages a set of technology automations to support financial management. But there's a counterpart on the technical side, saying, okay, this is the service owner for financial management, he or she deals directly with the business service owner for financial management and comprising that financial management service are some systems They might be an ERP system like SAP or Oracle Financials.
    You know, so we've got this person not the business relationship manager necessarily, who can speak and deal with the business for business requirements, but also knows the technologies and is responsible for assembling the right technologies to deliver that service outcome. Does that make sense, Chris?
    Yep, I'm thinking the service center is probably part of the career path to get to my dream job of business relationship manager.
    Some organizations, they have every service owner playing this role of business relationship manager. But that causes complications because you might have, I don't know, 30, 40, or more services. That means you have 30 or 40 people to talk to for service presentations, service management. This is where we kind of bundle these up into the Account Manager role.
    Yeah, I meant it's part of the career path, like you have to be a service owner before I'll even consider you for the Business Relationship Manager. You've walked the walk, you've been in the trenches I suppose. Yeah. That's true. This sounds like a trench job. So, that's for the sake of clarity, stay with the tech for a minute.
    Okay. And talk about a service owner for fleet management, or for any of the other things you're talking about. All right, so fleet management. So I'm in fleet. And I'm one of many shared service functions to the business, right? So I have to understand what does fleet do in the context of the business model.
    Fleet can be part of my transportation mechanism for delivering product to market. So big trucks. It can be responsible for a fleet of cars for executives one of their executive perks. It could respond to and deliver rental vehicles for visiting people from another part of your organization, who are visiting your area and so you basically put a fleet together that way, maybe dealing with an external supplier like one of the rental companies.
    So you've got these series of types of services you're offering to the business. So the service owner would have to understand the business requirement for each of these service areas and then develop an offer with the right resources, in this case, vehicles of different size and shape and attribute with the right price point for the right business requirement.
    And as that business requirement changes those offers change and of course they're dealing with the consumers of this fleet service to say what that change is. And they're continually modifying and improving their fleet offerings based on changing requirements dealing both with functional, what it must do, and non-functional, you know, how it must exist and be supportive.
    So is this some type of human parameter for looking in your service improvement?
    Well, someone who is visioning what this is and is continually modifying and augmenting or changing it based on changing needs. Right. But this is not just the guy or person responsible for leasing a bunch of cars. Or a bunch of trucks.
    No, he saying from suit to nut.
    There's so much more to a service than just the physical resources.
    But when we talk about continual service improvement, because the word service gets tossed around like the word fine when you ask someone else how they're doing. Continual service improvement means you're continually refining and looking at the life cycle and having to removing, you know, the pipeline, what's coming in, what's going out.
    I would think a service owner, for that matter, would be responsible for making sure that it's constantly improving.
    And meets the needs. And It's not just the product, right?
    Right, it's also the experience.
    We've discussed this before that the product, in the case the car or the truck, is not the totality of the service being offered. No, it's the financial aspects of the service, it's the experience from the outside in with the customers that are using and consuming that service. It's understanding the needs of the business and the demand for that service.
    It's a lot of things, correct? Correct. So the product is only one element of the service experience, the service outcome, right? So being able to track the trucks through a GPS technology and understand where they are for point of time delivery at any moment, would be part of that fleet service.
    You gotta be a pretty expansive thinker. You have to understand the business requirement for that service to build that offer that meets the need. And the business requirement, what business you're actually in, and it might be helpful if you understood something about the service. And the technology and/or the resources that you need to build it.
    So you need to know both, the technical aspect as well as the business requirement, and marry those two together with the right Ingredients, the chef. The service owner is like the chef who has to pick his ingredients, her ingredients from various suppliers. And come up with an offering, an a la carte menu, that the customer wants to buy from.
    Does the service owner have any input? Would they have anything to do with this service level agreement negations and creation of that documentation? Absolutely, because of of the things that we have to keep in mind is that its not just defining and developing an offer which will be published in the catalog, which is another discussion, but it's also about being involved in all the processes which are required to support the service.
    In fact, the one you just mentioned, service level management. So the service owner would be part of the negotiations and discussions for internal operational level agreements between different groups which own different elements of the service offering. That service level of agreement now with the customer, right, my agreement about how I will deliver the service to The end consumer is also something the service owner would work with the service level management process owner to define.
    So, its really the service owner that actually varies the responsibility for definition. A service level manager process works with the service owners to achieve those results.
    Reminds me of the scene in the original Superman movie. Or at least the ones from 1977 where they're on Krypton, and Superman's parents are part of like this jury, and they send those 3 bad guys off to space but it's like all those people in that big judging room are like all service owners and they find some rogue element and banish the e-mail service back off into space until it explodes on the moon and then has superpowers and comes to take on the social media collaborative service.
    Wow, that's pushing it.
    Wow, that was a stretch for me, but I see. Okay. Whatever you want.
    Oh, you were there. Don't lie. You were there. Okay you were there until the I was there.
    I was there. I remember this movie. I'm just trying to build the correlations that you have.
    Alright, well there's some somebody in the audience, its probably in Germany. So now let's role play. So now I have a better understanding [xx] fleet manager. I have a better understanding what the service level agreement information you give me. I want to be the service owner for a particular service in my infrastructure.
    I want to talk to you about it as a consultant to help me understand what I need to think about.
    Okay, so let's talk about data centers and the kind of services you would find in an infrastructure type organization. Because often that's, in the place where many times this service concept begins, actually. So, you know you gotta bunch of servers, in a bunch of racks, right, but those servers and those racks and that data center environment and the power generation capability and the cooling generation, those are all specific elements to deliver a service called hosting.
    Where I have come up with a number of different offers and those offers might be represented by a development server of a certain size, A, B, and C server, a testing server, and literally you'd have these kind of products that are, you know, part of this hosting service but they would be just the forward facing instantiation of the service.
    Because built into that development server that I could ask for, whether it's physical or it's a virtual machine provision through cloud, you know, or those types of activities. Not only do I have the physical or virtual server that I have the monitoring built into that, I've got the security and auditing and compliance checking built into that.
    I have, let's say, the service level agreements that have been defined into this offer. We have the support that for, you know to get access to support for. So, you have all these elements that would be built into this hosting service, which is more than just the server that you're actually provisioning as the product.
    So many people when they're at conferences - to just go back to the conference they're talking about services, really start with, you know, you see it all over the map, but most people seem to get to the point where they go, "Okay." They just almost like get exhausted and they go okay. I understand how to define a service.
    Now I don't think a lot of people...I would have never in listening to you I thought, "Oh, hosting service." But you went there and I'm like, "Okay, you're right. That makes sense. You lose some of them but you went to the highest, purest level." So most people get that and then they always go, Okay so I figured out how to build my service.
    How, or is it too soon, once you've identified all the pieces and parts that make up that consumable service. The service owner you just can't by proxy be the person or the teams, is there a process or is there a person who makes the most sense to be the service owner? How does someone get trained to understand what they're owning?
    Okay. Remember, we talked about the fact that they have to have both a business understanding of the requirement as well the technology. So they can't be too far from the technology viewpoint and/or the colleagues they work with to pull this together. Okay Before I can create this offer, I literally have to go shopping internally, because let's say I have this hosting service, well, some of it will come from the infrastructure part of it, some of it will come from a monitoring group.
    Some of the elements will come from a security group, some of it will come from an architecture group. Some of it will come from the support organization, the service desk, and the knock more corporation center. All of these are elements. I literally have to go shopping internally and externally because I can build my service out of components which are both internal and external.
    It doesn't all have to be internal. Right. I have to build that package and negotiate how that's going to be built before I can go go to my consumer customer and say, Okay here is what I can do and here are the elements, the attributes, the measurements, the SLAs, the supporting elements. So you have to be an inside person to be able to do this effectively.
    To try to do this without the technical concepts and the relationships would be a very difficult thing. Someone in the audience is thinking - because I know if I'm thinking it, someone else is - what comes first, the chicken or the egg? And you know the chicken and you know the egg. Well, we're delivering services today.
    We just haven't defined them well, right? What do we do first to find the services or find a service owner. We haven't done either well. But, let's step back in the evolution of service design. You're always putting me in that Troy Dumalay Delorean, you're always doing that to me. The interesting thing is, this is not totally foreign to the whole value chain we've come from.
    The technical value chain. So when a new capital initiative is invested in, it's because there's a business requirement hopefully that's been put forward. We want to go into this market. We want to adopt this new online capability. We want this new solution. But to develop that solution, the architect doing the designing has to think about the whole model.
    They have to think about the business process, understand the requirements, then understand the application layer that would support that, the infrastructure layer that needs to be in place to support the application layer, and then the data layer. So they have to design the service outcome tip-to-toe, end-to-end, as a full service entity, because that's the only way I can build it in design.
    And so when that architect has completed that design, sourcing strategy determines which elements are internal, which will be external. But then we take that design and we move it to production as the result of a major capital investment or project. And we move it to production, but what happens to that end-to-end relationship model when it moves to production?
    It's not a rhetorical question. It literally evaporates. What was created as this end-to-end service concept in design, when moved to production, now is managed as if every component of it exists in mythical isolation. So we actually manage to design it in a service orientation put to the run environment we treated it as individual resources or domains.
    So we have to kind of find an owner for that end-end view, and maintain that owner from design going forward into production. Does that make sense? Yeah, I think what you're saying is that we need to know, the owner needs to be part of the process of making this happen. Well yes, cause right now we treat it like a project.
    We have a project manager which is kind of the proxy owner of this whole thing. I guess I I'll just put it real simple. I would think that most organizations, struggling, or not struggling, or thinking they're doing fine, would get a bunch of people together in IT, and say okay, we're going to create our service catalog.
    So to do that we need to define our services. And let's define at least one service. Let's all talk about one service. What service should we talk about? And someone says communications or something hosting. Okay, let's talk about hosting and then they start, What pieces of hosting? Alright we got the server, we got the security, all the things you mentioned earlier, right, everyone sitting together at this table.
    At that table, is the service owner present or is it possible for that team or that project or I shouldn't have even been thinking about project mentality because we know that's between a group and a team. We discussed that last time. When does this person get infused into the process of the birthing of a service or is a service handed to them on a bundle of blankets and it's theirs to care for for life or is there benefits to one and not the other.
    Does that make sense?
    It does. You can't manage what you haven't defined first.
    Some people do.
    It's the first exercise organization usually get through or go through is to create their service taxonomy. When I say create, that's the wrong word actually, because we're already delivering these services.
    Yeah.
    Identify their service taxonomy it already exists. They just haven't managed it as this service structure. They're managing it as a bunch of technology domains. So the first thing they get together and say, "Here are all the things that we do today relative to business.com." All right, there it is, there is the list of services and their corresponding systems and resources.
    Now, the second question is, who owns those areas, right? Because right now very rarely will you find an organization that owns any resources other than that within their functional area. So the concept of owning a service, which is comprised of elements outside of their functional department, is totally foreign to our Org [sp?] design.
    it's this horizontal role like a process owner. You've got to know what you do first. Identify your services. And then the second question is, okay, who gets to own the is going forward? And that is a role.
    In your experience, does that person become apparent once you have that discussion, or what have you seen?
    Well in some cases where there's really complex mission critical things in place already. You already have a service owner. If you have an enterprise resource planning application like SAP or oracle financials, I guarantee you I can point to someone and say she or he owns SAP as a system and the service of financial management, RHR, by extension.
    So the more mission critical you are, probably already done this. You might find somebody responsible for messaging because that is a service that is typically, mostly with an infrastructure, like an enterprise application. You kind of have sporadic ownership identified for the stuff that is really deemed important, but everything else has no ownership.
    When things break in an organization fingers usually point to the person who owns the piece of the service. The piece. That's right. They're all going "Well it's not my problem". The networks up, right? Well, the server is running or the application went down or the database hasn't crashed. So where is the service owner when something breaks?
    Well, let's ask that question a different way. How is the service owner involved in support? Can we go there and take it from that?No , you read my mind. Okay. So actually let's...you started this conversation with a service level management question you asked earlier. Yeah. I try to be smart. So Let's say a major, mission-critical service has failed.
    Yep. Part of the ITIL process of incident management is a major incident process and many organizations will call the meeting, [xx] the war room together. Everyone will go into a conference room or a bridge will be opened. and everyone, basically all hands on deck will be part of this major incident process.
    Who would be a critical person to be in that room or on that bridge called the service owner, because he or she is responsible to communicate to the business what the current status of that service is and when it's likely to be back up. because they're the senior sponsor within an IT context who owns the accountability for that offering to be provided as required.
    They'd have to be involved in the incident process You follow me there?
    Oh yeah. Let's keep going.
    Problem management. Over and over again, we experience incidents against this service outcome. When there's no one accountable or worried about the outcome as a service. We can totally go and basically live with the repeat issues over and over again, because no one is accountable for it. Everyone's got their little piece.
    But I call that the hamster wheel of death because we're willing to resolve the same incidents thousands of times. If I'm the service owner for that incident, I'm going to be asking some hard questions and get problem management involved and say, "This is not acceptable. I've been called on the carpet ten times this past month because of the same damn incident repeat over, repeat over.
    We need problem investigation done. So they would drive problem management.
    How about change and release?
    Most outages are caused by production changes to an outcome, to a service not because we have a technical failure. That means there's a certain level of due diligence, production assurance we do with release management, and approvals for, you know, promotion and the production that changed, takes care of his scheduling.
    I would want to be, if I'm the service owner, one of the last points of approval, to say A, this change can go. Yes or no based on release having defined that this is production ready and is ready to be moved to production based on all these criteria having been satisfied. So the service owner would be critical, because again, their skin is in the game and they're accountable.
    A critical reviewer and approver of both release acceptance and change readiness for promotion to production. Without that, no one else is accountable for the outcome. They all have their little piece.
    So if I've got a process center for change management, a service owner for hosting, and a business relationship manager sitting in a room and there was some major incident. All three of those people would have different audiences, they'd be responsible and communicate to.
    Yes and if I was the service owner who was the owner a very problematic, unstable service. Be asking some very hard questions around the design, the availability, the capacity, the service continuity, all of those elements.The processes are enabling the service owner. And when they are in lack, the service owner is in a great deal of pain because they're in front of the firing line here if things go wrong.
    There's almost a second org chart.
    Think about your vertical, traditional org charts.
    Yeah. You have development. You have infrastructure. Yep. And each of those have vertical departments, right.
    Yep.
    Horizontally crossing both of these are services and processes.
    Yep.
    So in the same way as processes span functional structures, so do services. But this concept of horizontal management, or virtual management across vertical structures, that's a difficult challenge because right now we have mostly vertical governance, not horizontal.
    Have you seen Prometheus yet?
    No, I haven't.
    Yeah, there's this UI at the end that he initiates where he sees things from inside this 360 degree, 3 dimensional, almost 4 dimensional UI. And that's almost sounds like the horizontal org chart you're talking about. Because literally when I think about the process owner for the change management process, the business relationship manager and the service owner all in the room after a major incident, I start to think almost multi-dimensionally about my organization.
    Because it is multi-dimensional, right? It's vertical as well as horizontal at the same time. Because demand, plan, build, run is a horizontal value chain which spans our vertical org structures and the services do the same.
    I'm on. I totally get. I guess I never realized how multi-dimensional our organization was because I've always been so, well not very flat, kind of bumpy. Well, you know what I mean.
    But right now most organizations only have roles and structures which manage vertically, you know, their domains and technologies and very little governance or ownership for anything moving horizontally.
    It might be time for a COBIT talk.
    We can do that, we'll see if we can get Jennifer to join us.
    We should.
    Yeah, it'd be great.
    We should put someone else over the practitioner, coals of the fires of this. Oh, goodness. It's teatime here in England, or as I call it Truth Thunderbolt Tip of the Day!
    Okay. Remember, Chris, everything that you care about managing should have an owner responsible for the full life cycle. Without this explicit assigned accountability, services will only continue to be managed on a best effort level.
    Not hire nannies carefully. This has been Chris Dancy and Tory Dumolet for Park National Radio. Episode 28, service owner. This is a good one. Again this is one of those ones we could go on for days. Thanks so much, Tory and I'll see you in two weeks.
    Two weeks, take care Chris.
    All right, buddy. [music]

    # vimeo.com/44645527 Uploaded 245 Plays / / 0 Comments Watch in Couch Mode

  5. Troy’s Thunder Bolt Tip of The Day:

    A distributed service desk strategy is practically a given for most organizations. The goal is untangle the current fragmented model and to establish clear and simple support channels from a customer perspective.

    Show Notes:

    The Service Desk To Call When You Don’t Know What Service Desk To Call!

    The Customer Response Center

    The Genius Bar

    Lucy’s Advice Booth

    Shadow Desks

    The Spaghetti Bowl Support Model

    Service Desk Chaos: (Single Point of Contact? You Got to be Kidding!)

    · Outsourced Desks
    · Shadow Desks
    · Application Support Desks
    · Rogue Forward Deployed Desktop Agents
    · Fragmented and duplicate tools and IVR systems

    Consolidation Options (Process, Roles and Technologies)

    Service Desk Inventory

    Tiered Service Desk Model

    Open Tick Initiative

    Service Desk and Service Offerings

    Support is a base element for any service provider

    Outsource Call Dispatch Decks disconnected from the back office Incident Process

    Project Culture vs Run Culture in IT

    PinkFORUM12 pinkelephant.com/PinkForum12/

    Service Desk Facades

    Local Service Desks vs Honking Death Star Desk

    The Service Desk Foyer

    Additional Information on Service Desks

    ITIL Implementation Roadmap (Incident Management / Service Desk)

    blogs.pinkelephant.com/index.php?/troy/comments/itil_implementation_roadmap_part_3/

    Dealing With Rogue Support Agents

    blogs.pinkelephant.com/index.php?/troy/dealing_with_rogue_support_agents/

    Service Request vs. Request for Information

    blogs.pinkelephant.com/index.php?/troy/comments/service_request_vs_request_for_information/

    Listen below or download the MP3 HERE! / iTunes / PinkAPP for BlackBerry, iPhone and Android

    TRANSCRIPTION:

    Welcome to another edition of Practitioner Radio. Pink Elephant's podcast for the IT management community. Welcome to Practitioner Radio: Think Elephant's podcast for the ITSM community, the fastest 30 minutes in ITSM audio. Hey, it's Chris Dancy. This is episode 26, and I'm here with Troy DuMoulin.

    Hey, Chris, how you doing today?

    Doing good. Crazy weather, I think it's because it's May. Thunderstorms last night, and I'm sitting there and I'm on the front porch because I'm getting older so I watch storms now, and make them.

    That can be debated.

    And there's this gigantic bolt, and what's the first thing that went through my head? Troy's Thunderbolt Tip of the Day!! I'm like oh, no, that's tomorrow, it's not tonight.

    Oh we have the same weather.I imagine we're in Seattle right now but actually in Toronto. I thought is was supposed to be April showers bring May flowers. What happened to the fact that we're supposed to be you're on the shower thing now. I think it has something to do with, the heavens have distributed service desk models.

    And they're not all in sync with each other. We ought to bring her back to talk to Chris. Yeah, but they don't pay me to be pretty. So Charlie - Yes? - I've seen, and I'm seeing this crazy the movements here, with people who have more than one service desk, some places two, some three, four, five.

    In some cases not even what they would consider a service desk, just a project team taking ticket something random. Just the other day, I thought to myself, I was trying to log a ticket at my company, and I thought, why can't I just ask for an HR thing through the system? and then I end up sending an email to each.

    So all this decentralized, all these different, what is going on? I feel like I'm in a mad mad world. Well yes, in fact I've seen so crazy that there is the service desk, they call him. You don't what service desk to call. You know, call this desk, if you don't know who to call and they figure it out for you.

    Yeah just recently actually that was creating a customer response center, and it was beyond IT. Because not only were we having the classic service desk, but if you needed the facilities or you needed a fleet management activity or you wanted a support item with your expenses, it was just anything that could be user or consumer base could come to this center, and a kind of Mac Genius Bar kind of setup, as well as the virtual entry points, right.

    It was a single, central point of access to anything user-based. It was kind of cool.

    I like that idea because I'm in a, you know, our company's growing very fast and I never sometimes know who to send it to. And I really do wish I had a what did you call it, the customer response center?

    Customer response center.

    I wish I had a CRC, I'll just use that because I won't remember the words, a CRC in front, because it would make my life as a customer a lot easier because I almost need an oracle. I was at, speaking of this, you said genius bar, didn't you?

    Yeah, I did.

    I was at Rackspace. You ever heard of Rackspace?

    I have indeed. In fact I have a cousin who works there.

    There you go. Down in Texas?

    It's one of the locations, I am not sure where.

    Yeah Okay. Yeah, we don't want to [xx] too much of Troy's personal life. So, yeah, I was down at I will put a picture in the show notes. I'll make sure I do this, remind me. So I've got pictures of this. They actually had a Genius Bar So they actually built a bar in front of the help desk and they put a Smoky Joe's Help Center, like an old neon sign flickering, and and members of the service desk, when they weren't on the phones, would actually man the bar.

    Anyone could walk up and ask any type of IT-related question. But then, kind of to today's talk downstairs in front of HR they had a similar type bar, but it looked more like, you know how Charlie Brown and Lucy had that little 10 psychiatric help sign. Thought you were going to say kissing booth, and that might be a bit inappropriate.

    Did she have a kissing booth? Lucy had a kissing booth. Somebody had a booth in Charlie Brown where they offered advice, it was like Advice 10cents. And I thought, I like the idea of this bar, but again I'd have to walk two different places This is the reality for most organizations, right? In fact, even having a front door is kind of an improvement for some.

    Reality, I think it seems the same thing Chris. We go to most organizations and over a period of time things have grown, whether that's been through mergers and acquisitions, whether that's simply been project by project creating its own support mechanisms. You've got this spaghetti bowl of support channels.

    And there really isn't any clear way to get access for one thing. You have to know the whole complexity to actually understand how to get support. And that's a big challenge. I would think it would be a huge challenge, not only for, You know, first person I'd think of would be a new employee. But just for, like you said, mergers and acquisitions.

    They are rapidly growing companies. You don't know who's in charge of what anymore. It's not like, I know Beth in HR and I just walk up to her and say, hey, I need help with this, how do our benefits work on this. At our company we actually outsourced the handling of our benefits. So I have a help desk I call that's not part of my company that just does that.

    So it is really confusing. And again, that's very common to what we see So you'll often find organizations with a component of their service desk outsourced. Let's say it's tier one kind of office productivity support. But then each of the application groups might have their own kind of special support desk, especially the big ERP systems.

    Then you're going to have the shadow desks that have been created in the business units, basically smart employees that became service desk because they were techies and they couldn't get anyone in the actual service desk to answer their phone calls then you've got these forward deploy or remote support agents out in the branch or on the plant floor, which are quasi-IT salaried people, but they've kind of gone native on you and now they're roaming around doing their own thing our there.

    Or as Sarah Palin would say, "Gone rogue".

    Gone rogue, yeah, absolutely. So this is reality for most organizations, so we think of best practices, they talk about single point of contact and we look at this spaghetti bowl aspect and We pull our hair out because this is so complex. How do you fix this, how do you improve the situation? Okay, it's almost like Troy's cooking hour, so I like a good spaghetti.

    You've got the spaghetti kind of strands, or the shells and noodle, all types of spaghetti. I guess my first question to you does it have to be fixed? We talked one time about pain versus is there enough pain to fix it? Are there times when it would work? Well, you play with the cards you're dealt, right?

    and so reality is, sometimes when you've got an outsource situation the contract's not about to be terminated any time soon, so you've got to deal with the partner you've brought into your family now, and treat like they're part of a family member. Very important. So that front door you've outsourced, so you've got to deal with that.

    But the reality is you've got to acknowledge you have all these different avenues. So rather than just throw the entire thing out, how do we take this bowl of spaghetti and start looking for the beginning and end of each gonna build this more complex, but single channel, or not single channel, or not single channel, but a, let's say, a simplified channel for support.

    pull all these things together would be my first goal. This is the concepts of good, better, best. Yes, you might identify opportunities for consolidation. Let's say in four or five of these desks that you found, shadow or legitimate, there is front level support. Well, maybe you can move some of those people to different parts of the organization.

    The reality is, you've got your front door, and that's both some technology, whether you're using an IVR phone technology, or you've actually got a single point of contact in a service desk. But then I've got to take the front door, whether that's push five. Then you go to the support desk for Application X. Push three and you go to customer support center.

    I take that front door and I've got to now clean it up so that front door will then have to deal with how do I pass calls through? Is it going to be warm transfer, where I take the call, try to solve the issue at the front end here? I can't do that, so I will then warm transfer you to a second tier desk, a specialized desk or is that gonna be a cold transfer where I just drop you into a queue?or is that going to be recognizing that the second tier desk actually is a frontline desk, because I literally allow you to hit number three on my IVR technology and you go directly for SAP support.

    Speaking of IVR technology, I've noticed a lot of times when I call different support desks, every single support desk I've called probably in the last ten years who has any type of IVR, I always get the same message: choices have recently changed. Have you ever noticed that? How often are they really changing or they just know that they do not want me to wait and hit the numbers I know.

    I'll hit zero and go to a live voice.

    Exactly. You talked about consolidation, and I think that's an interesting concept. I want to pick your brain a little bit about that. Does consolidation have to be a physical move of people, does it have to be using the same tool? Can it be a consolidation of ideology?

    OK, so consolidation can come at different levels so let's think about it.

    Yeah, I knew you'd know this, I knew you'd know this one.

    So you have process consolidation, we still want to have one common process for gaining support, right? So, there's a way to understand what a first, second, third level support process is, and how things move trough that queue based on who is supposed to do what. Then there are roles and so, you can have first, second, second, third level roles distributed.

    You can consolidate people relative to the role. Then there are technologies. And literally you have the telephony IVR technology consolidation and you have the ticketing tool consolidation, right? So, you can look at consolidation on of three levels, but most organisations do that the beginning is taken an inventory, where all the possible elements of support, who's doing what, what are their areas that they're supporting, what kind of roles do they have, what technologies are they using.

    So it's almost like they map out their support graph and all the different touch points, They start pulling the spaghetti strands apart and looking at each one. Because until I figure out what I've got I can't make a determination about what I do as a next step. But once I've got this inventory of practice, I'm not even going to call it a process maturity assessment, that's how do I compare against some framework like ITIL or COBIT, just who's doing what, and with what and by whom.

    Write it down down, cause until it's written down it's not true. Yeah. My favorite Troyism. Now the ghost desk, the shadow desk have now been identified as, you know, there's legitimate people here and they have a and they have an impact to the bottom line. Now I've got to figure out the strategy.

    So let's put aside the inventory for a minute, right? Let's say in the strategy where I do have a single point of contact relative to the IVR telephony. There's a single number. Okay. And there are neat technologies depending on if you're a global organization, if you're calling from a certain area code, you literally get kind of funneled to one desk versus the other based on based on that's not Alright, so it comes to somebody.

    And then on that front level, there's this determination, whether it's again automated or it's manual, where this call should be routed to. Do I handle it at the front level, and what kind of things do I handle at the front level? You've got desktop support. No. Shrink-wrapped applications, password resets, request fulfillment activities, facilities requests, whatever that is, that's tier one.

    And then you identify what kind of person with a relative salary level will I need at tier one? What skill levels are those generics skill levels? So that's my tier one. Then I've got this tier two concept. And now I could have specialized desks, so each business unit might have instead of application desk, or each application might have it's own desk, whatever that might be, but in your inventory, again you've kind of figured out they might have multiple roles there.

    I've got this tier two desk, how do I pass tickets or calls through from tier one to tier two? Because, I either have to, kind of, go through that automated IVR direct, and literally that becomes now a tier one desk, right? Or it's an indirect where it's a pass-through, and now that's either going to be a warm pass-through or drop into a queue.

    And then, I've got to come up with policies about how long I want to wait for that to occur, the response time policies. And then what kind of role do I need on that tier two desk? Because, let's say I have identified as more of a specialized desk, they're a specialized skill set on a specific technology your application, that means they're going to have this kind of salary expectation, and if I've got that to find and I find mismatches of people that it might be more of a tier one type of roll within that tier two desk, well that person might be identified to move to the tier one organization whether that's outsourced or not And then, finally, what's my tier three?

    And, this is where I get into my supplier integration as well as my engineer type, back office, third level role. so now I've got to have underpinning contracts in place, with cloud suppliers too, like Service Now, right, because if I have an issue My service now instance. I have to have service desk strategy incident management process connected with my external suppliers.

    So that whole model now is kind of taking this bowl of spaghetti and stretching each of these lines out and saying, here is the channel of support for each of these avenues and here's how it passes from tier one, tier two, tier three. Now, we consolidate on technologies because we're going to have one common process across this strategy.

    I'm going to hopefully have one technology, and if not, then all the technologies I use have to be kind of configured in the same way, which is complex and costly. Well that's bit of a rant there, but that's kind of how you think through this process.

    The two things about that stream of knowledge that you called a rant. One, I read someplace last year, and I'll have to dig up the article. There's actually a consortium of service desk vendors, all sorts. Little service test honors, big, all of them actually last year created this I think its called open ticket initiative so you can do what you said.

    Transfer stuff back and forth, even though you have different tools. It was almost like someone created a framework for this is a basic incident transfer and It was kind of interesting, because when you talked about your level three, that's the first thing that popped in my mind. But, as you were talking about all these different, you know, before you consolidate, you've got your different processes, maybe different teams, some different tools, different skill sets.

    My mind started going back to some of the podcasts when we would talk about creating service offerings and how you would look at all the resources around a service, whether it's software people, process, hardware, all the different things that you bundle up and make a nice little service offering for someone to put into a catalog and/or portfolio.

    And I wondered, could you use the skills that you or maybe someone in your organization who has done service bundling to help you in your consolidation efforts. It seems like they have similar skills.

    Well in reality what we're talking about is a support service.

    We've never talked about that; is there such a thing?

    Absolutely, outside of management there's always, a macro operation model will have you know planned processes, build processes, run and support. Support is an understood concept, whether you're coming from a business manufacturing financial industry type concept or an IT concept, support is just a set of capabilities and a service you need to It's a base element.

    it's a base element, any operating model. You have to build a support model That's good to know that we won't be out of business then. Not at all. And that's why you can actually use technologies that were traditionally used even for, I don't know, maintenance within a manufacturing plant, like IBM has, and use it in service management, because the reality support, support, support.

    You've got to come up with this model regardless of what you're supporting, and understand the complexities of the different tiers of support you want to put behind your offers. And that catalog, as you described it, would actually present your service offering, called support, in its different flavors you know, you have that service desk element, you have the forward deploy concept, or desktop support aspects of this you know you go to my Telco right now and I can go online and actually have instant chat relative as a channel for giving us support.

    So all of these are [xx] of a base capability or offer called support. Speaking of combining support and consolidation models, have you ever heard of GoDaddy? Oh yeah, absolutely. know Canada's far away. Well I don't know. I use GoDaddy. I always get in trouble because people always go, Chris, do you think America only knows that sort of stuff.

    Well I don't know. Do you have water in the US, Chris? no, we're not clean. We have Dean Cayman, though, and he creates machines to clean water. But Go Daddy, for those of you who don't know, is an Internet hosting stuff. But when I've called then for support I've noticed that their support people also review - I don't know how they do it, they must be really down to.

    But they are reviewing my contract and always commenting, oh, did you know you're about to expire on this, okay change the DNS address to this, oh and did you know we can offer you this, this and this. It's almost like their support people are also marketing slash sales people at the same time. It's cross sales.

    Absolutely. I mean that's really, that's synergy, the big word there, right. You're using multiple talents.

    So is there such a thing as a traditional IT service test that would invoke some of that synergy and why you're helping someone?

    Let's play a scenario through. We've had this conversation in the demand and service catalog in the request right? But let's say for the moment, that I had access to the services that we offer, which is our general catalog, then I can also look at your subscribed use of that set of offers and I could actually now see the actual use of the different service elements that you're currently subscribed to.

    Of course there's even a forecasted target you might have set and I can say/ Listen, I see that you're about to move from hosting level one to hosting level two and, we can do that proactively, otherwise you're going to be in overage charges. Right. Do you want to do that right now? Or, let's talk about ways you can, kind of, keep yourself in the bounds of hosting level one.

    But that means we'd have an accurate understanding of our consumers. What their currently subscribed to in the catalog, and their current demand, and what the current consumption is against that demand. it's really hot, and that's what's happening in that Go Daddy scenario. Again, this wasn't invented just for IT service management right?

    These are simply elements of building this continuity of the base element of support. And upselling now, not just upselling for additional profit, but literally being on the side of the consumer, helping them to engage in do things better for themselves. Yeah, and up selling isn't always a profit thing.

    There are a lot of hospitals and non-profits, people that aren't out to make money that when you're meeting with their support personnel, they give you choices. Like you've said many times, there are lots of decisions you can make around that sort of thing. Now let's play this scenario where you've outsourced the service desk because - I still, I like the scenario you just did.

    I would love, I would go back to a help desk, I'd be on a help desk again if I had that ability. I would love to know what people were using. But reality is a lot different, in IT anyway, because we've outsourced the service desk some manage service provider based on low cost. And we've said this is what you shall do and no further.

    After that everything is now kind of pitched into the wall, over the wall into the partition our organization, because there's no continuity of belief that is just part of the same support system. So, there's no information for that poor call dispatch center that 's been outsourced. And, we love to hate them because they're doing such a poor job, but yet, we've pushed them at the end of our hands, saying, 'You're not part of this family.

    We've just given you this Joe job here to do,' and you are not going to get any information other than just take the call and dispatch it. So how is that organization empowering, A, their front door, but B, increasing the satisfaction of their consumer coming in through that front door, through this disjointed, that's your spaghetti string over there and this is mine.

    I mean that's just mind boggling, to think about how fundamental, because we're always, you and I, we talk about different processes and we've talked about frameworks and our printing models and governance, but, you know, support is a base element and how it really plays a big role in this idea of, you know, distributed or service desks, you know, and support models.

    I guess distributive support models.

    Yeah, distributive support model's a good way to say it. Now, but think about it this way. We've had this conversation before. The project culture versus the run culture. Now is this the one where everybody wants to be an artist? Everyone wants to be an artist and everyone wants to be in research and development right.

    Everyone want's to be focused on the plan-build side of the model, and not the run. So, in that model we don't have good ongoing support, because everything is focused on projects and new capital initiatives and net new value creation. Run, that's not sexy, I don't want to bother with that, we'll just kind of keep things as they are.

    Unless you're Flo Jo Who's Flo Jo? I don't know. She's some girl from the Olympics like a decade ago. She was a super fast runner. Sorry. Oh, I see. Okay. Dude, you know my cultural references are [xx]. There you go, Flo Jo, I've got cultural turrets Flo Jo right, but let's say I'm in project mode, which is where most IT cultures are right , all the project mode, so in the absence of good run, all they do is create new support models for every project.

    So project A, B and C all create their own support models and end up creating support processes and support functions by application, by project. So inthis model[sp?] of forever focusing on the project versus run which is where support lives. I'm not improving the situation. I'm on going, adding complexity and distraction to the environment, adding more spaghetti to my spaghetti bowl.

    Now that's amore. That's amore. Is the problem that we need to make RUN sexier? We need to get more interested in it, I mean...We've got to bring people up from the fact that, you know, yes, plan build is important, but it only produces the potential for value. You don't deliver value until you actually deliver it in a stable-run environment.

    Right? So we have to get at least equal footing for RUN. Because that's where value is delivered. And the current satisfaction for the RUN processes and the support processes is at a low level because We have not paid attention to it, we haven't pulled apart the spaghetti bowl and created these distributed support channels.

    Talking about the RUN versus the project and into the idea of consolidating this support model. It kind of brings me back to some stuff I've seen at the Pink conference. By the way, congratulations on your Arizona event.

    Thank you.

    You guys are having a big, when is that.

    That's in August, that's going to be in Scottsdale.

    We'll put a link in the show notes. Check out the pink form in August. But it reminds me of a couple of things I saw in pink the past few years, one was Paul Wilkinson talking about ABC.

    Yes.

    And then I think you guys might even had Ian Clayton this year talking about outside and thinking.

    That's right.

    I mean I would think those two, you know culture in them and customer centricity, these things, that would think they would be really important and if you're going to do this base element, to do it right.

    Culture is what's challenging right now because we prefer to live in this, this is my spaghetti-verse and that's yours and this is my tool and that's yours, this is my process and that's yours, even though we're in this cohesive, integrated support organization.

    Maybe we leave everybody's spaghetti alone and just give the table one spoon.

    Yeah, we've got to figure out something relative to changing status quo.

    Yeah.

    But the US buck and Ian Claytons concept is exactly what we're talking about here. And I'll give him total due. We have to look at it from the customer perspective, the outside-in perspective, because when I create these support channels, they have to be simple, clear, and understandable. Because I have to know how to get support and how it occurs.

    And that's the outside-in thinking. I had to design this distributed model from the customer experience, not from the inside, what's expedient for technology type organizations to do. Or how do I maintain my my influence, my power, and my tool without letting go of my toys. Which would be fun for the designer type people you were talking about, to envision these magical customer experiences.

    When it comes down to the runners, the people making those experience happen, where are those people in the organization? Well, to your point, there's actually two parts to this discussion. Because we will often paint the front door and fix up the porch but not deal with the back end of this thing.

    We actually are guilty many, many times of basically building a new front door and a new front porch, bringing in a new outside supplier to do front level, first level support, never fixing the back office IT black hole, so all we we keep getting is someone else to yell at.

    In architecture, that's called a facade.

    A facade, we change the facade, but then, you know, so people are on the front level, front door, answering phones and taking responses and being very courteous and polite.

    Yes.

    Maybe in a different and foreign accent, but the reality is they're being responsive.

    The Greeks had brilliant facades on the fronts of their buildings. You were thought you're walking into a temple and, you know, it was nothing once you got through the door.

    Well, it's kinda like the Vegas casinos, right? It's all a facade. Go inside.

    We 've covered spaghetti, Greek history, facade. I mean, what doesn't this show have?

    That's right.

    Oh, my goodness.

    So I can change the facade but not fix the back office black hole, the hot potato syndrome, the I lose the ticket as it leaves the service desk and never see it again until someone screams loud enough. Unless I fix the end to end process, which is this distributed model, second and third level, and have one process coherently holding that together I fix nothing except getting someone else to yell at.

    What about the cultural aspects? So when you're collapsing - for lack of a better term - multiple support elements, whether they be rogue desks, shadow desks, rogue people. Do you ever have to consider that maybe the mini desk sits in front of ERP, those people might treat their customers completely differently than the HR mini desk sitting in front of HR and how do you align that mindset?

    Well, there's definitely a view, and some reality to the fact that the closer the desk is to their consumer, the more affinity that desk has. And understanding of their knowledge.

    That's interesting. So the closer a desk is to the consumer - I have to use these simple words, sorry - the nicer that desk is?

    The better they understand the context within which they're supporting.

    That's true. 'Cause that's different than they heard, they better understand it. They can still be mean, they just know they're mean.

    At least they understand the context within which they're being mean, they understand the culture, that their clients better. And so that's why I'm not advocating let's for all just go to one central hunking Deskstar desk, right? We still have to maintain the distributed model which has some elements which are close to the consumer, some which are central 'cause that's still a balance we have to find but then we have to pull this together because what happens is the very remote elements of our support model will start to feel closer affinity to their consumer client, especially if they're actually getting paid by that - it's a whole other conversation - maybe we can do that next time and how do you deal with that.

    'Cause it really is a two-part podcast.

    Yeah, so we can deal with the rogue support agents in our next discussion. But how do I keep them part of the team connected but yet still close in providing that value added knowledge-based service that you're doing on the plant floor in the branch.

    Totally.

    I think if I was like a consultant and like someone actually paid me for my advice, I would say, "Okay, before we even look at the tools and the IVR's and everything." You know, doing your little mapping exercise on our graph of support, right?

    Support Model as a support strategy we are talking about.

    Before I did anything with tools or I would just want to sit with each team and make sure everybody was consistently answering the phone the same way.

    Well that's the front door. But in the end I've still got to get this big picture of what does tomorrow look like Yeah.

    model, front to back. And then I take my inventory and I start mapping it and understand how to better consolidate improve the current state to where I want to be, well maybe in today's show some people at least have the idea that it's OK that if the front door is done and you don't have to do the whole house, you can just maybe do the front door and the front room.

    First step. Yeah. Because again, you're going to change the front door, paint it up and make it nice and pretty and easy to access. But unless you fix the back end, you're eventually going to be in the same place you were. Right now we're foyer and next time, next show, we'll maybe move into the main living quarters.

    Absolutely, I like that. Troy, do you know what it is? It's that time. It's time for Troy's Terrible Tip of the Day! Okay, so Chris, a distributed service desk strategy is practically a necessity or a given for every organization. The goal is to untangle the current fragmented model and to improve the clear channels of support.

    Until next time, part two, the distributed service desk rogue agents and moving into the main living area of the base element. This is Chris Dancy with Troy DuMoulin and we'll see you in two weeks.

    # vimeo.com/42491906 Uploaded 411 Plays / / 0 Comments Watch in Couch Mode

Follow

Practitioner Radio

ServiceSphere PRO

Browse This Channel

Shout Box

Channels are a simple, beautiful way to showcase and watch videos. Browse more Channels. Channels