Are We Conditioned to Tolerate Mediocrity?

I learned a long, long time ago while decorating the exterior of my home for the holidays that you should test the strands of lights BEFORE you put them on the house. Well, geeze, you don’t want to be looking for the broken bulb outside, on a ladder, on your roof in November in any climate but especially not in Minnesota. While you’ll probably agree that testing the strand before you put it up is a good thing, I ALWAYS hate it. I have to go through each bulb, one at a time, to find the Dirty Little Culprit (DLC) that was keeping the strand from lighting - limiting the capability of the entire strand. By the way, this is an example of the Theory of Constraints; but I digress. This generally requires a meticulous exercise of removing each little bulb, one at a time, from the unlit strand and inserting it in the socket of a strand that I know will light. I have broken more than one bulb over the years just trying to determine if it was the culprit that was limiting the other bulbs in the strand from fulfilling their state purpose.

Last year I realized I had had enough of this nonsense. I splurged for a bulb tester; I really splurged - it was marked down at an attractive AFTER-Christmas price. So, this year while carrying out my strand testing ritual, just as I expected, I found a strand that would not light. Out comes the new toy, the bulb tester, from last season. I dutifully read the instructions (yeah - really) and, after inserting the batteries backwards once (hey, you just try to read the + and - indicators inside the battery compartment of this device without high contrast lighting and a magnifying glass) I tested the strand. Wow! All I can say is WOW! It worked. In just a few moments I found the DLC, replaced the bulb and - I’ll say it again - WOW, the whole strand lit. So why am I surprised? Well here’s why…for once, the product worked as advertised and I did not need an engineering degree in electronics to use the product. I guess I’ve been disappointed so often that I’m now conditioned to expect mediocrity in the products and services I buy and use. And therein lies a few lessons for IT services. If you want your customers to be in awe of your services think of the service you provide in context of what you’re trying to accomplish with the service.

1. Understand the need you’re filling for your customer. The bulb tester fills a very specific need. But you have to go further. You need to know how the customer will use your product. The designers of this little device not only understood my need but understood how I would be using the device. In addition to testing the bulb, it has a slot to test the in-line fuses that are common in decorative lighting. And, it has a bulb extractor that will save your thumb and fingernails. I suspect they had their own personal moment of truth each holiday trying to find the DLC and designed a product to meet the all the varied activities that are part of getting a strand of lights to, ah, light.


2. Simplify. Make it easy for the customer to use. The tester I have uses a series of very intuitive and idiot-proof red and green lights. Except for the battery alignment indicators which are tiny and scribed in the same color as the plastic device, the product was indeed simple to operate.


3. Don’t burden your customer with the complexity of the service. As curious as I am about how exactly this bulb tester works (inductive fields or something), the product literature was probably not the place to include this information. From a user or customer perspective it is enough that the device works.


4. Set the customers’ expectations. Make it clear what the service will do and will not do. The bulb tester tests the line voltage and the bulbs. It also works as a bulb extractor. But it is not designed to test household current, the viability of a cable television outlet or the presence of a network.


5. Deliver against the expectations. Make sure the product does what it says it will do. This little device did meet my expectations. OK, so I’ll say it again: Wow.


6. WOW your customer. It’s not enough to just meet expectations. Exceed them. I was astounded at how easy this product was to use, the price point at which I acquired it (remember-I bought this last year at a very attractive after-Christmas discount) and the scalability of the item (it will work on any length of strand or type of Christmas bulb or lighting configuration).


7. Make the customers’ lives easier. The product should solve a problem (see number 1 above) and should be designed in such a way that the solution is simpler than the problem it is meant to solve (see number 2). I no longer dread the annual testing ritual.

In these seven points we have highlighted the importance of key aspects of IT Service Management:

• Availability and Service Level Management
• Service Level Management
• Financial and Service Level Management

Further, the instructions, or the training if you will, were legible, made sense and used illustrations. As customer, I made the effort, budgeted the time, to read the instructions. Funny how the product works if all parties, the service designer and supplier and the customer or user, both make a commitment to do their respective parts.

Are Your Expectations Too Low?

Growing up I came to expect certain things as “normal.” These were events or conditions that were routinely part of my life. I didn’t know anything different and besides, I figured they were out of my control anyway. Well, now that I’ve “grown up” - and I use that term cautiously since I’m not all that sure I ever really grew up - I no longer want my pork chops broiled to shoe leather toughness, I expect air conditioning in the warm weather months, I DO want cruise control on my car and it’s OK to have a phone and television in multiple rooms my home. I also expect a certain level of service for businesses I frequent and I have become addicted to instantaneous news over the internet rather than waiting for the afternoon paper delivery. Since Jurassic Park, I have a higher standard regarding special effect movies. All this brings to mind how we in IT are conditioned. I came to expect getting paged over the weekend as routine and regarded such interruptions as “part of the job.” I would start each day expecting the worse; and generally my expectations were fulfilled beyond my anticipation. But it didn’t take too many Sunday morning pages to realize that there had to be a better way.

We in IT don’t need to settle for a life of interruptions, infrastructure faults, frustrated customers and poor morale. Edwards Deming said it best: “We have learned to live in a world of mistakes and defective products as if they were necessary to life. It is time to adopt a new philosophy.” The faults we deal with each day are not necessary to life. There is a better way. As any Six Sigma belt will tell you, the world looks completely different once you have completed a Six Sigma project. What seemed “normal” is no longer necessarily acceptable.

