taruu :: home

Service Management Training, Consulting, and Support Materials

Green is more than just part of our color scheme.

Ask us about our 1% for trees pledge.

Exploration Seminars --New!

July 27

When Does It Become Service Management?
These days, we talk about ITSM pretty loosely. We use guidance from various sources like ITIL or CObIT, presumably to improve Service Management practices, but is that really the case? What makes Service Management that rather than just a better way of managing technology?

I think a lot of what passes as "Service Management" is in fact just better technology management. Let's face it: you can do great Incident Management, Change Management, Problem Management, etc. without ever worrying in the least about services, a service catalog, or any of the other trappings of genuine Service Management. And, frankly, most shops do just that.

So, when does it become Service Management?

Clearly there's no magical point of arrival, but it's easy for me to suggest a few milestones that probably make a difference:

First, coming to a basic definition of what a service is within your organization is a good start. Decide what exactly it is that makes a service a service. In effect, decide how to model services in your environment. This can be simple or quite complex. Just make it clear for starters!
Second, you're making a decided turn towards Service Management when you actually have a list of services. And, when I say 'list', I do mean list. You don't need a catalog to get started. But, you do need a basic awareness of what services you want to manage.
Assigning service owners marks one of the most important moves toward actual Service Management. Without ownerhip, the reality is that services will continue to play a shadow role at best in your organization, one easily eclipsed by technology concerns, financial concerns, or just plain lack of time. Ownership of services and intergration of the Service Owner role into the HR structure of your organization is critical at some point along the Service Management journey.
Yep...you saw this one coming...developing a Service Catalog clearly indicates motion towards actual Service Management. Take that list you came up with earlier and make it pretty, searchable, and useful to customers and stakeholders. Integrate it with your support strategy at the Service Desk. Focus not on what a Service Catalog should look like, but on what it can do for you that's useful.
Get busy working on Service Level Agreements. Services deliver defined value on an agreed basis, they're not just abstract things we talk about in ITSM circles. In other words, your customers should understand (contractually) what they're getting and how. A strong SLM program makes that happen.

There are certainly more stations along the way toward Service Management we could talk about. Try this basic list for starters and you'll be well on your way.

12:32 PM GMT | Read comments(0)

June 25

Organizing for ITSM: The Big Shift
Last week I had another opportunity to work with an organization undergoing an ITSM restructuring. At base, what we were up to was restructuring to help the shop transition from a primarily technology orientation to a service and process orientation.

We were working on what I call 'The Big Shift', by which I don't mean ITSM implementation as a whole, but rather one particular change (among several) involving basic organizational structure, one which makes better ITSM possible. Let me explain.

I've seen plenty of organizations approach ITSM improvement without really addressing underlying organizational structure. Results are usually sub-optimal. Structure drives behavior, after all, and if ITSM improvement is about anything at all it's about changing organizational behavior. So, if you leave the structure the same, behavior tends to stay pretty much the same too.

This is where 'The Big Shift' comes in. Frustratingly, the ITIL core guidance sections dealing with organizing for service management leave quite a bit to be desired. Standard roles are listed and described. There's some material on four basic functions. The rudiments of organizational change are introduced. What's NOT there is a clear statement of what actually happens in fundamental organizational terms when an IT shop really starts doing service management.

Here it is in plain terms:

Existing functional-technology management gets scaled back and becomes pretty much just resource management. As a result, fewer people are required in this part of the organization.
Management energy (FTEs) are shifted into process and service focused roles.
New organizational structures are created to help support the new roles and to act as organizational centers for new capabilities.
Actual work is directed mostly via processes rather than by management intervention.

That's what I call 'The Big Shift'. It's easy to see why lots of organizations shy away from it. It's restructuring, plain and simple and it takes a lot of clarity and resolve to make it happen. It's not about just 'implementing a process' or 'changing attitudes' or buying a tool. It involves as much of what I call 'letting go' as it does adoption or implementation. In fact, failure to 'let go' of old structures and commitments predictably leads to organizational bloat, conflict, and confusion and directly impedes forward progress.

