Transforming IT

How to Get Your Head OUT of the Game

In the battle to transform your organization you have one great enemy and one great weapon - and they are one and the same: yourself.

So much of the time, we are our own worst enemy.  We make things more complicated than they need to be and we let ourselves get in the way of our own success.  The reason is that it is easy to forget why we are doing what we do and we end up putting too much focus on the wrong things.

As I have written about before, I spend an hour an a half each week with my tennis coach. He loves to laugh at me and tell me that I must be self-employed...because I am miserable at taking direction. But in truth, I see a lot of similarity between what he does with me and what I do with my clients.

Essentially, he helps me build a process, a routine and a rhythm that leads me to be in the right place to strike the ball and a consistent form with which to do it. It is not unlike what we do when we work with clients to institute a new or improved process. The purpose of the process is to provide us with the "step-by-step" so that we can develop a rhythm that will help us deliver a better service.

But there is always this point when my coach is working me on a drill when I have to put all of the "step-by-step" aside and just play the ball. It is an important step that we often forget when we are talking about process improvement - the purpose is not to go through the steps. The purpose is to play the ball well.

While the step-by-step creates muscle memory and teaches me where I should be ending up and helps me practice the rhythm, there is a point when the process stops becoming a help and becomes a burden. It takes too much energy to think about every step and I start messing up my strokes. It is at that point that I must stop thinking about the process and just play the ball - trusting that my practice will have paid off.

The same is true when we are working with IT processes. The process is important. While we are learning the new way to operate, we need to rely on the process to guide us. But we can never let the process become our crutch. Our purpose is not to go through the process. Our purpose is to deliver a great service. The goal is that the process simply becomes how we operate and it ceases to be something that we must spend too much time thinking about.

Instead, we just play the ball.

So if you are wondering what is going wrong with your process improvement effort, it might be that you need to get your head out of the game a bit. Spend a lot of energy getting you and your team to understand what you need to do and the purpose behind every step.

Then stop thinking, get your head out of the way, and just play the ball. That is, after all, why you went through all of this trouble in the first place.

Should You Break All the Rules During an Emergency Change?

During an emergency change, do you know which rules to break?

It rained a lot in California last month. Every time it rains, there are a lot of accidents.  Californians, it seems, just don't know how to drive in the rain. A lot of accidents mean a lot of ambulances.

I do not want to make light of these accidents. They are serious incidents and a horrible occurrence.  But having several ambulances roll by me did make me think about how they operate and what we can learn from them in relation to emergency changes.

RULES ON BREAKING THE RULES
As I was sitting at a stop light, I heard the siren coming from my right.  As our light turned green, the ambulance approached the intersection. We, of course, all stayed where we were, giving them the right of way. With all of us sitting still, but his light red, the ambulance essentially came to a stop at the intersection and gingerly eased his way across it. The driver almost lurched across the intersection a couple of times as he cautiously peered around cars to ensure that there was not a distracted driver about to come flying through the intersection oblivious to his "right of way."

As I watched this unfold - as I had many times before - a thought occurred to me.  The ambulance was following a set of rules on how to break the rules.

The laws vary from jurisdiction to jurisdiction, but they all come down to the same thing: the ambulance driver is permitted to break the normal traffic rules, go through red lights, pass in non-passing lanes, etc. as long as they take due caution for public safety. It makes sense, right?

IF AN EMERGENCY CHANGE WAS AN AMBULANCE...
This makes perfect sense to us as drivers. If instead of cautiously edging across the intersection, the ambulance driver had blown through it at 80 miles an hour, several of us would have been calling 911 reporting them for being reckless. It is obvious and intuitive - the ambulance should be able to break the rules, but not if they are going to introduce greater risk to themselves and other drivers.

While this makes perfect sense in the world of ambulance driving, for some reason it  seems somehow illogical whenever we are talking about emergency changes.

