From the course: Putting ITIL® Into Practice: Applying ITIL® 3 Foundation Concepts

Root out variation and dependency - ITIL Tutorial

From the course: Putting ITIL® Into Practice: Applying ITIL® 3 Foundation Concepts

Start my 1-month free trial

Root out variation and dependency

“

- [Narrator] The fifth and a vitally important way of applying ITIL foundation concepts is relentlessly rooting out variation and dependencies. It's a good assumption that you're pretty technical if you're watching this, so I want to use a technology example to illustrate, perhaps, the most important point I can make to you on how to go about applying ITIL foundation concepts. Way back in the day, there was a network protocol called X.25. It was great for use in places where you couldn't count on nice, clean circuits to ride. It was great because it had super high error correcting overhead. You knew that those packets were going to get through eventually. It was necessary and useful for those circumstances. Along comes fiber and all of a sudden, you can count on nice, clean circuits and you don't need all that overhead. Here's the point, as the amount of protocol overhead required is a function of how messy or clean the circuits used are in my example, the amount of overhead you'll need in reaching the outcomes of all the ITIL processes will be a function of how messy or clean the target you're managing is. That's why we need the fifth way, relentlessly working to reduce unnecessary complexity that is irrational variations and dependencies. If you learn to do nothing else from this course, but take this back on your job and apply it, you'll get a lot of value out of this course. Debounce practitioners have a metaphor for this, they call it pets versus cattle. Pets are all unique, we give them names, and they're all cute, et cetera. It's kind of like what we do with traditional servers, really, each has a name, this one has a utility drive, it's unique, this one does not, it's unique, this one's running one version of the software, and this one is not, how cute? Well, not really because wherever we have these snowflake entities, meaning each one is unique in some way, like snowflakes, wherever we have these snowflake servers, snowflake switches and the like, we have to meet and talk about stuff. When we have to change something or where we have a release or we have a problem, it takes longer to figure out problems, incidents, risks et cetera, it adds overhead all the way up and down the stack, so not so cute. To me, reducing variation and maximizing standardization is a huge part of successfully applying ITIL. Quality experts don't always agree on everything, but one thing they almost always agree on is that the one thing that consistently erodes the quality of a product or a service is when you allow variation and unnecessary dependencies to creep into your development and delivery processes. Processes need to be repeatable and standardized without unnecessary dependencies and variation in order to deliver high quality and value at high velocity. I like to sum it up by saying that, through ITIL, unnecessary variation and dependency is discouraged, while standardization is encouraged. And that includes variations in skills, knowledge, and mindsets of people, variations in how processes are performed, variations in terminology, variations at the hardware, software and platform levels, variations in service levels, availability, performance, and so on across services and processes. Variation and irrational dependencies are our number one enemy in IT. For example, when a client of mine continued to have nagging issues with Switch configurations because the three brands of Switches they were buying all had different default settings for key parameters, leaving daylight for misconfiguration. Simply going to one model of Switch relieved the whole set of issues so do yourself a favor and move to vanilla, or whatever flavor you like, whenever you can. Our other enemy besides variation, as I mentioned, is dependencies. Think about it, why do groups need to meet at all to discuss a change? Why do you have to package changes into large, monolithic releases? The answer is dependencies. Dependencies drive the need for process overhead. Lose the dependencies and you lose the overhead. This includes both dependencies inherent in our technology, infrastructures, platforms, applications and services, but also, dependencies introduced by our own work practices and our own mental models for how we manage services. Here's an example from one of my clients who started with a two-year release cycle with lots of people in the room discussing everything, you got it - dependencies and variation, and afterwards, having lots of stuff blow up in their release, to getting to a release every year, to every quarter, to now, releasing every few minutes. How do they do that? I'll tell you how, by relentlessly rooting out dependencies. For example, they eliminated breaking changes by using data contracts with web services instead of accessing the schema directly. And they began using versioned API's to allow other's to move when they were ready and not be broken in the meantime. They instituted lots of changes like these and voila, lower dependencies related in lower process overhead and faster time to value. To summarize, perhaps the most important thing I can get across to you in this course is this, our enemy in IT is unnecessary complexity, unnecessary variation, and unnecessary dependencies. The critical business need is to move ever quicker with quality when introducing change into the Ecker Systems on a massive scale, and complexities to the point that they cannot be comprehended in one mind. A common approach is get the process out of the way. The well-intentioned but flawed thinking in that is that process equals overhead, so less process means less time required to make changes. This is true for bad and bloated processes, but there's a better path to achieving the outcome of moving quickly with quality, relentlessly rooting out unnecessary dependencies and variations.

Contents