The old riddle asks a simple but deep question: Which came first, the chicken or the egg? It’s not as easy a question as it seems, because a chicken would’ve had to lay the egg, and an egg would have had to hatch the chicken. Maybe there isn’t a right answer… In many ways, IT departments that implement Service Management policies have the same issue. These processes are meant to work together and build off one another, and you can’t fully succeed in one without the successful foundation that another provides. However, it can be hard to think about the best starting point in a Service Management program, because it may not be obvious.
It’s time to ask: Which process comes first, in Service Management? What’s the chicken, and what’s the egg?
Service Management’s Role Within IT
Service Management touches every aspect of IT, and a mature program can unlock untold benefits in collaboration and efficiency for your organization. Service Management should be an honest broker between disparate IT functions, providing sets of guidelines and the necessary collaboration to facilitate excellent service.
The Key Axiom of Service Management
Service Management is ultimately concerned with both the main aspects of a successful IT department: run the business (day-to-day), and change the business (visionary improvements). A winning Service Management program will form a basis for excellent day-to-day support for BAU issues, while also providing enough data and know-how to facilitate big improvements to the overall IT program.
Remember these 3 key points with Service Management:
If I define it, I can control and stabilize it.
If I control and stabilize it, I can measure it.
If I measure it, I can improve it.
The Chicken and the Egg Time
You must execute Service Management in a systematic way to make all the pieces fit together best. Such an implementation requires implementing processes in a certain order.
I have participated in Service Management rollouts in several organizations as a consultant and practitioner. From my front-row seat, I believe this is the best order of operations for a Service Management program:
Service Level Management
This is not a universally-held belief, but I believe it’s clear that Service Level Management is the firm foundation and beating heart of a successful Service Management program. This is because Service Level Management, at its core, has two components, which answer the first 2 issues of Service Management:
- The Service Catalog serves as a menu for what IT provides to the business (defining it, allowing for control and stabilization)
- Service Level Agreements (SLAs) allow you to define targets for the services IT provides, which allow you to measure whether IT is fulfilling its obligations to the business.
Everything in Service Management comes off of this. For example, if you are in a heavily-outsourced environment, you will not be able to hire third-party outsourcing providers with arrangements that are beneficial to your business unless you know what you actually expect those providers to give your company. If SLAs aren’t in place, you don’t know whether your partners are holding up their end of the bargain, and there’s no mechanism to hold them accountable if you don’t consider their service to be at acceptable levels.
Service Level Management is so powerful because it requires deep knowledge of the IT environment and strong interactions with both business stakeholders and service owners. The Service Catalog can’t be done in a vacuum, and all parties have to agree in order for an SLA to have any teeth to it.
You could decide to split up the 2 components of Service Level Management if needed, but the Service Catalog, at least, needs to be the first step of your Service Management program.
Incident Management and Service Desk
This is what most average users think of when they hear the phrase IT: the Service Desk and Incident Management. This is why Incident Management, through a Service Desk (or Help Desk, if you prefer that term), is stop 2 in your Service Management journey.
Incident Management is straightforward; the goal is to restore service as quickly as possible following an unplanned outage. Implementing Incident Management involves several key steps:
- Develop a procedure for receiving user calls.
- Have some kind of ticketing system to record and track those calls.
- Ensure the tickets quickly get to the proper team that can resolve the issue.
- Prioritize tickets based on Impact and Urgency.
While Service Level Management is #1 in your Service Management journey, Incident Management is #1A. Incident Management, especially your Service Desk/Help Desk, is the Face of IT, and in some cases this is the only interaction users will have with your IT department. It’s on you to make sure that impression is a good one!
Change Management seeks to document and review any alteration to the IT environment, known as a Change. This is an area in which lack of preparedness and maturity can really come back to bite you.
Without strong and enforced Change Management, IT becomes little more than the Wild West, with Changes being executed without any oversight or communication, preventing both input and any audit trail if something goes wrong.
For example, I worked in an organization that suddenly started having strange network issues at offices in a certain region of the world. After a week of calls with our network provider, they finally discovered that they had changed the entire vendor network backbone serving these offices, right before the issue started happening. Not having ready access to this caused frustration, time, and money that could have been put into fixing the issue more promptly.
Change Management should be a collaborative process with teeth behind it. The Change Advisory Board (CAB) should be put in place, with a Change Management leader, to hear all changes and have an open dialogue between stakeholders. Changes should be vetted and approved before technical teams are allowed to deploy them inside the environment.
Now we come to Problem Management, which some have called the hardest Service Management process to implement (no, I’m not just saying that because Problem Management is my thing…I promise).
There’s an easy analogy to look at Problem Management and Incident Management, which might seem like they’re the same (and, let’s be honest, we’ve all heard those 2 words used interchangeably in IT). Think of Incident Management as the firefighter and Problem Management as the arson investigator. Incident Management seeks to restore service as quickly as possible (put the fire out), and Problem Management seeks to identify the unknown, underlying root cause of the outage (investigate the fire).
Problem Management is so powerful because, first, it requires deep integration with other teams, because you will often need to pull many stakeholders together to investigate a root cause. There is also potential for environmental improvements, such as process changes or proactive remediation. For example, I was in Problem Management at a company that had 4 major incidents, all caused by port settings mismatches between the server and the switch to which it was connected. An audit revealed that another 50 servers in the environment also had these mismatches, and, by remediating this, we were able to prevent 50 potential major incidents.
As we see, Problem Management also has a dependency on Incident Management, because it’s the main feeder of the Problem Management process (though other feeders, like proactive trend analysis, also exist). When done right, Problem Management can improve IT’s functionality and prevent future incidents from occurring, in addition to its day-to-day root cause investigations.
Configuration Management is IT’s asset management, storing physical systems and software programs (Configuration Items) into a central database (called a Configuration Management Database, or CMDB).
Configuration Management should come next because your IT department has to know what’s in the environment. I remember performing a physical inventory assessment using an automated tool for an international client in my consulting days. They told us, for example, that they did not allow outside software downloads, and they were incredulous when we showed them that 20% of the PCs in their environment had iTunes software installed
Configuration Management has 3 component parts that are important with your Service Management program:
- Inventory Management allows you to understand what’s in your environment, and their attributes (e.g. PC models and the operating system(s) they run). Turbonomic can give you a leg up in Inventory Management by providing real-time physical inventory assessments.
- Configuration Management: Configuration Management allows you to take the inventory management to the next level, by adding in how the different components of the inventory relate to each other. For example, you could track what applications are on what server.
- Asset Management: Asset management adds the financial component to Inventory Management. It helps IT accurately track the cost of buying and using equipment.
Configuration Management has the strongest dependency on Service Level Management, which you should’ve executed at the beginning of your program. You have to be able to map the Configuration Items to the Services on the Service Catalog’s menu of IT.
Release Management is a vitally important function which carries with it a strong risk of potential issues. Simply put, Release Management seeks to make sure that any new or updated service released into the environment is ready to use without major issues.
Release Management has many components of DevOps, the new philosophy of rapid deployment and deep engagement that is eating the IT world. Good release management ensures that the business’ requirements are well known, the release has been adequately tested, and everyone is aware of any necessary downtime required to perform the release.
Release Management and Problem Management might be the most collaborative functions, touching many aspects of IT and the business. For example, a good Release Management strategy will involve the Project Management Office (PMO) where necessary, the development team, the business stakeholders, service support, and IT communications to ensure everyone is on the same page and those who need to know are informed.
Service Management is a powerful tool at the IT leader’s disposal, but the disparate processes involved can sometimes leave eager practitioners feeling overwhelmed. If you take a step-by-step process, and understand how the pieces fit together, you can have your chicken…and the eggs, too!