Whenever there is some critical incident that requires an emergency change, the prevailing wisdom is that the change should be able to be made without any regard for the rules. But how is this any different than that ambulance running through the intersection at 80?

THE DIFFERENCE BETWEEN URGENCY AND PANIC
Emergency changes are tough because they come with a demand for urgency. The impact to service can create a near state of panic as teams rally to fix the problem.

But there is a fine line to be found.

During a critical incident, a sense of urgency is required - demanded even. But urgency is not panic. Urgency is not action at all costs. Urgency means that you are reacting as fast as you possibly can while ensuring that you don't make the situation worse.

Among several posts during his career, my father ran a narcotics team for the Los Angeles County Sheriff's Department. I once had the opportunity to do a "ride along" during the surveillance of a suspect. While this guy was driving around, completely unaware that he was being followed, my dad and his team were literally creating a virtual net around him. My dad and members of his team were running red lights and breaking all kinds of traffic laws in order to stay in the proper position to maintain the surveillance.

While these were urgent actions and reactions, they were completely devoid of any panic. In fact, my dad and his team were completely calm and in control at all times.

There can be this misconception as to how you should react during a time of crisis. Thanks to the movies, there is this image of the commander frantically running around barking orders. During a crisis, however, the most effective leaders are those who remain perfectly calm and in control. They instill a sense of urgency, but they are not frantic. And they absolutely refuse to throw out all of the rules in the name of urgency. In fact, they know the secret - that during a time of crisis, many of the rules are more important than ever.

CREATING YOUR RULE BREAKING RULES
The trick is to provide a clear path to guide a calm reaction during a crisis. In the cases of both the ambulance driver and my dad's surveillance team, there were defined rules on how they were to break the rules. An emergency change process must be the same thing.

It cannot be a free pass. Instead, it must provide a clear set of rules which will allow for the urgent reaction required, but in a way that does not introduce undue risk. It must also define the responsibilities of others to make the urgent execution of the emergency change safer (i.e. other drivers must pull over as the ambulance approaches).

Your goal is to create an emergency change process that enables an urgent reaction, but that does not result in or rely on panic. You seek to create an emergency change process that results in a calm and controlled execution of necessary changes as fast as possible.

Doing this will require that you carefully think through the rules that you need to break the rules.  And a siren couldn't hurt.

Do your ambulance drivers know the rules to breaking the rules?

Drunk on the ITIL Kool-Aid

There was a great conversation started by Craig Wilkey at the itSMF USA LinkedIn Group the other day. His question was simple: is there real value in giving every member of an IT organization ITIL Foundations training. (Click here to read and join in on the conversation)

I want to make it clear that I DO NOT oppose ITIL training. I've actually taught the ITIL v3 Foundations course. But what I've found is that injecting ITIL training into the discourse of an improvement/transformation initiative is a 50/50 proposition. Sometimes the common understanding and language helps and sometimes it makes it a lot harder to move past the dogma to get something done.

The most successful "service management" initiative I've ever been a part of is when I did it for myself (I was responsible for technical operations at a large healthcare organization). And we didn't know how to spell ITIL, let alone go through Foundations training. That's because we weren't focused on Incident or Change Management. We were trying to figure out how we could enable the rapid integration of acquisitions and how we could better enable and support a new business to provide remote patient care. The solutions to those business challenges had everything to do with how we handled Incidents and Change, but it frankly wasn't critical that we "knew ITIL" to solve the problem.

I see ITIL training as much more about personal growth and professional development. If you're willing to invest in yourself and you seek to use your newly acquired knowledge to look at how you can best serve your organization and its customers, then you will win. But we are often confronted with needing to break highly ITIL trained people from their dogma long enough to focus on the business problem at hand. We have seen countless practitioner and even Expert-level trained people that simply have very little understanding of how to truly apply the principles in pursuit of a business solution.