I feel very strongly that my students and the process and service improvement project team members I work with will come to expect a something better. Their expectations will increase. They will have no tolerance for faulty processes, accidental design, expensive maintenance, poor availability and excessive or frequent outages. Their world will be filled with a different set of expectations built upon a higher standard of effectiveness, efficiency and simplicity. And that is as it should be.

So what does this mean to you and me - to those of us who manage people? We have responsibility for our staff and must empower these folks to realize the world they envision. And I submit this not because it’s just the “right thing to do.” I offer this for discussion because if we are going to continue to attract the best people to information technology, we need start providing them the skills, tools and power to remake the world of “mistakes and defective products” into the new philosophy. They already know they do not have to settle for less. We need to see that they don’t have to.

What’s a FOB-AIP-SEPR??

Don’t try to “google” this phrase. You’ll end up with all kinds of returns. Google will find everything from a German language dictionary and Israeli web sites to a listing of United States stock codes. How do I know? OK. I “googled” it. But only to see what would happen. FOB-AIP-SEPR is an acronym created by a friend and colleague as a memory peg for the steps involved in an ITIL implementation. The steps to the traditional roadmap follow the FOB-AIP-SEPR sequence:

F-Feasibility Study
O-Objectives and Scope
B-Budget
A-Awareness Campaign
I-Identify Roles & Responsibilities
P-Procedures, Options and Integration Points (of the program)
S-Staff Recruitment
E-Evaluate Tools
P-Pilot Implementation
R-Review

While this looks very much like a very well-defined step-by-step sequential process, in actuality these steps are iterative. We learn something from each step which generally requires us to revisit a previous step to validate our new information. That said, however, the logic of the steps is directionally valid.

This step-by-step approach is always done, then, within the context of the following guidelines:

1. What is the vision? (Business Objective, CTQ Workshops) - The IT organization that is seeking improvement must understand, in no uncertain terms, what it is they are all about, what they want to accomplish. Unfortunately, our experience indicates that far too little time and effort is devoted to this first but critical step of an improvement program that establishes where IT is going.

2. Where are we now? (Assessments, Surveys, Interviews, Executive Overviews and Workshops) - While Step 1 addresses the goal, Step 2 is equally important in that it is essential to know where you are today. Like Step 1 above, Step 2 is loosely aligned with the “Define” stage of the Six Sigma DMAIC process. But it also deals with “Measure” as it is an essential baseline measurement. The specific methodology of discovery at this stage is dependent upon the current state of the processes and organization. Often a very preliminary investigation must be carried out. This may be accomplished simply with management during an executive management overview to determine the best approach or means that we’ll want to use to evaluate the organization’s capability from which we’ll derive the starting point - the baseline.

3. Where do we want to be? (Control Objectives, Measurement Targets, Gap Analysis) - The specific method of discovery at this stage is dependent upon what you find in Step 2, the baseline. Thus, it CANNOT be done without Step 2. Only once the organization understands its current process baseline (Step 2) can they begin to visualize what they want to accomplish with the process improvement initiative.

4. How do we get there? (Process Improvement/6 Sigma, Process Design Workshops) - There is only a limited amount of science at this stage. Oh sure, there is some math, weightings and guided evaluative exercises. But the talent and experience of the process improvement expert comes into play significantly at this level. Further, the openness and commitment of the process team is essential. Come to think of it, this aspect is controlled and managed by the improvement expert as he or she must facilitate the sessions that will target the steps to improvement. So while improvement will impact the technology and process components, the real value at this stage is in empowering the “people” component to overcome the biases and inconsistencies of, shall we say, “the human condition.”

5. What are the quality criteria? (CTQ, functional, non-functional and business tracking matrices) - At first, this step may seem to be out of sequence, but in fact, it is an extension of Step 1. The quality criteria are captured in Step 1 and, through the methodical process of tracking and traceability, translated into evaluative criteria to see what was intended is actually implemented as an output of Step 4. Didn’t I say at the outset that this sequential approach is iterative and interdependent?

6. Maintenance (Control Plan, Reporting, Feedback) - Step #6 provides the self-correcting algorithm feedback loop to evaluate the strategy and vision and determine if we're on-track or if we need to adjust our strategy - the essence of a learning organization.

That's the roadmap; or at least the outline of the stages the improvement roadmap will address. But timing is a different issue because of the challenges unique to each organization. Some of these include:
• Cultural issues and resistance to change
• Leadership skills in managing change
• Tools dependency (and I might add obscene tool proliferation and flagrant point solutions)
• Capability and maturity of the organization which directly influences the transformation (from system support to service management) potential of the organization
• The level or degree of unrealistic expectations (inadvertently set by poorly trained and inexperienced champions)
• Inability to measure (lack of process and process metrics)
• Reluctance to measure (fear of "being found out")
• Accountability (also fear of "being found out" or perhaps fear of actually having to do something)

Thus, the timelines are highly variable. Each organization has all of these concerns to varying degrees. Further, the individual steps an organization will take is dependent upon the current maturity and capability of the organization, the starting point and the level of commitment and budget available. There are roadmaps; at least one unique roadmap for every organization that has successfully made the transformation. But each of these roadmaps would have no value for the another organization because what was designed to work at one would not fit the culture, needs and performance requirements of another. The programs we have assembled for client organizations are based on our understanding of client’s challenges at the time. The measures, communications, objectives, vision, and final milestones were specific to the needs of the organization at that time and what would work at that specific point in time, for that unique organization, given the capacity of the organization to deal with change within the capability of the existing processes.