ITSM Uncovered

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 solely 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 desirable. 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 24x7. 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 perform 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 deliverable 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 front-line 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 business 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 subconscious 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.

There are mainly two core elements to technology: infrastructure and development. The deployment of these elements and understanding how they are leveraged together is key to any successful organization. Each contains various flavors of implementation that are fundamentally designed to service the business mission. Some provide competitive advantages while others are generally designed to keep the plant operating and are not unique to a specific corporate business process.

Infrastructure is the true foundation upon which all technology rides. In many ways it is not unlike the plumbing, electric, foundation and framing of a house. It is the base that technology depends on to exist. For a start-up, simply getting the business off of the ground distracts from the longer term vision for the company. A technology trap many fall into.
As with a home, designing the right infrastructure will make or break how your technology evolves to meet the business needs both in the immediate and long term. Imagine designing and building a two bedroom home for a newly married couple. It suits their immediate need in starting their new life together. But what happens four years later when they are planning on their second child? That two bedroom begins to not seem as appealing as it once did; a true problem of capacity planning.

Plan, design and build for growth. If you don’t get these right, chances are the results will be both painful as well as costly. Infrastructure however, has an image problem. The power of infrastructure lies not with what the business or end users can see, touch or experience. Because of this, it is often overlooked in terms of investment. This fault is usually what bites most businesses in the ass when system failures begin to occur.

Development on the other hand, is usually the most visible and highly touted. It is these products that ride on the users desktop and provide the entry point to business functionality needed to complete the corporate mission. Whether that development is provided internally, via large commercial software houses or 3rd party vendors, the role is clear: Deliver core business process functionality.

It is assumed, although not always the case, that developers understand the business processes and are able to work it into their design to develop effective solutions. Internal development takes that concept even further as these groups exist within the company to provide custom solutions that deliver a presumed competitive advantage within a specific industry. For those companies who can afford this option, the value is clear as it can provide an edge over competitors in the never ending fight for market share. More importantly, it comes down to control. Proprietary applications that may contain functionality based on processes developed from within an organization can leverage the business knowledge in a way that drives development into very specific directions. The disadvantage with any software application regardless of who develops it, is that like Infrastructure, when it fails, there is a direct impact to business.

In the new-world order of Technology, there is a third element to IT which, like the Infrastructure, goes relatively unnoticed until something breaks. This is not software, nor it is hardware, let’s call it what it is; People. Yes, people run the infrastructure and people write code, but then there is Jack O. All-trades. The individual who knows a lot about infrastructure and development, yet also has that special skill to be able to communicate with the customer. Jack is not a Systems Administrator, nor a C# or C++ coder. Nope, this individual knows about Command Windows, X-Terms, Consoles, Windows Scripting Host, SQL Queries, HTML and Java development, tools of the trade. Jack knows how to run IP Config on a Laptop and understand what DNS servers it is connecting to, while running a shell script to recursively remove files from at TMP directory.

More importantly, Jack knows how to explain to the customer that their computer isn’t connecting to the web because when they booted their machine up, it did not pick up a new IP address or DNS settings from the DHCP servers which might be due to a faulty Ethernet cable, port, DHCP isn’t configured or the LAN may just be down. No, Jack will simply say “Let me take a look and see what I can do to get you up and running again.” Take a second or two to run IP Config /all to check under the hood, discover that all network connections appear in order, see’s the lights on the Ethernet port flashing, confirming network connectivity; run IPConfig /release + IPConfig /renew, Ping a few hosts or websites and viola~! Turning back to the user, simply says “There you go, back up and running. If you have any more problems, please let us know and we’ll get right on it.” Jack is on his way again.

This is an example of customer service and support skills in action, leveraging the basic tools of the trade that go unrecognized as a valid technology field in it’s own right. Of course this was a very basic example which does go much deeper than that in terms of ensuring that business services and users are not impacted by infrastructure or development system failures. It is not some individual with English as a second language behind a desk reading from a script calling themselves IT Support (I’m sure I will have more to write about in that space.) I am referring to that undervalued and overlooked position on the front lines of technology, leveraged as a critical element to an effectively run technology environment. This group of individuals needs to be recognized as the not just a “IT guy/gal”, but that bridge which binds a business to its technology.