My BLOG

IT Systems Do Not Equal IT Value

Thu, 10 Jun 2010 14:03:13 -0400

Many people in IT are confused about the term "IT service". IT services are comprised of IT systems, and neither the IT system nor its components are of direct value to the consumer. Rather, it is the performance made possible by the IT system that produces a given value for the consumer and that value exists entirely in the perception of the consumer ― therefore, by association, IT's value exists entirely in the perception of the customer. Read the article at CIO Update to understand the difference between an IT system and an IT service, and why it matters.

Silos, for lack of a better word, are good.

Tue, 25 May 2010 12:24:21 -0400

I am tired of hearing “experts” rail against silos. You know, those organizational structures that allow us to manage increasing complex topics of all sort. When will managers finally take responsibility?

Silos have been with us since the beginnings of humanity. We developed silos to store one type of food grain apart from another. The very word means “corn pit” -- and it today represents specialization. Or at least it should. I hear so many well meaning people decry silos, especially silos in IT Organizations (ITOs.) In my opinion, this is really an indirect attack designed to misdirect, to take our mind off the real issue.

Silos are the only way to manage increasingly complex concepts. Medicine, education, government and business all rely upon silos. Consider a sales organization. Sales is different from say, transportation. Sales and transportation both have different needs. It makes sense to develop staff, management and other systems based on the unique requirements of each. Silos also exist within silos. Within a typical sales organization (er, silo) you often find inbound sales and direct field sales. They usually have different systems, staff and needs. They are silos too. Yes, silos are everywhere, but you seldom hear experts complaining about “evil” sales silos or intransigent transportation silos. Why the attack on ITOs?

An ITO is also a silo of silos, and that is a very good thing. Silos are needed and serve an important purpose: specialization, process, and governance to deliver competence. Who does not want that? We want our healthcare providers to be specialists that follow a process. We want our airline pilots to be competent too.

No, the issue isn't the presence or absence of silos. The issue is the lack of communication and coordination between them. Wikipedia states: “The silo effect is a phrase that is currently popular in the business and organizational communities to describe a lack of communication and common goals between departments in an organization. It is the opposite of systems thinking in an organization.”

The real issue is lack of management. Could the solution be as simple as business customers and user assuming responsibility for their consumption of ITO services? I think poor management by business and ITO managers is the problem, not silos. When business and IT managers decide to lead, they can leverage the power of silos in a matter of days. Until then, it is a tower of babel.

But know for sure, silos are permanent and silos are good. You need to learn how to resolve the “silo effect” -- but “tearing down silos” is like “tossing the baby out with the bath water”...

ORGANIZATIONAL HEALING: "What does an ITSM expert do mommy?"

Thu, 15 Apr 2010 11:58:26 -0400

There is a lot of good conversation around the ITIL Expert designation. While there are "paper experts" (e.g., those who can pass a test) there are also those who are experts in IT Service Management who also happen to have passed a test. Forgetting the former and focusing on the latter, here is what an ITSM expert or ITIL Expert should be able to do for you.

First, some context: a philosophy if you will. An expert in ITSM treats the service provider as a medical doctor treats the patient. People have similar systems (e.g., circulatory, nervous, digestive, etc.) And just as a person is unique they are also more or less the same -- we all suffer from the same basic illnesses and luckily most benefit from the same cures too. This is what makes medicine work.

Typically, a person with symptoms consults a health care provider who checks for signs of disease. The provider formulates a likely diagnosis and often does further testing to confirm, clarify or discard the diagnosis before prescribing treatment. This is how medicine works.

The same is true for ITSM. All service providers also have systems, and just as people are all wonderfully unique and special so are service providers. Even though every service provider is unique, they suffer from the same dysfunctions and benefit from the same "cures" -- the dosing or prescription may vary, but the cause and effect remains the same. This is what makes ITIL and ITSM work.

