ROI - Rationalizing Our Insecurities

The way organizations look at project initiatives, one would think that no move, no investment decision, ever proceeds without a clear return-on-investment calculation. Such a calculation is then followed by the obligatory sign-off by everyone who might have something to say about how funds are spent, all to ensure alignment with organizational strategy. Is this really what is going on?

My guess, my suspicion, is it has more to do with paranoia than alignment. It has more to do with fear than leadership. Leadership sets the direction, crystallizes the vision, and rallies the resources for achievement. Return-on-investment is a necessary step but it is not, no, it should never be, the sole determinant of a go/no-go decision. Six Sigma rightfully rose in prominence because it provided a means to measure that which was thought immeasurable. The DMAIC framework provided assurance that improvement would translate to the bottom line. But Six Sigma's DMAIC approach demanded the rigor of:
1. Clearly defining the goals in objective, no-nonsense, measurable terms and,
2. Establishing a valid, valid reliable, and meaningful measurement system.

That there are no shortcuts to precision is the beauty of Six Sigma. It is successful today because it objectively and precisely addresses the paranoia that is present in many of our organizations.

Return-on-investment can be as valid and reliable if such objectivity and precision is used to identify the realized value of the effort. But too often we fall short in:
1. Clearly defining the goals in objective, no-nonsense, measurable terms and,
2. Establishing a valid, acceptable, and meaningful measurement system.

Look familiar?

ROI is no worse than any other criteria that might enter into the decision criteria. Unfortunately, ROI is used as a crutch. It is one of the necessary steps in any project plan and is too often hurried. Without the rigor of objectivity and measurement purity we see in Six Sigma, ROI may become a "check-in-a-box" of the project plan. If it is based on solely on assumptions that were uncovered in benchmarking other institutions, it has no relevance to our culture, our constraints, our challenges, and the way we execute projects.

That's when leadership comes into the picture. One has to have the courage of conviction that Service Management is going to be "the way we do business from this point forward." Can you benchmark others to see what they have accomplished with Service Management? Yes! Can you assume that what worked for them will generate the same return-on-investment for your organization?

You can only make that assumption if you can measure it. If it's the right thing to do, leadership must step up to the task of making a case for it.

Coordination of Beauty Takes Planning

Attending a concert this afternoon I was struck by the similarity between what it takes to produce a work of art and a successful improvement program, a Service Management program, or an attempt at organizational change. Just think, for a moment, about a musical work. It has a writer, composer, and an arranger. Those who play the musical score have studied their specialties be it the Flute, Oboe, Trumpet, Clarinet, or what ever the instrument might be. The artists have studied the music. They have perfected their instruments. Yet these individuals, regardless of how good they may be independently at their respective crafts, fail miserably playing together unless they have guidance: That of a conductor.

Now, the conductor has studied his or her specialty too. But they have also studied the instruments that will make up the piece. The conductor knows the musical piece and all its constituent parts thoroughly. The conductor understands all the parts of the composition, how it fits together, and how it should sound - the end state - once all the pieces perform together. The conductor understands too the intent of the composer, his or her history, and what was embodied in the fabric of the composition.

Yet, after all this, the piece is not ready to be heard. There must be rehearsals. The conductor must know the strengths and weaknesses of the artists who will perform the various parts. The conductor must coach those needing special assistance, subdue those who may be too earnest at one point or another, and encourage those who have the talent and skills but are reserved and subdued. This is important because all parts must work together or risk compromising the intended result. The conductor, seeing the system holistically, must ensure proper flow from one part of the composition to another. The timing, rhythm, and sequence of activities are critical. At all times the conductor must hold dear the end state, the intent of the piece, how it will sound, what it is intended to stir in the audience. To do this takes planning, preparation, training, practice, and character.

