Guy Nadivi: Welcome everyone. My name is Guy Nadivi and I’m the host of Intelligent Automation Radio. Our guest on today’s episode is Troy DuMoulin, Vice President of Research and Development at Pink Elephant, a premier global training, consulting, and conference service provider. Now, I have no doubt that many members of our audience have either taken Pink Elephant training or attended a Pink Elephant event. And Troy is a leading ITIL, IT governance, and Lean IT authority with a solid and rich background in executive IT management consulting. He was also one of the 12 architects on ITIL 4, and given his extensive expertise with business process re-engineering in organizational transformation, we thought our listeners would enjoy hearing his thoughts on these issues from an ITSM practitioner’s standpoint. So we’ve invited Troy to come on the show because we’re eager to get his insights about the intersection between ITIL and automation, AI, and other transformative technologies. Troy, welcome to Intelligent Automation Radio.
Troy DuMoulin: Thank you, Guy. It’s definitely a pleasure to be here today. Guy Nadivi:Troy, our show is very focused on an IT executive demographic, all of whom I’m sure have heard of ITIL and ITSM, but I wonder if you’d indulge us a little bit and define these from your perspective.
Troy DuMoulin: Absolutely. It’s always an interesting question. I’m asked what is ITIL because it really is what we’ve always done. In my role, Guy, I often get asked to come and speak to senior leadership teams and describe to them the goings on in the ITIL and ITSM worlds. And I ask them a few questions before I even start. I say, “Tell me, guys. Today do you have practices and management capabilities for sitting down with your customers and sitting down and asking and figuring out where they’re going and how you can help them?” “Yes, of course we do. Obviously.” Okay. All right great. Then you take those conversations and you capture those requirements somehow in a meaningful way that you can verify you’ve heard what has been said and is shared back. “Yes, that’s what we do.”
Troy DuMoulin: “All right, then you hand those over to someone else to kind of figure out how we’re going to blueprint it and then we’re going to actually get ‘er done, whether it’s a project or not a project. We have to get it acquired or built, and then we’ve got to somehow, again, validate before we move it into production this thing called ‘the requirements’ that we first gathered on the front end.” “Yes, your point?”
Troy DuMoulin: “Hold on a second. Then we move those things into production once we verify that it won’t blow up upon arrival, and of course then you get the honor to support and run and deliver value that you’ve initially helped develop and co-created with your customer.” He said, “What’s your point?” I said, “Congratulations, folks. You’re doing ITIL.” Because all that ITIL has ever been, IT Service Management, and that’s what we talk about, is a set of organizational capabilities for taking requirements or demand and translating those through a complex value chain to the other side until we get value on the other end. Basically, it’s a value chain. And the recent version of ITIL 4 is very much oriented and visualized that way.
Troy DuMoulin: The interesting thing is people often think that’s service management over here and that’s architecture over there and that’s project management over there and that’s software development over there as if somehow these things are all separate, distinct, and independent. Well, they are different organizational capabilities. I’ll grant you that, Guy. But here’s what ITIL has always done. It’s the gift of ITIL, I like to call it. 3-step process. Every single major version, iteration, whatever you’d like to call it. It figures out what we’re all talking about, so it aggregates, it pulls in. Aggregates is the key word here. All of the different topics du jour. Things we’re talking about.
Troy DuMoulin: And then it integrates what seemingly was independent but is not, because these things all work together, or they should. And then it republishes a new picture, codifying the new holistic view of the IT management workspace. And this new picture becomes the new version. So it’s always a lag indicator. It doesn’t lead, it doesn’t invent anything. ITIL has never invented anything, and service management is just another way without using the word ITIL to talk about just the general organizational capabilities, AKA things we wish to be good at, to take, demand and produce value.
Troy DuMoulin: I chuckle. The conversation is usually starting, “Can you tell us about this new thing that you’re trying to introduce to us and prove to use why we should do it?” And in essence, because I’ve just asked them these questions, I say, “Congratulations, folks. You’re doing everything ITIL talks about now. Not one thing that ITIL covers doesn’t already exist in your organization. It’s not whether it exists or not, it’s whether you have it under intentional governance and management and whether you understand how it all connects in the bigger ecosphere of value generation.”
Troy DuMoulin: And so that’s the initial going in conversation is congratulations, you’re already doing it, but are you focused on it? Because typically they’re not. They’ll be focused on technology, maybe on structure, but very, very, very infrequently on an operating model of IT management practices. That’s service management. So what is service management? Yes, anything your organization does in the soft skills people side process area we could call ‘service management’. I’m not sure if that was the answer you were looking for, but that is in essence what is service management today.
Guy Nadivi: It’s interesting that you define service management that way because in a recent article on Pink Elephant’s blog, you make a provocative statement that, quote, “Service management process and tool projects are really organizational change projects in disguise”. In your experience, Troy, what percentage of ITSM projects successfully transform an organization? And what factors do the successful ones share in common?
Troy DuMoulin: Yeah, so let me unpack that statement a little bit. You know what they say; hindsight is 20/20, or wisdom is a cumulative experience. So after 20 plus years in the industry of seeing many projects not succeed, I had to do a little insight here in thinking about the basis of what you just asked me.
Troy DuMoulin: The reality is, most organizations don’t recognize that the true problem we’re trying to solve here is to gain agreement and alignment of the organizations, plural, inside our value chain so that we can agree to agree what we’re going to do, how we’re going to do it, and do it hopefully in a consistent, coherent and high velocity way.
Troy DuMoulin: In essence, it’s an organizational change project. The process and the tool are very important but they’re not the goal, they’re enablers to the goal. I sit down and I hammer out through this dialogue all of these discussions with folks around “how are we going to get stuff done”? We finally, through negotiation, horse trading, all of that, agree to agree what it is, but then we’ve got to actually codify it quickly before we forget and leave the room, otherwise we leave the room and it’s open to subjective debate. So we’ve got to write it down and constitutionalize it. We the people find it self-evident and true and we have signed here. Documents are important, but more as a constitutional aspect of agreement.
Troy DuMoulin: And then you’ve got to have this tool. You’ve got to make it visible. The principle of Jidoka in Lean says you cannot govern or manage what you cannot see so putting it in a tool makes it visible, makes it measurable, makes it even automated in the sense of flow of work and the visibility of the flow of work or lack thereof.
Troy DuMoulin: The tool’s really critical as well. We’ll call it a critical success factor and enabler, but it’s not the goal. The goal is agreement. We have all these diverse organizations which want to have the right to independent thought and practice. The document was simply to document agreement that we finally hammered out. The tool was to make it visible. But here’s the problem; the goal or the deliverable of the project was the agreement, not the document nor the tool. And so they’re enablers, you can’t work without them, but most organizations who don’t recognize that what they’re really up against is a people change project, which is supported by processing tools, will invariably fail because they focus on the wrong stuff.
Troy DuMoulin: Guy, think about this; how many times in your professional career have you seen people spend hundreds of thousands of dollars, if not more, on process documentation and tool implementation, go live and the very next day nobody does anything different. Right? It completely fails to deliver the value after a six month to a year project. Have you ever seen this?
Guy Nadivi: More times than I care to recount, actually.
Troy DuMoulin: So what’s the definition of insanity?
Guy Nadivi: Doing the same thing over and over and expecting a different result.
Troy DuMoulin: But this time it’s going to work. We’re going to slap the easy button. So here’s your answer; most organizations fail miserably when they think there’s a tool or a process project and this is what I’m not proposing. I speak a lot about DevOps and I talk about the DevOps tool chain. It’s obviously a great thing if I could find a way to automate code flow from the point of code commit all the way to deployment without stopping and I’ve got all these things verifying, production assurance, verification of test result, et cetera and I can deploy in a high velocity way, this would be awesome. This tool chain sounds wonderful.
Troy DuMoulin: But, there are five questions that I’ve been able to articulate, and I’ve written it on my blog. Maybe we can link to it, but the reality is these are the five questions that CIOs and leaders would have to be able to answer before their organization could ever use a shared tool or tool chain like I’ve described. The first question I’ve kind of already articulated. Can we agree that we need to agree across silos on anything? Agree to agree. That’s the first question. Second question; can we agree, please, on one way to do it? Because unless it provides strategic differentiated value, variation in Lean actually has an impact on quality, costs, and speed. Can we agree on one way, please? One way? OMG, as long as it’s my way. No. One way.
Troy DuMoulin: Okay, third question; can we agree that we’ve got one way and we keep it simple? Because we’re engineers, we’ll over engineer everything to the point of almost un-usability. Question four; can we agree if we’re going to do it one way, can we do it with one tool? Unless it’s a strategic differentiated tool. Again, a system of parity means it doesn’t give us more money to have multiple variability here or get us more market share, it just costs us more in impact speed. So can we reduce variability and come up with one tool to do the one way? And the final question is can we agree that that one tool isn’t a point solution or best of breed, it’s an integrated tool system. Folks, it’s a tool chain. The output of one tool becomes the input of another which is the output, et cetera, et cetera.
Troy DuMoulin: And this is interesting because these five questions you would have to be able to answer as a leadership team before that organization would ever use a shared tool chain. Because where I work and how I often see this play out, Guy, is that people can’t even get past question one. And none of those questions are actually process or tool questions, really. They’re organizational, culture, leadership, and organizational will. And what I typically see is not one shared platform is a service technology being used in a multi-tenancy way by product teams. Each product team develops their own tool chain. And nowhere in any DevOps literature have I read that’s the actual intent.
Guy Nadivi: You just touched upon the fact that, to begin with, people just need to agree to agree. And Tony Saldanha is a former Vice President of Proctor & Gamble that recently appeared as a guest on our show. He published a book in 2019 called Why Digital Transformations Fail, which claims that the failure rate for these projects is as high as 84%. And Tony attributes that high rate of failure to basically two things; lack of leadership and lack of creativity, which you’ve kind of touched upon. But I’m curious, Troy, from an ITIL/ITSM perspective, what are the primary factors you see derailing organizational change projects?
Troy DuMoulin: I completely agree with Tony’s premise. Let’s take it from this angle. Two things. Again, as you mentioned, I’m a Lean advocate and Lean leadership is a big part of the philosophy of how Toyota succeeds year over year and is still one of the highest brands. And they talk about persistent adaptation towards truth north values in a direction. This is the premise, though; true north means we have a shared outlook and a shared view of where we’re all going. Andy Stanley was once quoted to say, “We all end up somewhere. Some of us actually get there on purpose.” So action or movement in its own right is not value necessarily. It’s a perception, perhaps a value, but it’s not necessarily unless we are getting somewhere we plan to go.
Troy DuMoulin: That being said, that means that leadership in this question, in this situation, has to basically deliver two things, and this is a principle out of the Shingo Institute connected to Utah State. That leaders create systems thinking, we the people include all of these different stakeholder groups both our brand and all those embedded now 3rd-party vendors we call partners. We the system, right? Systems thinking. And then the other is once we have a system identity, constancy of purpose. We’re all going there. Where are we going? We’re going there. We’re going there because velocity is speed with direction over there. And we’re going to do it the same way. We’re going to share the same values, beliefs, practices, and the same basis for prioritization of work. And this is what leadership is. It’s called alignment. Pulling everybody together pulling in the same direction. And then we get velocity which is speed with direction.
Troy DuMoulin: So this principle of failure is key because we lack systems thinking. Or if we think systems, we only think technology systems, because let’s take the word systems integration. So I have this vision in my head of a systems integration approach to technology. Data layer, infrastructure, all of that, application layer in an integrated system. Well, to use that integrated system, systems integration, I would have to have an integrative set of management practices because that’s what it’s automating. Which would mean I have an integrative organizational context. We, all the people, work together in a cross-functional product team like this. Think of it in your mind like a three layer stack. Yes, I have an automation layer, but I have a practice layer and on top of that an organizational layer, or if you want to flip them, organizational layer comes first as the basis and you go up this way when we don’t think systems thinking, we only think technology.
Troy DuMoulin: But again, that’s a means to the end. Systems thinking, if you’re going to use that premise – because we can have a management system, a technology system, an organizational system – is to have this much more holistic view. Because with integrative tech, it doesn’t mean I’ve got people to agree.
Guy Nadivi: Speaking of principles, Troy, principle seven of ITIL 4, the last principle of the latest ITIL framework is, “optimize and automate”. I’ve read that this principle’s considered by many to be a first step towards acknowledging the need for more AI and automation in ITSM. From your considerable ITSM practitioner perspective, where do AI and automation add the most value to ITSM?
Troy DuMoulin: Well, it’s our business, first of all. We are in the business of automation and technology so we should be good at doing that. And what do we typically automate? First of all, if we can standardize a practice, we can all agree that this is what we’re doing, and then stabilize it, then we should automate it because we should get onto higher value heuristic versus algorithmic work. But that would be dependent on us agreeing to stabilize and have standards, which by the way is a dependency for all of this. And if we can actually do that then awesome. We should automate it because machine learning and artificial intelligence are excellent at detecting patterns that we the people can’t see because we have inability to see massive data correlation.
Troy DuMoulin: This is data analytics, machine language – excuse me – machine learning, data science. This is the whole basis of what information technology is as compared to operational technology. Information technology is to manage the information and data in such a way we can make decisions based on the automation of data correlation. So we the people, can be learning from machine learning and pattern recognition, AIOps, et cetera. I have an event. If I see so many events of a certain nature within a certain timeframe, maybe that might predict a failure, let’s avoid it. Or can I see this event so many times within a certain timeframe? Show me there’s a pattern with an unstable environmental component, I should remove, AKA problem management. So machine learning, artificial intelligence, the automation of all of that helps we, the people, make better decisions which is the premise of information technology versus operations technology is machine teaches machine. Do this, change this because this condition is met for the purpose of machine automation.
Troy DuMoulin: So this is critical for us to make better decisions. But take a page out of Google’s SRE. They say 50% of what we do we’ll call toil. That’s the stuff the manual administration kind of standard operations, and we’d like to reduce that as much as possible through automation because the other 50% of assisted men’s time should be on innovation, it should be on finding ways to automate the thing we called toil so that we could get up and start working on higher value, more heuristic work. We can’t do that well without knowing what the data says and that is the value and the blessing of machine learning and artificial intelligence.
Guy Nadivi: Troy, for the CIOs, CTOs and other IT executives listening in, what is the one big must have piece of advice you’d like them to take away from our discussion with regards to organizational transformation?
Troy DuMoulin: Yeah. We need to go back to your first observation that when we realize that transformation really is a people change project, that really process and tool projects are people change projects in disguise, and that process and tools, while critically enabling, are valuable, they’re not the goal. They’re the enablers. They’re not the goal themselves. And if we can focus on first principles in this way, understanding the organizational alignment is the predictor of systems alignment, then we’re going to get somewhere but not until we realize that that is the goal.
Guy Nadivi: All right. Looks like that’s all the time we have for on this episode of Intelligent Automation Radio. Troy, I can say with confidence that you’re the most distinguished ITIL/ITSM expert we’ve ever had on this podcast. And I’m sure I speak for our listeners when I say it’s been very educational tapping into your insights to gain a better understanding about this space. Thank you so much for sharing your perspective with us today.
Troy DuMoulin: Thank you, Guy, for inviting me.
Guy Nadivi: Troy DuMoulin, vice president of research and development at Pink Elephant, a premier global training, consulting, and conference service provider. Thank you for listening, everyone, and remember; Don’t hesitate. Automate.