1. An ITSM expert listens for symptoms (subjective evidence of dysfunction experienced, in this case, by a service provider) and then seeks signs (objective evidence of dysfunction that can be detected by an ITSM expert -- missing/misused process, artifacts, etc.) This is called diagnosing and it is the first job of an ITSM expert. ITIL, COBiT and ISO-20000 are critical in this step since they describe the structure and artifacts one should find to verify signs. So equipped, the expert can then develop a diagnosis: for example Role Ambiguity and Role Conflict are common diagnoses of dysfunction suffered by service desk agents.

1. The next job of the ITSM expert is to develop a treatment for the cause(s) of the diagnosis, perhaps a failed management strategy (Gap 1 failures usually result in Role Ambiguity) and miscommunication to customers about capabilities (Gap 4 failures typically generate Role Conflict.) The ITIL is invaluable here since it documents how highly functional service providers typically operate. Also key here are other diagnostic tool sets like Six Sigma and SERVQUAL.

1. Using the ITIL, PMBOK, SQBOK or other model (there are many) the ITSM expert chooses the closest situational template as a starting point to create a prescription, in this case to treat Gap 1 and Gap 4 failures. In this example, for Role Ambiguity, the prescription might be working with Human Resources to develop job descriptions (and provide management training on properly using job descriptions) so that service desk agents are properly supported to accomplish an agreed task. Perhaps for Role Conflict the ITSM expert engages with marketing or Service Level Management and Service Catalog Management to correct misstatements and properly set expectations in customers.

1. Lastly the ITSM expert schedules a follow up visit to "keep an eye on" the patient.

A true ITSM expert understands "the patient and environment", diagnoses organizational dysfunction, uses models and norms to discover its cause, prescribes a specific solution and monitors to ensure organizational healing occurs.

If the question is "what does an ITSM expert do?" the answer is "An ITSM expert treats and heals dysfunctional IT service provider organizations."

If your "Expert" can't have this conversation with you, then they are not really an "Expert". Find some self-proclaimed "experts" and see for yourself!

ITIL is like Cooking Pastries

Fri, 9 Apr 2010 12:56:21 -0400

If you listen to the skeptics and even some pundits you might think ITIL is over with and done, ready for retirement if not the closet. Of course, this argument is often put forth by those who have failed to realize value from their investments in ITIL. On the other hand, there are those firms who have seen remarkable benefits from their investments in ITIL. What gives? How can so many fail miserably while so many others succeed wildly? Could the answer lie in how ITIL was positioned and used or not used as the case may be?

By way of an analogy, think about getting ready for a party for a group of friends. Your friends at the local culinary club want you to bring a dish to a party, a dessert. The day before the party you take the cookbook off the top of the refrigerator and turn to the dessert chapter. You know everyone in the club likes fruit, so you turn to the fruit desserts section. You see a number of possible desserts, but you also know that lite and fresh fruit desserts would be best given the time of year. You personally like a heavier, thicker dessert -- perhaps a really nice flan -- but since you have a general idea of what some of the others will bring you select a recipe to compliment. Your choice is a very nice fresh fruit tart -- in many ways a tougher dessert to prepare well, and one more challenging of your skills!

Here is what you just did: First, you realized you had to make something, create something of value -- you are in a culinary club after all -- so you choose a recipe based on what would be best for the partygoers, one that would fit in well with the circumstances. You also subsumed your own desires to meet the needs of the partygoers. Perhaps most importantly, you understood what the partygoers wanted and needed -- you understood your "customer" and your "marketplace". You chose your recipe carefully too, choosing a more difficult dessert to prepare (and one you might not have wanted on your own) because it would make the party more enjoyable -- and thus meet the needs of the culinary club event. Using your understanding of how fruit flavors mix and your own past experience you change the recipe slightly to make it work even better. And you learn from your experience as well -- gaining valuable (and impressive!) new culinary skills along the way that prepare you for the next event.

Here is what you didn’t do: You could have stopped by the store on the way to the party and bought some prepared dessert, but you didn’t. You didn’t "pass the buck" with a canned or "in the box" dessert. You didn’t abdicate your responsibilities but rather took on a challenge. You didn’t open your cookbook to the dessert section and randomly choose the easiest dessert to make; nor did you choose a dessert that you wanted, but rather one that met the needs of the partygoers. You didn’t follow the recipe exactly either -- you modified it based on your circumstances, needs and experience.