In our world we study formulas for success. We hear about critical success factors, risk analysis, project principles, process design, measurement, communication, service design, and control. We talk endlessly about vision, objectives, scope, sub-optimization, alignment, and variation. We have to study to understand all this. There is no denying this is important. But it must all work together.

Might it not just be easier to take an afternoon off, attend a concert? Take some time, perhaps to learn from the masters what it takes to bring individuals together to harmonize. I would challenge you to stop looking for the quick hit, silver bullet, fast track to driving improvement and acknowledge that it requires no less than the discipline exhibited by those who bring us art. There are no short cuts. If we can master that discipline, then our efforts are as worthy as those of a musician to be considered art. And our efforts will be as successful as a orchestration that moves the audience to tears.

Due Dilligence?

Are we doing all we can to meet the needs and understanding of ITIL for our clients? I have to ask this now, after attending the itSMF Fusion event in Dallas this past week. The presentations were, in my opinion, better than previous years. We're seeing a lot of progress in applying ITIL concepts in the real world. But I am concerned that our training is not keeping pace. The reason? I overheard someone behind me in one of the sessions complaining that you can't do what the speaker was suggesting. He commented that change is not involved 'that' early in the process. Now I have no way of knowing if this individual had completed Foundations training. But I know, given the context of the topic of the presentation, this gentleman was wrong. He had a short-sighted understanding of the scope of Change Management.

Why does this concern me? As consultants, we work with customers to help them adopt ITSM concepts as documented by ITIL to drive improvement in their operations. ITIL cannot be force-fed. If our clients are not being trained properly, we, as consultants, have to deal with their lack of knowledge, lack of understanding WHILE WE'RE TRYING TO HELP THEM IMPLEMENT SERVICE MANAGEMENT! There are enough challenges in any ITSM effort without having to deal with educating our clients in the basics of Service Management as espoused by ITIL. It is both a distraction and an additional expense.

I made a point to raise this concern this past week with those leaders in ITIL who DO care. I did this simply because if one assembles a group of people to drive improvement one should expect that if those people have a specific level of qualification, they understand the basics. I recognize it is our job to help clients incorporate these concepts into a practical framework for implementation and in doing that we have to help them fully understand the key concepts. But if the basics are missing, or worse, if the basics were not addressed properly to begin with, some individuals fill the gap with their own interpretation(s). Once they integrate this in their minds, it becomes a barrier to being open and understanding the real facts. In a consulting situation it presents challenges, barriers, and possible embarrassment for the customer (imagine a workshop in which a key manager makes a statement that everyone else in the room knows is in direct conflict with the fundamental principles of a process!). It adds a level of complexity that may derail the entire service management initiative.

I find those individuals who received their certification through on-line training to have the greatest problem in understanding the concepts. They may pass the exam. But quite frankly, how valuable is the certification, really? If they don't fully understand the full scope of the concepts - an impossible expectation of on-line training - they are only making incremental progress in being good stewards of their company's processes.

One of the principles I offer to my clients is to use the same training organization for all of their training. That, at least, provides some level of assurance of consistency. In dealing with change, there are enough variable with which to contend without being concerned that "ITIL 101" is compromised.

Quality is Still Valid

How about all this quality stuff? I am regularly asked how, or worse, "if" the essential components of quality are applicable to service. In fact, I amazed at how often clients challenge the underlying elements of quality. The usual objections falls into one of these three categories of myth:

Myth Number 1: Quality principles were born in manufacturing; they have no relevance to service.
Myth Number 2: We are different.
Myth Number 3: We tried that "quality stuff." It didn't work for us.

To this I have the following responses:

Quality is based in manufacturing; it has no relevance to service. Naturally I beg to differ. In fact, I insist on differing. I can show that the essential elements of quality are applicable to all customer-centric issues.

We are different. No you are NOT! You are no more unique, different, complex, or have any special conditions that exempt you from the benefits that can be found in the fundamental concepts of quality than anyone else, regardless of the industry or customer niche you are serving. If it makes you feel better to say you are different, great. Go ahead and say it. Just don't believe it.