I will often start a process conversation with something like, "This is what ITIL says about this...now you need to figure out how to apply this to the problem you're trying to solve."  A lot of time, what results is nowhere near a "good practice" and I know it will need to be refined and fixed somewhere down the road, but it is the right thing to do because it moves the ball forward for the organization. And in many cases, we have to drive this over the objection of those ITIL-trained folks who are drunk on the Kool-Aid and have forgotten that we're not there to "implement ITIL" but rather to simply solve a problem.

So the answer to the question of how much ITIL training is appropriate is really rather simple - however much, if any, is required to move your organization toward solving the business problem at hand.

No more and no less. And if you can lay off the Kool-Aid a bit, everything will go much more smoothly!  (Thank you for joining me for today's rant!)

Why Knowledge Fails to Transform

Whenever we're involved in an IT Transformation effort, we employ an adoption philosophy that has four components: Awareness, Involvement, Education and Adoption.  The point is to create engagement and investment in the changes being made.

But what we always find challenging to overcome is the reliance that teams have on knowledge as the key driver to enacting change.  But as Dan Heath puts it so well in a recent Fast Company article, "The problem is this: Knowledge rarely leads to change."

Yet time and time again, teams go through the entire process and then finish with a thud by rolling out some boring training program and then expect people to change.  But as Dan Heath points out, it's not knowledge that's needed - it's feeling.  People must make an emotional connection with the transformation effort before they will willingly change their behaviors.

It's this emotional aspect of transformation that can be uncomfortable for IT people.  We like bits and bytes.  We like things tangible and logical.  Where does emotion fit in?  But the reality is that behavioral change is fundamentally driven by human emotion.  Because it is only an emotional connection that will overcome the ingrained desire to simply "hold course."

So, to be successful in your transformation efforts, you need to break free of the "Chains of Knowledge" and put a little bit of feeling into your program! 

Checklist for Change

A client recently sent me this article about the utilization of checklists as we were going through some discussions on the implementation of a new ITIL-derived change management process. 

What I love about it is that it has nothing to do with IT.  It's about operating rooms.  Yet the lessons still apply - and my client was wise enough to see the correlation.  At the end of the day, most of what we do, well, isn't surgery.  It can be complex and can be incredibly important and risky for the business, but most of the time it's not life or death.  So where we can find lessons from people or organizations who are playing where the stakes are that high, we should look at them carefully and ask ourselves how we might learn something from their challenges and solutions.

My client did just that.  If you read the article, though, there is an extremely important piece of information that is easy to miss.  The checklist is important - but the real value comes from verbally going through the checklist as a group.  It is this interactive and interrogative process that creates the true power of the checklist - and when that step is skipped, the checklist loses its effectiveness.

I think that this is a perfect corollary to the Change Advisory Board (CAB).  There has been a lot of push recently to this concept of a "Virtual CAB" - a change authority body that doesn't actually meet, but reviews and approves changes based on a review of the RFC by using some automation tool.  Don't get me wrong - I'm a fan of the "Virtual CAB" for minor, low-risk changes.  But I believe that their use is becoming too prevalent and organizations, in their zeal for automation, often miss the true point of the CAB - to discuss and evaluate the risk of the change with all stakeholders to ensure that the risk has been adequately quantified, mitigated and accepted.  It's tough to do that with a click of a button.

So perhaps there is a lesson to be learned here.  We should use a checklist to help the CAB ensure that risk has been mitigated and that RFC approval requirements have been met.  But to really make it effective, we must require that the CAB does it verbally.  Maybe by doing so, we will get that dialogue that supposed to occur and perhaps we will begin to get a more complete understanding of the true impact and risk of proposed changes.  And maybe, just maybe, the process will work a little bit better.

Read the article by clicking here and see how you think you might apply it yourself.

The Fuss and Hype over CMDBs (aka "myCMDB")

We may have finally reached the pinnacle of CMDB hype with Managed Objects' release of their new product, myCMDB.  While I have been somewhat of a fan of Managed Objects, this one just has me completely baffled.  The press release hype is talking about bringing 'Web 2.0' to the CMDB.  Huh?

It seems to me that this is indicative of a general trend to make the CMDB so much more than it was ever meant to be...and in so doing make it more and more difficult to actually make it work.  Managed Objects is certainly not alone.  It seems as though there is a virtual land rush out there to see who can cram the most different types of data into the CMDB.

Call me a simpleton, but here's my take on effective CMDB implementations:

1. Keep It Simple - CMDBs (and really the Configuration Management System (CMS) - so we can avoid this whole discussion of one really big CMDB!) should be a relational representation of the core and critical assets that IT utilizes to deliver services.  Each organization needs to determine how deep that needs to go to be effective, but there is a definite balance point that must be found.  The more detailed the data, the harder it will be to keep it accurate.  So, the key point is to get the level of detail just "good enough."  IT people are sometimes their own worst enemy here - once we get a hold of this, we want to put everything under the sun in this wonderful, magical database.  Remember that we can provide access to additional detail and related information through the federation model, but when we are talking about what should be considered a CI there must be relentless restraint to keep the data model as simple as possible while still delivering data relevant to the delivery of service - just good enough.
2. Relationship Trumps Granularity - I always find it fascinating that so much effort is put into defining CIs to an excruciating level of detail, but little effort is put into mapping the relationships between CIs.  The truth is that it is in understanding the relationships that the true value of a CMDB/CMS will be found.  I believe that a CMDB/CMS that defines CIs at only a very, very high level, but maps their relationships effectively will provide significantly more value to an organization than one that contains infinite levels of detail about each CI and its various changes in state over its useful lifetime, but which cannot describe the relationship between each CI and others in the delivery of service.  Get this one right and everything else will fall into place.
3. Process is Still Key - ITIL is all about process (well, v2 anyway).  But when it comes to the CMDB/CMS, it seems that we throw process out the window.  Yes, I'm a big believer in discovery tools and application mapping applications.  But when it comes to maintaining the CMDB, nothing will take the place of a rigorous process.  Anywhere that there is a change to a CI, process should dictate how the CI data is updated in the CMDB.  This should be a key process activity tied to Change and Release Management.  It should also be incorporated into the Standard Change process that might be executed as a function of Incident Management.  The key point, though, is that if your CMDB is falling out of sync, it's a process failure.  Can tools help?  Sure, but nothing can take the place of a well executed, well managed process.

In the end, IT and the many wonderful ITSM vendors must resist the temptation to turn the CMDB/CMS into something that is delivered in and for itself.  It's not.  The CMDB is nothing more than a tool that provides appropriate and relevant data during the execution of a process, in the delivery of a service so that those responsible for the execution and delivery can do so effectively and efficiently.  A well implemented CMDB/CMS is one that becomes virtually transparent.  The data you need is available when and where you need it to get the job done.  If you're having to interact with your CMDB data directly - "Web 2.0" or not - well, you're kind of missing the point.

Changing Perspectives: Pena Pachamama, The Upside Down Map and the Meaning of ITIL

I spent Memorial Day weekend in San Francisco and got some much needed mental rest.  Over the course of the weekend, I had a couple of experiences that made me think about the meaning of ITIL, but it might surprise you what they were.

First, I stumbled into a fair trade shop in Healdsburg and came across a map with the fun title, "What's up? South!"  An image is below.  It was simply a map of the world printed "upside down" but with the name of each country, ocean, etc. printed "correctly."  The result is an entirely new view of the world.  If you step back and look at this with "fresh" eyes and don't let your mind automatically flip it around for you, you will realize how an arbitrary decision (who decided that north was "up"?) can inform our perspective to the point that we don't challenge it.  I must have spent 10 minutes just taking it in.

Later in the weekend, we were wandering down (or was it up?) to North Beach for some good Italian and rather than cutting over on Green as we had intended, we continued down Powell....and stumbled across this little restaurant called Pena Pachamama - an amazing Bolivian restaurant in the middle of Little Italy.  They had a Bolivian band playing which was followed by a Middle Eastern band - complete with belly dancers! 

It was quite an experience.  There were a number of locals who were obviously of Bolivian descent and they were interacting and dancing traditional dances to the band.  My wife and I felt like we had almost crashed a family party.  What I found most interesting was that while there were a number of similarities to my Mexican culture, there were also some very strong differences.  It was an experience that opened my eyes to a way of life that was both familiar and unfamiliar and challenged my perspective of what I would find in "Little Italy."

So what does all of this have to do with ITIL?  Well, maybe I'm turning into too much of an ITIL-geek these days, but these two experiences exemplify two of the greatest challenges that we encounter while trying to adopt ITIL within an IT organization:

• Recognizing that it is less that what we are doing is new and more that we are challenged to look at what we do and who we are in a different and new way
• Understanding that while all IT organizations come from a similar place, every organization has its own unique cultural elements that must be understood and accounted for in order to make an ITIL adoption successful

ITIL IS NOT NEW
One of the greatest challenges that we have to overcome is the recognition that, for the most part, ITIL is not new.  Most IT organizations are already doing large parts of ITIL in some way - you almost have to if you're going to function as an IT organization.  But like the map, ITIL is about changing how you look at what is already there and challenging some of the preconceived notions of how IT should operate.  Yet, when an organization embarks on an ITIL adoption effort, what's the first thing that they start with?  Process development.  There is always this significant effort involved with tearing everything down and "developing the new XXX process."

In reality, however, I have typically found that most organizations have a lot of the building blocks already in place.  It doesn't necessarily require that everything be thrown out.  What is really needed is a deliberate review of what's there, what's working and what isn't - and the conceptualization of the behaviors that will drive change.   It's all about organizational change - and that means changing perspectives and changing the assumed way of doing things so that new, more effective and efficient ways of operating can be envisioned.

THE CULTURAL QUOTIENT
Culture is a powerful thing.  Even when cultures come from a similar history and share many common elements small, subtle differences can have a profound effect.  My brief experience with Bolivian culture, contrasted with my Mexican upbringing brought that into sharp relief.  And so it goes with IT organizations.  Over the years, I have probably been on the "inside" of 30-40 IT organizations and no two are ever alike.  Sure, almost all IT organizations operate using a lot of the same elements.  There are only so many ways to structure an organization and most IT groups are responsible for broadly the same types of services, but the subtleties of how those services are delivered and how interactions take place between management and staff (among other elements of culture) make all the difference. 

So remembering that adopting ITIL is really about driving cultural and organizational change, you must understand the cultural nuances of your organization before you can set out to change it.  That's why an initial, singular focus on "process development" or any other type of process-focused work is often misguided.  The focus must always be on understanding and quantifying those outcomes that will support the goals of the business and then undertaking those tasks that will change operating behaviors in a way that will result in the desired outcomes.  Will the redevelopment of processes be required?  Probably, but as those process changes are rolled out, it must be done in the context of the unique and subtle elements of the organizational culture. 

That's why when it comes to ITIL, one size does not fit all.  Any attempt to adopt ITIL "out of the box" without applying the filter of your organizational culture and unique perspectives will find limited success, at best.  The contrast, however, is also true.  You can drive significant value for your organization, making IT more effective, more efficient and more business focused if you begin by embracing the role that your organizational culture plays in both your successes and your failures and by recognizing that you must change the perspective of how both of these are viewed to truly affect change.

Map Image © ODTmaps.com

The Maslow Adoption Model for ITIL

There appears to be a bit of 'Maslow Mania' taking root in the business press these days.  I've been a fan of his straight forward approach to understanding human psychology since I was introduced to his concept of the "hierarchy of human needs" by my dad as a kid.  But I really hadn't thought much about it or him until recently.

Over the past few weeks, I've been reading "Peak: How Great Companies Get Their Mojo from Maslow" by Chip Conley, the CEO of Joie De Vivre hotels.  As you might guess, he has used Maslow's theory as the basis for both his book and for how we runs his chain of hotels.

Then a couple of days ago, I read a great article from Baseline Magazine entitled, "Multiple Online Personas: The Choice of a New Generation."  In it, it discusses how marketers must start a new type of conversation if they are going to break through with what Gartner is dubbing "Generation V" - for Virtual.  The gist of it is that Generation V is not defined by age or geography, but by their desire for belonging, esteem and self-actualization, realized in online communities - the top three layers of Maslow's "needs pyramid."

So how can stories about a chain of hotels and retail marketers selling to an online generation and how they are using a 50+ year old psychology theory apply to the world of IT?

Applied to business, Maslow's theory is really about understanding a customer's needs. And let's face it, this is something that has not always been IT's strong suit.  But perhaps the most important thing that it can do is to frame an ITIL adoption effort.  One of the greatest challenges that an IT organization must overcome to succeed with an ITIL adoption program is to answer the question why?  Why is this project being undertaken?  Why is the investment of human and capital resources worthwhile?

These questions can only be answered by understanding the needs of IT's customers.  And Maslow's theory can help frame those needs.  Maslow basically said that humans (and therefore your customers) need five layers of needs to be met (paraphrasing a little): Physical, Safety, Belonging, Esteem, and Self-Actualization.  Chip Conley in PEAK boiled this down further into his Customer Relationship Model and identified three distinct stages in the relationship with your customer: Meets Expectations, Meets Desires and Meets Unrecognized Needs.

At it's core, ITIL is really about understanding and meeting a customer's base set of expectations and needs.  According to Maslow, until we've satisfactorily met that need, we cannot have a meaningful conversation with our customer about meeting any of their other needs.  So, why should you adopt ITIL?  First, because it is a key way in which you will help your IT organization meet the core, underlying needs of your customer.  Second, until you do that, you will be unable to move up the pyramid and find success with your customer at any higher level.

At the same time, when you begin an ITIL adoption it's also important to realize that adopting ITIL is also not enough.  While meeting their base set of needs is the first step, it's not what the customer really desires.  They are looking for solutions that will drive business value and help them succeed (personally and professionally).  The goal must be to enable IT to meet the "customer's desires" by enabling transformative uses of technology and ultimately identifying innovative ways that technology can provide competitive and differentiating advantage to the business ("unrecognized needs").

But none of this can happen until their basic, operational needs are met first.  So Maslow provides an incredibly useful framework for ITIL adoption: use it to meet the base needs of your customer, but only in the context of achieving a larger goal of business transformation that leverages technology for the betterment of the enterprise.  Not bad for a 50 year old theory.

Secrets of ITIL Success

I'm not typically a big fan of Pink Elephant, but SearchCIO recently posted excerpts from Graham Price's (of Pink) presentation at Pink's annual conference.  In it, he addressed the 10 biggest mistakes IT organizations make during an ITIL implementation - and what to do about it.  As I read it, I felt that it succinctly addressed the very common pitfalls that I have seen with ITIL projects.  There are other issues, to be sure, but what I particularly liked about his presentation was that he focused on the management and planning aspects of an ITIL adoption effort that are often overlooked or willfully skipped.

It's somewhat ironic that ITIL is all about process and management and yet when people embark on an adoption project, they skip over those very elements of the adoption process itself.  As in any project, an ITIL adoption effort is often won or lost at the beginning.  If you're about to start an ITIL adoption program (or restart one), this quick read will be well worth your time, provided that you take its lessons to heart.  Read the article here.

I'm curious to know what others think about this list.  Did he nail it?  What other mistakes would you have included?