It's hard for me to say whether the people who wrote the sections of the ITIL guidance treating these matters just didn't have the clarity required to spell it out or if they politely declined to spell out the hard facts because they knew that it might scare off potential adopters. I'm guessing it was just lack of clarity, mainly because the simple weight of the guidance pretty much already communicates what you're up against. After all, if just reading it is that difficult, surely implementation must be even scarier, eh? So, I'm thinking they just didn't connect all the dots.

Organizational structure is in fact a primary determinant of a shop's success with ITSM. There's no way around it. If process and service focused roles aren't significantly or even centrally represented on your org chat, you're probably not going to get very far very fast.

What about matrix management? Can't we use that to get the job done? Well, maybe. Some type of matrix structure is almost always part of the picture. But there are a couple of things to keep in mind. First, matrix management is advanced kung fu. It's important to be realistic. If your shop currently scores low on the maturity scale (very likely), is it a smart thing to bet your ITSM strategy on a management approach which in organizational terms might be compared to juggling chainsaws on a unicycle over a shark pit?

Second, I've seen matrix management used as a strategy for avoiding the real change required to make significant ITSM gains. Rather than actually restructure so that processes and services are organizationally supported (e.g. with straight-line reporting and actual positions), shops lose their nerve and take the easy way out: leave everything pretty much the same, draw some dotted lines, create a few second jobs for people, and call it good. Again, results are almost always sub-optimal...at best.

So, if you really want forward ITSM motion for your organization, consider 'The Big Shift'. Take time to understand it. Get the sponsorship and support you need. Plan carefully. Muster your resolve, and make it happen.

You'll be glad you did.

9:46 AM GMT | Read comments(1)

June 16

Bees In Your Datacenter
As it happens, when I'm not teaching or working with a client or writing, I spend most of my time in the garden, often pausing to observe what's going on around the two beehives I keep. I've had bees twice now in my life, this time around for two years running.

Bees are unlikely grist for a blog about IT Service Management, but I'd guess that few tech shops out there come even remotely close to matching the beautiful efficiency evidenced within a bee colony. I certainly find ample opportunities for consideration.

One of the first things I learned from bees is that there are no rockstars. Still (probably as a result), everything gets done and gets done in amazing style and on a nearly perfect schedule. All workers in a honeybee colony are pretty much the same size and have roughly the same basic equipment. Bees follow a set of pretty closely defined task patterns with uncanny dedication and, despite the fact that each bee only produces about 1/12th of teaspoon of honey in its entire life, the colony as a whole can make more than a hundred pounds of honey in a year. Go figure.

Patterning inside a beehive (we call them 'models' in ITSM) also offers good material for consideration. Hives, especially wild ones, are wonderful combinations of order and variation. Bees use basic patterns (honeycomb cells, spacing between combs, etc.) extensively and with great efficiency to build their homes and to get on in the world producing honey, raising new bees, etc. But, where necessary, the bees assemble or apply these patterns with great and often beautiful creativity in order to meet special needs, as for example when they build out honeycomb to fit the inside of a tree bole or the wall of a building. I don't hear many complaints from my bees about how difficult it is for them to create these 'models' of theirs or how horribly constrained they feel having to use them day in and day out. It's also amazing to me that despite the bees extensive reliance on these 'models', the results they produce are so perfectly customized to the unique needs of each colony. Somewhere in there amidst all that buzzing I imagine a good lesson lies waiting for us regarding what 'Good Practice' actually entails.

The famous 'bee dance' discovered by Karl von Frisch more than a half century ago provides a stunning example of operational communication. Bees forage widely for food (nectar and pollen), often travelling three miles or more to reach an exceptional source. Upon returning to the hive, they 'dance' for their colleagues as a means of communicating the precise location of the nectar source. There is no exception and timing is critical since many nectar sources peak over the span of only a few hours. So, of necessity, the bees communicate clearly and without exception as a means of enabling concerted action in pursuit of food. They do this on the spur of the moment, dynamically, in perfect response to the vicissitudes of the flora around them. Instinctively, they know that communication means survival and they know just what must be 'said' in each circumstance to make a difference. Hmmm.