We tried that quality stuff and it didn't work. You didn't do it right!

I won't go into the second two issues, but bear with me while I discuss the first point.
-The basic model of any product or service is based on understanding DEMAND which allows us to DESIGN to meet that demand, and then we put that design into PRODUCTION
-The Value Chain model of manufacturing parallels this same model.
-The IT service model, not surprisingly, follows the exact same model with slightly different terminology.
Everything comes down to customer demand, design of service or product, and production (followed by support / maintenance, etc.). By definition, quality is defined by the customer. The principles of quality are then applicable to any and all products or services that meet a customer need.

Now again, what was the objection to quality?

Cost of Quality

What is the cost of quality? Six Sigma asks this question from a different angle. What is the cost of poor quality? If you're in information technology and just need an acronym, that's COPQ!

So let's answer that question. What is the COPQ (Cost of Poor Quality)? A major manufacturer which, for the past three years has been outperforming the market, just reported earnings at less than half what market analysts had been expecting. Needless to say, the days of "outperform" are over...for now at least. OK, so that's the cost. Now, what about the quality side of the equation?

Well, this company is citing "higher warranty liabilities" on its products. Why do we have higher warranty liabilities? The company goes on to describe higher repair costs have impacted warranty costs. OK, so why higher repair costs? Well, we could go on and on, asking "why" five times to get to the root, but I think you get the point.

Now, let's consider a solution that approaches this from the top-down.
1. First we want to understand the market we wish to serve. Obviously this company has done just that. Then, let's target that market with a product that will meet the needs of this market we've identified, and let's come up with product characteristics and requirements that will allow us to compete profitably while differentiating ourselves from our competition.
2. Now let's translate those requirements into technical specifications so we can design a product that meets the market segment we want to serve. We want to design this product with:
a. Clarity around how we will manufacture this product economically while still meeting the specifications we developed and...
b. An understanding of how we will produce the product so we can meet the quality specifications while controlling costs.
c. Quality designed-in so we can economically support this product in the market place once it is in production and distributed.
3. With clear strategy (Step 1) and and eye to quality requirements (Step 2), we can now transition the product into production. If steps one and two were done properly, transition into production should be relatively straightforward as long as we thought about the risks that may arise as during transition.
4. Finally, we have a well-designed product, with clear specifications of designed-in quality, and the foresight that included risks of production. If stages one, two, and three were done properly, we can now rest assured stage four, operation, will have few surprises for us. We can be certain that the product will operate as expected because we designed this product with the end-in-mind within cost and quality requirements to meet the demands of the market we elected to serve at a reasonable profit level.

Hmmm, what a concept. Not a new idea...this has been with us for over 75 years.

Improvement is Everyone's Responsibility

I'm unhappy with what I'm seeing in this industry-the space in which I work- the industry that I CHOSE to serve - because I think it's a reflection of the sense of entitlement we are seeing in our nation. It has me concerned. My job is NOT to do FOR a client, but to show them the way so they may DO FOR THEMSELVES. Yet increasingly we are seeing a detachment from the law of physics: a failure to acknowledge that our actions today impact the results tomorrow. There seems to be a pervasive sense that one doesn't have to do anything, that one does not have to take responsibility for anything, yet by some magic, their processes and services should improve.

For some reason, many in this industry are of the opinion that it doesn't matter what they do; that someone will "bail them out" or there will always be time to "do it again". Well, there isn't. If an organization is looking to improve, it is the responsibility of EVERYONE in that company, not just the consultant, and not just the CIO, and not just the project manager. Quality is EVERYONE's business. Anything less is a waste of time, and effort. Quite frankly, anything less than universal acceptance of responsibility for our actions is useless.

