My experience in IT Service Management has been with large, global organizations either driven by fast moving global markets or supporting highly complex infrastructure and application sets. It is easy in these types of environments to forget the main purpose of technology support. When things break, it is usually all-hands on deck. Needless to say, it is a highly reactive environment. These types of environments suck technologist in to becoming focused soley on the technology rather than the reason for being.

In 2003, I was asked to move back into my old support team to head up the group as my old Manager had decided to resign. During my absence the team had grown substantially and morale was less than desireable.  The business was growing, as was the demands placed on the team. Having cut my teeth in this environment I was very familiar with the pressures of ensuring that the business was executing on all cylinders, with as much up-time as possible 24×7. This had, and was once again, taking its toll on even the senior support analysts on the team. One of the first things I did when returning to the team was to have one-on-one sessions with each and every one of the 20 team members to determine not just what they were working on, but more importantly where their heads were at.

This was something that seemed the logical thing to do as a mid-level manager of a support team, which I likened to managing troops under my charge during my 8 years in the Marine Corps. I began every session with one simple question which guided the discussion from that point forward. It may seem like a strange question, but one vital to ask anyone in a support role:

Why are you here?

Profound in its simplicity, I was set back by the general response across the team. Most of the responses began with”I support X application,” “I peform monitoring on X systems” or “I respond to user calls about broken hardware.” In every case, in my mind these were all wrong answers. Of course these are the functions they perform while on the clock, but as to why they were there, I wanted to hear things like “To make sure the users can do their jobs,” “Make sure we can deliver to clients,” anything of that vein would have been more than welcome, but it was not what I was hearing. I asked myself why these individuals had lost touch with the basic business deliverables of not only IT, but that of the company as a whole.

To me this is often an oversight of Management lost in administrative responsibilities more driven towards demonstrating delivery to leadership instead of establishing a culture of understanding as to an individuals up-stream contribution to the business strategy and bottom-line. Without that perception of self-worth any individual will quickly loose sight. As a result, you will not get the level of individual performance by a person in technology who is clear on their purpose and contribution to the corporate mission. Take someone in Sales for example, they are very clear on their goals, deliverables, contributions and value to the business. Their approach every day is to bring in new business to raise the bottom line as well as gain a commission, if that is the value structure in place. In technology, this frontline value structure doesn’t always exist to drive awareness of their contribution. For this reason, it is vital that managers keep as part of their responsibility matrix, the importance of communicating the team’s contribution to the overall business delivery model to its clients and how that helps the business be more successful in relation to other competitors.

Reach out to the buisness and try to get your hands on the annual report information. That information is not only critical for you to understand, but ot use as a motivational tool to get everyone aligned with the business drivers. We used to love hearing this type of information and where our company sat in the market against our competitors. It became a subconsious driver to feel like we were truly part of the team. Not the IT team, but the corporate team, as a result we pushed that much harder to give the business the tools it needed to help the company compete with its competitors.

As managers, it is easy to get wrapped up in the metrics and numbers in delivering technology. Just never lose sight on the PEOPLE who deliver that technology and helping them feel as a vital part of the business, not just a tool used by the business.

When it comes to barriers in adopting ITIL as a means of managing a technology operation efficiently, it is often said that obtaining buy in from leadership is a “must have” or the “key to success.” I want to dive into that for a second with some possibly outlandish observations.

In most organizations there are usually three different layers or tiers within a technology organization; Leadership/Upper-management, Middle Management and the Operational layer. Like almost anything with three layers, the outer layers are usually firm and designed to absorb what comes at them from the outside. For leadership/upper-management their role is pretty clear. Deal with the business, budget and branding of technology. On the opposite end of the spectrum you have the day-to-day operational teams. These are the lower echelon of the organization who have developed a clear understanding of their role as well; the Business, Bullets and Bullsh*t.

When it comes to any change in the way any organization operates, it is usually mandated by the top layer, and implemented at the lower layer. Where it is driven from, in any successful implementation of not just ITIL but any mission, should be at that middle layer. It is at this layer where I believe success or failure lives and I don’t make this comment lightly.

Having spent 8 years in the U.S. Marine Corps and a Sergeant, I can tell you first hand that the success or failure of any unit’s mission lies squarely on the shoulders of its Non-Commissioned Officer Corps. That Middle Management layer of the Military, also referred to as “the back-bone” – The Sergeants, Staff-Sergeants and Petty-Officers, is where true change is managed and effected. It is where the Orders or Goals are received, interpreted, planned for and executed.

Now I am not suggesting that every business middle management layer operate like the Military. What I am saying, is that without middle-management buy-in and acceptance, any implementation of ITIL or any other endeavor will generally fail. Often what we see is Leadership or Upper Management attends a conference about ITIL or some other framework, becomes sold on the talking points, returns with the mission to have those benefits within their own organizations. They are essentially setting the goals of the organization. In most cases, not how to achieve the goals, just that this new destination is where they want the organization to be leaving it up to middle management to sort out the delivery.

At this point is where the fear of change begins to kick in. I have been astounded to enter into organizations where many within the middle management layer had risen through the ranks in an organization where small scale process had organically grown to a point that could no longer sustain the scale of business growth. Changing the only method of operations known, strikes fear into many. Diving into a new way of thinking or operating does not alway spark the passion and drive needed to move a organization into a new way of thinking. So what happens? Not a whole lot. There may be a few Overview sessions or training courses put in place, but in terms of mapping out a strategy, plan and then delivering on it proactively, there isn’t the push needed. The leadership needed is stonewalled by the fear of change.

