Spoiler alert: You may get more value out of ITSM after reading!
Much is written about the business value of ITSM and the failure of many organizations to achieve the full results available. In truth, many ITSM implementation failures start at the beginning of an initiative, when the people implementing ITSM don’t design processes in alignment with the business (from the start of the initiative). The result of IT working on improving itself is often the creation of processes that reflect the current state of IT operations rather than a transformative effort.
How can you tell if you’re organization is falling into this trap? Read on, taking a serious look at some of the danger signs.
Read the signs
Danger Sign #1: Does your Change Management process actually protect the business from unintended consequences of deploying changes or stop it from making progress? A well-designed change management process can help IT support the strategic initiatives of the business by helping to achieve them rapidly and without unintended impacts. How well does your process stack up?
- Is there a formal way for the business to engage IT in projects that involve technology?
- Is there a steering or executive committee process to review and prioritize projects?
- Is IT engaged in projects that start with the business, or are most projects IT projects?
- Are business projects considered an interruption to the work IT needs to perform?
As an outside consultant, I have an opportunity to see how a lot of IT organizations function. The topic of change management has come up for me recently. I have been working with an organization where the process is in the way of the project, particularly as a result of a heavy documentation load that even internal team members don’t understand. It doesn’t work if people cannot understand and manage the process.
Danger Sign #2: Do you treat all system issues the same? If the organization has not yet defined the business services that IT supports and has established business-focused Service Level Agreements, it may be said that IT uses a “one size fits all” approach to prioritizing incidents. The problem with this approach is that it doesn’t really align with business needs. IT runs the risk of working on less critical service interruptions before addressing those that actually impact the business more heavily.
It’s amazing how many organizations I work with that don’t really have defined and publicized Service Level Agreements. They have some targets that can be set up in a tool and measured, but the business has never agreed to these service levels. Even more interesting is that some of these organizations have well-funded ITSM implementations underway but have missed some of the basics.
Danger Sign #3: Is IT able to communicate the cost of operating a service by user, per month? In other words are you able to provide the same level of transparency as an external service provider? Inability to do this puts IT at a disadvantage, not understanding that they are actually in silent (or secret) competition with third party providers, cloud providers and other businesses that are able to sell well-defined services to the organization. If IT cannot communicate what services cost to operate and the value delivered to the business as clearly as the competition, they risk replacement by the competition.
Danger Sign #4: Failing to achieve balance: A strong, well-aligned IT organization achieves a level of balance between successful operation and strong business alignment. They are able to maintain stable operations while responding appropriately to the business’ need for changes to be made to a system. A really strong organization has the ability to sustain a heavy change load successfully, while still meeting service levels for performance and availability. When an organization cannot execute changes successfully, without impacting business operations, they are likely struggling with configuration management, risk assessment and missing a general understanding of the infrastructure. Thus, they have a heavy focus on operations but don’t put enough time into understanding the environment well enough to execute change successfully.
What can you do?
If you’re seeing some of these danger signs, there are some basic areas you can spend some time addressing:
- Conduct a survey of process effectiveness: look for processes that take too long to manage, from the standpoint of the business, IT and the process owners and then create an improvement program for any processes that need adjustment
- Define your business services, working with the business. This will support the next few items on the list
- Draft and negotiate service level agreements and put a practice in place to manage these
- Build your CMDB or improve on it: you need to know and understand your operational environment to be effective at Change Management, Problem Management and respond appropriately to incidents. It will also be required to get to the level of financial understanding required to understand the cost of delivering services
- Build a financial management practice with the goal of understanding the cost of delivering defined services on a per user/per month basis.
This is like saying “go implement ITSM” but consider it more of a roadmap to help you achieve the next level of maturity, focusing on several areas that directly impact the user and business experience. All too often, IT implements those ITSM processes that are operational or which protect operations (like change management) but either cannot gain the financial backing needed for some of these or lack the interfaces to the business needed to implement them. Focusing on these however, will ultimately increase alignment with the business and start increasing the business value of the implementation. It’s called IT Service Management for a reason, yet we still excel at IT Infrastructure Management, retaining our focus on the technology rather than the business drivers.
Latest posts by PhyllisDrucker (see all)
- Service Request Catalog: Failing to Fail - October 31, 2016
- Common IT Pitfalls in the Age of ITSM - October 17, 2015
- PII, PHI Who am I Anyway? A question of security management - May 31, 2015