Improvement is about changing the way we do things. The tentacles of change MUST reach across the organization, deep into the psyche of those essential assets, the PEOPLE, that add value in producing a product. It is in this state of entitlement that creativity, productivity, and success are stifled. There is no motivation to make the incremental improvements that, when aggregated under a focused effort, will lead to the improvement that is essential to success.

-- 

Well, We've Got To Do Something!

Our economic stimulus package is being justified by those promoting it as a measure we had to put in place because we couldn't stand idly by. Yes, something HAD to be done, but is it the right thing?

Many of today's organizations jump on the "program of the day", the favorite campaign of a new administration in organizational governance, with the same intent: "Well, it's as good as anything else. We've got to do SOMETHING".

OK, even if it's not the right thing?

There may have been a time when we could try something, stop, regroup, and then try something else. This is NOT that time. And why would we? Why do we have to learn the hard way? Today, we have countless examples of what doesn't work. But better, we have numerous case studies of what DOES! We have a framework within which we may drive improvement. We have time-tested guidance that goes beyond the "what" and directly addresses the "how".

The danger in doing "something" without thinking through the "why", "what", and "how" is the damage such reactionary, short-term actions may do to:

• Any current initiative
• The prospect of any future improvement effort
• The loss of credibility we will suffer in the process

Ask yourself, looking at the current state of the economy and the "stimulus package" do any of our representatives in Washington have any shred of credibility?

Service Management Won't Work for Us?

Many organizations do not believe common and centralized approach to processes will work for them. I find this particularly interesting. The underlying principles of ITIL and the concept of Service Management have been with us for a very long time. Prior to that, the elements expressed by the "good practices" framework were espoused in the principles of quality. The concepts are not new and, in fact, were used to manage mainframes years before the concept of distributed computing was ever developed.

Often resistance takes many forms but arises out of fear: fear of change; fear of accountability; fear of management. Regardless of the root of the resistance, it propagates unhealthy behaviors. Such behavior has the tendency to:

• Reinforce the perception that a given company is unique;
• Make individuals think their problems are unique to their business;
• Undermine the introduction of new ideas;
• Challenge the rationale of change;
• Promote activity that is incompatible with efficiency and effectiveness;
  
• Promote the sense that the road to success is an expressway.
  

Organizations that cannot come to terms with these issues will indeed struggle to be successful...but not just at implementing Service Management...they will struggle being successful in any endeavor.

Rather than focusing on all the reasons this "stuff" won't work for them, they should redirect their attention to understanding what might work and how IT Service Management can be used.

Not Every Organization Will Be Successful

I am constantly amazed by the number of organizations that operate with the belief that adopting this or that methodology or complying with a given standard or framework will make all their dreams come true and their problems go. There are a number of reasons not every organization that starts down the ITIL path is going to be successful. And those reasons go back to one of the quality gurus of the 40's and 50's. For your consideration I present the reasons in no particular order:

• Adopting a process framework requires change. An organization that is not open to change cannot be successful in adopting a standard or framework.
• Decisions require facts. Assumptions, soft figures, guesses, and "from the gut" intuition have no place in decision-making.
• Changing one element of a business process impacts other elements. Think of a water balloon. You cannot push down on one side of a balloon filled with water without displacing water elsewhere in the balloon and altering the shape and functionality of the balloon in general.
• The concept of constraints as they impact a system is very closely related to the above point. Regardless of where one may be in an organization, providing a service or fulfilling support, all individuals operate within a system. Ignorance of the reality of a system is just naive. One process, one individual, or one team can only be as good as the constraints placed on it by the system.
  
• Leadership, though vital to the successful adoption of any process framework, is not sufficient. Motivation for improvement must be integrated into the overall program and ultimately the fiber of the organization.
  
• Maintaining focus, momentum, and energy throughout an improvement program requires clarity. Clarity as to why we're doing this. Clarity as to what this means to me. Clarity as to how what I do today impacts the overall organization.
  
