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.
- 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
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.
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.
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.
Horizontally crossing both of these are services and processes.
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.
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]