Interestingly enough, it is the operational layer that after a couple of these training or overview sessions sees the benefit of adopting a new way of operating, even if it means a certain amount of pain to get to a place where fewer things break, service is delivered faster and their daily lives move from fighting fires and being door-stops to being more proactive in finding solutions to not only make their own lives easier, but also contribute to moving the organization forward.

If you do not address the resistance of adoption at that middle management layer, you will end up with a dysfunctional and sometimes hostile environment of change. Deadlines to leadership are not management, then at the last minute it becomes another exercise in jumping through hoops at the operational layer which breeds contempt and a lack of respect for what appears to be mis-management of the organization as a whole. In-turn there is a drop in morale and, well everyone loads into the hand-basket for the trip to hell.

The self-fulfilling prophecy of failure is the responsibility of middle management. To be fair, I am not referring to all individuals in middle management, you do have your champions. The problem is, these individuals are not always put into a position to drive the movement forward. These are the believers, the visionaries, the ones who “get it.” Empowering them is the key. Placing them in positions that are either directly backed by leadership with authority or given the illusion of authority will go a long way to silence the resistors in the organization.

I have to admit that I have little tolerance for those who choose to be part of the problem rather than part of the solution; call it the Sergeant in me. On the up-side however, in my position to implement two key ITIL processes I have developed the unique ability to remain ‘at-ease’ when I hear “Yea we know it is supposed to be like that and we will get there, just not now because it has never been done that way.” Back in the day, those would have been words which called for an immediate blanket party to sort the situation out. Ooh Rah!

So my advice is this for anyone in a leadership/Upper-management position thinking about implementing ITIL or any other change that results in a significant thought process shift for the organization; Find your motivators, your proactive, open-minded individuals up front. Develop a program outside of any specific department or team, empower them, supply them with the tools and training necessary to succeed, communicate your support for them to the Organization then turn them loose and get out the way. You may be surprised how much can get done.

1. Don’t Abuse Delegation
2. Support and Protect
3. Understand the Consequences
4. Listen and Learn
5. Champion Champions
6. Be Firm But Fair
7. Listen
8. P.O.T.S. (Part Of The Solution)
9. Teach and not lecture
10. Never forget… Its NOT all about you!

I’m not sure why it is a general human trait to want to be satisfied with chaos. What I mean by that is in the world of technology there needs to be a certain state of order to be effective. It is for this reason that certain “Industry Standards” have been develop based on best practice.

Take for example the basic premise that the entire existence of technology is to serve the user. Somehow that concept becomes lost on those who work in technology. As long as I have been doing support, I still understand that no matter what happens, it isn’t about protecting mistakes made by individuals, nor is it about throwing people who make mistakes under a bus. It is simply about making sure that the products or services that we in technology provide are available to those who make a living using it.

In order to do this, it has been my experience that you need to put in place guardrails of sorts to ensure that no matter what side of the road you travel down to get to to your destination, you are at least not going to run off of the road completely. These guardrails are the processes and policies that are developed and implemented to ensure that all is operating and being measured within a set of standards.

It is an evolutionary thing really, organizations start out small. There is no real level of complexity that demands standards, so you do what it takes to get the job done. This is the “Wild West” phase of organizational growth. At some point however, you do reach critical mass where simply doing “whatever it takes” creates more problems than it solves. The mentality is to get it to market and if something breaks, just fix it and push on.

At this point is when a serious assessment needs to be made on whether or not it is a one-off issue or a growing state of mind that needs to be adjusted or reigned in with some structure. The general perception is that there is a right way or a wrong way to do things. I would argue that there is a single way to do things. A way that is dictated by several things. The first is the tolerance of the technology deployed to adapt, the other is the tolerance of the business to accept failure from its technology.

The bigger an organization gets the less tolerance for failure will be accepted. I believe it is the mark of a good technology leader to see this coming and put controls in place to ensure that everything begins to melt down at one time. It is a serious cultural change in the way technology organizations operate.

Take for example, a service like Twitter. For years, it worked. It drew crowds. Then it began to hit critical mass and the infamous “Fail Whale” began to appear more frequently. So much so that capacity outages became almost a daily occurrence. Not having been a fly on the walls of twitter-ville, I can’t say that anyone had the controls in place to see this coming. To predict when things were due to break before they actually broke. From a customer point of view, all I knew what that the uproar from the twitter community was huge. Many began to leave for other services, giving up on twitter completely.

Apply the service provider/customer model to any business and you can see where managing technology effectively becomes a higher priority than just making it through another day with a few outages. At the end of the day it is about revenue and market share. When technology understands its true contribution to this model will we then begin to see more investment in controls, governance and risk management.

These are not traditional hands on development or system administration roles, and that is probably the reason why technology departments haven’t embraced the concept of managing technology as a business. Most senior management has grown up in the very chaotic environment that they now struggle to manage. There is no experiential growth that can get them to understand the importance of running technology as a business.

The most effective leader is one who abandons “the way it has always been done” and begins to look to the industry to provide the answers needed for stability and growth. Once that happens, can the chaos begin to be managed into something which supports growth and stability in any organization.

In the realm of a high transaction environment I find very little value in trying to analyze data on a day by day basis. That poses the question, what are we trying to perform analysis this low in the transaction chain?