• Measurement is essential. You've heard the adage, now excessively over used. You can't improve what you cannot...what...?
• Uncertainty must be eliminated! How is it possible to eliminate uncertainty? And what uncertainty are you talking about? Process owners must feel they are working in a culture that is open to change, willing to support the entrepreneurial spirit, and will not condemn those who are working with a sincere commitment to the organizational objectives.
• Process owners must believe in and trust management. Sorry management. If your people do not trust and believe you, their efforts will lack heart and commitment. They will always be looking over their shoulder rather than forward.

Disservice of ITIL Training

As we struggle in the transition to ITIL V3, our industry is still dealing with a pervasive and, yes, unfortunately, very destructive influence left over from previous versions. If not corrected, this will only serve to slow acceptance of V3, but will undermine acceptance and integration of IT Service Management in general. Our clients look to us as experts. If we are hired as consultants, either internal or external, the expectation is we understand the ITIL framework. Further, if we are providing certification training, our customers should expect that we are preparing them to understand the conceptual essence of the framework. Unfortunately, this does not seem to be the objective of some training programs. The focus is on "training-to-the-exam" to maintain the high pass-rate advertised in the training sales literature. For those of you trainers out there, how many have been asked, "What's your pass rate?" as if that is the ONLY metric that matters?

When working with Foundations graduates, I am repeatedly amazed at the shallowness of knowledge exhibited by a percentage of individuals. They know the terminology. But they lack understanding. Each and every process is underpinned by a key objective and purpose. Yet this is not emphasized in training. We are distributing pins with a hope and a prayer that book smarts will translate to understanding.

Even at the Practitioner and Manager levels, many successful candidates have failed to integrate the concepts. It is not uncommon to hear, "ITIL says this..." or "ITIL allows for that...". And those trusting us, accept such announcements as gospel and, too often, as justification for ignoring risk that is being designed in to the process. Indeed ITIL may "say this" or "allow for that." But just because the framework makes such allowances, doesn't mean that going that direction is right for the organization - at that point in their maturity and capability! These are the tough questions that are overlooked - or perhaps avoided for the sake of expediency.

I would very much like to understand the cause of this all-too-evident phenomenon. One could conjecture that it is due to:

• The commoditization of ITIL training;
• The limited experience of newly minted trainers;
• The single-minded focus on one metric: pass rate;
• The inability or resistance of trainers to challenge the understanding of their students;
• The tendency of trainers, consultants, and certified professionals to take the easy course and avoid the tough issues.
  

Experienced trainers know that students will internalize new concepts within a mental framework with which they are familiar. They instinctively relate to something with which they are familiar. It is difficult for a student to divorce a new concept from previous experience. A trainer must recognize this and challenge assumptions to ensure the underlying objective and purpose crystallizes understanding.

Based on what we are seeing in the industry today, however, this does not appear to be happening. Many trainers are not challenging their students. Some consultants and "certified" internal personnel are not asking the tough questions. And for those who DO ask the tough questions, they face the daunting task of overcoming flawed beliefs reinforced by faulty, or at least, incomplete training. The credibility of the whole industry suffers as a result.

ITIL V3 Benefit

A lot of speculation and considerable confusion surrounds the ITIL Refresh. I feel this is good because discussion promotes understanding. A friend of mine sent me a Computer World article discussing some of these changes, "ITIL Starts Making Sense in v3" which provides a very good perspective on the value of the changes to the ITIL framework. The ideas expressed are excellent and right on target. Another set of insights on each of the books comes from the ITSM International Portal. If you're interested, follow the thread of updates through all the books. I'll not restate what these authors have already expressed.

But there is a danger here that concerns many of my peers. Now, before I list these concerns, let me say, AGAIN, that the ITIL Refresh was long, long overdue. And it helps tremendously in clarifying some of the ambiguity and in emphasizing the interdependence of the services as critically related components in a cyclical, service-centric framework. I am not certain that my concerns, which are shared by others in the industry, could have been addressed fully and appropriately in the framework. Regardless of what I say or how I say it though, some will interpret my comments as criticism and resistance to the refresh. That is not the case.