In the ITSM world in recent years, we've built massive tooling for, among other things, management of assets and configurations in our environments. I've often marveled at how bees manage to map their own assets (food sources) across huge and highly complex expanses of territory. They do this using a brain roughly the size of grain of sand and consisting of no more than a million neurons, yet they can locate a single flower within a radius of about miles. Stunningly, in addition to mapping spatially, bees also map in time (within an accuracy of about 20 minutes) as a means of optimizing their foraging at the precise time of day that the flower or plant is producing maximum nectar. How is this possible? Well, I can tell you this: they're not mapping every flower and they're not mapping every 'attribute' about every flower. They're just very clear about objectives and, using those, they're mapping only what matters most.

I could go on, I suspect for quite a while, but I think you get the picture: simple stuff matters a lot...more than anything else. We humans mostly get that wrong or waste a lot of time making things complicated for ourselves. Focus, process, models, good practice, clarity about objectives, flexibility, etc. are powerful capabilities whether your a bee or an IT manager.

5:19 PM GMT | Read comments(0)

April 26

Process Basics: Categorization
Conservatively speaking, I'd estimate that 80% of the questions I address regarding ITIL can be resolved armed only with a handful of process fundamentals. In such cases, whether the question concerns Change Management, Incident Management, or Problem Management is mostly irrelevant. What does help is having a good grasp of basic process principle like scope, logging, categorization, prioritization, review, etc.

For me, process understanding at this level is my Swiss Army Knife for ITSM problem solving.

The process fundamental I'd like to talk about for a bit here is categorization, a generic step usually located at the very top end of a process which serves the purpose of typing or grouping instances of the process together. Owing to the idiosyncrasies of ITIL, it's sometimes referred to as 'classification' depending on the process in question. Not to worry, the idea is the same. In Incident Management, for example, the 'by the book' approach is to classify incidents as hardware, software, etc. related so as to more efficiently handle them. For changes, categorization determines whether RFCs are emergent, normal, standard, etc.

I don't really know how much consideration most people give to categorization in general, that is, as a fundamental concept. But, judging from my encounters with ITSM professionals (even highly credentialed ones) as well as students in my classes, I'd say that substantially more reflection wouldn't hurt a bit. I don't mean this as a slight to others, but rather as an encouragement to poke harder and get more from this very productive little aspect of ITSM processes.

Let's start here: Not all process steps or activities are created equal. Some matter a lot more than others. Categorization is one that matters a lot for a couple of reasons.

First of all, as I mentioned a second ago, it sits at the front or top end of most processes. That means it has downstream effect on the majority of the rest of what happens in the process. So, just as with project management, controls applied early have the possibility of influencing more of the project budget whereas controls applied late can only hope to influence whatever's leftover in the project budget at that time...or, worse, to direct additional overrun spending needed to rescue an effort that should have been better controlled earlier. So, significantly, as an early process step, categorization drives much of what happens next in any process simply because it happens first.

Second, categorization also matters a lot not just because it happens first, but because it's explicitly tasked with determining how best to continue processing the incident, change, problem, etc. Wherever sub-processes, models, etc. are used to add efficiency or improve consistency, they must be preceded by and coupled with a categorization step which enables selection of the appropriate model, sub-process, workaround, etc. Incident models, change models, release models, configuration models, etc. all exist (or should!) in a 1:1 mapping with incident categories, change types, release types, CI types, etc. And, importantly, models can only be created after types or categories have been clarified.

Let's consider an example from Incident Management. Our metrics tell us that on average we spend the following amounts on tickets resolved at various support tiers:

Level One = $28
Level Two = $183
Level Three = $468

Clearly, keeping tickets at level one matters a lot. Categorization, in many cases, determines whether or not we're forced to escalate to level two. An accurate categorization against a meaningful categorization scheme (more on that in a bit!) enables more frequent location and use of a relevant KEDB entry and workaround, thereby enabling level one resolution. Inaccurate categorization or even accurate categorization against a poorly defined categorization scheme means almost certain escalation to level two and therefore increased costs.

So here, clearly, getting categorization right makes a huge difference because we're using it to drive (or avoid!) downstream activity.

As you've already guessed from my comments, categorization really depends on getting two separate things right: definition (first) and then application (second) of the categories.

