Having said that, it is also one of many roles which requires soft-skills in dealing with core technologists, leadership on both the IT and Business side, I would probably not be employed if I didn’t learn to interact and maneuver around the politics and personalities at all levels, in getting anything done in IT.  So to say there is a back-lash or that I am a weenie for possessing soft-skills is somewhat an oversight as to how Technology needs to function in the modern business environment regardless of industry.

In short; all roles in Technology play their part in delivering on a business strategy.  If we are failing in anything it is not ensuring that technologists “core” or otherwise do not think of themselves as better than any other technologist and that each requires different skills to serve a higher purpose.  The cog in the machine if you will.  Maybe then we can begin to leverage these different skill-sets instead of further instigating a “who’s better than who” battle in IT. This is no longer the 1980’s.

To compare a “Core” technologist to that of a general technologist will always garner the contempt between various IT fields.  My background is in support for example.  I love technology and make every attempt to learn about the technology behind the products I have supported.  Now, further on in my career as an Incident, Problem and Crisis Manager,  I have to know about all areas of the products and services that IT delivers to the Business, including the likes of Storage, Database, Applications and Networking/Voice.  I am not a specialist any any of these core technologies, but I am a GEEK for driving to understand them and how they work together to enhance our deliveries to the business.

Having said that, it is also one of many roles which requires soft-skills in dealing with core technologists, leadership on both the IT and Business side, I would probably not be employed if I didn’t learn to interact and maneuver around the politics and personalities at all levels, in getting anything done in IT.  So to say there is a back-lash or that I am a weenie for possessing soft-skills is somewhat an oversight as to how Technology needs to function in the modern business environment regardless of industry.

In short; all roles in Technology play their part in delivering on a business strategy.  If we are failing in anything it is not ensuring that technologists “core” or otherwise do not think of themselves as better than any other technologist and that each requires different skills to serve a higher purpose.  The cog in the machine if you will.  Maybe then we can begin to leverage these different skill-sets instead of further instigating a “who’s better than who” battle in IT.  This is no longer the 1980’s.

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.

The reality is, there is not always going to be a clear cut work around or a definitive root cause determined.  Take performance issues for example.  There is clearly something impacting the service, tickets are generated from the user community, but when being analysed by Problem Management, there is no single area that may be determined as the culprit.  In cases like this, every layer needs to be analysed, poked, prodded and explored to determine where the root cause may be hiding.

Today’s technology environment is complex.  The amount of dependencies and integration points are not always as clearly mapped out as they should be.  What may appear, from the end user’s perspective as an application level of slowness, may actually be the result of something either in the infrastructure of the network itself or other services consuming bandwith on the network.  Being able to track down and clearly identify the source is a daunting task.

This raises the question of how many layers and types of Problem Management are there and how are these documented with regard to types of Service the Problem Management function provide?  In my own daily practice, I have been able to identify three layers of Problem Management that would need some form of service model built around them, documented and assosciated with service level agreements. They are:

Proactive Problem Management

• Service Desk Problem Management
• Escalation/Performance Problem Management

Reactive Problem Management

• Incident generaged Problem Management

Regardless of the model implemented in an organization, there is no possible way to focus on all of the above from a single role or function of Problem Management.  Each area has its different level of process and practice.

I would argue that the easiest of the three would be the Problem Management response to Major Incidents.  In these cases, root cause is almost always identified during the investigation & diagnosis phase of the response to the Incident.  Providing Problem Management with the clear timeline of events and actions performed in the resolution and any other details leading to root cause is generally performed.  A caveat here is that it is highly dependent on whether or not your Incident Management process is structured in a way to capture and track all lifecycle information during the Incident.

Conversely the most level of Problem Management would be that of incident tickets generated as the result of escalations or performance related incidents through the Service Desk.  These waters are often muddied because the are being generated from the user community which can be very skewed by perceptioin.  What may be an issue for one user may be acceptible to another.  Tracking down the reality is a very difficult process.  Combine that with not having a clear direction to travel to find the root cause can lead individuals down many different paths and throw up distractions away from the original Problem.  Sort of what I refer to as the “Mall Effect” where you intend on going in for one thing and end up wasting time going in and out of every other store eventually forgetting why you went to the Mall in the first place.

In terms of developing a Problem Management program and how ITIL helps describing the process, it is very focused on Problem Management as it applies to a Service Desk environment.  Known Error databases are housed and maintained, for the most part, at this layer of an organization.  That is, if you have one at all.  Problem Management outside of the Service Desk, can quickly become more Project Management like.  That is where some sort of Service model or description should be developed up-front and presented to leadership to help them understand that Problem Managment is not a single role, function or process, but should be approached in the various levels it can be utilized in.  Without that, description of services, it is easy for many to assume that everything is a Problem that needs the attention of Problem Management.  Not structuring the Problem Management organziation with a tiered model is a good way to set the program up for failure from day one.

Would be interesting to hear how Problem Management is approached in other organziations.  Sharing that sort of information would be of immense value in the development of any Problem Management program for those just starting out.

~ Rik Jones

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.