The concern is not the structure of the revision but the apparent lack of understanding of some of the content that is presented. For example, the book I reviewed prior to publication gave, well there's no other way to say it, "lip service" to long-standing principles of quality. Herein lies the danger: there is "just enough" information provided in the texts to make someone potentially dangerous. Based on my review and documented critique, "some" of the materials addressed core concepts that lie outside the immediate domain of ITIL. That is fine. But these concepts were simply resurrected, referenced and reiterated, ad infinitum with no convincing indication that the authors actually had first-hand, practical experience using the concepts. It is my fear that because there is no depth, no richness based on first-hand experience, the concepts will:
1. Fall on deaf ears;
2. Be dismissed as too inconvenient or complex to apply to an ITSM implementation;
3. Be applied with minimal understanding of the intended consequences.

Any outcome can only hurt ITIL in the long run. Inexperienced certified ITIL "experts" may adopt the same shallow attitude and rush forward with "all the right words" and none of the practical application insight. I saw it happen when only V2 was available. I suspect there is even a greater likelihood today; particularly if the emphasis is on "upgrading" your certification and "complying" with the framework for the sake of compliance rather than understanding the concepts to a depth of competence that will promote a solid implementation.

A solid implementation requires considerable "soul searching" and extensive decision-making. Many organizations cannot or will not:

• Do what is necessary to understand why they're implementing ITSM;
• Face up to the truth from their customers;
• Follow-through with a solid program implementation framework based on the principles of quality;
• Make the hard decisions;
  
• Have the patience to "stick with it."

Lacking the depth of understanding of the quality principles underlying ITIL, an implementor has little foundation to maintain course once it's started. Of course, that only positions many of us to come in and fix the damage after a failed implementation. That is, if the client organization hasn't already tired of the struggle.

ITIL V3 an Upgrade(?)

Two articles from the Bill Gates world of upgrades crossed my screen last week:

Giving up on Vista? Here's how to downgrade to XP

and

Microsoft gives OEMs five more months to install XP.

There seems to be an underground forming as a resistance to the Vista upgrade. And even Microsoft realizes they can't force it down the throats of enterprise IT as fast as they might wish. The timing of of these articles is interesting because just this week I've answered a lot of questions about the ITIL V3. Some people, service managers in particular, are worried. Others are wondering. Wondering what, you ask? Just wondering...

• Do we need to restructure our implementation plan?
• Do we need to retrain everyone?
• Do we need to bother upgrading at all? Why can't we just continue on the path we've already started?
• If I'm certified, what does this mean to me?
  

I'll save response to these issues for another post. What I will address is the undercurrent that seems to be taking shape in the ITSM world. These questions indicate there is a lot of confusion about the ITIL refresh. And the questions, prompted by frustration, are coming from some who just started structuring their service management program in line with ITIL. I am worried that the ambiguity is not helping promote the ITIL framework. I am worried that the acceptance ITIL has gained in the past five years will stall. I am worried that those of us working in the gap between IT and corporate quality see the gap only widening. I am worried about an undercurrent of resistance to the refresh will expand into a full-blown underground.

This refresh was long overdue. The organizational structure, which we have been advocating even before ITIL was widely recognized in the United States, has been addressed. The service life cycle, which again most experienced quality professionals have been recommending for years, has also been addressed. The focus on service is admirable. The evolutionary changes vividly demonstrate that ITIL is a living, breathing framework that will mature as needs dictate.

What concerns many professionals is ITIL V3 will be seen as an upgrade rather than the evolutionary improvement intended. Training, certifications and even the nomenclature, Version 3, reinforce that perception. The ambiguity that surrounds how an individual or organization can "evolve" to V3 risks fomenting a backlash of resistance that may well begin to resemble the anit-Bill movement.