So, what's the right way to define categories? Simple: they need to be defined specifically to support selection of downstream effort. This sounds so trivial as to be hardly worth mentioning, but you'd be amazed at the number of shops with Incident Management processes that use "by the book" categorization schemes based upon hardware or software hierarchies, schemes which utterly fail to reflect or enable prioritization of subsequent process activity.

In high-functioning Incident Management processes by contrast, categorization drives relentlessly towards the specific KEDB entry that can be used to resolve quickly and efficiently or towards an incident model, etc. In a Change Management process, categorization drives the process toward a streamlined RFC form, selection of an efficient CAB, and identification of a useful Change Model. You get the picture.

In other words, no matter what you may think the ITIL Core Volumes say about categorization, there is no generic set of categories (for incidents or changes or anything else) that makes sense. You derive your categories based upon your own organization's approach to handling things consistently and efficiently.

As a highly leveraged point in almost every process, particularly those which are performance oriented, categorization deserves every bit of practical attention you can give it.

4:13 PM GMT | Read comments(0)

November 08

Getting to the Bottom of Root Cause Analysis

So, first off, let's get one thing straight: 'root cause' is, strictly speaking, a myth. Actual cause is always complex, rarely single or 'root'. Moreover, The notion of a single truly 'root' cause misses the point that root cause analysis should always be guided by practical objectives, just like most of what we do in IT.

Does that mean that it doesn't pay to try to get to underlying causes? Of course not. In general, the 'deeper' the cause we can address around a given problem, the greater our ability to prevent future impact will be. Still, objectives behind problem management and root cause analysis vary, and so how we focus RCA also needs to be flexible enough to accomodate variations.

A practical example: An RCA team does its magic around an embedded system and discovers a hardware fault with controller module which (unfornuately) supports all of the job control systems in multiple plants. Yes, the hardware fault is (arguably) the 'root' cause but, no, it cannot be cost effectively addressed. The RCA team also knows that the controller fails when it undergoes a soft reset at peak load condtions. The objective here, strictly speaking, is to prevent downtime and maintain plant output in a cost effective manner. The team opts instead to focus on timing and practices around device resets.

Beyond the practical concerns about keeping production going, we could also ask questions about what allowed the faulty device to be placed into production in the first place. Or we could focus on the vendor selection process. Etc. The point should be clear: what constitutes a 'root' cause is a matter of perspective and purpose, not theory. I'm sure you can also cite examples from your own experience where objectives serve as much better guides to what 'root' cause means than do more absolute and abstract notions of causation.

So, why make a point about this? Simple: it saves time and money. Being clear about your objectives when addressing root cause makes it possible to focus more quickly and efficiently on what matters. This may seem like just common sense, but many shops still believe firmly in 'first causes' and do their RCA on that basis.

Beyond clarity about objectives, RCA quickly boils down to four basic activities: factor mapping, building a causal model, narrowing the model, and validating results.

Factor mapping is about identifying factors which might produce the fault in question. It's commonly guided by the use of Ishikawa or other fishbone models to help ensure that all type of factors are considered: process, human, environmental, technical, etc. Brainstorming approaches to populating the fishbone are helpful. Overall, the emphasis here is mostly on factor identification NOT factor evaluation.

Construction of a causal model comes next. This takes factor identifcation a step further by attempting to describe the specific mechanism by which factors bring about a given result. Approaches like the '5 Why' which probe behind and beyond each factor are useful here. Visually, causal models can be usefully constructed much like process flows showing dependency, branching, etc.

Narrowing a causal model is about starting to think towards intervention or solutions and ranking factors (points of intervention) in terms of how well they map to original objectives. The result is a simplified factor map and causal model that can be efficiently validated.

Validation is about probing potential solutions to warrant submission of an RFC. Using the causal model as guide, it's usually possible to find points where dependencies in the model can be made visible and monitored by asking questions like, "If step X happens, what will it look like?" or "If factor Y is NOT present, what will it look like?"

And, as we mentioned at the beginning, the outcome of all this is really not 'root' cause but a recommendation about how to most efficiently intervene to achieve a specific objective: avoid downtime, maintain productivity, save costs, etc.

11:33 AM GMT | Read comments(1)

Great Service Management doesn't have to be complicated.