The ITIL is also a collection of "recipes" and we who manage IT organizations are "pastry chefs" of a sort. All too often those who fail at ITIL did not go along as our erstwhile pastry chef, not even as a novice, but rather "stopping by the store on the way to the party."

Recently I talked with a very senior executive for a multi-national IT service organization. This person was upset that the new strategy he/she designed was not working out. So I asked a couple of very basic questions right out of the Service Strategy book (you know, the one book everyone likes to disparage.) I asked if they had agreed the strategy with customers in their market place. The response was no. Sensing a deeper issue, I moved from Service Strategy to Continual Service Improvement. (Again, you know, that book at the end of the library. The one many like to say has no place in the ITIL or perhaps more gently put, the one few understand.) So I asked if they had identified existing customers to talk to about this new service -- or perhaps identified firms that represent the kinds of customers they want to capture with the new service. The answer was again, no. No focus groups, no customer surveys, no engagement at all. So I asked point blank "How do you expect your plans to work? Why are you surprised that your plans are not delivering the value you wanted?" then I added, "You should not be surprised your ITIL investments are not paying off." Sadly, this is more common than it need be.

As you might expect, conversations with successful firms take a different route. Successful adopters seek out customer input and use proven marketing techniques to engage, understand and agree customer priorities. They use ITIL in the form of an IT service improvement program or project (using formal project management techniques.) They adapt to the situation and pragmatically use those bits of the ITIL that help them prepare a solution -- they seldom use the guidance as-is.

One senior executive of another very large multi-national firm recently told me "I don’t care one ounce for ITIL. If it has something in it I can use to improve my business I want it. I don’t want it all and could care less for the rest." He/She then proceeded to define critical services, engage the business, prioritize IT service improvement based on service value to customers, allocate resources accordingly and align internal processes with ITIL where and only where it made sense to do so. Perhaps there is a reason why this firm is doing well from its ITIL investments.

I wonder how many of those who dismiss ITIL out-of-hand took the former versus the later route? Did they get their ITIL strategy by swinging by the store -- Web surfing, perhaps a few blogs and vendor white papers? How many actually own the ITIL? I mean the books, you know, the kind you read? How many have read them, thoroughly, as in more than once? Of that sub-set of a sub-set, how many have bothered to obtain more advanced training or experience in the more subtle nuances of managing services?

I will throw good old-fashioned management skills in here too. At a recent tradeshow a very sincere and well-meaning manager asked me for advice. He/She explained the most excellent ITIL Change Management process recently put in place. They had taken training, got a good vendor tool solution in place, gotten certified and so on. Just one question though "How do I get my people to follow the process?" Well, I said "In truth this has nothing to do with ITIL and everything to do with your success with ITIL. You need to put in place job descriptions outlining required process and workflow. Anyone who does not follow the process should go on an action plan to termination."

Unfortunately too many failures with ITIL result from a well-meaning manger taking a Foundation class and then assuming he or she "knows what to do now." Or worse, thinking ITIL is something you can buy and not taking the time to really understand how to use ITIL. Perhaps worst of all, failing to be a manager with the willpower to properly motivate and lead subordinates.

When I hear that ITIL is bureaucratic or impedes competitiveness and velocity I know it is being "done wrongly." Clearly there are a whole lot of people who are disenchanted with ITIL, and I doubt that most of them will accept responsibility for their failure (not in our nature, and especially not in this day and age.)

Blaming ITIL for failure to properly use its guidance is like blaming the cookbook when you choose the wrong recipe -- and about as useful. At its heart ITIL is a set of recipes to specific organizational issues, it is a cookbook of sorts, and it is up to the chef to choose a recipe, adapt it, prepare it -- use it. Let me paraphrase some things for those who do not understand the ITIL:

