Troy’s Thunder Bolt Tip of The Day:
Justifying process improvement starts with determining if you can really tolerate the status quo. ROI can never be accurately expressed without understanding your current costs and risks
- 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?
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, 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?
sorry, i know sorry that will be the last, it takes real courage to Well it certainly does.
Some navel gazing.
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.
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.
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.
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.
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 Nature99 .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.
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 livethe 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.
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]