• You can't do everything in the ITIL, nor would you ever want to! But, I have yet to find an IT service management issue that the ITIL does not describe and for which ITIL guidance does not offer a workable pattern, starting point or out-right solution.
• Everything you need to use the ITIL isn’t (let me repeat IS NOT) in the ITIL! ITIL is IT service management; not project management, not quality management, not maturity, not security -- and you will need key elements of all those frameworks and perhaps others to be successful (with or without ITIL.)
• The ITIL presents a MODEL, and all models are WRONG, but some are USEFUL (to misquote Box.)
• You can't "paint by numbers" using the ITIL either, you actually have to think -- as my friends in the US Marine Corps like to say "you must adapt, improvise and overcome."
• The ITIL is wonderfully generic specific guidance, but it is not and cannot be verbatim instruction, and you must adapt it to fit your own needs.
• ITIL is not best practice and it is not a standard! The ITIL is good practice (at least that's what it says it is [mostly!].)
• The ITIL is not even for everyone and does not work in all firms! There are many service management frameworks, ITIL is but one.
• ITIL describes the management of an IT organization in pursuit of delivering valuable services to its customers. ITIL will never come out of a box. It will never be something you can take 1 class and master. It most definitely is not something you can purchase.

How to Get Started with ITIL® Incident Management

Mon, 29 Mar 2010 11:55:53 -0400

[Getting back to roots here, if you will. Focusing on basic “how to do it yourself” concepts as well as the more forward looking stuff. -Hank]

The ITIL is a great reference, but its multiple books and hundreds of pages of explanatory text aren't always clear about where to get started or minimum requirements. ITIL spends lots of time on the things you could do but little time on the basics required to get started. This leads to lots of questions about where to start, understanding how much you are already doing and even when to stop and move on to the next process or activity.

ITIL v3 defines an Incident as an unplanned interruption to service, or a reduction in the quality of a service. Incident Management is the term used to describe the process responsible for managing Incidents. The main goal of Incident Management is to restore service to users as quickly as possible. When you handle a call or email from a customer or user experiencing something wrong with a service you provide, you are "doing" Incident Management. The ITIL explains the reasons for Incident Management and how to setup an Incident Management process.

There are many aspects to carrying out Incident Management, explained in detail within the ITIL; however, there are just 6 things you need to do. If you do these 6 things consistently, then there is a very good chance you are "doing" Incident Management well enough to achieve the benefits the ITIL describes:

1. Create and maintain a database for all Incident Management records. Make sure every Incident (each and every call, email, fax or drop-by) gets recorded into a database -- and that means capturing important information about the Incident as well. Be sure to capture information about the Incident (work done, resolution, note, etc.) 
2. Create a knowledge base by capturing and providing access to other records, data and information as well -- as much information as required to perform the Incident Management function. ITIL calls this a CMDB (Configuration Management Database) and/or a CMS (Configuration Management System). 
3. Make sure you have (and enforce) written procedures for recording, prioritizing, classifying, escalating and reviewing Incidents. 
4. Put in place procedures to manage the impact (effect of an Incident) on customer business based on how defined Service Levels will be affected. 
5. Create a "Major Incident" model -- a set of rules that clearly describe a very bad Incident. Major Incidents affect important services and/or numerous customers and users. In either case, a Major Incident requires immediate escalation, notification of customers and IT management and other special handling. Basically the concept is that this Incident type needs a full organizational response as soon as possible. 
6. Keep the reporter of the Incident (that is, whomever contacted you about the service issue) informed about the status of the Incident as your team works it. You might also have to keep the customer (users work for customers) informed as well. Be sure to know in advance whom to keep updated, how often to update them. You may also need to advise them if it appears that you wont be able to get service back into agreed parameters within agreed timeframes too. 
If you are not doing even one of the above items, you can improve your service quality by focusing on doing it. If you are already doing these things consistently, then you might not need to spend more time in this area -- focus on another ITIL area instead, perhaps Problem Management or Change Management.

These six items might take you months to implement and tune -- but the results will be tremendous improvement. Use these six steps to guide your ITIL implementation, and use the guidance in the ITIL if you have questions about how to do these steps.

When you have mastered these six steps you may or may not be "done" -- these 6 steps are the minimum number of activities you should have and do well to deliver the benefits described in the ITIL. Of course, depending on your situation, you may need and want to do more too!